The Outlier Lab

Real-Time Transaction Risk Scoring

Scoring each funding, payment, payout, trade or redemption before it settles and mapping score bands to actions (allow, step-up, hold, review, decline) within a defined latency budget.

What it is

Real-time scoring is the decision point where everything else in this vault comes together, including single-event Transaction Pattern Anomalies and network context. Device, session, account-change, funding, payee and velocity features go in. A decision comes out that sets the customer's experience and the company's exposure for that transaction.

It is a different job from Transaction Monitoring:

Real-time scoringTransaction monitoring
WhenBefore the action completes (synchronous)After the fact (near-real-time or batch)
UnitOne event, in contextPatterns over time, entities, networks
OutputAn action the customer experiencesAn alert for investigation, case, SAR
LatencyTens to hundreds of millisecondsMinutes to days
Primary purposeStop lossDetect, investigate, report, learn

On irreversible rails (RTP, FedNow, push-to-card, crypto, wires) real-time scoring is the only preventive chance. Once the money settles, recovery depends on the receiving institution cooperating.

Decision orchestration

The score is one input. Orchestration is the layer that turns many inputs into one action. In mature stacks it looks like this:

Diagram: Event (withdrawal / send / deposit / redemption), Feature assembly (real-time + precomputed), Hard rules (sanctions, deny lists, regulatory blocks), Model scores (ATO, scam, funding, first-party), Policy layer (score bands x action tier x segment), Action, Allow, Allow + reduced limit / partial availability, Step-up (bound to this transaction), Hold / delay / cooling-off, Queue for manual review, Decline / block

Design principles:

  • Separate scores from policy. Models estimate probability. Policy decides what to do about it, by segment, action tier and business context. Changing a threshold should be a governed policy change that needs no model retrain (Rule Governance and Change Management).
  • Use more than one model. ATO, scam, funding/return and first-party risk have different labels, features and best responses. One "fraud score" mixes them, and the response is then wrong for some cases. A high scam score should trigger an intervention, not a step-up the victim will pass.
  • Return reason codes. Every decision should return its top drivers. You need them for analysts, customer messaging, adverse-action requirements where they apply, QA and model debugging.
  • Log everything with versions. Model version, rule set version, features as seen at decision time, and the action taken. Point-in-time correct logging is what makes backtests and audits possible (Fraud Data Architecture).

Score bands to actions

An illustrative policy matrix for one action type (a withdrawal or outbound send). Bands are relative to your own score distribution; calibrate to your data.

Score bandTier 1: established destination, normal amountTier 3: new destination, irreversible rail, large share of balance
Very low (most traffic)AllowAllow; maybe a soft cap until the destination is seasoned
LowAllowAllow with partial amount, or step-up
MediumAllow with step-upStep-up plus delay; or route to a slower rail
HighStep-up or holdHold for review; notify customer via a known channel
Very highHold / reviewDecline or block; freeze payouts; open ATO/scam case

Several actions are often under-used:

  • Rail downgrade. Offer standard ACH instead of instant: same outcome for the customer, with more time to react and return rights.
  • Partial availability. Release part of the amount now and the rest after the hold (Funds Availability Holds).
  • Delay with notification. A short hold plus an alert to existing channels catches ATO cases where the owner responds.
  • Scam interstitial. Targeted warnings and questions when scam indicators fire (Payee Confirmation and Payment Friction).

Latency budgets

Each decision point has a latency budget set by the rail and the user experience. Exceed it and the system either fails open or degrades conversion. The figures below are illustrative engineering norms. Take the hard limits from your card network's and payment operator's documented response windows, then allocate your fraud call a share of that.

Decision pointTypical budget (illustrative)Notes
Card authorization (issuer side)Very tight, often tens of milliseconds for the fraud call within the network's overall response windowPrecompute heavily; few synchronous lookups
Card checkout (merchant side, pre-auth)~100–300 msPlus 3DS round-trip if challenged
RTP/FedNow/P2P send~100–500 ms for scoringInstant rails have strict end-to-end timeouts
ACH origination / withdrawal requestSeconds acceptableMore room for richer lookups; settlement isn't instant
Mobile deposit / instant funding grantSecondsDecide on availability, not acceptance
Reward redemption / cash-outSecondsBusiness-set; often batchable

Engineering consequences:

  • Precompute aggregates (velocity, tenure, graph features) in a streaming feature store. Fetch only a few fresh values at decision time.
  • Give every external call (consortium, vendor, IDV status) its own timeout and a fallback value.
  • Use tiered evaluation: cheap rules and models first, expensive lookups only for the uncertain middle band.

Fallbacks

Every decision point needs a written answer to "what happens when the scoring service is slow, down or returns garbage?"

FailureTier 1 actionsTier 3 actions
Model timeoutFail open with rules-only decisionFail to safe: hold, delay or downgrade the rail; don't fail open
Vendor/consortium timeoutUse a missing-value default; flag for later reviewUse a conservative default; consider holding
Full scoring outageStatic rules + conservative limitsPause instant availability; route to standard rails
Bad model deploy (score drift)Automatic rollback triggered by distribution monitorsSame; plus kill-switch to rules-only

Attackers notice fail-open behavior. Outage windows and timeout-driven approvals are a known way losses jump. Monitor approval rate by fallback path.

What it stops (and what it doesn't)

  • Stops:
    • ATO cash-outs whose context (new device, recent changes, new payee, full-balance send) separates them from normal behavior
    • Funding fraud where the source account is risky
    • Mule inflows and fast-out patterns (Fast In Fast Out Patterns)
    • Stuffed reward accounts redeeming to new destinations
  • Struggles with:

Implementation path

StageWhat it looks likePrerequisites
CrawlSynchronous rules at withdrawal, payout change and funding; simple velocity and new-payee checks; actions: allow, hold, reviewEvent hooks on money-moving endpoints; Rules Engine; review queue
WalkSupervised model(s) per decision point; score bands mapped to a policy matrix; step-up and partial availability as actions; feature store; reason codes; documented fallbacksLabeled history (Fraud Labeling and Feedback Loops); feature pipeline; Real-Time Decisioning Architecture
RunMultiple specialized models (ATO, scam, funding, first-party); cost-sensitive policy optimizing expected loss + friction; graph features; champion-challenger on policy; automated drift monitors and kill-switchesMachine Learning Models, Graph Analytics, Experimentation and Champion-Challenger, Model Risk Management

Customer friction and trade-offs

  • Most of the value comes from approving good traffic faster and more often: lower friction for low-risk customers pays for the investment. Give low-risk segments faster availability and higher limits.
  • Every hold or decline on a genuine customer has a cost, including support contacts, churn and complaints. Price it explicitly in the policy (Friction and Customer Experience Tradeoffs).
  • Opaque declines drive complaints and regulatory scrutiny. Give clear, non-revealing messages and a resolution path.

Measuring effectiveness

  • Dollar-weighted catch rate at each decision point (fraud dollars prevented ÷ fraud dollars attempted), alongside count-based rates.
  • Precision at action thresholds: the share of holds, reviews and declines that are confirmed fraud. Track the good-customer insult rate separately.
  • Loss basis points by rail and decision point.
  • Latency percentiles (p50, p95, p99) and fallback-path usage, along with the approval and fraud rates on fallback paths.
  • Policy counterfactuals: use holdout groups or backtests to estimate what each policy change actually did (Experimentation and Champion-Challenger).
  • Label maturity: ACH returns, chargebacks and scam reports arrive weeks later. Report rates on matured cohorts (Fraud Metrics and KPIs).

Common failure modes

  • A single model and score drive every response, so scams get step-ups and ATOs get warnings.
  • Fail-open defaults on irreversible rails.
  • No point-in-time logging, so features leak in training and the model looks better offline than it performs.
  • Policy hard-coded in the model, so threshold changes need a retrain and governance can't see them.
  • Holds without review capacity. Queues are sized for normal days and get flooded during an attack (Alert Review Operations).
  • Uneven coverage, such as scoring only at login or only at funding, which leaves payouts or redemptions unscored.
  • Declined transactions never get labels, so the model can't learn what it would have caught.

Regulatory and policy notes

  • FFIEC 2021 authentication guidance. Names transaction monitoring and layered controls as part of managing authentication risk, and points out the risks of push payments.
  • Nacha 2026 fraud monitoring rules.
    • Require ODFIs, many originators and RDFIs (for credits) to have risk-based processes to identify unauthorized and False Pretenses entries.
    • Pre-processing screening of every entry is not required, but real-time scoring is one way to meet the expectation (Nacha Rules and ACH Risk).
  • Reg E. Timelines for investigating disputed transfers, and liability allocation, are unaffected by your scoring. Decision logs are evidence (Regulation E and Unauthorized Transfers).
  • Model risk management. Material fraud models at banks fall under SR 26-2, the April 17, 2026 interagency guidance (Fed, OCC, FDIC) that superseded SR 11-7; it is risk-based and described as most relevant to banking organizations over $30B in total assets (Model Risk Management).
  • Fairness and adverse action. Where decisions affect credit-like products (instant credit lines, overdraft), ECOA and Reg B adverse-action notice obligations may apply. Get legal review (Privacy and Data Use in Fraud Prevention).

Mechanisms addressed

Sources and further reading