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.

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.

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.

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.

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.

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.