FinCrimeOps

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.

“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;^[1] a team lead needs expertise in “KYC/AML/Fraud/Screening”.^[2] Monzo’s job board in October 2026 listed a “Senior FinCrime Operations Manager”.^[3]
• Vendors use it for products. Fenergo launched a “FinCrime Operating System” with AI agents in May 2025, according to trade coverage:^[4] 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”,^[5] 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.

• 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).
• Not this Atlas’s ComplianceOps or 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”.^[6]

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.^[7]
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.^[8] The FCA fined Monzo £21,091,300 in July 2025 because its controls “failed to keep pace with its customer and product growth”.^[9]
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.^[10]

Good looks like: every product covered, every alert reasoned, useful reports on time, and a team that knows what it misses.

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.

The work is older than the label: national law implements the FATF Recommendations (2012 text, “as amended June 2026”).^[5] 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.^[10] We found no documented origin of the label.

FinTechOps moves money correctly; FinCrimeOps stops it being abused.

flowchart TB
  FT["FinTechOps<br/>money moves<br/>exactly once"]:::neutral
  FC["FinCrimeOps<br/>detect, investigate,<br/>report abuse"]:::core
  RK["RiskOps<br/>appetite and risk method"]:::neutral
  CO["ComplianceOps<br/>audit evidence"]:::neutral
  DO["DecisionOps<br/>rule and model engines"]:::neutral
  MO["ModelOps<br/>model validation"]:::neutral
  PR["PrivacyOps<br/>personal-data rights"]:::neutral
  FIU["FIU and<br/>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

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;^[6] 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”;^[6] this Atlas adds: no launch without screening and monitoring coverage.
5. Measure usefulness and misses, not just volume.^[10]
6. Humans own decisions; machines prioritise.

Non-goals. Zero false positives (that means missed crime); “defensive” filing;^[10] judging guilt.

Every FinCrimeOps function runs some version of five controls, mapped here to the FATF Recommendations:^[6]

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.^[14] 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.^[15] As of 23 October 2026 comments have closed (9 June) and the Federal Register lists no final rule.^[16]

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.^[12]
• UK, FCA-authorised firms within SYSC 6.3: an MLRO with “authority and independence”.^[17] 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.^[14]

This RACI is a proposal (R/A/C/I = responsible, accountable, consulted, informed; “MLRO” = whichever officer applies; detection engineering makes scenario changes).

Customers meet the controls repeatedly, not only at onboarding.

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<br/>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

If CDD cannot be completed, FATF R.10 says do not open (or end) the relationship and “consider making a suspicious transactions report”.^[6] 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.

• 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.

Engines are replaceable; the case record, clocks and feedback loop make the operation defensible.

flowchart TB
  S1["Customer and<br/>ID data"]:::neutral
  S2["Payment and<br/>ledger events"]:::neutral
  S3["Sanctions, PEP,<br/>media lists"]:::neutral
  E1["Screening<br/>engine"]:::core
  E3["Customer<br/>risk scoring"]:::core
  E2["Monitoring<br/>rules, models"]:::core
  Q["Alert queue<br/>priority, clocks"]:::core
  S4["Referrals and<br/>LE requests"]:::neutral
  CM["Case management<br/>evidence, decisions"]:::core
  D{"Decision"}:::decision
  O1["FIU report"]:::risk
  O2["Hold, restrict<br/>or exit"]:::risk
  O3["QA, MI and<br/>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

Design choices that matter more than vendor choice:

flowchart TB
  A["Alert, hit or referral"]:::neutral --> B["L1 triage<br/>enrich, check history"]:::core
  B --> C{"Explained by<br/>known facts?"}:::decision
  C -->|"yes"| D["Close with reason<br/>QA samples it"]:::core
  C -->|"no"| E["L2 case<br/>evidence and timeline"]:::core
  E --> F{"Need facts from<br/>the customer?"}:::decision
  F -->|"yes"| G["Scripted request<br/>no hint of suspicion"]:::risk
  G --> E
  F -->|"no"| H["Draft narrative and<br/>recommendation"]:::core
  H --> I{"MLRO: suspicion?"}:::decision
  I -->|"no"| J["Record no-report<br/>decision per policy"]:::core
  I -->|"yes"| K["File SAR/STR<br/>before the deadline"]:::risk
  K --> L{"Transaction pending?"}:::decision
  L -->|"UK: seek DAML"| M["Hold until notice or<br/>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

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.^[11]

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).^[18] US rules make a SAR and “any information that would reveal the existence of a SAR” confidential.^[19] Fraud teams, complaint handlers and data-access responses are typical leak points. The wall in practice:

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

• A sanctions true match. Freeze, then report to OFAC (US) or OFSI (UK) on their clocks (comparison).
• Urgent ongoing laundering. A US bank must notify law enforcement immediately by telephone, in addition to filing the SAR.^[19]
• Activity continues after a report. US continuing-activity SARs on a 90-day cycle are optional, as the October 2025 FAQs confirm.^[11]

Other US institution types have their own SAR sections, listed in FinCEN’s FAQ;^[11] sanctions clocks are in the US/UK table. Lab 3 codes these clocks.

The five controls and RACI say who does what; these playbooks cover the steps that most often go wrong.

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.^[25] 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.^[25]
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.^[26] FATF’s EDD examples include source of funds or wealth, senior approval and enhanced monitoring.^[6] 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”;^[6] the MLRs add changed circumstances such as new owners or inconsistent transactions.^[27] 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.

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.^[29]
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).

As of October 2026.

Answer who, what, when, where, why it is suspicious, and how, with amounts, dates, accounts and the trigger; describe grounds, not guilt (template). Wolfsberg notes that context can raise a report’s value and that feedback from authorities is the best indicator of quality.^[10]

Requests for information (RFIs) use pre-approved wording with no mention of monitoring, reports or law enforcement (template). A refusal or implausible answer is evidence.

Fraud and laundering meet in mule accounts that receive scam victims’ money, but the duties differ.

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).^[35] 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^[36] and may share under the 314(b) safe harbour after notifying FinCEN.^[37] 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.^[38] Each route has conditions.

Examples verified 2026-10-23, not recommendations.

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 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.^[40]
• 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.^[41] It “does not set forth enforceable standards”, and generative and agentic AI models “are not within the scope of this guidance”.^[42] Govern monitoring models through 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.

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.

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.

3. Tuning change request: evidence, approval, rollback.

Example status: syntax-checked (YAML), not executed.

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

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).

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).

"""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.

python3 screen.py | tail -6
python3 screen.py --with-alias | tail -6

Expected output (first run, then second run):

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.^[29]

Troubleshooting. A SyntaxError means Python older than 3.6; different scores mean the file changed.

Teardown. Lab 3 removes the folder.

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).

"""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.

python3 tm.py 12000 10000 7500 5000 2500

Expected output:

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;^[10] 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.

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).

"""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).

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):

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,^[48] 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.^[21] The continuing-SAR date follows FinCEN’s optional timeline (day 150, or 180 if the first SAR took 60 days).^[11]

Troubleshooting. A KeyError means a typo in NATION. US dates count calendar days, so file early before holidays.

Teardown. rm -r ~/fincrime-labs.

The first two apply the sourced cases in The problem it solves (screening failures have their own runbook); 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 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.^[34] Method: fraud signals (new account, device changes) plus pass-through scenarios (Lab 2) and information sharing. Success: a falling share of claims as receiver. Pitfall: fraud staff contacting a mule before AML decides.

Volume ratios describe quantity, not usefulness,^[10] so balance them (formulas are this Atlas’s).

Review operational metrics weekly and effectiveness quarterly; set targets from risk appetite, not peers’ ratios.

flowchart TB
  A["Scenario in production"]:::core --> B["Alerts and dispositions"]:::core
  B --> C["Metrics: escalation,<br/>reports, other-route share"]:::neutral
  C --> D["Below-the-line and<br/>coverage tests"]:::neutral
  D --> E{"Change needed?"}:::decision
  E -->|"no"| A
  E -->|"yes"| F["Tuning change request<br/>evidence and capacity"]:::core
  F --> G["MLRO approval and<br/>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

• 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) are minimums; US banks keep SARs and supporting documents five years from filing.^[19]
• Privacy. Coordinate data-access requests with PrivacyOps so responses do not reveal reports; the exemptions are national law.
• Fairness. Blanket exits exclude legitimate customers; FATF works on “mitigating unintended consequences”.^[5]

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

Cheaper alerts come from better data (aliases, identifiers, profiles), not faster analysts.

Team leads review daily, independent QA samples decisions, and internal audit tests the programme (a US minimum).^[14] Add automatic checks: list reconciliation, canary names, coverage reports and clock breaches raised as incidents.

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);^[31] OFAC within 10 business days for blocked property;^[32] possibly your supervisor (Starling “reported multiple potential breaches”).^[8]
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.

• “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.^[10]
• “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.^[40]

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”.^[49] 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.)^[50]
• 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.

flowchart TB
  A{"Are you an obliged<br/>entity under AML law?"}:::decision
  A -->|"no: partner bank is"| B["Do the work under<br/>contract and<br/>bank oversight"]:::neutral
  A -->|"yes"| C{"Daily alerts or<br/>onboarding volume?"}:::decision
  B --> C
  C -->|"low"| D["Compliance officer plus<br/>outsourced reviews"]:::neutral
  C -->|"high"| E{"Data and risk<br/>assessment in place?"}:::decision
  E -->|"no"| F["Fix data and risk<br/>assessment first"]:::risk
  E -->|"yes"| G["In-house team;<br/>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

This Atlas’s simplification: obliged-entity status is a legal question, and sanctions duties apply widely either way.

This is this Atlas’s model, not an industry standard.

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; coverage gate for launches. Milestone: first evidence-based tuning change.

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

Report narrative skeleton (adapt to your FIU’s form and guidance):

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):

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):

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 and tuning request complete the set.

See neighbours, fraud versus AML and US/UK sanctions. Operating models (this Atlas’s comparison; accountability stays with the MLRO or BSA officer in every model):

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).

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;^[11] the FFIEC examination manual still says banks should document decisions not to file,^[20] 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); 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;^[12] FCA-authorised firms within SYSC 6.3 also need an MLRO.^[17] US banks designate a BSA officer.^[14]

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).

• Monitoring beyond transactions (industry guidance). Wolfsberg’s MSA concept adds customer behaviour to transaction rules and retires tested routines that produce no value.^[10]
• EU direct supervision (planned). AMLA plans to select 40 entities during 2027 and supervise them from 2028.^[24]
• AI agents in case work (vendor claims). Vendors advertise autonomous KYC and alert agents;^[4] govern them under your own framework with human sign-off, as SR 26-2 excludes agentic AI.^[42]

• Prerequisites: how accounts and payments work (FinTechOps); basic risk vocabulary (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.

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);^[20] 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);^[8] 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.

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.

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.

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).

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.