From risk assessment to controls a supervisor can trace

Having a risk assessment and being able to show the line from it to the controls you actually run are two different things. The second is what a supervisor is looking for, and the regulations are unusually explicit about it.

The obligation is to identify, understand, manage and assess the crime risks in your business, proportionate to its nature and size, taking into account the risk-based approach and the results of the national risk assessment — and to document the identification and assessment process, retain the study, update it on an ongoing basis, and provide it to the concerned authorities on request.

Read the verbs. Only two of them are analytical. Document, retain, update and provide are all about whether the work survives contact with someone who asks.

The risk assessment is a document, not a state of mind

Because it must be retained and produced on request, a risk assessment that lives in a spreadsheet nobody has opened since it was built, or in the experienced judgement of one person, does not satisfy the sentence. The test is simple: if your supervisor asked this afternoon, what would you hand over, and would it be current?

Continuously update is where an assessment goes stale without anyone deciding that it should. An assessment dated two years ago describes a business that no longer exists. New products, new markets, new channels and new counterparty types all change the picture, and none of them updates the document by itself. The regulations make this concrete in one place: risks arising from new products, practices, delivery mechanisms and technologies must be identified and assessed before the product or technology is launched or used, not after.

Risk has to reach the controls

The regulations tie the two together in sequence: consider all relevant risk factors — customer, country and geography, product, service, transaction and delivery channel — before determining the overall level of risk and the appropriate mitigation measures. Risk assessment first, control design second, and the second follows from the first.

A risk assessment that rates a customer segment high, sitting alongside a control set that treats every customer identically, is not really two problems. It is one: the assessment has not reached the controls. The regulations make the connection explicit, so a programme where the two do not line up is difficult to explain in the order the regulations ask for.

The practical form of that connection is a mapping. For each risk you have identified, what control addresses it, who operates that control, how often, and what it produces. Where a risk has no control, that is a gap you have chosen to carry and should have recorded as such. Where a control addresses no identified risk, you are spending effort you have not justified.

Governance is named, not implied

Internal policies, controls and procedures must be approved by senior management, must enable the identified risks to be managed and mitigated, and must be reviewed and updated on an ongoing basis. Two things follow. Approval should be dated and attributable — a version and a name, not a general understanding that management is supportive. And the policies have to be proportionate to the nature and size of the business, which cuts both ways: a small firm running a bank's manual has not complied any more successfully than a large one running a template.

The regulations do not stop at writing policies down. They require the policies to be monitored in implementation, their effectiveness assessed, and enhancement where necessary — and they require an independent audit function whose job is to test whether the internal policies, controls and procedures are effective and adequate. A programme that has never been examined by anyone other than the people who run it is missing a named component, not just a nice-to-have.

Evidence is a design requirement

Records must be retained for not less than five years and made available to the concerned authorities promptly on request. Read alongside the risk obligation, this makes evidence a property of the control rather than a task after it.

A control designed without an output — a screening run that leaves no record, a review with no artefact — may well have worked, but there is nothing to show that it did. The regulations go further than requiring records to exist: they require them to be organised so that individual transactions can be reconstructed and financial flows traced. That is a design instruction, not a filing instruction.

One more that sits naturally here: where the compliance officer reviews a suspicious-transaction case and decides not to notify the Unit, the regulations require the reasons to be stated. The decision not to report is a recorded decision, not an absence of one. A programme that documents only what it escalated has half a trail.

It is also worth remembering that supervisory authorities run their own risk assessments across the populations they supervise, and set the frequency and intensity of supervision by reference to each firm's risk profile. Your file is read against a view of your sector that already exists. Being unremarkable in a high-risk sector is not the same as being low risk.

Three tests before you call it finished

This is ZLORYX's working method, not a statutory test. It has held up well, and we use it before we call a programme finished:

Could you hand the risk assessment over today, and is it current? Can you trace any one control back to a risk in that document, and any one identified risk forward to a control? And does every control leave something behind that someone other than its operator could read?

A programme that answers those three can be traced by a supervisor. One that cannot may still be a good programme — but it will be assessed on what it can show.