The technical problem is that fraud detected after clearing can no longer be intercepted. Once a card transaction clears, the issuer has committed to fund it. The clearing instruction marks the point of no return. Anything afterward becomes chargeback recovery, with greater cost, slower processing, and an uncertain result.
A frequent payments architecture error is keeping fraud scoring outside the clearing pipeline, as a post-authorization hook or post-clearing webhook, then describing it as real-time. The score may return seconds after completion, but seconds after clearing is already too late. This design choice has direct consequences for how fraud infrastructure must be built.
When Card Clearing Creates Liability
Card scheme rules are clear here. In most card-present and card-not-present cases, issuer chargeback liability starts at authorization, rather than when the cardholder files a dispute. Once a fraudulent transaction is authorized and cleared, the issuer carries liability for that transaction. Finding the fraud after clearing means the loss could not be prevented.
This risk is operational, not hypothetical. Chargebacks bring dispute filing costs, scheme fees, staff time, and, under the corridor's scheme rules, recovery of the transaction amount that can fall well below 100%. Each chargeback costs materially more than declining a fraudulent transaction.
Post-clearing detection can achieve high accuracy without preventing the loss. Its output supports chargeback evidence, which is useful for disputes but serves a different purpose. For an issuer, the central value measure is fraud stopped before clearing, not fraud discovered afterward.
What Post-Clearing Scores Reveal
Post-clearing scoring still has value, but its role differs from inline clearing-time scoring. Applied properly, it exposes fraud patterns that emerge only across several transactions over time. A clearing-time model evaluating one transaction cannot see that broader window.
Small test payments followed by a large purchase form a familiar fraud pattern. The same applies to an abrupt geographic change across sessions or a BIN-specific velocity pattern appearing over 48 hours. Detecting these signals requires aggregation across time and sessions, beyond what a clearing-time model with a 20-millisecond inference budget can practically manage.
Post-clearing scoring should complement, rather than replace, clearing-time interception. It detects patterns that update blocklists, velocity rules, and card suspension decisions. If recent transactions indicate a compromised card, the post-clearing model informs the clearing-time model, which blocks later transactions. The layers cooperate while serving separate functions.
Why Bolt-On Fraud Scoring Breaks
Many banks and payment platforms attach fraud scoring to an existing clearing flow instead of placing it inline. The usual sequence authorizes the transaction, sends a webhook to the scoring service, then either tries to apply the response to a later action if it arrives quickly enough or reserves it for post-clearing review.
This design has two failure modes. If the score returns before clearing and is used to block the transaction, an asynchronous side channel has added latency to the clearing path. Correctly coordinating that response with the main path is difficult at scale, while the available latency budget remains tight.
If the score arrives after clearing, detection has no interception power. The system identifies fraud that can no longer be stopped. Operations may review the resulting reports, but the associated fraud losses have already occurred.
This architecture is usually inherited. The clearing pipeline came first, fraud scoring was added later, and the existing design limited the integration. Adding inline scoring to a pipeline not built for it is an engineering project, not a configuration edit. New clearing implementations can avoid the constraint by including scoring from the outset.
Requirements for Inline Clearing Scoring
Inline fraud scoring must finish within the clearing window's latency budget, usually 20 to 30 milliseconds of usable inference time. Model design, feature computation, and infrastructure must all be selected around that constraint. We cover the engineering tradeoffs, including model selection and fallback handling, separately in our article on AI scoring latency.
The pipeline must receive the fraud score before issuing the clearing instruction. Scoring therefore runs synchronously, inline, and on the critical path. An unavailable scoring service also requires an explicit fallback. Its availability and latency SLAs must match those of the clearing pipeline because it is part of that pipeline.
That operating requirement is stricter than a post-clearing webhook. A webhook delayed 30 seconds cannot change the clearing result. An inline synchronous service delayed 30 milliseconds can cause a clearing timeout. Inline scoring consequently demands greater operational discipline.
The Working Architecture
Clearing and fraud scoring operate as one pipeline. The model runs inline before the clearing instruction is issued, and its result decides whether that instruction is sent, held, or blocked. A separate asynchronous post-clearing layer detects patterns, then feeds model and blocklist updates back into the inline decision context over time.
This is the architecture behind enza. Fraud scoring is part of the clearing pipeline, not an integration attached to it. With enza's clearing infrastructure, fraud detection already sits in every transaction path. Real-time scoring needs no separate API call or webhook configuration because it runs before the response is returned. Interception therefore occurs at the only meaningful point, before the clearing instruction is issued.