AML programs and the risk-based approach

Anti-money-laundering controls help identify and address illicit finance under the applicable legal framework. Countering terrorist financing overlaps with AML but can involve funds from lawful sources. A suspicious pattern is a reason to investigate, not proof of a particular crime.

The familiar placement, layering, and integration model can organize thinking about laundering, but real activity does not always follow a neat sequence. Digital movement may combine stages or skip an obvious cash entry. Use the model as a teaching aid. Build controls around the actual products, customers, and fund flows rather than forcing every case into three boxes.

Fraud and AML teams may examine the same transfer for different reasons. The fraud team may focus on whether the customer was deceived and whether a loss can be prevented. The AML team may focus on whether activity is consistent with the customer profile and whether the institution has an applicable reporting obligation. One team’s resolution can provide evidence to the other without settling its distinct decision.

This is why a shared data platform should preserve the underlying facts and maintain separate decision records. A refund to a customer does not by itself resolve an AML concern. An AML alert does not by itself prove fraud. The program needs controlled coordination between teams, including a clear route for urgent information and appropriate limits on confidential material.

Inside the mechanism. Program objectives, legal duties, risk assessment, monitoring rules, investigations, and reports are separate layers. A large alert count does not prove that the program covers the relevant activity. Map each control to a supported risk or obligation and identify the population it should reach. The operating record should show what the institution knew, what it did, and how it checked the result.

A concrete example. Fraud prevention and AML assessment can use the same transaction facts while serving different duties. Shared evidence does not make one team’s decision sufficient for the other. The case identifies 1,287 eligible records from a source population of 1,650. The required workflow completes for 1,248, but 19 completed records miss the illustrative internal target. Another 39 remain incomplete. Communication evidence covers 1,236 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. A fraud refund automatically closes the AML case. Retain separate scopes, owners, rationale, and reporting decisions with controlled coordination. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

Fraud prevention and AML assessment can use the same transaction facts while serving different duties. Shared evidence does not make one team’s decision sufficient for the other.

01Reference conditionDistinct financial-crime decisions↗02Failure and stressDistinct financial-crime decisions↗03Controlled responseDistinct financial-crime decisions↗

Separate the purpose from the machinery — the flow

1. 01ContextUnderstand the financial activity
2. 02ConcernIdentify a plausible illicit-finance risk
3. 03ResponseInvestigate under the applicable program

Separate the purpose from the machinery — the distinction

AML concern

• Possible handling of illicit proceeds

Terrorist-financing concern

• Purpose can matter even with lawful source funds

Program distinction

Fictional educational excerpt / Not for execution

Program distinction

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Funds sourceapparently lawful

   Does not resolve every concern

2. 2

   Purposeunresolved

   Separate investigative dimension

3. 3

   Conclusionnot established

   Suspicion is not a conviction

One simple stage model cannot cover every pattern

Separate the purpose from the machinery — control and failure modes

Control design

Assess source purpose and behavior in context. One simple stage model cannot cover every pattern.

Failure mode 1avoid

Require visible cash placement in every case. Digital activity can differ.

Failure mode 2avoid

Treat an alert as proof of crime. It is an investigative lead.

Failure mode 3avoid

Assume lawful source removes all financing risk. The intended use can still matter.

The term fintech does not determine a firm’s legal duties. Entity type, activities, licensing, products, geography, and partner arrangements matter. A bank, money services business, software provider, and marketplace may face different direct obligations and contractual responsibilities.

Create an applicability register with the legal owner. For each duty, record the covered entity, activity, source, effective date, control, evidence, and owner. Do not copy a bank manual into every startup and call it complete. Equally, outsourcing work does not automatically remove duties that remain with the regulated institution.

Inside the mechanism. Applicability depends on the institution, activity, product, and jurisdiction. A fintech partner and its bank do not become interchangeable legal actors because they share a customer journey. Document the relevant duties and the operational division of work, then test the handoffs. A contractual allocation can support execution but should not be treated as an automatic transfer of every regulatory responsibility.

A concrete example. The product uses a fintech interface, a sponsor bank, and several service providers. The applicable duty follows the entity and activity, not the product’s marketing label. The case identifies 823 eligible records from a source population of 980. The required workflow completes for 798, but 12 completed records miss the illustrative internal target. Another 25 remain incomplete. Communication evidence covers 790 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. A vendor screening result is mistaken for completion of the institution’s entire program obligation. Map each applicable duty to the responsible entity, delegated task, evidence, and oversight. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

The product uses a fintech interface, a sponsor bank, and several service providers. The applicable duty follows the entity and activity, not the product’s marketing label.

01Reference conditionInstitution-specific duty map↗02Failure and stressInstitution-specific duty map↗03Controlled responseInstitution-specific duty map↗

Map duties to the actual institution — the flow

1. 01EntityIdentify the legal actor
2. 02ActivityMap the services it performs
3. 03DutyLink applicable requirements to owners

Map duties to the actual institution — the distinction

Direct obligation

• Applies to the entity under the law

Contractual task

• Work required by a partner agreement

Applicability register

Fictional educational excerpt / Not for execution

Applicability register

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Entityplatform subsidiary

   Specific legal actor

2. 2

   Activitypayment service

   Scope to analyze

3. 3

   Ownercompliance counsel

   Approves the duty map

Brand labels do not establish legal applicability

Map duties to the actual institution — control and failure modes

Control design

Determine scope before implementing the duty. Brand labels do not establish legal applicability.

Failure mode 1avoid

Apply all bank rules to every software vendor. The covered activity and entity matter.

Failure mode 2avoid

Assume a sponsor handles everything. Responsibilities may remain or be delegated by contract.

Failure mode 3avoid

Use an undated policy. Requirements change over time.

An AML risk assessment considers the business’s customers, products, channels, geographies, and other relevant exposure. Inherent risk describes exposure before considering controls. Residual risk describes what remains after evaluating the controls and their limits.

Do not calculate residual risk by subtracting arbitrary color scores. Document why a control reduces a specific risk and what evidence shows that it works. A new instant-payout feature changes the opportunity to detect and intervene, even if the customer base is unchanged. Revisit the assessment when the product or operating model changes.

A risk assessment becomes operational when it connects an exposure to coverage. For example, a product that introduces cross-border payouts changes counterparties, jurisdictions, data handoffs, and possible loss of information. The assessment should identify which existing controls still apply, which need adaptation, and which evidence will show that the new controls work. A document that lists risk categories without changing ownership, monitoring, or testing does little to improve the system. Product changes should update the assessment through the same governed process that updates the product.

Inside the mechanism. Assess the actual money flows: sources, destinations, expected counterparties, channels, currencies, volume, and the customer’s stated purpose. Consider what the institution can observe and where data is lost. Risk categories should lead to concrete evidence and controls rather than a static score with no operational meaning. A new product flow can change risk even when the customer profile and transaction amount remain familiar.

A concrete example. A cross-border payout feature changes parties, corridors, data handoffs, and operating volumes. The assessment should lead to observable changes in monitoring coverage. The daily source population is 8,400 items, but 168 are outside the completed monitoring run. The included population creates 296 hits and 243 unique cases. With 55 cases already open and capacity for 245, the queue closes at 53. Coverage, duplicate work, and staffing are separate causes; reducing one number does not prove that the overall control improved.

When the assumption fails. The new transfer type is absent from the old event filter. Reconcile the new population and verify that its evidence reaches the intended cases. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A cross-border payout feature changes parties, corridors, data handoffs, and operating volumes. The assessment should lead to observable changes in monitoring coverage.

01Reference conditionNew product risk assessment↗02Failure and stressNew product risk assessment↗03Controlled responseNew product risk assessment↗

Build the risk assessment from flows — the flow

1. 01Inherent exposureMap the uncontrolled loss or crime path
2. 02Control evidenceAssess design and operation
3. 03Residual riskExplain remaining uncertainty

Build the risk assessment from flows — the distinction

Control exists

• A policy or system is documented

Control works

• Evidence shows the intended coverage and action

Feature-change assessment

Fictional educational excerpt / Not for execution

Feature-change assessment

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   New featureinstant payout

   Shorter intervention window

2. 2

   Old controlnext-day review

   Timing mismatch

3. 3

   Residual concernpre-release gap

   Needs a revised design

A policy title does not prove coverage

Build the risk assessment from flows — control and failure modes

Control design

Tie control effectiveness to the specific risk. A policy title does not prove coverage.

Failure mode 1avoid

Subtract red from green numerically. Unjustified scoring can hide assumptions.

Failure mode 2avoid

Ignore product changes. The risk path may change.

Failure mode 3avoid

Count an installed vendor as complete mitigation. Operation and coverage need evidence.

A program needs accountable leadership, suitable policies, training, testing, and operational capacity according to the applicable framework. Governance is the mechanism that turns unresolved issues into decisions. An issue without an owner or due date can persist through several clean-looking reports.

Separate control operation from independent challenge where appropriate. Test both design and actual execution. A rule may be well written but receive only half the eligible transactions because of a data mapping error. Use end-to-end evidence from the source event through review and disposition. Training should address the work people actually perform.

Inside the mechanism. Governance needs decision authority, resources, escalation, and an independent way to test whether the design works. Testing should examine population coverage, rule execution, case delivery, investigation quality, and corrective action. A successful job run proves less than an end-to-end trace from a known source event to its intended control outcome. Track unresolved findings with owners and evidence of closure.

A concrete example. A control owner can explain the intended program while independent testing examines whether it actually works. Findings need an accountable remediation path. The case identifies 688 eligible records from a source population of 740. The required workflow completes for 667, but 10 completed records miss the illustrative internal target. Another 21 remain incomplete. Communication evidence covers 660 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. A repeated data gap is accepted as closed because the policy document was updated. Require evidence that the affected control and population now behave as intended. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A control owner can explain the intended program while independent testing examines whether it actually works. Findings need an accountable remediation path.

01Reference conditionGovernance and independent testing↗02Failure and stressGovernance and independent testing↗03Controlled responseGovernance and independent testing↗

Assign governance and testing — the flow

1. 01OwnAssign authority and resources
2. 02OperateExecute the defined controls
3. 03ChallengeTest design and actual coverage

Assign governance and testing — the distinction

Design effectiveness

• Control could address the risk

Operating effectiveness

• Control actually ran as intended

Coverage test

Fictional educational excerpt / Not for execution

Coverage test

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Eligible events1000

   Source population

2. 2

   Monitored events620

   Observed coverage

3. 3

   Gap380

   Missing data path to resolve

Well-written rules can still miss data

Assign governance and testing — control and failure modes

Control design

Test source-to-disposition coverage. Well-written rules can still miss data.

Failure mode 1avoid

Review only policy wording. Execution defects remain invisible.

Failure mode 2avoid

Close issues without evidence. The gap may persist.

Failure mode 3avoid

Train all roles with the same generic slide. Different tasks need different operational knowledge.

New products, partners, jurisdictions, and data feeds can change monitoring coverage and reporting needs. Use a change assessment before launch. Record which assumptions remain valid and which require new controls.

A change should include a test population, expected alerts, access checks, and an owner for unresolved findings. After release, compare expected and observed coverage. A silent feed is not evidence that customers became less risky. It may mean the integration stopped. Build health checks for event volume, field completeness, and queue delivery alongside the detection logic.

Inside the mechanism. Changes in products, partners, data schemas, customer mix, or legal requirements can invalidate earlier assumptions. Connect material changes to risk assessment and control review before relying on the old program configuration. A versioned change record should identify affected populations, tests, approval, deployment, and rollback or remediation. Monitoring after release must check business coverage as well as technical health.

A concrete example. A new vendor, business line, or rule change can alter the program’s inputs and responsibilities. Change review is part of the program rather than an annual paperwork event. The case identifies 920 eligible records from a source population of 1,260. The required workflow completes for 892, but 13 completed records miss the illustrative internal target. Another 28 remain incomplete. Communication evidence covers 883 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. A provider schema change removes a field used by several scenarios. Trace the dependency to affected controls, tests, cases, and any required correction. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A new vendor, business line, or rule change can alter the program’s inputs and responsibilities. Change review is part of the program rather than an annual paperwork event.

01Reference conditionProgram change management↗02Failure and stressProgram change management↗03Controlled responseProgram change management↗

Treat change as part of the program — the flow

1. 01AssessIdentify changed obligations and risks
2. 02TestVerify the new control path
3. 03ObserveConfirm live coverage after release

Treat change as part of the program — the distinction

No alerts

• May reflect low detected activity

No coverage

• May reflect a broken monitoring path

Launch coverage check

Fictional educational excerpt / Not for execution

Launch coverage check

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Expected events500 per day

   Illustrative baseline

2. 2

   Observed events0

   Possible feed failure

3. 3

   Actioninvestigate ingestion

   Do not celebrate fewer alerts

Silence can indicate a broken control

Treat change as part of the program — control and failure modes

Control design

Monitor the monitoring pipeline. Silence can indicate a broken control.

Failure mode 1avoid

Treat no alerts as proof of safety. Coverage may be absent.

Failure mode 2avoid

Launch without an applicability review. New duties can be missed.

Failure mode 3avoid

Leave test findings unowned. The release can carry known gaps.

Continue with Customer due diligence and beneficial ownership to follow the next part of the system. Use the glossary for terminology and risk mathematics for formulas and worked calculations.