ADR-010: Financial crime and fraud detection platform¶
| Status | Accepted |
| Date | 2026-04-10 |
| Deciders | CTO, CCO, CRO, Head of Payments |
| Affects repos | bank-payments, bank-aml, bank-risk-platform |
Status¶
Accepted — 2026-04-10
Context¶
Financial crime and fraud are related but distinct disciplines with different tooling requirements:
Fraud detection operates on the transaction path — it must score a transaction in real time (≤ 200ms, NFR-021) and block or flag suspicious activity before funds leave the bank. It relies on device intelligence, behavioural biometrics, network analysis, and transaction velocity signals.
AML / financial crime monitoring operates asynchronously — it analyses patterns of behaviour across time, detects typologies (structuring, layering, placement), and generates alerts for investigation. It does not need to block a transaction in sub-200ms.
The bank must decide: build fraud scoring in-house using Snowflake Cortex ML, use a specialist external vendor (BioCatch for behavioural biometrics, Featurespace ARIC, Feedzai, or similar), or a hybrid approach.
Capability breakdown¶
Fraud detection components¶
- Device intelligence and fingerprinting — is this device known, is it behaving normally?
- Behavioural biometrics — how is the user interacting? Typing cadence, navigation patterns, mouse/touch behaviour
- Transaction velocity and network scoring — is this transaction unusual for this customer, this merchant, this time of day?
- Real-time ML scoring — composite fraud score < 200ms on transaction path
AML / financial crime components¶
- Typology rules engine — structured rules for known patterns (smurfing, rapid transfers, round-dollar transactions)
- ML behavioural scoring — anomaly detection for unusual customer behaviour over time
- Network analysis — connected party analysis; identifying mule networks
- Alert and case management — investigation workflow, SAR drafting, submission
Options evaluated¶
Option A — Build in-house (Snowflake Cortex ML + custom)¶
Build fraud scoring models in Snowflake Cortex. Build AML typology rules and ML models in Snowflake. Write-back fraud scores to Postgres for transaction path use. Build alert management in SD03 (bank-aml).
Strengths: Full control; no vendor dependency; models trained on proprietary data; cost-effective at scale; models improve as data accumulates; aligned with AP-007 (Evolution) and SG-007 (AI-native).
Weaknesses: Behavioural biometrics require device SDK — hard to build well in-house; cold start problem — new bank has no fraud history to train on; real-time scoring latency requires careful architecture; significant time-to-capability vs a vendor with pre-trained models.
Option B — BioCatch (behavioural biometrics) + Snowflake for transaction scoring¶
BioCatch is the market leader in behavioural biometrics — it analyses how a user interacts with a device (typing patterns, navigation, touch/swipe behaviour) to detect account takeover, social engineering, and mule activity in real time. Combined with in-house transaction ML scoring in Snowflake.
Strengths: BioCatch is proven at major banks; solves the hardest part of fraud (account takeover and social engineering) with pre-trained models; SDK integration into mobile app; provides signal the bank cannot generate internally; in-house Snowflake scoring handles transaction patterns; hybrid approach balances control and capability.
Weaknesses: Vendor dependency for the biometrics layer; BioCatch licensing cost; SDK adds to mobile app complexity; data sharing with a third party has regulatory implications.
Option C — Full-stack fraud vendor (Featurespace ARIC, Feedzai, NICE Actimize)¶
End-to-end fraud and AML platform from a single vendor. Pre-trained models, managed rules engine, case management, SAR workflow.
Strengths: Fastest time to capability; pre-trained models with broad industry data; integrated fraud and AML workflow; regulatory reporting support.
Weaknesses: Significant licensing cost; heavy implementation; vendor lock-in on core risk capability; models are black-box — explainability for regulatory purposes is harder; data must be shared with vendor; overkill for a startup bank; KISS violation.
Option D — Hybrid: BioCatch (biometrics) + Snowflake (transaction ML) + in-house AML rules¶
BioCatch for behavioural biometrics at the customer session layer. Snowflake Cortex for transaction-level fraud ML and AML typology models. In-house rules engine for AML detection. Alert management built in SD03.
Perspective evaluation¶
| Perspective | In-house only | BioCatch + Snowflake | Full-stack vendor | Hybrid (D) |
|---|---|---|---|---|
| Performance & Scalability | ~ Cold start risk | ✓ | ✓ | ✓ |
| Strategy | ✓ Full control | ✓ Best of breed | ~ Vendor lock-in | ✓ |
| Evolution | ✓ Models improve | ✓ | ~ Vendor-dependent | ✓ |
| Integration | ✓ | ~ SDK complexity | ~ Heavy integration | ~ |
| Cost | ✓ | ~ BioCatch licensing | ✗ High | ~ |
| Regulatory | ✓ Full auditability | ~ Data sharing | ~ Black box models | ✓ |
| Capability | ~ Cold start | ✓ | ✓ | ✓ |
| Resource | ~ ML expertise needed | ✓ Vendor expertise | ~ Platform skills | ✓ |
See perspectives.md for how to use these evaluation lenses.
Principles alignment¶
| Principle | Assessment |
|---|---|
| AP-001 KISS | Hybrid is more complex than in-house but simpler than a full-stack vendor platform |
| AP-003 Compliance | Fraud scoring on payment path is a GATE; AML monitoring is AUTO/ALERT/LOG |
| AP-004 Security | BioCatch data sharing requires DPA and security assessment |
| AP-006 Cost effective | BioCatch licensing is justified by the capability gap it fills for a new bank |
| AP-007 Evolution | In-house Snowflake models improve with data; BioCatch is supplementary |
Recommendation (pending decision)¶
Option D — Hybrid: BioCatch for behavioural biometrics + Snowflake Cortex for transaction scoring + in-house AML:
- BioCatch integrated via mobile SDK for session-level behavioural biometrics. Score returned per session and fed into the fraud scoring composite. Addresses account takeover and social engineering — the fraud types hardest to detect without behavioural data.
- Snowflake Cortex for transaction-level fraud ML — velocity rules, network scoring, merchant risk, time-of-day anomalies. Models trained on proprietary transaction data as it accumulates.
- Composite fraud score written back to Postgres via write-back API (≤ 60s for background; the transaction-path score is from a materialised table, not a live query).
- Real-time payment gate reads the pre-computed fraud score from Postgres. If a live-call is needed for high-value transactions, a synchronous Cortex inference endpoint is called (≤ 200ms target, NFR-021).
- AML monitoring built in-house in Snowflake (SD03 bank-aml) — typology rules + ML behavioural scoring. No external AML platform at launch.
Revisit full-stack AML platform at 12 months if in-house AML alert volumes and complexity exceed what the team can manage.
Relevant viewpoints¶
- Functional viewpoint — Fraud scoring on payment path; AML monitoring pipeline; alert and case management
- System viewpoint — BioCatch SDK in app; score ingest to Snowflake; write-back to Postgres; fraud gate in payment service
- Security viewpoint — BioCatch data sharing DPA; model explainability for regulatory purposes
- Operational viewpoint — False positive rate monitoring; alert queue management; model performance tracking
See viewpoints.md for guidance on producing these viewpoints.
Signoff record¶
| Date | Name | Role | Status |
|---|---|---|---|
| 2026-04-10 | Ross Millen | CTO | Approved |
| 2026-04-10 | Ross Millen | Head of Architecture | Approved |
| 2026-04-10 | Ross Millen | Head of Data | Approved |
Capabilities¶
| Capability | Description | Relationship |
|---|---|---|
| CAP-026 | Exception-only case routing | enabled — AML alert queue routes only confirmed typology matches |
| CAP-027 | Automated AML submission pipeline | enabled — in-house AML typology rules and ML models produce SAR inputs |
| CAP-038 | Real-time fraud scoring & block | enabled — composite fraud score gates payments |
| CAP-040 | Scam warning system (payee risk scoring) | enabled — fraud scoring architecture extends to payee risk assessment |
| CAP-062 | CDD automatic tier assignment | enabled — ongoing AML monitoring triggers CDD tier re-evaluation |
Related decisions¶
| ADR | Title | Relationship |
|---|---|---|
| ADR-002 | Snowflake as the analytics and risk compute platform | Snowflake Cortex is the transaction ML scoring engine |
| ADR-036 | Decision result publication — governed Snowflake → Neon write-back contract | fraud actions published back to Postgres via decision inbox |
All ADRs
Compiled 2026-05-22 from source/entities/adrs/ADR-010.yaml