Case Study · Banking & Payments

Unified Fraud Detection Platform

Most fraud decisions don’t need a large language model. The architecture is built around knowing which ones do — and what it costs to find out.

01 — The problem

Money moves faster than review

Payment rails carry enormous volumes of legitimate activity, and fraud hides inside that flow rather than beside it.

The forms it takes are varied and keep changing: cards used from geographies the cardholder has never visited, wire transfers initiated after a customer has been socially engineered into handing over credentials, accounts opened with synthetic identities, deposits deliberately structured to stay under reporting thresholds, and credential-stuffing runs that follow a breach elsewhere.

What they share is a single operational constraint. The decision has to be made while the transaction is still in flight, on data that is incomplete, and at a volume where the cost of every individual decision matters. A system that is accurate but slow does not prevent fraud. A system that is fast but indiscriminate buries the fraud team in false positives and blocks legitimate customers.

02 — Why the obvious approach fails

An LLM in the hot path does not survive contact with production

The instinctive response to a hard classification problem in 2026 is to route it to a large language model. Applied to a payment stream, that design breaks on three independent constraints — and it only takes one to make it unviable.

  • Latency. A card authorisation gives the issuer a decision window measured in a second or two. Multi-step reasoning does not fit inside it.
  • Cost. Inference priced per transaction, applied to an entire payment stream, produces a cost curve that grows with the business rather than flattening against it.
  • Data residency and control. Sending transaction detail to an external model creates a compliance exposure that many regulated institutions cannot accept, whatever the accuracy gain.

The relevant insight is that the overwhelming majority of transactions are not ambiguous. They are cleanly legitimate or cleanly suspect, and cheap methods resolve them well. Expensive reasoning is only warranted for the residue that cheap methods cannot separate — which is a small fraction of the flow.

03 — The approach

Tiered decisioning across two lanes

Every event enters a common scoring contract and is escalated only as far as it needs to go. Four tiers, arranged by increasing cost and increasing depth of reasoning.

Machine learning is not one tier among four — it is the scoring substrate the whole platform shares. Each tier emits evidence with a confidence weight, and a scoring service fuses those signals into one running fraud score. That is what makes the tiers composable rather than four disconnected detectors arguing with each other.

01

Machine learning scoring

Trained models score the event against known fraud patterns and historical behaviour, producing the base risk score that routes everything downstream. Most traffic is resolved here.

Real-time
02

Deterministic rules

Hard conditions the business can state and audit: geography inconsistent with the cardholder’s registered residence, velocity breaches, amount thresholds, new-beneficiary patterns. Cheap, explainable, and defensible to a regulator.

Real-time
03

Small language model classification

A compact model, run locally, categorises behaviour into risk classes that the first two tiers cannot express — phishing-shaped interaction patterns, coached-customer language, interaction abuse. No data leaves the estate.

Real-time
04

Agentic investigation

For what survives the first three tiers, orchestrated agents assemble context across systems, reason over it, and return a verdict together with the evidence behind it. Slower and materially more expensive — which is precisely why it is reached last.

Near real-time
REAL-TIME LANE — DECIDES IN THE FLOW Payment event 01 ML scoring base risk score 02 Deterministic rules geography · velocity 03 Small language model behaviour classes Confidence gate fused score Approve or decline clear ambiguous — escalate NEAR-REAL-TIME LANE — BOUNDED REVIEW WINDOW 04 Agentic investigation verdict + evidence Human investigator timeout or policy new features and rules — the cheap tiers absorb what the expensive tier learns
Escalation is the mechanism. Traffic that the cheap tiers resolve never reaches the agentic lane; what does reach it returns either a verdict inside the review window or a case for a human. The dashed return path is where the compounding value sits.

04 — Decision policy

What the platform does while it is still thinking

Escalation raises an obvious question: the customer is waiting. The platform issues a provisional outcome immediately and flags the event as under review, and the agentic tier has a bounded window to return something better. If it does not, or if the result stays ambiguous, the case routes to a human.

Two design rules make that policy safe rather than reckless.

The provisional default is set by reversibility, not by confidence

Where a transaction can still be held or unwound — a card authorisation before settlement — provisionally approving and letting the agent finish is sound. Where the rail is irreversible, an instant transfer that is gone the moment it clears, the same default is a loss. There, the correct provisional action is a short hold or a step-up authentication challenge, not an approval that cannot be taken back.

The review window is a property of the rail, not a single number

Card authorisation leaves no room for a multi-minute review, so tiers one to three decide and the agentic tier runs after authorisation — informing the hold at settlement and the next decision on that account. Wire and ACH genuinely can be queued for a period, and there the full near-real-time flow works as designed. One architecture, calibrated per rail.

Guardrail

A score below threshold never means automatic rejection. It means further checking or human investigation. And above a defined exposure, cases go to a human regardless of how confident the platform is — automation is bounded by policy, not only by score. Thresholds themselves are calibrated to each institution’s risk appetite and false-positive tolerance; they are not a fixed constant of the design.

05 — System architecture

Two tiers, one contract

Intelligence is created in a lab environment and executed in production, with a hard boundary between them. Production never handles raw data — it receives structured runtime signals over authenticated APIs, evaluates them with pre-trained agents and models promoted through gated release, and returns a score with a recommended action.

Digital banking Payment platform Onboarding CLOUD PLATFORM — COMPUTE · STORAGE · NETWORK · IAM API gateway — authentication, authorisation, rate limiting Message queue — ordered event stream, replay, back-pressure APPLICATION MICROSERVICES Scoring service Rules service SLM classifier Case management ML model serving tiers 01–03 Agentic orchestrator agents A1 … Ax — tier 04 DATA PLANE Feature store versioned signals Object store evidence packages Audit log every decision MODEL DEVELOPMENT TIER — LAB Ingestion, feature engineering, cataloguing Behavioural modelling and ML pipelines Agent design and orchestration simulation MLOps · LLMOps · DataOps lifecycle Version control and gated promotion promote telemetry — continuous retraining
The queue is what makes escalation possible: it decouples the decision the caller is waiting on from the investigation that continues afterwards. The lab tier holds all raw data and training; production holds only promoted artefacts and the signals it is sent.

06 — What it delivers

A cost curve that bends the right way

The commercial argument follows directly from the architecture. Because expensive reasoning is reserved for the ambiguous residue, inference cost scales with genuine difficulty rather than with transaction volume. And because the agentic tier returns evidence and new patterns that are pushed back down into the rules and features of the cheap tiers, the residue itself shrinks over time.

The expensive tier’s job is to make itself less necessary. That is the difference between a platform that gets cheaper the longer it runs and one that gets more expensive with every transaction the business wins.

How success is measured

These are the criteria an engagement is held to — set as targets at design time and instrumented from day one, not claimed in advance.

DimensionWhat is measured
Detection qualityFraud caught per unit of review effort, and the false-positive rate borne by legitimate customers
Decision latencyReal-time lane held inside the rail’s authorisation budget; escalated cases resolved inside the agreed review window
Escalation ratioShare of traffic reaching tier four — the direct driver of inference cost, expected to fall as feedback lands
Analyst loadCases routed to humans, and the proportion arriving with a usable evidence package attached
AuditabilityEvery decision reconstructable: which tier decided, on what evidence, under which model and rule version

07 — Engagement shape

Where this starts

Nothing here requires a bank to replace its existing fraud stack to find out whether the approach holds. The first tier is usually already in place in some form; the work is to put a shared scoring contract around it, instrument the escalation ratio, and prove on real traffic that the ambiguous residue is small enough for agentic reasoning to be affordable.

That is a scoped, measurable piece of work with a decision point at the end of it — which is how this kind of programme should begin.

Tech Manthan · techmanthan.com · info@techmanthan.com