Skip to main content

Transaction Lifecycle

Every transaction you submit goes through the same pipeline, whether it ends up auto-approved in milliseconds or sitting in an officer's queue for two days. This page walks through that pipeline end to end.

Transaction lifecycle: submit, enrichment, scoring, rules, decision, and (if flagged) alert review

  1. Submit. You call POST /create/transaction with your transaction data. See Offsite Integration for the request reference.
  2. Enrichment. Shufti derives attributes from the data you sent — this is also where AML and sanctions-list screening happens (the customer and the beneficiary on every account; the transaction's other involved parties where that screening is enabled for your account), alongside things like device and IP signals.
  3. Scoring. The enriched transaction is scored. More than one scoring component runs — see the resilience note below for what happens if one of them is slow.
  4. Rules. Your configured rules evaluate the enriched transaction and the score, and decide the outcome.
  5. Decision returned. The decision, score, and evidence come back in the response to your original request — see Decision Values for what each value means.
  6. Alert created, if the transaction wasn't auto-approved. This happens after your response has already been sent — it's not something you wait on.
  7. Officer review and close. See Alert Routing and Review Tiers for how that works.

What "Auto-Approved" Means​

A transaction is auto-approved when every rule that fired approved it (or no rule fired at all) and its score is at or below your account's auto-approve ceiling (30 by default). It's returned as Approved and never reaches a reviewer. A transaction can still score above the ceiling and be returned as Approved by its rules — in that case it still goes to a reviewer, because the score alone was enough to warrant a second look even though no rule declined it.

Idempotency​

Give every transaction its own trans_id. If you send the same trans_id again — for example, retrying after a network timeout — Shufti treats it as the same transaction, not a new one: it keeps the same Shufti transaction ID and never opens a second alert.

The retry is still scored again, though, so its response can differ from the first one if something changed in between. For example, you submit trans_id TX-1001 at 10:00 and receive Approved (data.approved = 1). At 10:05 you retry TX-1001 after a timeout; the customer has made four more transfers since 10:00, so a velocity rule now fires and the retry returns Manual review (data.approved = 2). Store the score, decision, and evidence from each response at the time you receive it.

Scoring Resilience​

Scoring runs multiple independent components (a cold/heuristic score, and one or more ML models), each with its own timeout. The response is built from whichever components complete in time, so a transaction always returns a decision without waiting on a slow component.