ML & MLOps

Real-Time Fraud Detection: Models and Rules

Trace a transaction from fresh features and model scoring to a deterministic allow, review or block policy, then follow delayed outcomes into governed learning.

Reference architecture - illustrative, not a client deployment

Separate the fraud score from the policy that allows, reviews or blocks a transaction.

Complexity
Advanced
Drawing
Supplied
  • Fraud Detection
  • Real-Time ML
  • Decisioning
  • Monitoring
  • Machine Learning

Overview

This reference architecture is illustrative, not financial advice or a record of measured accuracy or a client deployment.

Real-time fraud detection has two distinct responsibilities: estimate risk and make a business decision. A transaction event retrieves recent, point-in-time features such as known-device history or short-window activity. The scoring service returns a risk score with a model version. A deterministic policy then combines that score with feature freshness, known signatures, customer protections and operational rules to allow, review or block the transaction.

Keeping policy separate makes degraded behavior explicit. If features are stale or scoring exceeds its latency budget, the system follows a preapproved fallback; it must not invent a score. Manual-review cases later produce confirmed outcomes, although labels may arrive after disputes or investigation. Offline training uses time-aware labeled data, and a new model returns to scoring only after evaluation and approval. Microsoft's reference architecture similarly separates stream processing, model scoring and activation, while Google's production guidance emphasizes monitoring served behavior and feedback loops.

A concrete example

A card-not-present purchase arrives from a device first seen moments ago. Fresh aggregates and account context reach the risk model. The model returns a score, but the policy - not the model - selects review because the device signal and transaction context match an approved rule. An analyst later confirms the outcome. That delayed label can inform a future candidate, but the current production model is not changed in place.

Common misconception

"The model blocks fraudulent transactions." The model estimates risk. A separate, auditable policy translates evidence into an action and can account for missing data, timeouts and obligations the model was never trained to represent.

Diagram & Walkthrough

Choose a declared scenario and step, or select a component by pointer, touch or keyboard. Playback starts only when you press Play and pauses when this panel leaves the screen.

100%
Real-Time Fraud Detection: Models and Rules A transaction receives fresh online features and a versioned model score. A deterministic business policy, not the model alone, decides whether to allow, review or block. Confirmed outcomes return later to an offline, approved learning process. Real-Time Fraud Detection: Models and Rules A risk score informs policy; deterministic controls choose the business action. ONLINE DECISION PATH · BOUNDED LATENCY OUTCOMES · ACTIONS AND HUMAN REVIEW LEARNING LOOP · OFFLINE AND DELAYED Entity + eventcontext Fresh featurevector Score +model version Policy outcome Manual-review case Confirmedoutcome Time-aware labelled data Approved model version Stale or missing features Inference timeout Transaction event DATA · ARRIVAL Online features+ freshness DATA · TIMESTAMPED Risk model scoring MODEL · SCORE ONLY Deterministicrisk policy RULES · FALLBACKS ✓ Allow, review or block EXTERNAL · POLICY ACTION Case management HUMAN REVIEW Delayed confirmedoutcomes DATA · MAY BE BIASED Offline training+ approval MODEL · GATED ✓ Flow legend Data · main path Control Feedback Fallback condition Illustrative architecture only. Thresholds, labels and observed outcomes require domain-specific governance.

Main walkthrough, step 1 of 6: Receive transaction context. idle.

Main walkthrough

The primary path through this reference architecture.

Active parts: Transaction event, Online features + freshness

Text walkthrough

This vertical reference remains readable without the interactive controls.

  1. 01Receive transaction context

    The transaction identifies the event and entity context required for feature lookup.

    Active parts: Transaction event, Online features + freshness

  2. 02Score current features

    A fresh point-in-time vector reaches the approved scoring model.

    Active parts: Online features + freshness, Risk model scoring

  3. 03Apply risk policy

    The deterministic policy receives a score and traceable model version as inputs.

    Active parts: Risk model scoring, Deterministic risk policy

  4. 04Allow, review or block

    Policy controls the transaction outcome and creates a human-review case when required.

    Active parts: Deterministic risk policy, Allow, review or block, Case management

  5. 05Capture delayed outcomes

    A later investigation or dispute outcome becomes a traceable label.

    Active parts: Case management, Delayed confirmed outcomes

  6. 06Train and gate future models

    Time-aware labels support offline training, and only an approved version returns to scoring.

    Active parts: Delayed confirmed outcomes, Offline training + approval, Risk model scoring

Connections

  • Entity + event contextTransaction event to Online features + freshnessdata
  • Fresh feature vectorOnline features + freshness to Risk model scoringdata
  • Score + model versionRisk model scoring to Deterministic risk policydata
  • Policy outcomeDeterministic risk policy to Allow, review or blockcontrol
  • Manual-review caseAllow, review or block to Case managementcontrol
  • Confirmed outcomeCase management to Delayed confirmed outcomesfeedback
  • Time-aware labelled dataDelayed confirmed outcomes to Offline training + approvaldata
  • Approved model versionOffline training + approval to Risk model scoringcontrol
  • Stale or missing featuresOnline features + freshness to Deterministic risk policycontrol
  • Inference timeoutRisk model scoring to Deterministic risk policycontrol

Components

Transaction eventdata

Carries the event identifier and the authorized context needed for a risk decision.

Responsibilities

  • Identify the transaction consistently
  • Supply only permitted event attributes

Inputs

  • Payment or transfer event

Outputs

  • Entity and event context

Risks

  • Duplicate events cause repeated decisions
  • Sensitive attributes are collected without a valid need
Online features + freshnessdata

Provides point-in-time entity and behavioral features together with their age and availability.

Responsibilities

  • Retrieve consistent online features
  • Expose freshness and missingness

Inputs

  • Entity and event context
  • Recent authorized observations

Outputs

  • Fresh feature vector
  • Or stale or missing signal

Risks

  • Training-serving skew
  • A stale aggregate looks current
Risk model scoringmodel

Estimates transaction risk and returns the model version; it does not choose the business action.

Responsibilities

  • Score within the latency budget
  • Return a traceable model version

Inputs

  • Fresh feature vector

Outputs

  • Risk score and model version
  • Or timeout

Risks

  • Calibration changes across segments
  • An adversary adapts to stable model behavior
Deterministic risk policydeterministic

Combines the score with approved thresholds, rules and degraded-mode behavior.

Responsibilities

  • Translate evidence into an auditable action
  • Handle stale features and timeouts explicitly

Inputs

  • Score and model version
  • Freshness state
  • Approved risk rules

Outputs

  • Policy outcome

Risks

  • Thresholds become detached from current costs
  • Conflicting rules produce inconsistent treatment
Allow, review or blockexternal

Applies the policy outcome in the transaction flow and creates a review case when required.

Responsibilities

  • Apply exactly one recorded outcome
  • Route review decisions to case management

Inputs

  • Policy outcome

Outputs

  • Allowed, reviewed or blocked transaction
  • Manual-review case

Risks

  • Decision latency harms the transaction experience
  • A downstream system applies a different outcome
Case managementhuman

Presents reviewable evidence to an investigator and records the eventual disposition.

Responsibilities

  • Prioritize and investigate review cases
  • Record the reason and confirmed outcome

Inputs

  • Manual-review case

Outputs

  • Confirmed outcome

Risks

  • Review queues exceed capacity
  • Inconsistent analyst decisions bias labels
Delayed confirmed outcomesdata

Stores confirmed fraud and legitimate outcomes with event time and decision context.

Responsibilities

  • Preserve label timing and provenance
  • Separate confirmed outcomes from provisional suspicion

Inputs

  • Investigation, dispute or settlement outcome

Outputs

  • Time-aware labelled data

Risks

  • Labels arrive too late for rapid detection
  • Earlier interventions create selection bias
Offline training + approvalmodel

Builds and evaluates future candidates offline before an approved version reaches scoring.

Responsibilities

  • Use time-aware splits and reproducible features
  • Gate model promotion

Inputs

  • Time-aware labelled data
  • Versioned training pipeline

Outputs

  • Approved model version

Risks

  • Future outcomes leak into training features
  • Offline metrics hide changed attack behavior

Scenario reference

Stale features

Select a predeclared conservative policy; do not silently use invalid features.

  1. 01Look up current context

    The event requests the relevant online features and their freshness metadata.

    Active parts: Transaction event, Online features + freshness

  2. 02Use the approved degraded policy

    Stale or missing features go directly to policy, which chooses an explicit business outcome.

    Active parts: Online features + freshness, Deterministic risk policy, Allow, review or block

Scoring timeout

A business-approved fallback, not an invented model score, determines the outcome.

  1. 01Attempt scoring within the budget

    Fresh features reach the scoring service, but no valid result arrives in time.

    Active parts: Online features + freshness, Risk model scoring

  2. 02Apply the timeout policy

    The timeout invokes the approved fallback and produces a recorded outcome.

    Active parts: Risk model scoring, Deterministic risk policy, Allow, review or block

Design Decisions

  • Version online features, freshness limits, model outputs and policy decisions together.
  • Reserve latency for a deterministic fallback and make degraded paths observable.
  • Use time-aware training data and prevent future outcomes from leaking into historical features.
  • Review false positives, missed fraud and intervention effects by segment and version.

Risks & Trade-offs

Fresh features add latency and operational dependencies. Aggressive policy reduces exposure but can harm legitimate customers. Confirmed labels are delayed and biased because earlier blocks prevent some outcomes from being observed. Attack patterns change, and feedback from investigations can encode inconsistent analyst decisions.

When to Use / Not Use

Use this pattern for high-volume decisions where predictive signals complement explicit policy and a fallback is approved. Prefer deterministic rules alone when data or labels cannot support a reliable model, or when every case already requires human adjudication.

Sources