A Common Language, Still No Common Understanding: Defining Risk in Financial Crime Compliance

In my last blog, I argued that the EBA’s proposed Regulatory Technical Standards (RTS) for AML supervision revealed a deeper divide in the way risk is understood and applied by supervisors versus regulated institutions. The language is shared (risk-based, inherent risk, control effectiveness) but the grammar is different. Supervisors think in terms of prioritisation and triage; institutions must grapple with risk in operational detail. 

This divergence is not just a matter of methodology, it is a matter of meaning. When the same words are interpreted in different ways by supervisors, regulated entities, consultants, and technology providers, the resulting ambiguity is not just unhelpful. It is dangerous. It can obscure weak controls, incentivise box-ticking, and undermine efforts to build systems that genuinely prevent financial crime. 

If we are serious about aligning efforts, between firms, supervisors, and technology vendors, then we need to be serious about language. That starts with definitions. Not vague, conceptual gestures, but clear, working definitions that reflect how risk is experienced, mitigated, and measured in practice. 

This blog is a little more technical than others I have published in recent weeks. But clarity is not a luxury, it is a prerequisite for effectiveness. 

Defining the Core Concepts of Financial Crime Risk Management 

Let us set out the terms that underpin our own methodology and, we believe, should underpin the industry’s collective efforts moving forward. 

Threat: A method or vector by which a criminal actor may attempt to exploit the financial system to launder money, finance terrorism, or evade sanctions. 

Threats are external. They do not originate from within the firm, but rather from the criminal environment in which the firm operates. They might include cash-intensive businesses, shell company networks, jurisdictional exposure to sanctioned entities, or misuse of correspondent banking relationships. 

The UK National Risk Assessment and FATF typologies are key sources of threat intelligence. But firms must also develop their own threat profiles based on their products, services, and client base, as well as their own internal intelligence (such as due diligence, SARs and the outcome of other investigations). 

Risk: The possibility that a specific threat could materialise within the context of the firm’s operations, causing harm to the firm, its customers, or the financial system. 

Risk is contextual. It emerges where a threat intersects with a firm’s exposure, its customers, delivery channels, geographies, and product features. 

Importantly, we define risk at the level of risk events: specific scenarios in which the institution might be used to facilitate a financial crime. We believe these are the critical building blocks of an effective risk assessment. 

Risk Event: A plausible, discrete instance of financial crime exposure that reflects how a specific threat could manifest within a particular firm. 

Examples: 

• A customer using nominee shareholders to obscure beneficial ownership in a corporate onboarding scenario. 

• A correspondent client sending wires to high-risk jurisdictions with minimal payment transparency. 

• A politically exposed person (PEP) channelling unexplained wealth through investment products. 

Risk events are where risk becomes operational. They are the units that must be evaluated, mitigated, and monitored, not just categorised and scored. 

Risk Factor: An attribute or characteristic that increases the likelihood or potential impact of a risk event occurring. 

These are often confused with risk itself. Jurisdiction, customer type, delivery channel, these are factors, not risks. They must be assessed in relation to how they influence specific risk events, not just tallied up in abstract scoring models. 

Risk factors are inputs into understanding exposure. But on their own, they tell us very little about how criminals might exploit the firm, or what should be done to prevent that from happening. 

Control: A specific, defined mechanism designed to prevent, detect, or respond to a risk event. 

Controls must be discrete and testable. Vague references to “CDD procedures” or “screening systems” are not controls, they’re categories. Examples of actual controls include: 

• A system-generated alert that blocks onboarding when beneficial ownership is incomplete. 

• A periodic review trigger for high-risk customers after six months of inactivity. 

• A rule-based sanctions filter that flags outbound SWIFT messages to embargoed countries. 

Good controls are not just documented; they are embedded in processes, monitored for operation, and tied to risk events they are meant to mitigate. 

Control Effectiveness: The extent to which a control reduces the likelihood or impact of a specific risk event occurring, when tested in the context of that risk. 

Effectiveness is not the same as existence. A control may appear well-designed on paper but fail in practice, either due to poor implementation, limited scope, or a mismatch between the control and the risk. 

Effectiveness must be assessed in context. You cannot test control effectiveness in the abstract. You must ask: Is this control capable of preventing or detecting this specific risk event? 

Inherent Risk: The level of risk that exists before the application of any mitigating controls. 

This is the raw exposure, the outcome of threat and vulnerability, based on a firm’s specific profile. Crucially, inherent risk must be defined at the risk event level. If you aggregate it too soon, you lose insight into where controls are actually needed. 

Residual Risk: The level of risk remaining after considering the design and effectiveness of mitigating controls. 

Residual risk should be the output of an assessment process, not the input to management action. When residual risk scores are used as headline indicators for strategic decision-making, they obscure the detail required for effective remediation. 

In practice, it is more useful to focus on where control effectiveness is weak, rather than trying to calibrate a “final score.” 

Why This Matters Now 

Regulators are increasingly speaking the language of risk-based supervision. That is a good thing. But the pressure to standardise, and the lure of abstract scoring, can flatten the complexity that genuine risk management requires. 

By clearly defining our terms, we push back against the drift toward simplification and opacity. We want to create a shared foundation, one that technology vendors, internal audit teams, first-line business leaders, and regulators can all build on. 

This is not semantics. It is systems design. You cannot automate what you have not defined. And you cannot prevent what you have not properly understood. 

Final Thoughts: Risk Literacy as a Strategic Asset 

In a world of evolving threats and heightened scrutiny, risk literacy is no longer just the domain of compliance professionals. Boards, product owners, frontline teams, and (building on the EBA’s recent opinion on the ML/TF risk landscape) even technologists need to understand what risk really means, and how it is mitigated in practice. 

If we continue to speak past one another, using the same words with different meanings, we will keep building systems that look compliant but fail to prevent harm. 

Clarity of language is the first step toward clarity of purpose. And in the fight against financial crime, that is a step we cannot afford to skip.