Real-time fraud and AML screening for cross-border remittances

Toggle to see the manual review queue collapse: with AI, every payment is scored and screened in real time, and only high-risk ones reach an analyst. Blueprint of a standard fraud + AML flow; figures in the case study are cited industry benchmarks.

1. Remittance transaction (source): A cross-border transfer: sender, recipient, amount and corridor arrive in real time.
2. Sanctions / PEP lists (store): Watchlists (sanctions and politically-exposed persons) the payment must be screened against before it clears.
3. Manual review queue (human): Today an analyst opens each flagged payment and checks it by hand — the queue is where days are lost.
4. Risk signals (AI): Velocity, device fingerprint, behaviour and corridor risk are computed for every payment in milliseconds.
5. Sanctions / PEP screening (AI): Names are matched against watchlists at the same time, not in a separate slow step.
6. ML scoring + rules (AI): A model trained on confirmed fraud and clean history scores the payment; rules add hard policy checks.
7. Analyst review + SAR/STR (human): Only high-risk payments reach a person, who confirms and files a suspicious-activity report; the model learns from the outcome.
8. Cleared / settled (sink): Low-risk payments pass straight through and settle without a human touching them.

Industry-typical projection, not a delivered NeuralYug result. Math uses cited benchmarks — ~60% fewer false positives, sub-300 ms decisions and ~2x fraud caught — on an assumed ~2% alert-trigger rate. Real numbers depend on data quality, corridors and model tuning. Nothing is stored; all figures compute in your browser.

Blueprint topology built from standard components; tap any node for its role and the real tech. Illustrative, not a live deployment.

1. Ingest API gateway (API, REST · gRPC): Every remittance enters here with sender, recipient, amount and corridor. Validates the payload, applies rate limits, and publishes each transaction as an event onto the stream — nothing sits in a manual queue.
2. Event stream (Queue, Kafka · Flink): A durable log plus stream processing. Flink computes rolling signals — transaction velocity, corridor risk, device reuse — in the moment, so scoring sees fresh behaviour rather than a nightly batch.
3. Feature store (Cache, Feast · Redis): Serves the same features online (for real-time scoring) and offline (for training), so the model behaves in production exactly as it did in testing. Low-latency reads keep the decision under the latency budget.
4. ML risk scorer (Model / AI, XGBoost + graph features): A gradient-boosted model over behavioural features, enriched with graph features (shared devices, mule-network structure) from the transaction graph. Trained on confirmed fraud and clean history; outputs a calibrated risk score.
5. Transaction graph (Data, Graph DB · Neo4j): Stores sender–recipient–device relationships. Graph features (community, shortest-path to known fraud) let the scorer catch laundering rings that per-transaction rules miss.
6. Rules engine (Service, Policy DSL): Enforces hard policy the model must never override — amount thresholds, blocked corridors, regulatory limits. Runs alongside the score, not before or after it, so policy and ML both land on the decision service together.
7. Sanctions / PEP screening (External, External · OFAC · UN lists): Fuzzy-matches sender and recipient against sanctions, PEP and watchlists in real time. Called through the decision service with retries and a circuit breaker; every hit is recorded for audit.
8. Decision service (Service, Score + rules + screening): Combines the risk score, rule verdicts and screening result into one call, all inside a ~300 ms budget. Low-risk clears and settles automatically; high-risk is routed to an analyst with the evidence attached.
9. Case store (Data, PostgreSQL): System of record for every decision, its reasons and the analyst's outcome. Row-level security isolates data; the immutable decision trail is what stands up to NRB and FATF scrutiny.
10. Analyst console (Client, Next.js client): Where a compliance analyst reviews only the high-risk cases, sees why each was flagged, and confirms or clears it. Their outcome feeds back to retrain the scorer — the model keeps learning.
11. FIU / STR reporting (External, External · goAML): When an analyst confirms suspicious activity, a suspicious-transaction report is filed to Nepal's Financial Information Unit. The case store holds the full lineage behind every filing.