Shivya Technologies
Real-Time Fraud & AML Detection
Streaming machine learning makes the call in milliseconds. Generative AI explains it afterward. The two never swap roles.
The problem
A rules engine that was both too strict and too slow to adapt.
False positives cost revenue
A hand-written rules engine declined a meaningful share of legitimate transactions — lost volume, support cost, and merchant churn, all from a system that couldn't tell a false alarm from a real one.
Rules go stale in weeks
Fraud patterns shift faster than a change-approval cycle can keep up with. By the time a new rule ships, the pattern it targets has already moved on.
AML alerting was almost all noise
Overnight batch alerting produced large volumes of suspicious-activity flags, the vast majority dismissed on review — analysts spent their time reconstructing context, not judging risk.
No memory across entities
A device shared across a dozen "unrelated" accounts is invisible to a system that scores one transaction at a time with no relationship signal.
The high-level solution
A three-tier decision system.
Deterministic guardrails handle what must always be explainable by construction. A real-time model scores everything else. Generative AI joins only after a decision has already been made — to explain it, never to make it.
Tier 1 — Guardrails
Sanctions lists, velocity hard-stops, blocked identifiers. Kept as deterministic rules on purpose: some decisions must be provable to an auditor by construction, not by explanation after the fact.
Tier 2 — Real-time ML
A model scores every transaction in milliseconds using behavioral, device, and relationship signals, returning a calibrated risk score with feature-level attributions.
Tier 3 — GenAI investigation
For elevated-risk cases, an LLM assembles a case narrative — what happened, what drove the score, what typology it resembles — and drafts the regulatory filing narrative for a human to confirm.
The model proposes. It never decides. The block/allow decision stays with a deterministic, auditable system. That separation is what makes the design defensible to a regulator, and it's the single most common mistake to get wrong in a fraud project like this.
Architecture
Three paths, three different latency budgets.
Synchronous decision path
Event
Checks
Risk Score
Decision
Target: under 100ms at the 99th percentile, including a feature-store lookup and a model inference call.
Streaming feature path
Stream
Processing
(Online + Offline)
Enrichment
The same windowed features feed both real-time scoring and model training — the single biggest source of train/serve mismatch, closed by construction.
Investigation path
Case
Gathering
Narrative
Grounding Check
Review
Every generation is logged with its grounding score. Ungrounded output is regenerated once, then escalated to a human with the raw evidence attached.
Tech stack
What it's built on.
This engagement ran AWS-native, matched to the client's existing cloud estate — the same pattern deploys equally well on Azure or GCP.
Pipeline
How it got built.
Foundation
Landing zone, event streaming infrastructure, and a security baseline — private networking, key management, and audit logging from day one.
Streaming & features
Event ingestion and windowed feature computation, with one feature definition shared by training and real-time serving.
Model training
Temporal train/test splits (never random — label maturity matters), bias evaluation across sensitive segments, and a versioned model registry.
Real-time serving
A low-latency scoring endpoint behind the decision API, with a rules-only fallback if the model ever fails or times out — a degraded decision beats a blocked payment.
Graph enrichment
Relationship signals — shared devices, shared beneficiaries, circular fund flows — that a flat, per-transaction model can't see on its own.
Investigation layer
LLM-assisted case narratives with citation requirements and guardrails, evaluated against a hand-labelled set of real cases before it ever reaches an analyst.
Monitoring & retraining
Drift detection, a scheduled retraining cadence, and a shadow-then-canary rollout for every new model version.
Outcomes
What moved.
| Metric | Before | Target |
|---|---|---|
| Fraud detection rate (at fixed false-positive rate) | ~62% | 85–90% |
| False positive rate | ~3.0% | 0.6–0.9% |
| Decision latency (p99) | ~140ms | <100ms |
| AML alert precision | ~5% | 25–35% |
| Analyst time per case | ~35 min | 8–12 min |
Figures are illustrative engineering targets for this solution pattern, based on comparable production systems — not a guaranteed result for any specific deployment. See our Terms.
Fighting a similar fraud or AML problem?
Tell us about your rules engine, your volume, and where it's breaking — we'll tell you honestly whether this pattern fits.
Talk to us