UK Transaction Monitoring Alert Adjudication — Solution Documentation

A production-ready Rainbird decision model that adjudicates transaction-monitoring alerts the way an experienced L2 analyst does: it takes an alert, its transactions and the customer's KYC context, and decides one of four outcomes — Close as False Positive, Request Information, Escalate to Investigation, or Recommend SAR — each with a certainty, a set of contributing evidence lines, a written rationale that cites the governing regulatory standard, a recommended next step, and second-reviewer routing where required. It is a generic demonstration and reusable Accelerator: no real institution is referenced, and every operational threshold is a recalibratable policy fact.

1. What the model decides

Outcome	Meaning	Governing standard
Recommend SAR	Reasonable grounds to suspect money laundering; refer to the nominated officer	POCA 2002 s.330; R v Da Silva ("more than fanciful"); s.333A tipping-off caution
Escalate to Investigation	Beyond merely unusual; enhanced scrutiny before a reporting decision	MLR 2017 reg 28(11) and reg 33; JMLSG Part I
Request Information	Unusual but not yet suspicious; make neutral enquiries without disclosing the alert	JMLSG unusual-vs-suspicious distinction; POCA s.333A
Close as False Positive	Activity is consistent with the known customer profile once benign patterns are applied; rationale documented	MLR reg 28(11) satisfied; FCA FCG documented-rationale expectations

Exactly one outcome is produced for every alert. When the data cannot support any determination, the model defaults to Request Information at certainty 65 — it never closes an alert out of ignorance.

2. Architecture

The graph is a layered pipeline of 157 rules:

1. Transaction feature derivation — pure arithmetic over the injected transaction set: inbound/outbound/cash totals, near-threshold cash deposit clusters and their date span, pass-through days and outflow ratio, cash-inflow percentage, expected turnover multiple, distinct unrecognised payer count, round-amount wire share, known-counterparty coverage, salary-band credit recognition, and FATF jurisdiction exposure. Every aggregation over a possibly-empty set is count-guarded.
2. Customer risk context — ten named risk factors (onboarding rating, PEP, credible financial-crime media, prior SAR, alert volume, dormancy, account age, KYC staleness) map through a points table into a summed score and four tiers: Low (<10), Standard (10–29), Elevated (30–59), High Risk Context (≥60).
3. Typology sub-models — seven typologies, each graded strong/moderate with its own certainty: Structuring (90/75), Rapid Movement (85/72), Money Mule Pattern (92 behavioural, 95 on an interbank fraud-report match / 75), Expected Activity Mismatch (82/70), High Risk Jurisdiction Exposure (88 call-for-action / 68 enhanced monitoring), Cash Intensity Anomaly (85/70, business customers only), Round Amount Corporate Flows (72). Strong signals approach the POCA suspicion standard; moderate signals mark JMLSG "unusual" activity.
4. Defeaters (false-positive suppression) — four benign explanations: a dominant declared salary pattern, recognised-counterparty coverage of at least 80% of flow, declared seasonal trading (with at least one comparable prior season), and genuine documented case-file explanations (property sale, loan drawdown, inheritance). A data-driven suppression map states exactly which explanation may set aside which typology; deliberate-conduct typologies (structuring, mules, call-for-action exposure) are absent from the map by design and can never be explained away.
5. Control layer — closure hard blocks (fraud report match, fraud database marker, unresolved sanctions match, call-for-action exposure, stale KYC, credible adverse media, prior SAR, staff-raised concern) and defeater overrides that void every benign explanation when a hard risk state exists.
6. Candidate outcomes and precedence ladder — graded candidate rules produce SAR, Escalate, RFI and Close candidates; a count-gated ladder resolves them with SAR > Escalate > RFI > Close and a Request Information default. Closure is an affirmative finding: it additionally requires transaction data present, a known risk rating and customer type, a positive expected turnover on file, known PEP/media/fraud/sanctions/prior-SAR screening results, current KYC, and a customer below the High Risk Context tier — so unknowns can never close an alert.
7. Evidence and rationale — every disposition emits human-readable evidence lines with actual figures (deposit counts, spans, ratios, multiples), set-aside notes for suppressed indicators, disregard notes for voided explanations, the customer risk tier, and a written rationale citing the governing standard verbatim. PEP dispositions, High Risk Context customers, and all SAR recommendations carry a Second Reviewer Required routing fact.

Certainty design

Feature and plumbing rules run at certainty 100. Typology rules carry graded certainties reflecting indicator strength; candidate rules use weight-1 gates so the final outcome certainty tracks the dominant signal (for example, a structuring-strong SAR lands at 90, a fraud-match mule SAR at 95, a clean no-indicator closure at 83). Where several rules support the same fact, the strongest wins.

Policy calibration surface

Twenty-six thresholds live as facts on the TM Policy instance (near-threshold band £8,500–£9,999.99 against a £10,000 cash threshold, structuring counts and windows, pass-through ratios and windows, mule payer count and floors, mismatch multiples, seasonal allowance, coverage share 0.8, round-wire share 0.5, salary band ±15%, KYC staleness 24 months and closure limit 12 months, and more). Recalibration is a data change — no rule edits. The FATF jurisdiction table, the suppression map, the risk points map, and the documented-explanation and directly-reportable registries are likewise data tables consulted by generic rules. Three policy constants are encoded directly in rules because the policy states them as fixed definitions rather than tunable thresholds: the cash-intensity strong test (declared ≤5% cash, ≥60% cash inflows) and the adverse-media recency bar (≤24 months).

3. Regulatory grounding

The model implements MLR 2017 regs 18, 19, 27(8), 28(11), 33 and 35; POCA 2002 ss.330, 331, 333A (with s.335/336 consent mechanics deliberately out of scope, handled in the SAR process after referral); the JMLSG Part I monitoring and unusual-vs-suspicious guidance; FCA SYSC 6.3 and the Financial Crime Guide's documented-rationale expectations (including FCG 3.2.5A on automated alert triage); the FATF lists and typology reports; and the Cifas/interbank fraud-reporting context. The complete bidirectional cross-reference — every provision to its implementing rules, and every rule family to its regulatory basis, reconciling to all 157 rules — is in Regulatory Cross Reference Documentation.md.

4. How to query the model

Primary decision surface (query per alert):

• <alert> has adjudication outcome — the single resolved outcome with its certainty.

Companion surfaces (query on the same session, after the outcome, for best latency):

• <alert> has adjudication rationale — the written, citation-bearing rationale with the full evidence list joined in.
• <alert> has contributing evidence — the individual evidence lines (plural).
• <alert> has recommended next step — File SAR With Nominated Officer / Assign To Investigations Queue / Issue Neutral Customer Enquiry / Close With Documented Rationale.
• <alert> has review requirement — Second Reviewer Required, where applicable.
• <alert> exhibits typology — the surviving typologies (plural).

Data contract (injection)

Per alert, inject: concerns customer, has alert type, has alert source, has documented explanation type (use No Documented Explanation when none), has inbound fraud report match, has unresolved sanctions match, and one has alerted transaction per transaction. Per transaction: amount, direction, channel, counterparty, jurisdiction, date. Per customer: the fourteen KYC facts (customer type, risk rating, PEP flag, adverse media relevance — plus credibility and age in months when relevance is not None — months since KYC refresh, expected monthly turnover, account age, dormancy flag, prior alert count, prior SAR flag, fraud database marker, salary payer — use No Declared Salary Payer when none — typical salary amount, declared cash intensity percent), plus has expected counterparty rows and has declared seasonal peak month where applicable.

When every fact is injected, runs are question-free. When facts are omitted, the model asks only the human-answerable KYC and case-file questions (every question supports "unknown"); systems-of-record data is never asked. Interactive answers are submitted one per /response call.

Feed-contract duties (validated by dedicated tests): the transaction feed must supply attribute-complete rows, non-negative amounts, and only review-period transactions. The model's behaviour on malformed rows is pinned and documented by tests A08 (negative amount), A09 (stray out-of-window deposit) and RT3 (dangling transaction reference) rather than silently corrected — data quality is enforced upstream, where it belongs.

5. Verification

The delivered graph passed the full verification loop live on the Rainbird engine:

• Acceptance suite — 77/77 pass with engine-exact certainties: 40 scenario tests (every typology at both grades, every defeater, every override, every control block, the context-tier boundaries) and 37 adversarial tests (exact policy boundaries such as outflow ratio 0.9 at 3 days, coverage exactly 0.80, salary band edges £2,210/£2,990, context score exactly 60, round-wire share exactly 0.5, KYC at exactly 12 and 24 months; override collisions; multi-alert isolation on one customer; distinct-payer counting; forged-explanation attempts).
• Interactive grade: a sparse-injection run asked 15 questions and resolved to the same outcome and certainty as its fully-injected equivalent.
• Additional red-team probes — 12/12 safe: unknown-heavy runs (every question skipped) and missing-customer runs default to Request Information at 65 — ignorance never closes an alert; empty transaction sets cannot close; same-day structuring clusters (span 0) still fire; band edges behave exactly at £8,500/£9,999.99/£10,000; a High Risk Context customer cannot be closed even with a genuine documented explanation; forged explanation labels (e.g. injecting "Salary Pattern" as a documented explanation type) are rejected by the registry; the suppression map does not over-extend (seasonal trade cannot excuse rapid movement); coverage cannot be claimed vacuously against an empty expected-counterparty set. Nine of these probes are included in the delivered Studio test suite (Rainbird Studio Test Suite (Main and Adversarial).json, tests RT2 to RT10) so the suite carries the adversarial coverage permanently.
• Simplification review: an independent review confirmed no dead or redundant rules and no over-fitting — every rule traces to a requirement and every certainty is pinned by the test suite.

6. Requirement → rule coverage

The requirements register (alert intake; feature derivation; the seven typology sub-models; the customer risk context layer; the four defeaters and suppression map; defeater overrides; closure blocks and the unknown-never-closes principle; the four outcome families; the precedence ladder; evidence; rationale; next steps; review routing; policy parameterisation) maps onto the rule families B1–B26 in Regulatory Cross Reference Documentation.md Part B, which reconciles to all 157 rules. The same document provides the regulation-side view (Part A).

7. Deployment and Studio testing

The graph is deployed in your Rainbird account as “UK TM Alert Adjudication”. In Rainbird Studio, open the map of that name, then:

1. Import Rainbird Studio Test Suite (Main and Adversarial).json (the 77-test acceptance suite plus the 9 red-team regression tests, 86 in all) into the Studio test suite and run them — all 86 pass with the expected certainties shown.
2. Or run an interactive session: query has adjudication outcome for a new alert name and answer the questions; the model asks only what a case handler could know and accepts "unknown" on everything.

To reuse the model elsewhere, import the graph XML (graph.xml) into any Rainbird account — the XML is the complete, self-contained graph.

8. Natural-language prompts (Rainbird NL endpoints)

The prompts below are generated verbatim from tested injection payloads and are alert-explicit (they name the alert, not just the customer, so the NL agent queries the correct subject). Note: the raw /nl/interact API and the Studio NL agent run on different backends — verify NL behaviour in Studio; a transient "Invalid query (selected by LLM)" from the raw endpoint is a backend outage, not a model fault, and resolves on retry. The NL narrator may render bare numbers with a currency symbol of its own choosing. /nl/explain (with a session and fact ID) produces audit-quality narratives of any result and was verified live.

Prompt A — data-rich (straight-through, expect Close as False Positive): "Alert ALT-E01 concerns customer Nina Fell, alert type Profile Deviation Rule, source Automated Monitoring, no documented explanation, no inbound fraud report match, no unresolved sanctions match. Nina Fell is a Personal customer, risk rating Low, not politically exposed, no adverse media, KYC refreshed 3 months ago, expected monthly turnover 3000, account open 60 months, not dormant, 0 prior alerts, no prior SAR, no fraud database marker, no declared salary payer, declared cash intensity 0 percent. The alert has one transaction: 2500 inbound by Faster Payment from Orchard Supplies in the United Kingdom on 10 July 2026. What is the adjudication outcome for alert ALT-E01?"

Prompt B — moderately specified (expect Recommend SAR via structuring): "Alert ALT-E02 concerns Zoe Hart, a Low-risk Personal customer with expected monthly turnover 30000 and clean screening (no PEP, no adverse media, no fraud or sanctions flags, no prior SAR, KYC 3 months old, account 60 months). The alert covers three cash deposits at the branch counter: 9000 on 1 July 2026, 9200 on 10 July 2026 and 9400 on 20 July 2026, all in the United Kingdom. What is the adjudication outcome for alert ALT-E02, and why?"

Prompt C — sparse (interactive; the model asks the KYC questions): "Alert ALT-FQ1 concerns customer Iris Whitfield and contains one inbound Faster Payment of 2600 from Weald Design Partners on 1 July 2026 in the United Kingdom. What is the adjudication outcome for alert ALT-FQ1?"

9. Design decisions and scope notes

• Alert-level adjudication: each alert is adjudicated on its own transactions; customer-level context (rating, PEP, media, history) is shared. Two alerts on the same customer can legitimately reach different outcomes (verified by test A11/A12).
• Deliberate-conduct typologies are never suppressible: no benign explanation can set aside structuring, mule patterns, or call-for-action exposure — the suppression map omits them by design.
• Staff-raised alerts bind: per the K Ltd line of authority, a staff-raised alert always at least escalates, blocks closure, and voids benign explanations. External referrals carry no such special treatment.
• Sanctions and DAML mechanics are routed, not decided: an unresolved sanctions match escalates into the firm's sanctions process; consent/moratorium mechanics (POCA s.335/336) live in the SAR process after nominated-officer referral.
• Unknown never closes: closure requires affirmative, current, known data across screening, profile and transactions. All unknown-heavy paths were probed live and default to Request Information.
• Jurisdiction table currency: the country rows mirror the FATF Call for Action and Increased Monitoring lists and should be refreshed after each FATF plenary.