---
title: "FinCrimeOps"
slug: fincrimeops
category: industry
term_status: niche
evidence_status: partially_verified
summary: "FinCrimeOps (financial crime operations) is the team and workflow that turn anti-money-laundering, sanctions and fraud obligations into daily decisions: check customers, screen names, work alerts, investigate, report suspicion to the authorities on time, and prove every decision later."
audience: [Beginners, FinCrime analysts and team leads, MLROs and compliance officers, Engineers building screening and monitoring, Fintech founders and leaders]
last_verified: 2026-10-23
key_takeaways:
- "\"FinCrime Operations\" is a real team and job title at fintechs and banks, but not a defined discipline; the practice behind it is AML/CFT, sanctions and fraud work set by the FATF standard and national law."
- "The unit of work is the alert that becomes a case: every alert ends in a documented close, an escalation, or a report to the financial intelligence unit, against a legal clock."
- "Tipping-off rules shape the whole workflow: the people who talk to the customer must not reveal that a suspicion report exists or is being considered."
- "Alert volume is not effectiveness. Measure useful reports, missed risk (below-the-line tests, referrals with no prior alert) and timeliness, not alerts closed per hour."
- "Detection has to keep pace with the business: the large recent enforcement cases (TD Bank, Starling, Monzo) were about controls that stood still while products and customers grew."
- "Every legal rule on this page names its jurisdiction and date: in 2026 the UK amended its Money Laundering Regulations (in force 30 June), the US proposed new programme rules, and UK payment regulation was moving to the FCA. It is orientation, not legal advice."
related: [fintechops, riskops, complianceops, decisionops, modelops, privacyops, legalops, responseops]
---
## What FinCrimeOps is
### In 30 seconds
**FinCrimeOps (financial crime operations) is the operational side of fighting money laundering, terrorist financing, sanctions
evasion and fraud inside a bank, payment company or other regulated business.** Policy says what must happen; FinCrimeOps does it
daily: it checks customers, screens names against sanctions and politically exposed person (PEP) lists, works alerts, investigates,
reports suspicion to the national financial intelligence unit (FIU) on time, and keeps records that reconstruct every decision.
In one sentence: **FinCrimeOps turns "know your customer and report suspicion" into a measured, auditable production line,
without telling the suspect.**
For analysts, team leads, money laundering reporting officers (MLROs), screening and monitoring engineers, and fintech founders.
Sources last verified **2026-10-23**.
::: warning Not legal advice
Every legal statement names its jurisdiction and the date checked. Rules differ by country, institution type and over time.
:::
### At a glance
| Question | Answer |
|---|---|
| Goal | Detect and report financial crime effectively and on time, and defend every decision |
| Who does it | Analysts, investigators, team leads, quality assurance (QA), the MLRO or BSA officer, detection engineers |
| Scope (this page) | Customer due diligence (CDD/KYC), screening, monitoring, cases, reporting, exits, law-enforcement requests, tuning |
| Out of scope | Ledgers ([FinTechOps](../fintechops/)); risk method ([RiskOps](../riskops/)); audit evidence ([ComplianceOps](../complianceops/)); rule engines ([DecisionOps](../decisionops/)); model validation ([ModelOps](../modelops/)) |
| Legal anchors | FATF Recommendations; US Bank Secrecy Act rules; UK Proceeds of Crime Act 2002, Money Laundering Regulations 2017 (amended 2026) and FCA rules; EU AML Regulation from 2027 |
| Key outputs | Risk ratings, dispositions, case files, suspicious activity/transaction reports (SAR/STR), exits, management information (MI) |
| Term status | **Niche**: a team and job-title family, not a standardised discipline |
### The name: a team title, not a discipline
"FinCrime Operations" is a working label from job titles and vendor marketing, not from law or standards:
- **Employers use it for a team.** Wise describes a senior analyst role "in our FinCrime Operations team" that handles
law-enforcement requests;[^wise-le] a team lead needs expertise in "KYC/AML/Fraud/Screening".[^wise-lead] Monzo's job board in
October 2026 listed a "Senior FinCrime Operations Manager".[^monzo-jobs]
- **Vendors use it for products.** Fenergo launched a "FinCrime Operating System" with AI agents in May 2025, according to trade
coverage:[^fenergo] marketing, not a definition.
- **No standard defines "FinCrimeOps".** We found no standards body, association or certification using the label. The
obligations come from the Financial Action Task Force (FATF) Recommendations, which "set an international standard, which
countries should implement through measures adapted to their particular circumstances",[^fatf-page] and from national law.
So this page uses "FinCrimeOps" for **the operating team and its workflow**, and teaches the practice under its standard names:
anti-money laundering and countering the financing of terrorism (AML/CFT), sanctions compliance and fraud operations.
### What FinCrimeOps is not
- **Not the policy owner.** The MLRO (UK) or BSA officer (US) and the compliance function set policy and risk appetite; operations
executes it and feeds evidence back.
- **Not fraud-only or AML-only.** Some firms combine the two, others separate them
([Fraud and AML](#fraud-and-aml-same-team-different-duties)).
- **Not this Atlas's [ComplianceOps](../complianceops/) or [RiskOps](../riskops/)**, though some firms call this team "Compliance
Operations" and fraud vendors sell "RiskOps" platforms.
- **Not law enforcement.** The firm reports suspicion; FATF Recommendation 21 protects good-faith reporting "even if they did not
know precisely what the underlying criminal activity was".[^fatf-recs]
### The problem it solves
Recent enforcement shows three failures:
1. **Controls stop matching the business.** TD Bank's US subsidiary pleaded guilty in October 2024. The US government says it left
92% of its transaction volume unmonitored from January 2018 to April 2024, added no new monitoring scenarios from at least 2014
to late 2022, worked under a "flat cost paradigm", and launched products such as Zelle without adequate monitoring.[^td]
2. **Onboarding outruns checks.** The UK Financial Conduct Authority (FCA) fined Starling Bank £28,959,426 in October 2024: since
2017 it had screened customers against only "a fraction of the full list" of sanctioned persons while customers grew from about
43,000 to 3.6 million, and it opened more than 54,000 accounts for 49,000 high-risk customers despite an agreed
restriction.[^starling] The FCA fined Monzo £21,091,300 in July 2025 because its controls "failed to keep pace with its customer
and product growth".[^monzo]
3. **Volume replaces value.** The Wolfsberg Group of global banks wrote in 2024 that growing SAR/STR volumes do not contribute
proportionately to effective outcomes, and that alert volumes and alert-to-SAR ratios measure quantity, not usefulness.[^wolfsberg1]
Good looks like: every product covered, every alert reasoned, useful reports on time, and a team that knows what it misses.
## Vocabulary, origins and neighbours
### Glossary and mental model
| Term | Meaning |
|---|---|
| CDD / KYC | Customer due diligence: identify and verify the customer and beneficial owner, understand purpose, monitor ongoing[^fatf-recs] |
| Beneficial owner | The natural person who ultimately owns or controls a customer, or on whose behalf a transaction is made[^fatf-recs] |
| EDD | Enhanced due diligence for higher risk, e.g. source of wealth (how the person became rich) and of funds (where this money came from) |
| PEP | Politically exposed person; family members and close associates count too[^fatf-recs] |
| Screening | Matching names and identifiers against sanctions, PEP and adverse-media lists |
| Transaction monitoring (TM) | Rules or models that flag unusual activity, such as "money in, 90% out within 48 hours" |
| Money mule | An account holder who moves criminal money for others, knowingly or not |
| SAR / STR | Suspicious activity / transaction report to the FIU: FinCEN (US) or the UK FIU in the National Crime Agency (NCA) |
| CTR, structuring | US report for cash over $10,000 a day; structuring (splitting cash to evade it) is unlawful[^fincen-faq] |
| Nominated officer | UK: receives internal suspicion reports and decides whether they give rise to suspicion[^mlr21] |
| Tipping off | Revealing that a suspicion report is being or has been filed, or that an investigation is contemplated or under way |
| DAML | UK "defence against money laundering": asking the NCA to proceed with a transaction after disclosure[^nca] |
| Typology / scenario | A laundering or fraud pattern / its detection logic |
| Below-the-line (BTL) testing | Lowering thresholds below production to see what would be missed[^wolfsberg1] |
| BaaS / programme manager | A fintech offering accounts or cards on a partner bank's licence |
**Mental model: a funnel with two exits and a wall.** Signals enter (alerts, hits, referrals, requests). Most leave by the first
exit, closed with a reason; a few by the second, a report to the FIU. A **wall** runs through the middle: nothing inside may leak
to the customer. The craft is a funnel narrow enough to work, wide enough not to miss crime, with the wall intact.
### Origins and evolution
The work is older than the label: national law implements the FATF Recommendations (2012 text, "as amended June
2026").[^fatf-page] In this Atlas's reading, two shifts produced "FinCrime Operations" teams: digital onboarding at scale, and a
move from technical compliance to effectiveness, which Wolfsberg traces to FATF's 2013 methodology.[^wolfsberg1] We found no
documented origin of the label.
### How FinCrimeOps relates to other Ops
[FinTechOps](../fintechops/) moves money correctly; FinCrimeOps stops it being abused.
::: figure FinCrimeOps and its neighbours in the money chain
```mermaid
flowchart TB
FT["FinTechOps
money moves
exactly once"]:::neutral
FC["FinCrimeOps
detect, investigate,
report abuse"]:::core
RK["RiskOps
appetite and risk method"]:::neutral
CO["ComplianceOps
audit evidence"]:::neutral
DO["DecisionOps
rule and model engines"]:::neutral
MO["ModelOps
model validation"]:::neutral
PR["PrivacyOps
personal-data rights"]:::neutral
FIU["FIU and
law enforcement"]:::risk
FT -->|"payments, events"| FC
RK -->|"risk method"| FC
DO -->|"runs the logic"| FC
MO -->|"validates"| DO
FC -->|"reports, responses"| FIU
FC -->|"control evidence"| CO
PR -. "access vs tipping-off" .- FC
classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
```
Text equivalent: FinTechOps feeds FinCrimeOps payments and events; RiskOps supplies the risk method; DecisionOps runs the logic,
which ModelOps validates. FinCrimeOps reports to the FIU and law enforcement and sends control evidence to ComplianceOps. A dotted
line to PrivacyOps marks the data-access versus tipping-off tension.
:::
| Neighbour | Shared ground | FinCrimeOps owns | The neighbour owns |
|---|---|---|---|
| [FinTechOps](../fintechops/) | Payment data | Abuse detection, holds | Ledger correctness, settlement |
| [RiskOps](../riskops/) | Fraud vendors' "RiskOps" | Risk decisions under AML law | Risk appetite, acceptance, quantification |
| [ComplianceOps](../complianceops/) | "Compliance operations" title | Working alerts and cases | Control libraries and audit evidence |
| [DecisionOps](../decisionops/) | Rules and scores | What a rule must detect; dispositions | Engine, testing, release |
| [ModelOps](../modelops/) | Monitoring models | Using model outputs; feedback on quality | Model inventory, validation, approval |
| [PrivacyOps](../privacyops/) | Customer data | Investigation records | Data-subject rights and AML exemptions |
| [ResponseOps](../responseops/) | Incidents | Financial-crime incidents (e.g. mule networks) | Security incident response |
| [LegalOps](../legalops/) | Legal requests | Producing records for law enforcement | Legal advice, litigation, outside counsel |
## Principles and operating model
### Charter and principles
::: note A proposal, not a standard
This charter is this Atlas's proposal; no body publishes a "FinCrimeOps charter".
:::
**Mission.** Keep products from financial crime, report usefully and on time, and show why every decision was made.
1. **Risk-based, written down.** FATF calls the risk-based approach "an essential foundation" of the regime;[^fatf-recs] every
threshold and exception traces to a documented risk assessment.
2. **Every alert ends in a decision with a reason, on a visible clock.** Nothing silently ages out.
3. **The wall holds.** Customer contact follows approved scripts; SAR data is need-to-know.
4. **Coverage follows the product.** FATF expects new-product risk assessment "prior to the launch";[^fatf-recs] this Atlas adds:
no launch without screening and monitoring coverage.
5. **Measure usefulness and misses, not just volume.**[^wolfsberg1]
6. **Humans own decisions; machines prioritise.**
**Non-goals.** Zero false positives (that means missed crime); "defensive" filing;[^wolfsberg1] judging guilt.
### Fundamentals: the five controls
Every FinCrimeOps function runs some version of five controls, mapped here to the FATF Recommendations:[^fatf-recs]
| Control | FATF anchor | What operations does | Output |
|---|---|---|---|
| Customer due diligence | R.10, R.12 (PEPs) | Verify identity and beneficial owners, record purpose, rate risk, EDD | Customer with a risk rating |
| Sanctions screening | R.6, R.7, R.16 | Screen customers and payments; resolve hits; freeze and report | Cleared hit or frozen asset |
| Monitoring | R.10(d) ongoing due diligence | Work alerts, referrals and external requests | Closed alert or case |
| Investigation and reporting | R.20, R.21 | Investigate, decide, file, avoid tipping off | SAR/STR or documented no-file |
| Records and feedback | R.11 | Transaction records five years; CDD records five years after the relationship ends; tune | Reconstructable file |
In the US, the bank AML programme rule requires internal controls, independent testing, a designated compliance individual,
training, and risk-based ongoing CDD, the "five pillars" in industry shorthand.[^cfr210] On 7 April 2026 FinCEN proposed to
"fundamentally reform" programme rules: an effectiveness focus, design ("establishment") separated from implementation
("maintenance") deficiencies, and the national AML/CFT Priorities built in.[^nprm] As of 23 October 2026 comments have closed (9
June) and the Federal Register lists no final rule.[^nprm-fr]
### Roles, ownership and RACI
L1 analysts triage; L2 investigators build cases; team leads own queues; independent QA samples decisions; detection engineers
tune scenarios; customer operations uses scripts. The accountable officer depends on jurisdiction (as of October 2026):
- **UK, businesses covered by the Money Laundering Regulations 2017 (MLRs), except a sole practitioner with no staff:** a
**nominated officer**, and, where appropriate to size, a board-level or senior manager responsible for compliance; e-money issuers
and payment service providers also appoint an individual to monitor and manage AML compliance.[^mlr21]
- **UK, FCA-authorised firms within SYSC 6.3:** an **MLRO** with "authority and independence".[^sysc] Payment and e-money firms
should check whether SYSC 6.3 applies; the MLRs duty applies either way.
- **US banks:** a designated individual (the **BSA officer**) responsible for day-to-day compliance.[^cfr210]
**This RACI is a proposal** (R/A/C/I = responsible, accountable, consulted, informed; "MLRO" = whichever officer applies;
detection engineering makes scenario changes).
| Activity | L1 | L2 | Team lead | MLRO/BSA officer | Customer ops |
|---|---|---|---|---|---|
| Disposition of a TM alert | R | C | A | I | – |
| Sanctions true-match freeze | C | R | C | A | I (script only) |
| SAR/STR decision | – | R (recommend) | C | A | – |
| Customer exit after investigation | – | R | C | A | R (notice, scripted) |
| Scenario threshold change | C | C | C | A (approve) | – |
| Law-enforcement information request | – | R | C | A | – |
### The customer lifecycle
Customers meet the controls repeatedly, not only at onboarding.
::: figure The customer lifecycle through financial crime controls
```mermaid
flowchart TB
A["Application"]:::neutral --> B["CDD and screening"]:::core
B --> C{"Risk rating"}:::decision
C -->|"standard"| D["Onboard"]:::core
C -->|"high"| E["EDD and senior approval"]:::core
C -->|"cannot complete CDD"| X["Decline; consider a report"]:::risk
E --> D
D --> F["Ongoing monitoring
TM, rescreening, referrals"]:::core
F --> G{"Trigger or periodic review"}:::decision
G -->|"no concern"| F
G -->|"concern"| H["Investigation"]:::risk
H -->|"explained"| F
H -->|"suspicion"| I["Report to FIU"]:::risk
I --> J{"Retain or exit?"}:::decision
J -->|"retain, monitored"| F
J -->|"exit"| K["Exit with scripted notice"]:::neutral
classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
```
Text equivalent: After CDD and screening, standard risk is onboarded, high risk needs EDD and senior approval, and failed CDD means
decline and consider a report. Monitored customers hit a trigger or review: no concern returns to monitoring; concern opens an
investigation, explained (back to monitoring) or reported, then retained or exited.
:::
If CDD cannot be completed, FATF R.10 says do not open (or end) the relationship and "consider making a suspicious transactions
report".[^fatf-recs] A report need not mean exit: an abrupt exit right after one can itself look like a tip-off. The MLRO decides
and records why.
### Operating model and governance
- **Daily:** queue stand-up (backlog by age, sanctions hits first). **Weekly:** QA results, calibration, capacity plan.
- **Monthly:** MI pack to the MLRO (volumes, ageing, timeliness, QA, reports, feedback, tuning).
- **Quarterly:** scenario performance and below-the-line results; coverage check against new products.
- **Annually:** firm-wide risk assessment; independent testing; MLRO report to the board.
## Architecture and workflow
### Reference architecture: from signals to reports
Engines are replaceable; the case record, clocks and feedback loop make the operation defensible.
::: figure Reference architecture of a financial crime operation
```mermaid
flowchart TB
S1["Customer and
ID data"]:::neutral
S2["Payment and
ledger events"]:::neutral
S3["Sanctions, PEP,
media lists"]:::neutral
E1["Screening
engine"]:::core
E3["Customer
risk scoring"]:::core
E2["Monitoring
rules, models"]:::core
Q["Alert queue
priority, clocks"]:::core
S4["Referrals and
LE requests"]:::neutral
CM["Case management
evidence, decisions"]:::core
D{"Decision"}:::decision
O1["FIU report"]:::risk
O2["Hold, restrict
or exit"]:::risk
O3["QA, MI and
tuning backlog"]:::neutral
S1 --> E1
S2 -->|"payment screening"| E1
S3 --> E1
S1 --> E3
E3 --> E2
S2 --> E2
E1 --> Q
E2 --> Q
Q --> CM
S4 --> CM
CM --> D
D --> O1
D --> O2
D --> O3
O3 -. "tuning changes" .-> E2
classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
```
Text equivalent: The screening engine checks customer data and, before execution, payment events against sanctions, PEP and media
lists. Customer risk scores parameterise monitoring of payment events. Alerts from both engines enter a queue with clocks and,
with referrals and law-enforcement (LE) requests, reach case management. Decisions lead to an FIU report; a hold, restriction or
exit; and QA/MI, which sends tuning changes back to monitoring (dotted).
:::
Design choices that matter more than vendor choice:
| Choice | Option A | Option B | What decides it |
|---|---|---|---|
| Screening timing | Real-time, blocks the payment | Batch after the event | FATF R.16 expects payment firms not to deal with designated persons,[^fatf-recs] so screen payments before execution; rescreen customers after list updates |
| Monitoring style | Rules (thresholds, typologies) | Models (scores, anomalies) | Explainability, data volume, validation capacity ([Automation and AI](#automation-and-ai)) |
| Case system | Part of the detection suite | Separate case tool | Whether many engines and referrals must meet in one record |
| Detection logic owner | FinCrime team | Central decision platform ([DecisionOps](../decisionops/)) | Release discipline, testing, change audit trail |
### End-to-end workflow: alert to report
::: figure Alert-to-report workflow with the tipping-off wall
```mermaid
flowchart TB
A["Alert, hit or referral"]:::neutral --> B["L1 triage
enrich, check history"]:::core
B --> C{"Explained by
known facts?"}:::decision
C -->|"yes"| D["Close with reason
QA samples it"]:::core
C -->|"no"| E["L2 case
evidence and timeline"]:::core
E --> F{"Need facts from
the customer?"}:::decision
F -->|"yes"| G["Scripted request
no hint of suspicion"]:::risk
G --> E
F -->|"no"| H["Draft narrative and
recommendation"]:::core
H --> I{"MLRO: suspicion?"}:::decision
I -->|"no"| J["Record no-report
decision per policy"]:::core
I -->|"yes"| K["File SAR/STR
before the deadline"]:::risk
K --> L{"Transaction pending?"}:::decision
L -->|"UK: seek DAML"| M["Hold until notice or
moratorium ends"]:::risk
L -->|"no"| N["Retain or exit decision"]:::decision
M --> N
classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
```
Text equivalent: L1 triage closes an alert with a reason (QA samples it) or escalates to an L2 case, which may send the customer a
scripted request with no hint of suspicion. A narrative and recommendation go to the MLRO: no suspicion means a recorded no-report
decision; suspicion means a SAR/STR before the deadline, a UK DAML hold if a transaction is pending, then retain or exit.
:::
**Happy path.** Most alerts close at L1 with a specific reason ("salary from employer on file; amount within expected range");
FinCEN's 2025 FAQs say "a short, concise statement … will likely suffice" where a no-file decision is documented.[^fincen-faq]
#### Exception paths and the tipping-off wall
In the UK regulated sector it is an offence to disclose that a disclosure has been made, or that an investigation is contemplated,
where that is likely to prejudice an investigation (Proceeds of Crime Act 2002, s.333A, as of October 2026).[^poca333a] US rules
make a SAR and "any information that would reveal the existence of a SAR" confidential.[^cfr320] Fraud teams, complaint handlers
and data-access responses are typical leak points. The wall in practice:
::: figure Handoffs when a customer asks why a UK payment is held
```mermaid
sequenceDiagram
participant C as Customer
participant CO as Cust. ops
participant L2 as L2
participant M as MLRO
participant N as NCA
C->>CO: Why is it held?
CO->>L2: Query to case
L2->>CO: Script, RFI
CO->>C: Routine checks
Note over C,CO: No mention of reports
C->>CO: Documents
CO->>L2: Add to case
L2->>M: Narrative
M->>N: DAML request
N->>M: Consent, refusal or silence
M->>L2: Release or hold
L2->>CO: New script
```
Text equivalent: Customer ops logs the customer's question to the case; L2 returns an approved script and information request,
sent as "routine checks". Documents flow back to the case. The MLRO discloses to the NCA with a DAML request and, after consent,
refusal or seven working days' silence, tells L2 to release or hold; customer ops only ever gets scripts.
:::
- **A sanctions true match.** Freeze, then report to OFAC (US) or OFSI (UK) on their clocks
([comparison](#sanctions-ownership-and-reporting-us-and-uk)).
- **Urgent ongoing laundering.** A US bank must notify law enforcement immediately by telephone, in addition to filing the
SAR.[^cfr320]
- **Activity continues after a report.** US continuing-activity SARs on a 90-day cycle are optional, as the October 2025
FAQs confirm.[^fincen-faq]
### Regulatory clocks (as of 23 October 2026)
| Jurisdiction | Clock | Rule | Source |
|---|---|---|---|
| International | Report suspicion "promptly"; report attempted transactions "regardless of the amount" | FATF R.20 and its Interpretive Note | [^fatf-recs] |
| International | Freeze designated persons' assets "without delay" | FATF R.6 (UN sanctions) | [^fatf-recs] |
| US (banks) | SAR within 30 calendar days of initial detection, up to 60 if no suspect identified; mandatory from "at least $5,000" | 31 CFR 1020.320 | [^cfr320] |
| US (banks) | The clock starts when review finds reason to suspect, not at the alert; reviews take a reasonable time | FFIEC examination manual | [^ffiec-sar] |
| UK | DAML notice period: seven working days starting the first working day after disclosure; moratorium 31 days from a refusal notice | POCA 2002 s.335 | [^poca335] |
| EU | AML Regulation (EU) 2024/1624 applies from 10 July 2027; AMLA direct supervision planned from 2028 | AMLR; AMLA | [^arendt][^ec-aml][^amla] |
Other US institution types have their own SAR sections, listed in FinCEN's FAQ;[^fincen-faq] sanctions clocks are in the
[US/UK table](#sanctions-ownership-and-reporting-us-and-uk).
[Lab 3](#lab-3-advanced-regulatory-clocks-in-the-case-record) codes these clocks.
## Practices, frameworks and tools
### Core practices and playbooks
The [five controls](#fundamentals-the-five-controls) and [RACI](#roles-ownership-and-raci) say who does what; these playbooks
cover the steps that most often go wrong.
#### Playbook: due diligence, EDD and periodic review
UK references are to the MLRs as of October 2026.
1. **Rate risk from recorded inputs.** CDD must reflect your risk assessment and the case: purpose, size of assets or
transactions, regularity and duration.[^mlr28] Store the inputs (customer type, geography, product, channel, PEP status) with
the rating so a reviewer can recompute it.
2. **Verify beneficial owners yourself.** The companies register alone does not satisfy the duty; record every step before
treating a senior manager as the beneficial owner.[^mlr28]
3. **Apply EDD to high risk**: PEPs and their families and close associates, false documents, unusual transactions, listed
countries, and whatever your assessment rates high.[^mlr33] FATF's EDD examples include source of funds or wealth, senior
approval and enhanced monitoring.[^fatf-recs] *Evidence standard (this Atlas's proposal):* documents showing how wealth arose
(sale contract, payslips, probate); a self-declaration starts the file.
4. **Review by risk and by trigger.** No rule fixes a cadence: FATF expects due diligence on existing customers "on the basis of
materiality and risk";[^fatf-recs] the MLRs add changed circumstances such as new owners or inconsistent transactions.[^mlr27]
Illustrative cycle: high risk yearly, medium every two to three years, low on triggers.
5. **Accept when** every high-risk customer has an approved EDD record and review date, overdue reviews appear in MI, and
non-responders are restricted or exited under policy, with a report considered.
::: note UK amendments in force from 30 June 2026
S.I. 2026/621, made 9 June 2026, amended the MLRs.[^si621] The mandatory country trigger for EDD now covers only FATF's "call for
action" list, no longer the increased-monitoring ("grey") list;[^mlr33] in this Atlas's reading, grey-list exposure now goes
through your risk assessment, so record why each is or is not high risk. Transaction EDD applies when "unusually complex or
unusually large in each case given the nature of the transaction". Euro thresholds became sterling (occasional-transaction CDD
£12,000, formerly 15,000 euros); pooled accounts gained due diligence rules; cryptoasset correspondent EDD starts 1 February 2027.
:::
#### Playbook: discounting a screening hit
1. **Compare identifiers, not just names.** Date of birth, nationality, address, registration number, and for banks the SWIFT
Business Identifier Code. OFAC lists missing identifiers such as BICs and unhandled alternative spellings ("Habana instead of
Havana, Kuba instead of Cuba") among root causes of sanctions violations.[^ofac-fw]
2. **Write the discriminating fact.** "Customer DOB 1991-04-02; listed person DOB 1958" beats "not a match".
3. **Escalate uncertainty** to a second reviewer with authority to freeze.
4. **Check ownership and control under every regime that applies**: a US-only 50% check misses UK control cases (table below).
#### Sanctions ownership and reporting: US and UK
As of October 2026.
| Point | US (OFAC) | UK (OFSI) |
|---|---|---|
| Ownership test | Entity owned 50% or more, directly or indirectly, by blocked persons, **aggregated** across them, is blocked[^ofac50] | Person holds **more than 50%** of shares or voting rights; holdings of different designated persons are not simply aggregated unless, for example, held under a joint arrangement[^ofsi] |
| Control | Control without ownership does not trigger the rule, though OFAC urges caution[^ofac50] | Counts: right to appoint or remove a majority of the board, or reasonable to expect the person could "ensure the affairs of the entity are conducted" as they wish[^ofsi] |
| Reporting | Blocked property reported to OFAC within 10 business days[^cfr603] | Relevant firms "inform OFSI as soon as practicable" when they know or reasonably suspect a designated person or a breach[^ofsi] |
#### Playbook: writing a report narrative
Answer **who, what, when, where, why it is suspicious, and how**, with amounts, dates, accounts and the trigger; describe grounds,
not guilt ([template](#templates)). Wolfsberg notes that context can raise a report's value and that feedback from authorities is
the best indicator of quality.[^wolfsberg1]
#### Playbook: asking the customer for information
Requests for information (RFIs) use pre-approved wording with no mention of monitoring, reports or law enforcement
([template](#templates)). A refusal or implausible answer is evidence.
### Fraud and AML: same team, different duties
Fraud and laundering meet in mule accounts that receive scam victims' money, but the duties differ.
| Dimension | Fraud operations | AML operations |
|---|---|---|
| Who is harmed | Usually the customer or the firm | Society; the customer is often the suspect |
| Speed | Seconds | Days to weeks, on legal clocks |
| Action | Block, warn, recover, reimburse | Investigate, report, restrict, exit |
| Customer contact | Open ("did you make this payment?") | Constrained by [tipping-off law](#exception-paths-and-the-tipping-off-wall) |
| Typical measures (this Atlas's) | Losses prevented, false declines, reimbursement claims | Timeliness, QA, useful reports, misses |
| UK anchor | Authorised push payment (APP) scam reimbursement: up to £85,000 per claim from 7 October 2024, split 50:50 between sending and receiving firms[^psr247][^psr-app] | POCA reporting and tipping-off offences[^poca333a] |
The UK rule gives the **receiving** firm a reason to find mules. The government has proposed to transfer all the Payment Systems
Regulator's powers and functions to the FCA (as of October 2026).[^psr-plan] A combined team needs separate contact procedures:
the open conversation that suits a fraud victim can tip off a launderer.
**Information sharing** is the main lever against mule networks spanning firms. US institutions must search their records for
FinCEN's 314(a) requests[^cfr520] and may share under the 314(b) safe harbour after notifying FinCEN.[^cfr540] In the UK, the
Economic Crime and Corporate Transparency Act 2023, s.188, removes civil liability for breach of confidence when regulated firms
share customer information on request or as a warning.[^eccta188] Each route has conditions.
### Methods, standards and frameworks
| Source | Status (October 2026) | What operations takes from it |
|---|---|---|
| FATF Recommendations (June 2026)[^fatf-page] | International standard, via national law | Risk-based approach, CDD, PEPs, records, reporting |
| US Bank Secrecy Act rules, e.g. 31 CFR 1020.210 and 1020.320[^cfr210][^cfr320] | Law (US banks) | Programme minimums, SAR thresholds, deadlines, confidentiality |
| FinCEN AML/CFT programme NPRM (April 2026)[^nprm][^nprm-fr] | Proposed, not final | Effectiveness focus; establishment vs maintenance; AML/CFT Priorities |
| FinCEN and agencies' SAR FAQs, October 2025[^fincen-faq] | Interpretation that does not change the law | Structuring, continuing activity, no-SAR records |
| UK Money Laundering Regulations 2017[^mlrs][^mlr21], amended by S.I. 2026/621[^si621] | Law (UK, incl. payment and e-money firms); amendments mostly from 30 June 2026 | Risk assessment, controls, CDD/EDD (2026: country trigger, GBP thresholds), records, nominated officer |
| UK Proceeds of Crime Act 2002 and FCA SYSC 6.3[^poca333a][^poca335][^sysc] | Law and FCA rules | Disclosures, DAML, tipping off; MLRO; regard to JMLSG guidance (6.3.5G) |
| OFSI general guidance[^ofsi]; OFAC compliance framework (May 2019)[^ofac-fw] | Regulator guidance (UK; US) | Ownership, control, reporting; programme components, root causes |
| EU AMLR 2024/1624 and AMLA[^arendt][^amla] | EU law from 10 July 2027; agency being built | Single rulebook; direct supervision of selected entities |
| Wolfsberg monitoring statements (2024, 2025)[^wolfsberg1][^wolfsberg2] | Industry guidance | Effectiveness, below-the-line testing, innovation |
| SR 26-2 model risk guidance (US, April 2026)[^sr2602][^sr2602a] | Supervisory guidance, not enforceable; excludes generative and agentic AI | Validation of monitoring models |
### Tooling landscape
Examples verified 2026-10-23, not recommendations.
| Category | Job | Examples (verified) | Selection criteria | Watch-outs |
|---|---|---|---|---|
| List data | Sanctions, PEP, media | Official lists; OpenSanctions (CC BY-NC 4.0, commercial licence needed)[^os-lic] | Latency, identifiers, aliases | Stale feeds |
| Screening engine | Fuzzy name and identifier matching | Moov Watchman (Apache-2.0)[^watchman]; yente for OpenSanctions (MIT)[^yente] | Explainable scores, transliteration, tuning | Threshold set without testing |
| Transaction monitoring | Rules and models over activity | Marble (Elastic License 2.0)[^marble]; Jube (AGPL-3.0)[^jube]; commercial suites | Data fit, scenario authoring, below-the-line testing, audit trail | Black-box scores; new-product gaps |
| Case management | Cases, evidence, decisions, clocks | Bundled or workflow tools | One record per case, access control | Notes kept in chat |
| Regulatory filing | Reports to the FIU | FIU portals | Acknowledgements stored | Late filing |
Elastic License 2.0 restricts use and AGPL-3.0 has network-use obligations: read licences first. Test identity-verification
vendors' failure rates by customer group.
### Automation and AI
Automation helps with enrichment, de-duplication, queue ranking and timelines; it is riskiest where it closes alerts unchecked.
- **Validation before trust.** Wolfsberg's 2025 statement sets three pillars: transition and validation, balancing model risk
against financial crime risk, and explainability. It calls the side-by-side "parallel run" "an artefact of a less advanced testing
environment" and wants the appetite for misses explained and agreed.[^wolfsberg2]
- **US model risk guidance, with limits.** SR 26-2 (17 April 2026) replaced the 2011 model risk guidance and the 2021 BSA/AML
model risk statement; it is "most relevant" to banking organisations with over $30 billion in assets.[^sr2602] It "does not set
forth enforceable standards", and generative and agentic AI models "are not within the scope of this guidance".[^sr2602a] Govern
monitoring models through [ModelOps](../modelops/).
- **Large language models and agents** can summarise cases and draft narratives. As SR 26-2 excludes them, this Atlas recommends
your own framework: SAR data stays in approved systems, facts are checked against evidence, a human decides.
## FinCrimeOps in practice
### Reference implementation: operating artefacts
A minimal set for a small regulated fintech (this Atlas's proposals).
**1. Alert disposition record**, one per alert, in the case system.
_Example status: syntax-checked (YAML), not executed; fictional data._
```yaml
alert_id: TM-2026-104233
source: transaction_monitoring
scenario: PT-01 pass-through (credits out within 48h)
customer_ref: CUST-0042911 # internal reference, not a name
opened_at: 2026-10-28T09:14:00Z
priority: high # from the queue ranking
clocks:
review_due: 2026-11-04 # internal service level for L1/L2 review
suspicion_determined: 2026-11-02 # US "initial detection": review found grounds
sar_due: 2026-12-02 # 30 calendar days later (31 CFR 1020.320)
triage:
analyst: analyst-117
facts_checked: [kyc_profile, 90_day_history, counterparties, prior_alerts]
outcome: escalate # close | escalate
reason_code: R07 # unexplained rapid movement, new counterparties
case:
case_id: CASE-2026-3381
linked_alerts: [TM-2026-104233, SCR-2026-55120]
rfi_sent: true # scripted wording only (template RFI-03)
recommendation: report
decision:
decided_by: mlro-delegate-02
decision: report # report | no_report
rationale: >-
Twelve inbound transfers from unrelated senders, 94% moved out within a day
to two new accounts; customer's stated purpose (salary) not supported.
filed_ref: FIU-ACK-PLACEHOLDER # acknowledgement number from the FIU portal
qa:
sampled: true
score: 92
access: restricted-sar # need-to-know group; no customer-facing roles
```
**2. Disposition reason codes.** "Other" above 5% of closures means the list is wrong.
| Code | Meaning | Allowed outcome |
|---|---|---|
| R01 | Consistent with documented income or business activity | Close |
| R02 | Known counterparty relationship verified (e.g. family, employer) | Close |
| R03 | One-off event evidenced (property sale, inheritance) | Close |
| R04 | Screening hit discounted on identifiers (DOB, nationality, registration number) | Close |
| R07 | Unexplained rapid movement of funds | Escalate |
| R08 | Activity inconsistent with stated purpose or profile | Escalate |
| R09 | Possible sanctions or PEP match unresolved | Escalate to second reviewer |
| R10 | Information request refused or implausible | Escalate |
**3. Tuning change request:** evidence, approval, rollback.
_Example status: syntax-checked (YAML), not executed._
```yaml
change_id: TUNE-2026-014
scenario: PT-01 pass-through
proposal: lower min_inflow_7d from 10000 to 7500
evidence:
btl_test: lab-2 style replay of 6 months, 2026-04-01..2026-09-30
alerts_per_month_before: 20
alerts_per_month_after: 31
confirmed_cases_found_only_below_line: 2
capacity_impact_hours_per_month: 6 # 11 extra alerts x ~30 minutes
risk_owner_approval: mlro # accountable for the change
model_governance: tier-3 rule change, logged with ModelOps
rollback: restore previous threshold; replay window kept for comparison
review_after: 2027-01-31
```
### Hands-on labs
Three labs on **synthetic data**: Python 3.8+, standard library, no cost. Expected outputs are copied from runs on 2026-10-23
(Python 3.8.10, Ubuntu).
::: warning Never practise on real customer or list data
Screening data is confidential and SAR information legally protected; never copy production extracts to a laptop.
:::
#### Lab 1 (beginner): what a screening threshold really trades
**Objective.** See how a fuzzy-match threshold trades misses against false alerts, and why aliases matter more.
**Prerequisites.** Python 3.8+. **Time.** 20 minutes.
1. Create a folder: `mkdir -p ~/fincrime-labs && cd ~/fincrime-labs`.
2. Save this as `screen.py`.
_Example status: verified by execution on 2026-10-23 (Python 3.8.10)._
```python
"""Lab 1: how a name-screening threshold trades missed matches for alerts.
All names are invented. Standard library only (Python 3.8+)."""
import difflib
import sys
import unicodedata
WATCHLIST = ["Ivan Petrovich Sidorenko", "Al-Noor Trading FZE",
"Maria Fernanda Quintero", "Oceanic Star Shipping Ltd"]
# (customer name, True if it really is the listed party)
CUSTOMERS = [
("Ivan P. Sidorenko", True), ("Iwan Sidorenko", True),
("Alnoor Trading F.Z.E.", True), ("Maria F. Quintero", True),
("Oceanic Star Shipping Limited", True),
("Ivana Sidorova", False), ("Maria Quintana", False),
("Al Noor Bakery", False), ("Oceanic Shipping Supplies", False),
("Ivan Petrov", False), ("Mario Quinteros", False),
("Star Ocean Logistics", False),
]
STOP = {"ltd", "limited", "fze", "llc", "the"}
def norm(name):
s = unicodedata.normalize("NFKD", name).encode("ascii", "ignore").decode()
s = s.lower().replace("-", " ").replace(".", " ")
return " ".join(t for t in s.split() if t not in STOP)
def score(a, b):
a, b = norm(a), norm(b)
full = difflib.SequenceMatcher(None, a, b).ratio()
tokens = difflib.SequenceMatcher(None, sorted(a.split()), sorted(b.split())).ratio()
joined = difflib.SequenceMatcher(None, a.replace(" ", ""), b.replace(" ", "")).ratio()
return max(full, tokens, joined)
def best(customer):
return max(score(customer, w) for w in WATCHLIST)
if __name__ == "__main__":
if "--with-alias" in sys.argv: # list publishers give AKAs; use them
WATCHLIST.append("Iwan Sidorenko")
for c, _ in CUSTOMERS:
print(f"{best(c):.2f} {c}")
print("threshold alerts true_hits missed false_alerts")
for t in (0.60, 0.65, 0.70, 0.80, 0.90):
alerts = [(c, real) for c, real in CUSTOMERS if best(c) >= t]
hits = sum(1 for _, real in alerts if real)
missed = sum(1 for _, real in CUSTOMERS if real) - hits
print(f"{t:.2f} {len(alerts):6d} {hits:9d} {missed:6d} {len(alerts) - hits:12d}")
```
3. Run it without and with the alias.
_Example status: verified by execution on 2026-10-23._
```bash
python3 screen.py | tail -6
python3 screen.py --with-alias | tail -6
```
**Expected output** (first run, then second run):
```text
threshold alerts true_hits missed false_alerts
0.60 9 5 0 4
0.65 8 5 0 3
0.70 5 4 1 1
0.80 4 4 1 0
0.90 1 1 4 0
threshold alerts true_hits missed false_alerts
0.60 10 5 0 5
0.65 9 5 0 4
0.70 7 5 0 2
0.80 5 5 0 0
0.90 2 2 3 0
```
**Validation.** Without the alias, "Iwan Sidorenko" (a transliteration) scores 0.69 and is missed at 0.70 and above; 0.65 catches
it with three false alerts. The alias catches all five true matches at 0.80 with none. As in OFAC's root-cause list, unhandled
alternative spellings, not the threshold, are the failure.[^ofac-fw]
**Troubleshooting.** A `SyntaxError` means Python older than 3.6; different scores mean the file changed.
**Teardown.** Lab 3 removes the folder.
#### Lab 2 (intermediate): tune a rule and test below the line
**Objective.** Tune a pass-through (mule) scenario below the line; see why recall, unlike precision, is hard to measure.
**Prerequisites.** Lab 1 folder. **Time.** 30 minutes.
1. Save this as `tm.py`.
_Example status: verified by execution on 2026-10-23 (Python 3.8.10)._
```python
"""Lab 2: tune a pass-through (money mule) rule and test below the line.
Synthetic data with a fixed seed; the 'mule' label exists only because we
generated it. Standard library only (Python 3.8+)."""
import random
import sys
random.seed(42)
DAYS = 30
def make_accounts(n=2000, mules=20):
accounts = []
for i in range(n):
mule = i < mules
tx = [] # (day, amount in, amount out)
for day in range(DAYS):
if mule and day % 6 == 0: # bursts of inbound credit, fast exit
amount = random.uniform(1500, 9000)
tx.append((day, amount, 0.0))
tx.append((day + 1, 0.0, amount * random.uniform(0.92, 0.99)))
elif random.random() < 0.08: # ordinary salary/spend pattern
amount = random.uniform(200, 6000)
tx.append((day, amount, 0.0))
if random.random() < 0.15: # a few pay bills straight away
tx.append((day + 1, 0.0, amount * random.uniform(0.9, 1.0)))
accounts.append({"id": f"ACC{i:05d}", "mule": mule, "tx": tx})
return accounts
def fires(acc, min_in):
"""Alert if, in some 7-day window, credits total >= min_in and debits
from the window start to 2 days after its end total >= 90% of them.
A simplification: debits are not linked to the credits they spend."""
for start in range(DAYS):
window = [t for t in acc["tx"] if start <= t[0] < start + 7]
inflow = sum(t[1] for t in window)
if inflow < min_in:
continue
fast_out = sum(t[2] for t in acc["tx"]
if start <= t[0] < start + 9 and t[2] > 0)
if fast_out >= 0.9 * inflow:
return True
return False
if __name__ == "__main__":
accounts = make_accounts()
thresholds = [float(x) for x in sys.argv[1:]] or [10000, 5000, 2500, 1000]
total_mules = sum(a["mule"] for a in accounts)
print("min_in alerts true_pos precision recall")
for th in thresholds:
alerted = [a for a in accounts if fires(a, th)]
tp = sum(a["mule"] for a in alerted)
prec = tp / len(alerted) if alerted else 0.0
print(f"{th:6.0f} {len(alerted):7d} {tp:9d} {prec:10.2f} {tp / total_mules:7.2f}")
```
2. Run the production threshold (10,000) with one setting above it and three below the line.
_Example status: verified by execution on 2026-10-23._
```bash
python3 tm.py 12000 10000 7500 5000 2500
```
**Expected output:**
```text
min_in alerts true_pos precision recall
12000 13 13 1.00 0.65
10000 20 17 0.85 0.85
7500 31 19 0.61 0.95
5000 127 20 0.16 1.00
2500 353 20 0.06 1.00
```
**Validation and interpretation.**
- At 10,000 the rule catches 17 of 20 mules with 20 alerts; 7,500 finds two more for 11 extra alerts; 5,000 finds the last for 96
more. Whether 7,500 is worth it is a **risk-appetite decision**, recorded in a tuning change request.
- Recall is computable only because we generated the labels. In practice you estimate misses from below-the-line samples, reports
from other sources such as internal referrals, and authorities' feedback, as Wolfsberg recommends;[^wolfsberg1] this Atlas adds
law-enforcement requests as a signal.
**Troubleshooting.** Different numbers mean `random.seed(42)` or `make_accounts` changed; threshold order does not matter.
**Teardown.** Lab 3 removes the folder.
#### Lab 3 (advanced): regulatory clocks in the case record
**Objective.** Encode the US SAR deadline and UK DAML periods with official holidays so cases show due dates (simplified rules).
**Prerequisites.** Python 3.8+; optional internet for the GOV.UK file. **Time.** 30 minutes.
1. Save this as `clocks.py`.
_Example status: verified by execution on 2026-10-23 (Python 3.8.10)._
```python
"""Lab 3: regulatory clocks for a case record (US bank SAR; UK DAML).
Encodes the rules as read on 2026-10-23; not legal advice. Python 3.8+."""
import json
import os
from datetime import date, timedelta
NATION = "england-and-wales" # or "scotland", "northern-ireland"
def load_uk_holidays(path="bank-holidays.json"):
"""Read GOV.UK's bank-holidays.json if downloaded; else a small sample."""
if os.path.exists(path):
with open(path, encoding="utf-8") as f:
events = json.load(f)[NATION]["events"]
return {date.fromisoformat(e["date"]) for e in events}
print("note: bank-holidays.json not found; using a 2026-27 sample")
return {date(2026, 12, 25), date(2026, 12, 28), date(2027, 1, 1)}
UK_HOLIDAYS = load_uk_holidays()
def us_sar_due(detected, suspect_identified=True):
"""31 CFR 1020.320(b)(3): 30 calendar days; up to 60 if no suspect."""
return detected + timedelta(days=30 if suspect_identified else 60)
def us_continuing_sar_due(detected, suspect_identified=True):
"""Optional timeline in FinCEN's 2025 FAQ: day 150, or day 180 when
the initial SAR used the extra 30 days (no suspect identified)."""
return detected + timedelta(days=150 if suspect_identified else 180)
def uk_working_day(d):
return d.weekday() < 5 and d not in UK_HOLIDAYS
def uk_daml_notice_period_end(disclosed):
"""POCA s.335(5): seven working days starting with the first working
day after the disclosure. Returns the last day of the period."""
d, counted = disclosed, 0
while counted < 7:
d += timedelta(days=1)
if uk_working_day(d):
counted += 1
return d
def uk_moratorium_end(refusal_received):
"""POCA s.335(6): 31 days starting with the day the refusal notice is
received (extensions by court order are possible; s.336A)."""
return refusal_received + timedelta(days=30)
if __name__ == "__main__":
print("US SAR due (suspect known): ", us_sar_due(date(2026, 11, 2)))
print("US SAR due (no suspect yet):", us_sar_due(date(2026, 11, 2), False))
print("US continuing SAR (if used):", us_continuing_sar_due(date(2026, 11, 2)))
print("UK DAML notice period ends: ", uk_daml_notice_period_end(date(2026, 12, 21)))
print("UK moratorium ends: ", uk_moratorium_end(date(2026, 12, 30)))
```
2. Run it with the built-in sample, then with the official UK bank holiday file.
_Example status: verified by execution on 2026-10-23 (the download uses the public GOV.UK file)._
```bash
python3 clocks.py
curl -sS -o bank-holidays.json https://www.gov.uk/bank-holidays.json
python3 clocks.py
```
**Expected output** (both runs give the same dates; the first also prints the sample note):
```text
note: bank-holidays.json not found; using a 2026-27 sample
US SAR due (suspect known): 2026-12-02
US SAR due (no suspect yet): 2027-01-01
US continuing SAR (if used): 2027-04-01
UK DAML notice period ends: 2027-01-04
UK moratorium ends: 2027-01-29
```
**Validation.** A disclosure on Monday 21 December 2026 starts counting on 22 December; 25 and 28 December (substitute Boxing Day)
and 1 January are not working days in England and Wales,[^ukbh] so the seventh working day is Monday 4 January 2027. The moratorium
is 31 days *starting with* the day a refusal is received: 30 December to 29 January.[^poca335] The continuing-SAR date follows
FinCEN's optional timeline (day 150, or 180 if the first SAR took 60 days).[^fincen-faq]
**Troubleshooting.** A `KeyError` means a typo in `NATION`. US dates count calendar days, so file early before holidays.
**Teardown.** `rm -r ~/fincrime-labs`.
### Use cases and scenarios
The first two apply the sourced cases in [The problem it solves](#the-problem-it-solves) (screening failures have their own
[runbook](#worked-runbook-the-sanctions-list-stopped-updating)); methods are this Atlas's proposals. The third is illustrative.
**1. A fast-growing digital bank (Starling, Monzo).** *Method:* restrictions on high-risk segments enforced by system rule, not
memo; a [capacity model](#cost-capacity-and-sustainability) reviewed with every growth forecast. *Success:* zero onboardings that
breach a restriction; backlog within service level at forecast peak. *Pitfall:* hiring analysts without fixing the data.
**2. Monitoring that stood still (TD Bank).** *Method:* a product × scenario coverage map; FATF R.15's pre-launch risk assessment,
extended by this Atlas into a coverage gate; quarterly below-the-line tests. *Success:* all volume mapped to a control, with
evidence. *Pitfall:* counting scenarios instead of measuring detection.
**3. Receiving-side mules under the UK reimbursement rule (illustrative).** A receiving firm pays half of each APP claim on its
mule accounts.[^psr-app] *Method:* fraud signals (new account, device changes) plus pass-through scenarios (Lab 2) and
[information sharing](#fraud-and-aml-same-team-different-duties). *Success:* a falling share of claims as receiver. *Pitfall:*
fraud staff contacting a mule before AML decides.
## Measure, govern, pay
### Metrics and KPIs
Volume ratios describe quantity, not usefulness,[^wolfsberg1] so balance them (formulas are this Atlas's).
| KPI | Formula | Type | Pitfall |
|---|---|---|---|
| Escalation rate | alerts escalated ÷ alerts closed | Leading | A low rate can hide missed risk |
| Report conversion | reports filed ÷ cases closed | Lagging | As a target, pushes "defensive" filing |
| Timeliness | reports filed by deadline ÷ reports filed | Compliance | Slow pre-determination reviews are findings too |
| Backlog age | alerts open > N days ÷ alerts open | Operational | Averages hide the oldest alerts |
| QA pass rate | sampled decisions passing ÷ sampled | Quality | QA by the team that decided |
| List-update latency | time from list publication to production screening | Control health | Unmeasured until a regulator asks |
| Other-route share | reports on customers with no prior system alert ÷ all reports | Estimated misses | Needs referral data in the case tool |
| Useful-report share | reports with authority feedback or use ÷ reports filed | Effectiveness | Feedback is sparse; say so |
::: example Worked calculation for one month (illustrative numbers)
A team closes 4,000 alerts, escalates 240, closes 200 cases and files 50 reports, 47 on time; 1,100 alerts are open at month
end, 165 older than 30 days; QA passed 279 of 300 samples; 9 reports concerned customers with no prior system alert.
- Escalation rate = 240 ÷ 4,000 = **6.0%**; report conversion = 50 ÷ 200 = **25%**.
- Timeliness = 47 ÷ 50 = **94%**: three late reports are a breach to investigate.
- Backlog age = 165 ÷ 1,100 = **15%** over 30 days. QA pass rate = 279 ÷ 300 = **93%**.
- Other-route share = 9 ÷ 50 = **18%**: scenarios may be missing typologies (Wolfsberg's false-negative analysis uses internal
referrals;[^wolfsberg1] counting law-enforcement requests is this Atlas's extension).
:::
Review operational metrics weekly and effectiveness quarterly; set targets from risk appetite, not peers' ratios.
::: figure Tuning feedback loop for a monitoring scenario
```mermaid
flowchart TB
A["Scenario in production"]:::core --> B["Alerts and dispositions"]:::core
B --> C["Metrics: escalation,
reports, other-route share"]:::neutral
C --> D["Below-the-line and
coverage tests"]:::neutral
D --> E{"Change needed?"}:::decision
E -->|"no"| A
E -->|"yes"| F["Tuning change request
evidence and capacity"]:::core
F --> G["MLRO approval and
model governance"]:::risk
G --> H["Release with rollback"]:::core
H --> A
classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
```
Text equivalent: Alerts and dispositions feed metrics, then below-the-line and coverage tests. A needed change becomes a tuning
request with evidence and capacity impact, approved by the MLRO and model governance, and released with rollback.
:::
### Quality, security, privacy and compliance
- **Confidentiality** is the security requirement: need-to-know access, logged, never in e-mail or chat.
- **Records.** FATF R.11's two five-year periods ([five controls](#fundamentals-the-five-controls)) are minimums; US banks keep
SARs and supporting documents five years from filing.[^cfr320]
- **Privacy.** Coordinate data-access requests with [PrivacyOps](../privacyops/) so responses do not reveal reports; the
exemptions are national law.
- **Fairness.** Blanket exits exclude legitimate customers; FATF works on "mitigating unintended consequences".[^fatf-page]
### Cost, capacity and sustainability
Analyst time is the main cost. A capacity model (this Atlas's):
`analysts needed = (alerts per week × minutes per alert + cases per week × hours per case × 60) ÷ productive minutes per analyst`
::: example Staffing estimate (illustrative numbers)
1,000 alerts a week at 12 minutes plus 60 cases at 4 hours = 26,400 minutes. At 30 productive hours (1,800 minutes) per analyst,
that is 26,400 ÷ 1,800 ≈ **14.7 analysts** before leave. A rule adding 300 alerts a week adds 3,600 minutes: two more analysts.
:::
Cheaper alerts come from better data (aliases, identifiers, profiles), not faster analysts.
### Assurance of the operating model
Team leads review daily, independent QA samples decisions, and internal audit tests the programme (a US minimum).[^cfr210] Add
automatic checks: list reconciliation, canary names, coverage reports and clock breaches raised as incidents.
## When things go wrong
### Common failures and troubleshooting
| Symptom | Likely cause | Diagnosis | Remediation | Prevention |
|---|---|---|---|---|
| Sudden drop in screening hits | List feed stale or truncated | Compare counts with the publisher; test canaries | Reload; rescreen since last good load | Daily reconciliation alert |
| Backlog grows every week | Capacity below inflow; noisy scenario | Inflow vs closures per scenario | Prioritise by risk; temporary capacity; tune with evidence | Capacity model in growth plans |
| Late reports | Determination date not recorded; reviews left to age | Compare alert, determination and filing dates | Clock fields in the case tool | Automatic due dates (Lab 3); review service levels |
| QA failures cluster in one alert type | Unclear procedure or reason codes | Calibration session | Rewrite procedure; add examples | Monthly calibration |
| Customer complains they were "reported" | Tipping-off breach | Review contact logs | Escalate to the MLRO; legal advice | Scripts, training, access control |
| New product generates no alerts | No scenario covers it | Coverage map | Interim manual review; build scenario | Pre-launch risk assessment plus coverage gate |
### Worked runbook: the sanctions list stopped updating
::: example Illustrative scenario, modelled on failure modes reported by OFAC and the FCA
Monday 08:10. The production list has 2,412 fewer records than the publisher's; the last good load was nine days ago.
:::
1. **Declare an incident (minute 0–15).** Severity high; notify the MLRO.
2. **Contain (15–60).** Load the list manually; verify counts and canaries. If that fails, hold new onboarding and risky payments
to new counterparties (MLRO decision, recorded).
3. **Rescreen (hours 1–6)** customers, counterparties and payments in the gap against records added since the last good load.
4. **Assess and notify (day 1–2).** With legal advice, decide whether dealings with designated persons occurred and whom to tell:
OFSI "as soon as practicable" (UK relevant firms);[^ofsi] OFAC within 10 business days for blocked property;[^cfr603] possibly
your supervisor (Starling "reported multiple potential breaches").[^starling]
5. **Root cause (week 1).** Why silent? Check for an expired feed credential, a publisher schema change, or monitoring of the job
but not its output.
6. **Prevent.** Reconciliation alert, canaries, list latency as a KPI, a quarterly end-to-end test.
**Exit criteria:** counts reconcile; gap records rescreened with dispositions; notifications decided; KPI live.
### Anti-patterns and myths
- **"Lower the threshold until nothing is missed."** It buries real cases; test below the line, then decide.
- **"Report everything to be safe."** Wolfsberg argues defensive filing rarely helps law enforcement.[^wolfsberg1]
- **"The vendor's default rules are our risk assessment."** Scenarios must follow *your* products (FATF R.1).
- **"Analyst speed is the KPI."** Speed targets without QA produce reasons that fail examination.
- **"ML will fix our backlog."** Only after validation, explainability and an agreed tolerance for misses.[^wolfsberg2]
## Deciding and adopting
### When to use and when not to use
Build a dedicated team when you are (or will be) regulated and your flows generate daily alerts. Two set-ups are easy to misjudge:
- **You run accounts or cards on a partner bank's licence (BaaS).** AML duties come from law, not contract: the bank is the
obliged entity. US regulators note that the third party may perform "monitoring and reporting suspicious activity, customer
identification programs, customer due diligence, and sanctions compliance on behalf of the bank", which "remains
responsible".[^baas] So you may still run that work under contract and the bank's oversight: size a team for it. (A September
2026 proposal would replace that statement; its guidance still says use of third parties "does not diminish" the bank's
responsibility. Comments close 16 November 2026.)[^tprm26]
- **Alert volume is a few a week.** A trained compliance officer with outsourced reviews may be enough.
**Do not** build one when the problem is upstream (bad customer data, no product risk assessment): fix that first.
### Decision framework
::: figure Do you need an in-house FinCrime operations team?
```mermaid
flowchart TB
A{"Are you an obliged
entity under AML law?"}:::decision
A -->|"no: partner bank is"| B["Do the work under
contract and
bank oversight"]:::neutral
A -->|"yes"| C{"Daily alerts or
onboarding volume?"}:::decision
B --> C
C -->|"low"| D["Compliance officer plus
outsourced reviews"]:::neutral
C -->|"high"| E{"Data and risk
assessment in place?"}:::decision
E -->|"no"| F["Fix data and risk
assessment first"]:::risk
E -->|"yes"| G["In-house team;
outsource peaks"]:::core
classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
```
Text equivalent: If a partner bank, not you, is the obliged entity, you may still run CDD, monitoring and screening under contract
and its oversight; either way, volume decides next. Low: a compliance officer plus outsourced reviews. High: fix missing data and
risk assessment first; otherwise build an in-house team and outsource peaks.
:::
This Atlas's simplification: obliged-entity status is a legal question, and sanctions duties apply widely either way.
### Maturity model
This is **this Atlas's model**, not an industry standard.
| Level | Observable behaviour | Exit criteria to the next level |
|---|---|---|
| 1. Reactive | Alerts in spreadsheets or mailboxes; reasons vary | Single case record; reason codes; clocks tracked |
| 2. Documented | Procedures, RACI, QA sampling; volume MI | Timeliness on target for two quarters; QA calibrated |
| 3. Measured | Coverage map per product; below-the-line tests; capacity model | Every product mapped; tuning by change request |
| 4. Effectiveness-led | Other-route share and FIU feedback drive tuning | Scenario retirements evidenced |
| 5. Intelligence-led | Network analytics, information sharing, validated explainable models | Sustained rise in useful reports |
### Adoption roadmap: 30/60/90 days
For a new head of FinCrime Operations at a growing fintech:
- **Days 1–30: see the work.** Inventory alert sources and backlogs; map products to scenarios; check clocks; read regulator
letters. *Quick win:* daily list reconciliation.
- **Days 31–60: stabilise.** One case record; reason codes; contact scripts; independent QA; capacity model; MLRO MI pack.
*Milestone:* no unowned alerts.
- **Days 61–90: improve.** First below-the-line test; tuning change process with the MLRO and [ModelOps](../modelops/); coverage
gate for launches. *Milestone:* first evidence-based tuning change.
## Toolkit
### Checklists
Each item is an acceptance criterion: tick it only with evidence in the case or change record.
**Launch readiness (new product or payment type)**
- [ ] Risk assessment signed off before launch (FATF R.15), naming the product's typologies
- [ ] Every flow mapped to screening and a scenario tested with synthetic cases (coverage gate)
- [ ] Capacity model, scripts and reason codes updated for the product
**Daily operations**
- [ ] List feeds reconciled and canaries hit; sanctions hits worked first
- [ ] Alerts past service level and reports near deadline have named owners
- [ ] Overdue periodic reviews and pending EDD approvals listed
**Before filing a report**
- [ ] Narrative answers who, what, when, where, why, how; each fact traced to evidence
- [ ] Determination date recorded; filed on time; acknowledgement stored
- [ ] Retain-or-exit decision and any DAML hold recorded; access need-to-know
**Quarterly review**
- [ ] Below-the-line test on at least one scenario; coverage map updated
- [ ] QA calibrated; other-route reports analysed for missing typologies
- [ ] Legal changes (e.g. the UK 2026 EDD trigger) mapped to rules
### Templates
**Report narrative skeleton** (adapt to your FIU's form and guidance):
```text
SUMMARY: [Customer ref] [type] conducted [activity] between [date] and [date]
totalling [amount], which we consider suspicious because [grounds].
TRIGGER: Identified by [alert/referral/request] on [detection date].
SUBJECTS: [names, identifiers, roles; linked accounts and counterparties]
ACTIVITY: [chronology: date, amount, channel, counterparty, destination]
PROFILE MISMATCH: Stated purpose [x]; expected activity [y]; observed [z].
CUSTOMER RESPONSE: [information requested and received, if any]
ACTION TAKEN: [restriction, exit, DAML request] (no tipping off)
```
**Customer information request** (scripted; approved by the MLRO):
```text
Subject: Information needed about recent account activity
As part of our regular checks, please tell us the source of the payments
received on [dates] and your relationship with the sender(s), and upload
supporting documents (for example, an invoice or contract) by [date].
```
**QA scorecard** (score each sampled decision; pass at 85 or above):
```text
Criterion Points
Correct outcome for the facts 40
Reason specific and evidenced (not "looks fine") 20
Required checks done (profile, history, links) 20
Clock and escalation rules followed 10
Language neutral; no tipping-off risk 10
```
The [disposition record](#reference-implementation-operating-artefacts) and tuning request complete the set.
### Deep comparisons
See [neighbours](#how-fincrimeops-relates-to-other-ops), [fraud versus AML](#fraud-and-aml-same-team-different-duties) and
[US/UK sanctions](#sanctions-ownership-and-reporting-us-and-uk). Operating models (this Atlas's comparison; accountability stays
with the MLRO or BSA officer in every model):
| Model | Strength | Weakness | Fits when |
|---|---|---|---|
| In-house | Product knowledge, control, fast feedback to tuning | Fixed cost; slow to scale | Steady, high volume |
| Outsourced L1 and L2 | Elastic capacity | Thin product context; QA and data-transfer burden | Low or spiky volume |
| Hybrid | Decisions in-house, bought L1 capacity | Two quality systems to calibrate | Growth or backlog recovery |
### FAQ
**Can we tell a customer why we froze their account?** That the account is restricted and what you need, yes, in approved wording;
that a report or investigation exists, no ([the wall](#exception-paths-and-the-tipping-off-wall)).
**Do we have to document a decision not to report?** In the US, FinCEN's October 2025 FAQ says there is no requirement or
expectation under the BSA to do so;[^fincen-faq] the FFIEC examination manual still says banks should document decisions not to
file,[^ffiec-sar] so recording a short reason is the safer course.
**Can machine learning replace rules?** Where validated, explainable and governed, it can improve detection
([Automation and AI](#automation-and-ai)); rules stay useful where a regulator expects a pattern covered.
**Do we need an MLRO?** In the UK, every business covered by the MLRs needs a nominated officer, except a sole practitioner with no
staff;[^mlr21] FCA-authorised firms within SYSC 6.3 also need an MLRO.[^sysc] US banks designate a BSA officer.[^cfr210]
**We are a fintech on a partner bank's licence. Is AML the bank's problem?** The bank stays responsible, but the work is often
yours under contract ([When to use](#when-to-use-and-when-not-to-use)).
## Going further
### Advanced topics and emerging direction
- **Monitoring beyond transactions (industry guidance).** Wolfsberg's MSA concept adds customer behaviour to transaction rules
and retires tested routines that produce no value.[^wolfsberg1]
- **EU direct supervision (planned).** AMLA plans to select 40 entities during 2027 and supervise them from 2028.[^amla]
- **AI agents in case work (vendor claims).** Vendors advertise autonomous KYC and alert agents;[^fenergo] govern them under your
own framework with human sign-off, as SR 26-2 excludes agentic AI.[^sr2602a]
### Learning path
- **Prerequisites:** how accounts and payments work ([FinTechOps](../fintechops/)); basic risk vocabulary ([RiskOps](../riskops/)).
- **Day 1:** read FATF Recommendations 1, 10, 11, 12, 20 and 21; do Lab 1.
- **Week 1:** your national rules (US: 31 CFR 1020.320; UK: POCA Part 7, the MLRs, NCA guidance); Labs 2 and 3.
- **Month 1:** shadow L1 and L2; score 50 decisions with the QA scorecard; read both Wolfsberg statements.
- **Specialise:** sanctions, investigations or detection engineering; portfolio: a coverage map and below-the-line test plan.
## Wrap-up
### Executive recap and cheat sheet
| Topic | Remember |
|---|---|
| Definition | The team and workflow that execute AML/CFT, sanctions and fraud duties |
| Status | Niche label; established, regulated practice |
| Core unit | Alert → decision with reason → sometimes a report, on a clock |
| Hard constraint | No tipping off; need-to-know access |
| Metrics | Timeliness, backlog age, QA, list latency, other-route share, useful reports |
| Biggest risks | Stale lists; uncovered products; growth outrunning capacity |
| First moves | Daily list reconciliation; one case record; clocks; independent QA |
### A judgement call: clear the backlog fast, or fix the funnel?
::: decision The situation (illustrative)
A fintech has 18,000 open alerts, 6,000 of them older than 60 days, after a marketing campaign tripled sign-ups. The board wants the
backlog gone in six weeks.
:::
**Option A: hire 40 contractors and clear everything.** Visible and fast. Risks: thin reasons from staff without product
knowledge; QA cannot keep up; ageing alerts are already a finding (US examiners expect reviews in a reasonable time);[^ffiec-sar]
the inflow remains.
**Option B: triage by risk, then fix the inflow.** Sanctions hits and high-risk scenarios first; test the noisiest scenario below
the line before changing it; contractors only for L1 under strong QA; tell the regulator if required.
**Assumptions that decide it:** whether you already operate under a regulator's restriction (Starling breached one);[^starling] how
much backlog a few scenarios cause; whether old alerts hide reportable activity.
**Reasoned choice:** B, with A's contractors inside B's controls. A treats the backlog as staffing, but the FCA's findings were
about controls not keeping pace with growth. Uncertainty: B's tuning may miss crime if test data is thin; record the risk
acceptance with the MLRO.
### Learning objectives and mastery check
You can now explain the label's status, run the alert-to-report workflow without tipping off, compute effectiveness metrics, tune
a scenario below the line, encode reporting clocks, and apply the right sanctions ownership test.
::: answer 1. Why is a falling escalation rate not automatically good news?
The scenario may have improved, or analysts are closing too fast, or the rule stopped seeing a typology. Check QA, below-the-line
samples and other-route reports first.
:::
::: answer 2. A US bank detects suspicious facts on 2 November 2026 and identifies the suspect. When is the SAR due?
By 2 December 2026, 30 calendar days from initial detection (31 CFR 1020.320); without an identified suspect, up to 1 January 2027.
:::
::: answer 3. Lab 1 missed "Iwan Sidorenko". What is the better fix than lowering the threshold, and why?
Load the publisher's aliases and use identifiers such as date of birth: 0.65 caught it with three false alerts, the alias at 0.80
with none.
:::
::: answer 4. A customer service agent asks whether they can tell a customer "compliance is investigating you". What do you say?
No. Use the approved script about routine checks. Revealing an investigation can tip off the suspect and, in the UK regulated
sector, may be an offence under POCA s.333A.
:::
::: answer 5. Your other-route share rose from 8% to 20% in a quarter. What does it suggest and what do you do?
Monitoring may be missing a typology. Look for patterns in those cases, build or tune a scenario, and test it below the line.
:::
::: answer 6. One designated person owns 40% of a company and another owns 20%. Is the company blocked in the US? In the UK?
US: yes; OFAC's 50 Percent Rule aggregates blocked persons' stakes (60%). UK: not on ownership alone, because OFSI does not simply
aggregate different designated persons' holdings unless, for example, under a joint arrangement; but check control (board
appointment, or the ability to direct the company's affairs), which counts in the UK.
:::
### Conclusion
FinCrimeOps is a modest label for demanding work. Law and enforcement history teach
consistent lessons: coverage follows the product, lists stay current, every alert has a reason, clocks are visible, and the
customer never learns what the analyst suspects. The newer lesson, pressed by Wolfsberg and the US reform proposal, is that success
is not alerts closed but reports that help their readers, and knowing what you miss.
## Sources and further reading
All sources were opened on 2026-10-23; "archived copy" means an Internet Archive copy, read because the live site blocked automated access (see the ledger).
[^wise-le]: [FinCrime Operations Senior Analyst - Law Enforcement](https://wise.jobs/job/fincrime-operations-senior-analyst-law-enforcement-in-tallinn-jid-3530) — Wise careers, undated (expired). Checked 2026-10-23.
[^wise-lead]: [FinCrime Operations Team Lead - PEP](https://wise.jobs/job/fincrime-operations-team-lead-pep-in-hyderabad-jid-4116) — Wise careers, undated. Checked 2026-10-23.
[^monzo-jobs]: [Jobs at Monzo](https://job-boards.greenhouse.io/monzo) — Monzo on Greenhouse (list changes daily). Checked 2026-10-23.
[^fenergo]: [Fenergo Unveils Agentic AI-Driven FinCrime Operating System to Help FIs Stay Compliant](https://thefintechtimes.com/fenergo-unveils-agentic-ai-driven-fincrime-operating-system-to-help-fis-stay-compliant/) — The Fintech Times, 2025-05-28 (vendor claims as reported). Checked 2026-10-23.
[^fatf-page]: [The FATF Recommendations](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html) — Financial Action Task Force, "as amended June 2026" (read via the [Internet Archive copy of 2026-10-17](https://web.archive.org/web/20261017091942/https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html)). Checked 2026-10-23.
[^fatf-recs]: [International Standards on Combating Money Laundering and the Financing of Terrorism & Proliferation (PDF)](https://www.fatf-gafi.org/content/dam/fatf-gafi/recommendations/fatf-recommendations-2012.pdf) — FATF, updated June 2026; Recommendations, Interpretive Notes and Glossary (archived copy, 2026-10-17). Checked 2026-10-23.
[^td]: [TD Bank pleads guilty to Bank Secrecy Act and money laundering conspiracy violations in $1.8b resolution](https://www.irs.gov/compliance/criminal-investigation/td-bank-pleads-guilty-to-bank-secrecy-act-and-money-laundering-conspiracy-violations-in-1-point-8b-resolution) — IRS Criminal Investigation (Justice Department release), 2024-10-10. Checked 2026-10-23.
[^starling]: [FCA fines Starling Bank £29m for failings in their financial crime systems and controls](https://www.fca.org.uk/news/press-releases/fca-fines-starling-bank-failings-financial-crime-systems-and-controls) — Financial Conduct Authority, 2024-10-02. Checked 2026-10-23.
[^monzo]: [FCA fines Monzo £21m for failings in financial crime controls](https://www.fca.org.uk/news/press-releases/fca-fines-monzo-21m-failings-financial-crime-controls) — Financial Conduct Authority, 2025-07-08. Checked 2026-10-23.
[^wolfsberg1]: [Statement on Effective Monitoring for Suspicious Activity, Part I: Moving Beyond Automated Transaction Monitoring (PDF)](https://db.wolfsberg-group.org/assets/e3d83d2f-fad9-46d2-b5a9-3cf4e932f53f/Wolfsberg%20Group%20MSA%20Statement%20Part%20I.pdf) — The Wolfsberg Group, July 2024. Checked 2026-10-23.
[^wolfsberg2]: [Statement on Effective Monitoring for Suspicious Activity, Part II: Transitioning to Innovation (PDF)](https://db.wolfsberg-group.org/assets/298bc488-6e47-465c-8d61-f776aa86594a/Wolfsberg_MSAP2_Transitioning%20to%20Innovation.pdf) — The Wolfsberg Group, 2025-08-27 ([announcement](https://wolfsberg-group.org/news/the-wolfsberg-group-publishes-its-second-statement-on-effective-monitoring-for-suspicious-activity)). Checked 2026-10-23.
[^nca]: [Suspicious Activity Reports](https://www.nationalcrimeagency.gov.uk/what-we-do/crime-threats/money-laundering-and-illicit-finance/suspicious-activity-reports) — National Crime Agency (UK). Checked 2026-10-23.
[^cfr210]: [31 CFR 1020.210 — Anti-money laundering program requirements for banks](https://www.ecfr.gov/current/title-31/subtitle-B/chapter-X/part-1020/subpart-B/section-1020.210) — eCFR, current text. Checked 2026-10-23.
[^cfr320]: [31 CFR 1020.320 — Reports by banks of suspicious transactions](https://www.ecfr.gov/current/title-31/subtitle-B/chapter-X/part-1020/subpart-C/section-1020.320) — eCFR, current text. Checked 2026-10-23.
[^nprm]: [Fact Sheet: Proposed Rule to Fundamentally Reform Financial Institution AML/CFT Programs (PDF)](https://www.fincen.gov/system/files/2026-04/Program-NPRM-FactSheet.pdf) — FinCEN, 2026-04-07. Checked 2026-10-23.
[^nprm-fr]: [Anti-Money Laundering and Countering the Financing of Terrorism Programs (proposed rule)](https://www.federalregister.gov/documents/2026/04/10/2026-07033/anti-money-laundering-and-countering-the-financing-of-terrorism-programs) — Federal Register, 2026-04-10 (RIN 1506-AB72; no final rule found on 2026-10-23). Checked 2026-10-23.
[^fincen-faq]: [Frequently Asked Questions Regarding Suspicious Activity Reporting Requirements (PDF)](https://www.fincen.gov/system/files/2025-10/SAR-FAQs-October-2025.pdf) — FinCEN, Federal Reserve, FDIC, NCUA and OCC, 2025-10-09. Checked 2026-10-23.
[^cfr603]: [31 CFR 501.603 — Reports of blocked, unblocked, or transferred blocked property](https://www.ecfr.gov/current/title-31/subtitle-B/chapter-V/part-501/subpart-C/section-501.603) — eCFR, text as of 2026-10-01. Checked 2026-10-23.
[^cfr520]: [31 CFR 1010.520 — Information sharing between government agencies and financial institutions](https://www.ecfr.gov/current/title-31/subtitle-B/chapter-X/part-1010/subpart-E/section-1010.520) — eCFR, text as of 2026-10-01. Checked 2026-10-23.
[^cfr540]: [31 CFR 1010.540 — Voluntary information sharing among financial institutions](https://www.ecfr.gov/current/title-31/subtitle-B/chapter-X/part-1010/subpart-E/section-1010.540) — eCFR, text as of 2026-10-01. Checked 2026-10-23.
[^baas]: [Joint Statement on Banks' Arrangements with Third Parties to Deliver Bank Deposit Products and Services (PDF)](https://federalreserve.gov/newsevents/pressreleases/files/bcreg20240725c1.pdf) — Federal Reserve, FDIC and OCC, 2024-07-25. Checked 2026-10-23.
[^tprm26]: [Proposed Third-Party Risk Management Guidance](https://www.federalregister.gov/documents/2026/09/15/2026-18859/proposed-third-party-risk-management-guidance) — OCC, Federal Reserve, FDIC and NCUA (Federal Register), 2026-09-15; comments close 2026-11-16. Checked 2026-10-23.
[^poca333a]: [Proceeds of Crime Act 2002, section 333A: Tipping off: regulated sector](https://www.legislation.gov.uk/ukpga/2002/29/section/333A) — legislation.gov.uk, revised text up to date to 2026-10-05 (archived copy, 2026-10-05). Checked 2026-10-23.
[^poca335]: [Proceeds of Crime Act 2002, section 335: Appropriate consent](https://www.legislation.gov.uk/ukpga/2002/29/section/335) — legislation.gov.uk, revised text up to date to 2026-10-07 (archived copy, 2026-10-09). Checked 2026-10-23.
[^mlrs]: [The Money Laundering, Terrorist Financing and Transfer of Funds (Information on the Payer) Regulations 2017: contents](https://www.legislation.gov.uk/uksi/2017/692/contents) — legislation.gov.uk (archived copy, 2026-10-09). Checked 2026-10-23.
[^mlr21]: [Money Laundering Regulations 2017, regulation 21: Internal controls](https://www.legislation.gov.uk/uksi/2017/692/regulation/21) — legislation.gov.uk, revised text up to date to 2026-02-11 (latest archived copy, 2026-02-11). Checked 2026-10-23.
[^si621]: [The Money Laundering and Terrorist Financing (Amendment) Regulations 2026, S.I. 2026/621 (PDF)](https://www.legislation.gov.uk/uksi/2026/621/pdfs/uksi_20260621_en.pdf) — HM Treasury / legislation.gov.uk, made 2026-06-09; regulations 1, 14, 15, 19, 20 and Explanatory Note (archived copy, 2026-07-11). Checked 2026-10-23.
[^mlr27]: [Money Laundering Regulations 2017, regulation 27: Customer due diligence](https://www.legislation.gov.uk/uksi/2017/692/regulation/27) — legislation.gov.uk, revised to 2026-10-08, paras (8)–(9) (archived copy). Checked 2026-10-23.
[^mlr28]: [Money Laundering Regulations 2017, regulation 28: Customer due diligence measures](https://www.legislation.gov.uk/uksi/2017/692/regulation/28) — legislation.gov.uk, revised to 2026-10-14, paras (6)–(13) (archived copy). Checked 2026-10-23.
[^mlr33]: [Money Laundering Regulations 2017, regulation 33: Obligation to apply enhanced customer due diligence](https://www.legislation.gov.uk/uksi/2017/692/regulation/33) — legislation.gov.uk, text before the 2026 amendment, revised to 2026-02-24 (archived copy). Checked 2026-10-23.
[^sysc]: [SYSC 6.3 Financial crime](https://handbook.fca.org.uk/handbook/SYSC/6/3.html) — FCA Handbook, SYSC 6.3.5G, 6.3.9R and 6.3.10G. Checked 2026-10-23.
[^eccta188]: [Economic Crime and Corporate Transparency Act 2023, section 188: Direct disclosures of information: restrictions on civil liability](https://www.legislation.gov.uk/ukpga/2023/56/section/188) — legislation.gov.uk (archived copy, 2026-08-29). Checked 2026-10-23.
[^ofsi]: [UK financial sanctions general guidance](https://www.gov.uk/government/publications/financial-sanctions-general-guidance/uk-financial-sanctions-general-guidance) — Office of Financial Sanctions Implementation, HM Treasury, updated 2026-05-12; sections 4.1 and 5.1. Checked 2026-10-23.
[^arendt]: [Clarity on the implementation timeline for a strengthened EU AML/CFT framework](https://www.arendt.com/news-insights/news/clarity-on-the-implementation-timeline-for-a-strengthened-eu-aml-cft-framework/) — Arendt & Medernach (law firm), 2024 (EUR-Lex could not be fetched). Checked 2026-10-23.
[^ec-aml]: [Anti-money laundering and countering the financing of terrorism at EU level](https://finance.ec.europa.eu/financial-crime/anti-money-laundering-and-countering-financing-terrorism-eu-level_en) — European Commission (AMLR labelled "from 2027"). Checked 2026-10-23.
[^amla]: [About AMLA](https://www.amla.europa.eu/about-amla_en) — Authority for Anti-Money Laundering and Countering the Financing of Terrorism, timeline as displayed October 2026. Checked 2026-10-23.
[^ofac-fw]: [A Framework for OFAC Compliance Commitments (PDF)](https://ofac.treasury.gov/media/16331/download?inline) — Office of Foreign Assets Control, US Treasury, May 2019 (date from PDF metadata). Checked 2026-10-23.
[^ofac50]: [Entities Owned by Blocked Persons (50% Rule), FAQs 398–399](https://ofac.treasury.gov/faqs/topic/1521) — OFAC. Checked 2026-10-23.
[^psr247]: [PS24/7: APP scams reimbursement – confirming the max level](https://www.psr.org.uk/ps24-7-app-scams-reimbursement-confirming-max-level/) — Payment Systems Regulator, October 2024. Checked 2026-10-23.
[^psr-app]: [APP scams](https://www.psr.org.uk/our-work/app-scams/) — Payment Systems Regulator. Checked 2026-10-23.
[^psr-plan]: [Annual plan and budget 2026/27 (PDF)](https://www.psr.org.uk/media/pm0pwp4h/psr-annual-plan-2026-27.pdf) — Payment Systems Regulator, 2026. Checked 2026-10-23.
[^ffiec-sar]: [Assessing Compliance with BSA Regulatory Requirements: Suspicious Activity Reporting](https://bsaaml.ffiec.gov/manual/AssessingComplianceWithBSARegulatoryRequirements/04) — FFIEC BSA/AML Examination Manual (archived copy, 2026-10-11). Checked 2026-10-23.
[^sr2602]: [SR 26-2: Revised Guidance on Model Risk Management](https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm) — Board of Governors of the Federal Reserve System, 2026-04-17. Checked 2026-10-23.
[^sr2602a]: [Revised Guidance on Model Risk Management (SR 26-2 attachment, PDF)](https://www.federalreserve.gov/supervisionreg/srletters/SR2602a1.pdf) — Federal Reserve, OCC and FDIC, 2026-04-17; section I and footnote 3. Checked 2026-10-23.
[^os-lic]: [Licensing](https://www.opensanctions.org/licensing/) — OpenSanctions. Checked 2026-10-23.
[^watchman]: [moov-io/watchman](https://github.com/moov-io/watchman) — Moov, GitHub repository (Apache-2.0). Checked 2026-10-23.
[^yente]: [opensanctions/yente](https://github.com/opensanctions/yente) — OpenSanctions, GitHub repository (MIT). Checked 2026-10-23.
[^marble]: [checkmarble/marble](https://github.com/checkmarble/marble) — Marble, GitHub repository (LICENSE: Elastic License 2.0). Checked 2026-10-23.
[^jube]: [jube-home/aml-fraud-transaction-monitoring](https://github.com/jube-home/aml-fraud-transaction-monitoring) — Jube, GitHub repository (AGPL-3.0). Checked 2026-10-23.
[^ukbh]: [UK bank holidays (JSON)](https://www.gov.uk/bank-holidays.json) — GOV.UK. Checked 2026-10-23.
**Changelog**
- 2026-10-23, r0: first draft (research, ledger, three executed labs, six diagrams). Not yet independently fact-checked.
- 2026-10-23, r1: independent fact check (`reviews/fincrimeops-r1.md`); SR 26-2 scope, FinCEN 2026 NPRM, UK MLRs, OFSI table, BaaS branch, information sharing, PSR transfer; labs re-run; trimmed.
- 2026-10-23, r2: independent score (`reviews/fincrimeops-score.md`); UK MLRs 2026 amendment (S.I. 2026/621), CDD/EDD and periodic-review playbook, reg. 21(6) exception, handoff sequence diagram, fuller checklists and operating-model comparison; trimmed.
- 2026-10-23, post-score polish (`reviews/fincrimeops-polish.md`): Figure 5 shows refusal; tipping-off glossary row aligned with POCA s.333A and FATF R.21; r2 line corrected.