The call that starts it

Before your payment handler executes a transaction, it makes one synchronous API call to the decision layer with the transaction context: customer identifier, amount, currency, counterparty, and channel. The payment handler then waits — briefly — for a decision before proceeding.

Everything described below has to complete within that wait, which is why architecture and latency budget matter as much as rule logic.

What runs, in parallel, inside that call

The evaluation isn't a single check — it's several running concurrently:

  • Customer risk state lookup. The customer's current risk state, KYC tier, and any active restrictions are retrieved — this needs to be a fast lookup, not a slow query, since everything else depends on it.
  • Rule evaluation. Every configured rule relevant to this transaction type runs against the transaction and the customer's recent history — velocity, structuring, behavioural anomaly, and any others configured.
  • Screening check. The counterparty (and sender, if not already verified) is checked against sanctions, PEP, and adverse-media lists.
  • Tier/limit enforcement. The transaction is checked against the customer's KYC tier limit and any other configured hard limits.

These run in parallel, not sequentially, because running them one after another would make the latency budget impossible to hit at any meaningful scale.

Latency budget is an architecture decision, not an afterthought.A synchronous compliance call that takes 2 seconds adds 2 seconds to every payment in your product. Sub-100ms is achievable, but only if it's designed for from the start — not bolted onto a system built for batch processing.

Converging on one decision

Once every check completes, the results converge into a single decision using a defined precedence: BLOCKED outranks HELD_FOR_REVIEW, which outranks FLAGGED, which outranks CLEAR. If any single check produces a BLOCKED result — a sanctions match, say — that's the final decision regardless of what the other checks returned. This “most restrictive wins” logic is what keeps the combined decision defensible: no individual risk signal gets silently overridden by an unrelated clean result elsewhere.

What happens after the decision returns

  • CLEAR — the payment handler proceeds. No human involvement, but the decision and its full reasoning are still written to the evidence store.
  • FLAGGED — the payment handler proceeds, but a case is opened for review — the transaction isn't blocked, but it's not silently ignored either.
  • HELD_FOR_REVIEW — the transaction is held pending review before it's allowed to proceed.
  • BLOCKED — the transaction is declined (and reversed, if it had already partially executed) and a case is opened automatically.

Writing the evidence, without adding to the latency

Writing the full evidence record — every rule evaluated, the customer state at that moment, the final decision — happens asynchronously relative to returning the decision to your payment handler, so evidence-writing doesn't add to the latency your users experience, while still completing fast enough that the record exists before any follow-up query would reasonably need it.

This is the pipeline behind Fintegrity's Compliance Decision API — parallel evaluation, a defined precedence for the final decision, and evidence written automatically to the audit trail, all inside a sub-100ms P99 budget.