Compliance program advisory
KYC and KYB, enhanced due diligence, sanctions screening, adverse media, fraud
investigation, transaction monitoring, and compliance program design.
The work is deciding which controls a business actually needs, and how strong each one
has to be. A risk-based program is not a lighter program. It is one where every
control can be traced back to a risk that was written down, and where the controls that
matter are strong because the assessment said so.
That same discipline decides how identity is verified. Most onboarding still rests on a
document and a selfie. We look at what the session itself already tells you, and at
which of those signals deserve to carry weight in the decision.
Every regime asks a program to stand up the same handful of things. What differs is
how far each has to go, and that is the judgment being bought:
- An accountable officer, and what they are actually
accountable for
- A risk assessment the controls can be traced back to
- Written policies and procedures that match what the
business does, not what the template assumed
- Training, and a plan for delivering it
- A review that tests whether any of it works
How that changes a KYC decision › Risk and Compliance product advisory
Which risk and compliance tooling you actually need, sized to your stage, budget and
product. A seed-stage startup and a scaling payments business need different things,
and the common failure is buying far too much or far too little.
KYC and identity, transaction monitoring, fraud, sanctions screening, case management,
regulatory reporting, and whatever else your obligations put in front of you.
Build versus buy. The decision is rarely about
features. It is about what you will still be maintaining in three years, which
obligations you cannot outsource, and whether your need is a product at all or a
process someone has to own. We work that through before anyone writes a
requirement.
Requirements and scope. Most failed compliance
implementations were scoped from a vendor demo rather than from the obligations. We
write the requirement from the risk assessment, so what you are buying can be traced
back to something you are actually required to do.
Selection, and then delivery. Running the selection is
the short part. We stay through implementation as the product manager for it: the
integration, the tuning, the hand-over to the people who will operate it, and the
evidence that it does what the requirement said. A tool that is bought and never
bedded in is worse than none, because the program now assumes it works.