Real-time transaction fraud scoring

The useful output is a decision on the live authorization, not a label on a settled item. For card and account payments, the ensemble returns a score and an action (allow, step-up, or block) before the payment posts. If the model runs after clearing or after the funds have moved, you have a detective control. You no longer have a stop.

Authorization paths are timed. Issuers, processors, and account-payment rails each have a window after which the network or the core treats silence as a decision. That window is a design constraint you size the scorer to. It is not a published latency statistic. If scoring cannot finish inside the window, write down the fail-open or fail-closed policy. Do not leave it as an implicit vendor default.

A late score is a quiet failure. The payment posts. A high score arrives afterward. Operations then chase a recall, a hold, or a customer call, and chargeback clocks have already started. On push rails the money may already have left. Card authorization scoring is also not the same problem as authorized push payment scam detection, where the customer initiated a transfer that looks legitimate at the moment of send.

Wire the path in this order. Intercept at authorization (the card network message, or the equivalent hold on the account rail), not at posting or settlement. Build features from data you already have at that moment: velocity, channel or device, merchant or counterparty, amount relative to the customer's history, geography, and any travel or expected-spend notice on file. Return the score, the recommended action, and a cite in one response. The payment engine should not wait for a second round trip.

Ensemble scoring (rules plus a statistical model, sometimes with graph or sequential features) is the usual pattern. Platforms in this class include Featurespace, Stripe Radar, and Feedzai. Treat those names as examples of real-time scoring stacks, not as a ranked shortlist. Whatever you buy or build, the contract with the payment engine stays the same: a score and an action before post.

A raw probability is not an outcome. Quality here means every in-scope transaction leaves with allow, step-up, or block, plus a cite that says why.

Allow when the score sits below your low threshold and no hard rule fires (for example a closed account or a listing you already enforce elsewhere). Allow is still a decision. Log it with the same cite structure as a block.

Step-up when the score is elevated but the customer may be legitimate: a new device with an amount inside their typical range, a merchant they have not used, a geography that is unusual but not impossible. Step-up is a second factor or a confirmation challenge before the payment posts. If the customer cannot complete the challenge inside the authorization window, treat that as a block by timeout, not as an allow.

Block when the score or a hard rule says the payment should not complete. Block is an authorization decline or a refused account debit. It is not a suspicious activity report. It is not proof that the card was stolen. A declined card can be a false positive, a velocity cap, a customer-reported lost card, or a processor fault. Do not treat the decline itself as confirmed fraud in case management or in dispute pre-triage automation.

Set thresholds on your own book. False-positive cost is a good customer declined at the terminal. False-negative cost is posted fraud. Recalibrate when you add a channel, a card product, or more step-up friction.

The cite is the minimum package a human needs to reverse the decision without guessing. At decision time persist transaction identifiers (tokenized PAN or account, amount, merchant or beneficiary, timestamp, channel), the score and the model or rule-pack version that produced it, the top contributing features or rule IDs, the action taken (allow, step-up completed, step-up failed, block), and whether the engine applied that action before post. If you show the customer a reason code, keep it consistent with the internal cite.

Without that package, overnight review is guesswork, and you cannot explain a block to the customer or to a scheme. The cite also blocks a dangerous shortcut: auto-filing a SAR from the score alone. A score is a risk signal. A SAR is a judgment after investigation, typically with AML transaction network monitoring and KYC context, not a webhook from the authorization model.

Do not wait for every blocked customer to call. Route a subset to human review as soon as the block lands: travel notices on file, merchants the customer has paid for months, payroll and bill-pay counterparties, and customers whose spend just shifted after a documented move or trip.

Illustrative path, not a measured case: a cardholder files a travel notice for Portugal. The first night, a hotel authorization in Lisbon is allowed. Later the same evening a restaurant authorization in the same city is blocked because the model still treats the country as unseen and the device as new (roaming, hotel Wi-Fi). The block is wrong. The cite should show the travel notice, the prior in-country hotel allow, and the feature that overweighted "new country." A reviewer who sees that package can release subsequent authorizations for the remaining trip. If you only stored "score high, blocked," the reviewer has nothing to work with.

Review does not mean silently converting every contested block into an allow. A person confirms or overturns the action using the cite, then feeds the overturn into rules (consume the travel notice, remember the merchant) so the same trip does not generate a stack of declines.

Three patterns show up even when the model is competent.

Blocking known travel spend. Geography and impossible-travel features fire on the first in-country meal or transit ticket even when the bank already has a travel notice, a booked itinerary, or a recent airport merchant. If travel data is not a first-class feature at score time, customers learn to leave the card at home or to call every evening of the trip.

Scoring after the payment has posted. Batch jobs that score the day's items are useful for cases and for tuning. They are not this control. If the live path times out and you score in a queue, you have already chosen an implicit allow or an implicit decline. Make that choice explicit.

Treating a timeout as a silent allow. When the scorer is slow or unreachable, many stacks fail open so authorization rates do not collapse. That is a business decision. Document it. Bound it, for example fail open only below an amount band or only for known devices. A silent allow with no cite is how a scoring outage becomes an unlogged fraud window. Prefer a recorded fallback in the same store as live scores: timeout, named policy, allowed or blocked.

Other traps sit next to the path: using the same score to file a SAR; treating a decline as confirmed fraud in the dispute stack; ignoring account top-ups that belong in mule account detection at top-up rather than only on card rails.

Real-time transaction fraud scoring belongs on the authorization path. It does not replace APP scam detection for customer-initiated pushes, AML network monitoring for layering and mule rings, dispute pre-triage after a claim, or mule detection when funds first land. Share identifiers and cites across those controls so a blocked card payment and a later APP attempt in the same session tell one story.

Buy or build in the Featurespace, Stripe Radar, and Feedzai class if you need a managed ensemble. The operating standard does not depend on the logo: score before post, emit allow, step-up, or block with a cite, review the blocks that look like false positives, and never treat a model score as a regulatory filing or as proof that fraud occurred.