B2B journey

Real-time UPI fraud.

A PSP's fraud SOC · 30M UPI legs a day · sub-second decisions or the transaction declines

A payments service provider wants verdicts that fire before the UPI leg authorises — not minutes after, when the money is gone.

Marketing claimb2b-fraud-sub-200ms
See the bank story Talk to us
The story · 4 scenes

Beginning to end.

A PSP's fraud SOC · 30M UPI legs a day · sub-second decisions or the transaction declines
·A payments service provider wants verdicts that fire before the UPI leg authorises — not minutes after, when the money is gone.
  1. Scene 01 · Classify the leg in flight
    Each UPI leg arrives over the partner webhook with the canonical fields. The classifier separates P2P from P2M and tags the merchant if it is a known one.
  2. Scene 02 · Score for anomaly
    The anomaly detector compares against the payer's own baseline and against fleet-wide patterns. Drift on either is reason-coded back to the SOC's queue.
  3. Scene 03 · Decide in under 200 ms
    If the leg crosses the threshold, the fraud verdict comes back as a sub-200ms ping. The Courtroom-signed bundle is in the same response — the SOC operator opens it inline.
  4. Scene 04 · Route ambiguous cases to human review
    When the score band straddles the threshold, the leg is forwarded to the partner's human-review queue with a structured handover. The SOC analyst sees every reason.
Helpers on call
The stack · helpers + models

Who's actually doing the work.

Features used
B2B API + Python / Java / Node SDKsHash-chained audit trail
Honest limits

What this flow doesn't do.

  • Sub-200ms verdicts are bounded by the partner's network round-trip; the SLO refers to Mukodi-side processing time.
  • The classifier separates P2P and P2M intent; it does not block UPI legs by itself — the partner's payment switch is the only enforcement point.
  • Anomaly scores are calibrated against operator-supplied baselines; coverage on a brand-new partner improves over the first weeks of live traffic.
← Back to all use cases