Real-Time Decisioning Architecture
How to design fraud decision points on the money path: synchronous vs asynchronous decisions, latency budgets, orchestration of rules, models and vendors, fallbacks, and safe change management.
Core components
Decision points on the money path
Map every point where value enters, moves or leaves, and decide what kind of decision each needs.
| Decision point | Typical timing constraint | Available actions | Notes |
|---|---|---|---|
| Sign-up / onboarding | Seconds (user waiting) | Approve, step-up IDV, limit, decline | Sets limits for everything downstream; see KYC and Customer Identification Program (CIP) |
| Login / session | Sub-second to seconds | Allow, step-up, block, restrict session | Enabler for ATO; see Risk-Based Authentication and Step-Up |
| Account change (contact, payout destination) | Seconds | Allow, step-up, cooling-off, notify old contact | Biggest single lever on payout loss; see Contact Change Cooling-Off Periods |
| Funding (ACH link/debit, card load, check deposit) | Seconds; settlement days later | Approve, limit availability, hold, decline | Decide availability as well as acceptance; see Funds Availability Holds |
| Card authorization (merchant or issuer) | Tight network response windows (hundreds of ms) | Approve, decline, 3DS challenge | See 3-D Secure and Card Verification |
| Purchase / trade / redemption | Sub-second to seconds | Approve, step-up, review, limit | Rewards: receipt or offer validation may be async |
| Money-out (withdrawal, payout, P2P, RTP/FedNow, push-to-card) | Seconds; irrevocable once sent | Approve, delay, hold for review, step-up, confirm payee | Last line of defense; see Withdrawal and Payout Controls |
| Dispute / claim | Hours–days | Auto-accept, request evidence, review | Regulatory clocks may apply; see Regulation E and Unauthorized Transfers |
Synchronous, asynchronous and deferred decisions
| Mode | When to use | Trade-off |
|---|---|---|
| Synchronous (inline) | The action is irreversible or the customer is waiting: auth, payout initiation, P2P send | Strict latency; must have fallbacks |
| Asynchronous (post-event) | Action is reversible or value is not yet released: deposits under hold, rewards before vesting | Can use slow signals (graph, document forensics, vendors with long tails) |
| Deferred / held | Turn a fast decision into a slow one by delaying release: "funds available in X", payout queued for review | Converts latency budget into friction; best lever for instant-funding and payout risk |
Latency budgets
Set the budget from the end-to-end SLA the product or network imposes, then allocate it. Measure p95/p99 latency, because tail latency is what causes timeouts. The numbers below are illustrative; calibrate to your stack and partner SLAs.
| Component | Illustrative p99 budget (payout decision, 300 ms total) |
|---|---|
| Request parsing, auth, enrichment from cache | 20 ms |
| Online feature store reads (parallel) | 25 ms |
| Streaming counters / velocity reads | 15 ms |
| Graph feature lookup | 30 ms |
| External vendor calls (parallel, hard timeout) | 120 ms |
| Model inference | 20 ms |
| Rules evaluation | 10 ms |
| Decision assembly, logging (async write), response | 20 ms |
| Headroom | 40 ms |
Design rules:
- Parallelize independent lookups and vendor calls. Hard timeouts on each.
- Precompute expensive features: graph metrics, aggregates and entity risk scores, refreshed by stream or batch.
- Cache vendor responses with TTLs where terms allow (e.g., email or phone risk for a known contact).
- Write logs asynchronously, but durably. If decision logs are lost during an incident, the post-mortem has nothing to work from.
Orchestration
A decision service typically runs in stages:
- Separate scoring from policy. Models output risk; a policy layer (rules) maps risk plus context to actions. This lets strategy change thresholds without retraining and keeps the model governable. See Rules Engine, Machine Learning Models.
- Segment-specific policies. The same score means different things for a three-year customer and a three-hour-old account.
- Action menu beyond approve/decline. Step-up, hold, limit, review, notify. Graduated responses keep friction proportional. See Payee Confirmation and Payment Friction. Review routing needs queue capacity behind it; see Manual Review Queues.
- Shadow and champion-challenger paths run alongside production without affecting outcomes. Log both. See Experimentation and Champion-Challenger.
- Post-decision async checks can claw back or freeze before settlement or vesting.
Fallbacks and failure modes
Decide in advance, per decision point, what happens when a dependency fails. "Default approve" on a payout endpoint during a vendor outage is an invitation; attackers notice degraded controls quickly.
| Failure | Fail-open option | Fail-closed option | Common middle ground |
|---|---|---|---|
| Vendor timeout | Approve without signal | Decline | Use cached/last-known value; tighten policy for risky segments; route high-value to review |
| Model service down | Rules-only policy | Decline all | Pre-approved fallback rule set ("safe mode") with conservative limits |
| Feature store stale | Use stale values | Decline | Use stale within a freshness limit; flag in log |
| Whole decision service down | Bypass | Block money path | Allow low-risk / low-value with caps; queue the rest; incident declared |
- Safe mode is a pre-built, tested policy for degraded operation: lower limits, holds on new destinations, no instant availability for new funding. Owned by strategy, with a kill-switch that on-call can flip. See Fraud Incident Response.
- Circuit breakers on vendors stop a slow dependency from dragging the whole service past its SLA.
- Chaos testing: periodically simulate vendor and feature-store failures in staging and verify the fallback fires.
Change management for live decisions
- Rule and threshold changes go through version control, review and staged rollout (shadow, canary percentage, full). See Rule Governance and Change Management.
- Emergency rules during attacks are allowed, but they're logged, owned and auto-expiring.
- Every decision records the versions of rules, model and policy that produced it.
- Rollback must be one action, tested.
How to build it
| Stage | Architecture |
|---|---|
| Crawl | Vendor or processor-native rules at a few decision points; batch reviews; manual holds |
| Walk | Central decision service for money-out and funding; online features; decision log; documented fallbacks |
| Run | Model + policy layer; parallel vendor orchestration with timeouts; shadow mode; safe mode; per-segment policies |
| Fly | Unified decisioning across all money-path points sharing entity context; real-time graph features; automated canary analysis; latency SLOs with error budgets |
Owners: engineering owns availability and latency SLOs. Strategy owns policy and fallback behavior. Data science owns models and features. On-call has authority to flip safe mode.
Artifacts and templates
Decision point specification
- Name, money path, rail, irreversibility
- End-to-end SLA and latency budget allocation (p99)
- Inputs: features, vendor signals, graph lookups; freshness requirements
- Action menu and who can change policy
- Fallback per dependency; safe-mode policy
- Logging fields (see Fraud Data Architecture)
- Shadow / experiment hooks
- Regulatory constraints (e.g., Reg E timelines for claims, Nacha monitoring obligations, network rules)
- Monitoring: latency, timeout rate, action mix, approval rate, alert thresholds
Failure-mode drill checklist
- Each vendor timed out in staging; fallback verified
- Model service disabled; rules-only safe mode verified
- Feature store stale beyond SLA; behavior verified
- Kill-switch for each money-out path flipped and restored
- Decision logs complete during the drill
Metrics
- Decision latency p50/p95/p99 per decision point; timeout rate per dependency
- Fallback activation rate and loss during fallback windows
- Action mix: approve, step-up, hold, review, decline, by segment
- Policy change lead time and rollback time
- Shadow-vs-production disagreement rate for candidate changes
Pitfalls
- Default-approve fallbacks on irreversible rails. Decide fail behavior based on the risk of each decision point.
- Serial vendor calls. Tail latencies add up; one slow vendor blows the budget.
- Embedding thresholds in model code. Strategy can't respond to an attack without a deploy.
- Only two actions. Approve/decline forces bad trade-offs; holds and step-ups are often better.
- Ignoring time as a control. Instant availability is a product choice, and it carries a fraud cost.
- Untested kill-switches. The first time you flip one shouldn't be during an incident.
Related
- Fraud Data Architecture · Real-Time Transaction Risk Scoring · Rules Engine · Machine Learning Models
- Withdrawal and Payout Controls · Funds Availability Holds · Velocity and Exposure Limits
- Real-Time Payment Rail Fraud · Instant Funding Abuse (Kiting) · Payout Redirection
- Rule Governance and Change Management · Experimentation and Champion-Challenger · Fraud Incident Response
- Vendor Selection and Evaluation · Payment Rails Map
Sources and further reading
- Federal Reserve, About the FedNow Service: launched July 20, 2023; 24x7x365 processing; optional fraud prevention tools
- Nacha, Fraud Monitoring Phase 1 (2026): risk-based monitoring without mandatory pre-posting screening; RDFI funds-availability delay for flagged credits
- Nacha, Risk Management Topics (Oct 2024): funds availability exception for credits suspected of false pretenses
- Visa, Guidance to guard against enumeration (Sep 2021): velocity checks, throttling and decline-code monitoring at authorization
- Federal Reserve SR 26-2 attachment (Apr 2026): controls on early model use and ongoing monitoring
- FINRA Regulatory Notice 21-18 (May 2021): adaptive authentication on large withdrawals and bank/email changes