Start with the risk assessment, not the controls
The most common way to build a programme badly is to start from a list of controls, implement them competently, and write the risk assessment afterwards to match. The result is a programme that works and cannot explain itself, because the risk assessment has become a description of what was already built rather than the reason it was built.
Work in this order.
1. Scope the business you actually have
- List every product and service, including ones sold to a handful of customers
- List every delivery channel, separating face-to-face, remote and intermediated
- List every jurisdiction you take customers from, not just the ones you market in
- List every customer type, and note which are entities rather than individuals
- Identify who introduces customers to you, and what they verify before you see them
Evidence to leave: a single document a newcomer could read to understand what the business does. If this takes more than a page and a table, the business is probably more complicated than the programme assumes.
2. Assess the risk before designing anything
- Rate each of the four factors separately — customer, product, channel, jurisdiction
- State the methodology, including what makes something high rather than medium
- Identify the specific typologies you are actually exposed to, not a generic list
- Record where you deliberately accept risk, and who accepted it
- Have someone senior enough to be accountable sign it
Evidence to leave: the rating and the reasoning. A rating without reasoning cannot be reviewed, only re-guessed.
3. Design controls that trace back to a risk
- For each control, name the risk it addresses
- For each risk rated high, name the control that addresses it
- Set thresholds and state why those numbers rather than others
- Define what happens when a control fires, including who decides
- Define what happens when a control fails, including how you would know
Evidence to leave: a mapping between risks and controls, in both directions. Gaps in either direction are the finding.
4. Make the customer lifecycle explicit
- Identification and verification, before screening
- Screening against sanctions, PEP and adverse media data, after identification
- Risk rating, after screening and jurisdiction assessment
- Enhanced due diligence for anything rated high, before onboarding completes
- Ongoing monitoring, with a trigger list and a review cycle
- Exit, including what you keep and for how long
5. Build the oversight before you need it
- Name the accountable person, and check they have the authority the role implies
- Define the reporting line to the board, and what actually gets reported
- Set the independent review cycle, and confirm the reviewer is independent
- Define training by role, not one course for everyone
- Record training completion in a way that survives staff turnover
6. Test that it works, not that it exists
- Sample real files and check the evidence is there, not just the outcome
- Re-run a closed alert and see whether the decision is reconstructable
- Check a high-risk customer actually received enhanced due diligence
- Confirm ongoing monitoring has fired at least once, and something happened
- Look for controls that have never fired, and work out whether that is good news
Evidence to leave: the sample, the findings, and what changed as a result. Testing that finds nothing and changes nothing is not testing.
The question behind all of it
An assessor is rarely asking whether you have a control. They are asking whether you can show why you have that control, why it is set where it is set, and what you did the last time it fired. A programme built in the order above can answer all three from documents that already exist.