1. Introduction & The Scale of Financial Fraud

Financial fraud costs the global economy over $5 trillion annually, and that figure continues to climb as digital transactions proliferate. Every second, millions of payments, transfers, and purchases flow through banking networks, payment processors, and fintech platforms. Among these legitimate transactions, a significant minority are fraudulent — unauthorized charges, account takeovers, synthetic identities, money laundering schemes, and sophisticated social engineering attacks. The challenge is detecting these fraudulent transactions in real time, before funds leave the system, while minimizing false positives that frustrate legitimate customers.

A real-time fraud detection system must evaluate each incoming transaction and produce a risk score within 100 milliseconds. This is not a batch processing problem; it is a streaming problem with extreme latency requirements. A transaction that takes 500ms to evaluate is too slow — the customer is already tapping their phone on the POS terminal, or the mobile app is showing a spinner. The system must be simultaneously fast, accurate, and explainable. Fast because latency directly impacts customer experience. Accurate because every missed fraud event costs money, and every false positive costs customer trust. Explainable because regulators require reasoning, and analysts need to understand why a transaction was flagged.

The architecture of a modern fraud detection system spans multiple domains: stream processing for real-time event ingestion, feature engineering for deriving behavioral signals, machine learning for predictive scoring, graph analytics for detecting organized fraud rings, a rule engine for encoding business logic, a case management system for analyst workflows, and a feedback loop for continuous model improvement. Each of these domains has its own complexity, and integrating them into a cohesive system that operates within a 100ms budget is the core engineering challenge.

Consider the journey of a single credit card transaction: a customer taps their card at a coffee shop. The POS terminal sends an authorization request to the payment network. Before the issuer approves the transaction, the fraud detection system must evaluate it. It retrieves the cardholder's recent transaction history, computes velocity features (how many transactions in the last hour, day, week), checks the merchant's risk profile, evaluates the device fingerprint if it is an online transaction, runs the data through multiple ML models, applies business rules, and produces a composite risk score — all in under 100 milliseconds. If the score exceeds the threshold, the transaction is declined or routed to step-up authentication. If it passes, the customer gets their coffee. This entire process happens millions of times per second across the network.

Real-World Case Studies

Stripe Radar is particularly instructive because it operates across millions of merchants, giving it network-level visibility that individual merchants cannot achieve. A fraud pattern detected on one merchant's transactions can be used to protect all other merchants in near-real time. This "consortium effect" is one of the most powerful mechanisms in fraud detection and represents a key architectural consideration: the system must be designed to share intelligence across entities while maintaining privacy and compliance constraints.

PayPal's approach to graph-based detection is equally noteworthy. By modeling the relationships between senders, receivers, devices, and addresses as a graph, PayPal can detect organized fraud rings that would be invisible to transaction-level analysis. A single transaction might look legitimate, but a pattern of 50 accounts all sending money to the same destination within an hour — linked by shared devices and IP addresses — reveals a money mule network. Graph neural networks have become a critical tool for detecting these types of coordinated attacks.

2. Functional & Non-Functional Requirements

Functional Requirements

1. Real-Time Transaction Scoring: Every transaction must be evaluated and assigned a risk score within 100ms. The score must be produced by combining rule-based evaluation, ML model inference, and feature computation.
2. Feature Engineering: The system must compute and retrieve hundreds of features per transaction, including velocity checks, behavioral biometrics, device fingerprinting, geolocation analysis, and historical patterns.
3. Rule Engine: Business analysts must be able to define, deploy, and modify fraud rules using a domain-specific language without code deployments. Rules must evaluate in under 10ms.
4. ML Model Serving: Multiple ML models (gradient boosting, neural networks, graph neural networks) must be served simultaneously with model versioning, A/B testing, and shadow deployment capabilities.
5. Graph-Based Detection: The system must maintain a real-time transaction graph and detect fraud rings, money laundering networks, and coordinated attack patterns.
6. Entity Resolution: The system must link multiple accounts, devices, and identities to the same underlying person to detect synthetic identities and account farming.
7. Alert Generation: When a transaction is flagged, the system must generate a prioritized alert with explainability information (SHAP values, triggered rules, contributing features) for analyst review.
8. Case Management: Analysts must be able to investigate alerts, view related transactions, make decisions (confirm fraud, approve, escalate), and those decisions must feed back into the ML training pipeline.
9. Whitelisting & Blacklisting: The system must support manual and automated whitelisting/blacklisting of entities (accounts, devices, IPs, emails) with configurable TTLs and scopes.
10. Consortium Data Sharing: The system must support secure, privacy-preserving data sharing with consortium partners to leverage network-level fraud intelligence.

Non-Functional Requirements

3. Capacity Estimation & SLA Targets

Capacity planning for a fraud detection system requires understanding both steady-state and peak loads. Consider a mid-to-large payment processor handling 50,000 transactions per second at peak. Each transaction requires feature retrieval, rule evaluation, and model inference. This translates to the following resource requirements:

Storage requirements are equally significant. At 50,000 transactions per second with an average payload of 2KB per transaction, the raw data stream produces approximately 100 MB per second, or 8.6 TB per day. Transaction logs with compliance-mandated retention of 7 years require approximately 22 PB of raw storage. Feature snapshots for model training (retained for 2 years) add another 5-10 PB. The system must use tiered storage — hot data (last 7 days) on NVMe SSDs, warm data (last 90 days) on SSDs, and cold data (archived) on object storage like S3 or Azure Blob.

The feature store itself must maintain rolling windows of varying granularity: per-second counters for real-time velocity, per-minute aggregates for short-term patterns, per-hour summaries for session-level features, and per-day statistics for long-term behavioral baselines. A single customer might have 500+ features active at any time, and with 100 million customers, the feature store must manage 50 billion feature values across all time windows. This requires a carefully designed data layout that optimizes for read-heavy, low-latency access patterns.

4. High-Level Architecture Overview

The fraud detection system is organized into several major subsystems, each responsible for a specific aspect of the detection pipeline. The architecture follows a streaming-first design where transactions flow through a series of processing stages, with each stage enriching the transaction data with additional signals before the final risk score is produced.

Component Responsibilities

The architecture separates the hot path (transaction scoring, which must complete in under 100ms) from the warm path (feature computation, graph updates, alert generation) and the cold path (model training, batch analytics, reporting). The hot path is deployed on dedicated, auto-scaling compute with strict latency SLAs. The warm path runs on stream processing infrastructure with softer latency requirements. The cold path runs on batch processing infrastructure with hour-level latency.

5. Transaction Scoring Pipeline (Sub-100ms)

The transaction scoring pipeline is the heart of the fraud detection system. It receives a raw transaction, enriches it with features, evaluates it against rules and ML models, and produces a risk score and decision. Every microsecond matters in this pipeline, so each stage is optimized for minimal latency.

Pipeline Stages in Detail

Stage 1: Transaction Enrichment (0-5ms)

When a raw transaction arrives, the first step is to enrich it with basic contextual data. This includes resolving the merchant's category code (MCC), the issuing country, the acquiring bank, and any merchant-specific risk flags. This data is relatively static and is cached locally in the scoring service with a TTL of 1 hour. The enrichment also normalizes the transaction format — converting different payment network formats (Visa, Mastercard, Amex, UnionPay) into a unified internal representation.

Stage 2: Feature Retrieval (5-10ms)

The scoring service issues a single batched request to the feature store to retrieve all features needed for the transaction. Features are grouped by entity type (customer, device, merchant, card, IP) and fetched in parallel across the Redis cluster. The feature store uses a two-tier caching strategy: an L1 in-memory cache within each scoring service instance for the hottest features (e.g., customer's last 10 transactions), and an L2 distributed cache (Redis) for the full feature set. This two-tier approach reduces Redis load by approximately 60% while maintaining feature freshness.

Stage 3: Rule Evaluation (10-18ms)

The rule engine evaluates the transaction against all active fraud rules. Rules are organized into tiers: fast rules (simple threshold checks, blacklist lookups) that execute in under 1ms, medium rules (velocity checks, pattern matching) that execute in 2-5ms, and slow rules (complex pattern analysis, cross-entity correlation) that execute in 5-10ms. Rules are evaluated in parallel across tiers, with fast rules completing first and potentially short-circuiting the evaluation if a high-confidence fraud signal is detected.

Stage 4: ML Model Inference (18-43ms)

The ML ensemble runs multiple models in parallel: a gradient boosting model (XGBoost/LightGBM) for tabular features, a deep neural network for high-dimensional behavioral patterns, and a graph neural network for network-level features. Each model produces an individual score, which is combined by a meta-learner. The models are served using ONNX Runtime for optimal inference speed, with model weights pre-loaded into GPU memory for zero-copy inference.

Stage 5: Score Aggregation (43-55ms)

The final stage combines the rule scores, ML scores, and graph features into a composite risk score. This aggregation uses a weighted combination where the weights are learned from historical data. The aggregator also produces the explanation payload — which rules were triggered, which features contributed most to the ML score, and the graph-based risk factors. This explanation is critical for analyst workflows and regulatory compliance.

C#
public class TransactionScoringPipeline
{
    private readonly IFeatureStore _featureStore;
    private readonly IRuleEngine _ruleEngine;
    private readonly IModelEnsemble _modelEnsemble;
    private readonly IGraphStore _graphStore;
    private readonly IScoreAggregator _aggregator;
    private readonly ILogger<TransactionScoringPipeline> _logger;

    public async Task<FraudScoreResult> ScoreTransactionAsync(
        TransactionEvent transaction,
        CancellationToken cancellationToken)
    {
        var sw = Stopwatch.StartNew();
        var context = new ScoringContext(transaction);

        var featureTask = _featureStore.GetFeaturesAsync(
            transaction.CustomerId, transaction.DeviceId,
            transaction.MerchantId, cancellationToken);

        var ruleTask = _ruleEngine.EvaluateAsync(transaction, cancellationToken);

        var graphTask = _graphStore.QueryEntityRelationshipsAsync(
            transaction, cancellationToken);

        await Task.WhenAll(featureTask, ruleTask, graphTask);

        context.Features = featureTask.Result;
        context.RuleResult = ruleTask.Result;
        context.GraphFeatures = graphTask.Result;

        if (context.RuleResult.HasHighConfidenceFraud)
        {
            return BuildResult(context, sw.ElapsedMilliseconds, 
                triggeredBy: "high-confidence-rule");
        }

        var mlScores = await _modelEnsemble.PredictAsync(
            context.Features, cancellationToken);

        context.MlScores = mlScores;

        var result = _aggregator.Aggregate(context);

        _logger.LogInformation(
            "Transaction {TxnId} scored {Score:F4} in {Elapsed}ms",
            transaction.TransactionId, result.RiskScore, 
            sw.ElapsedMilliseconds);

        return result;
    }

    private FraudScoreResult BuildResult(
        ScoringContext context, long elapsedMs, string triggeredBy)
    {
        return new FraudScoreResult
        {
            TransactionId = context.Transaction.TransactionId,
            RiskScore = 1.0,
            Decision = FraudDecision.Decline,
            TriggeredBy = triggeredBy,
            TriggeredRules = context.RuleResult.TriggeredRules,
            ElapsedMilliseconds = elapsedMs,
            Explanation = _aggregator.GenerateExplanation(context)
        };
    }
}

6. Feature Engineering Deep Dive

Feature engineering is arguably the most important component of the fraud detection system. The quality of features directly determines the accuracy of ML models and the effectiveness of rules. A well-engineered set of features can make a simple logistic regression model outperform a poorly-featured deep neural network. This section covers the major feature categories in detail.

Velocity Features

Velocity features capture the frequency and volume of transactions over various time windows. They are the most fundamental fraud signals — a card that makes 20 transactions in 5 minutes is highly suspicious. The system computes velocity features across multiple time windows (1 minute, 5 minutes, 15 minutes, 1 hour, 6 hours, 24 hours, 7 days, 30 days) and multiple dimensions (amount, count, unique merchants, unique countries).

Velocity features are computed using a sliding window approach with pre-aggregated counters. The stream processor maintains a set of counters per customer-card pair in the feature store, incrementing them on each new transaction and expiring them as the window slides. For 30-day windows, the counters are maintained in a separate batch-computed layer that runs hourly, because maintaining second-granularity counters for 30-day windows would require excessive memory.

Device Fingerprinting

Device fingerprinting creates a unique identifier for each device used to make a transaction. The fingerprint is constructed from multiple signals: browser user agent, screen resolution, installed fonts, WebGL renderer, canvas hash, time zone, language settings, and hardware concurrency. For mobile apps, additional signals include device model, OS version, accelerometer data, battery level, and gyroscope readings.

The device fingerprint is a powerful fraud signal because fraudsters frequently use virtual machines, emulators, or multi-device setups that produce distinctive fingerprints. A single device linked to multiple card numbers is highly suspicious. The system maintains a device reputation score that decays over time and is updated based on confirmed fraud decisions. Device fingerprints that have been associated with fraud in the past are flagged, and any transaction from those devices receives an elevated risk score.

Geolocation Analysis

Geolocation analysis examines the physical location of the transaction and compares it against the cardholder's known locations. Key features include: distance from the cardholder's home address, distance from the last transaction, time elapsed since the last transaction (to detect impossible travel — a transaction in New York followed by a transaction in London 30 minutes later), whether the transaction country matches the card's issuing country, and whether the IP geolocation matches the billing address.

The system uses a multi-source geolocation approach: GPS coordinates from mobile apps (most accurate), IP-based geolocation for web transactions (moderately accurate), and merchant country from the MCC for POS transactions (least granular but always available). For IP-based geolocation, the system cross-references multiple GeoIP databases and flags VPN/proxy/Tor exit nodes, which are strong fraud signals.

Behavioral Biometrics

Behavioral biometrics analyze how a user interacts with the device during the transaction. This includes typing speed and rhythm, mouse movement patterns, swipe velocity and angle on mobile devices, time spent on each page of the checkout flow, and navigation patterns (e.g., did the user go directly to checkout or browse first?). These signals are particularly powerful for detecting account takeover, because even if the attacker has valid credentials, their behavioral patterns will differ from the legitimate user.

The behavioral biometrics system builds a profile for each user over time, capturing their typical interaction patterns. During each transaction, the current session's behavioral data is compared against the user's profile using a cosine similarity score. Significant deviations (e.g., different typing rhythm, different navigation pattern) increase the risk score. This is implemented as a lightweight neural network that processes raw behavioral sequences and produces a behavioral similarity score in under 5ms.

C#
public class FeatureEngineeringService
{
    private readonly IFeatureStore _featureStore;
    private readonly IGeoLocationService _geoService;
    private readonly IDeviceFingerprintService _deviceService;
    private readonly IBehavioralBiometrics _biometricsService;

    public async Task<TransactionFeatures> ComputeFeaturesAsync(
        TransactionEvent transaction)
    {
        var tasks = new List<Task>();

        var velocityTask = ComputeVelocityFeaturesAsync(transaction);
        var geoTask = ComputeGeolocationFeaturesAsync(transaction);
        var deviceTask = ComputeDeviceFeaturesAsync(transaction);
        var behavioralTask = ComputeBehavioralFeaturesAsync(transaction);
        var merchantTask = ComputeMerchantFeaturesAsync(transaction);
        var historicalTask = ComputeHistoricalFeaturesAsync(transaction);

        await Task.WhenAll(velocityTask, geoTask, deviceTask,
            behavioralTask, merchantTask, historicalTask);

        return new TransactionFeatures
        {
            Velocity = velocityTask.Result,
            Geolocation = geoTask.Result,
            Device = deviceTask.Result,
            Behavioral = behavioralTask.Result,
            Merchant = merchantTask.Result,
            Historical = historicalTask.Result
        };
    }

    private async Task<VelocityFeatures> ComputeVelocityFeaturesAsync(
        TransactionEvent tx)
    {
        var windows = new[] { "1m", "5m", "15m", "1h", "6h", "24h", "7d", "30d" };
        var counters = await _featureStore.GetVelocityCountersAsync(
            tx.CustomerId, tx.CardNumber, windows);

        return new VelocityFeatures
        {
            TransactionCount1h = counters["1h"].Count,
            TransactionCount24h = counters["24h"].Count,
            TotalAmount1h = counters["1h"].TotalAmount,
            TotalAmount24h = counters["24h"].TotalAmount,
            UniqueMerchants24h = counters["24h"].UniqueMerchants,
            UniqueCountries7d = counters["7d"].UniqueCountries,
            AmountZScore30d = CalculateZScore(
                tx.Amount, counters["30d"].MeanAmount, 
                counters["30d"].StdDevAmount),
            TimeSinceLastTx = counters["1m"].SecondsSinceLast
        };
    }

    private async Task<GeolocationFeatures> ComputeGeolocationFeaturesAsync(
        TransactionEvent tx)
    {
        var currentLocation = await _geoService.ResolveLocationAsync(
            tx.IpAddress, tx.GeoLat, tx.GeoLon);
        var lastTransaction = await _featureStore.GetLastTransactionAsync(
            tx.CustomerId);

        var distanceFromHome = lastTransaction != null
            ? CalculateHaversineDistance(
                currentLocation, lastTransaction.Location)
            : double.MaxValue;

        var impossibleTravel = lastTransaction != null
            ? DetectImpossibleTravel(
                currentLocation, lastTransaction.Location,
                lastTransaction.Timestamp, tx.Timestamp)
            : false;

        return new GeolocationFeatures
        {
            DistanceFromHome = distanceFromHome,
            DistanceFromLastTx = distanceFromHome,
            ImpossibleTravel = impossibleTravel,
            IsVpnOrProxy = currentLocation.IsVpn,
            IsTorExit = currentLocation.IsTorExit,
            CountryMismatch = currentLocation.Country != 
                tx.CardIssuingCountry,
            DistanceFromBillingAddress = CalculateHaversineDistance(
                currentLocation, tx.BillingAddress)
        };
    }
}

7. Real-Time Feature Store

The real-time feature store is the central nervous system of the fraud detection platform. It must serve hundreds of features per transaction with sub-5ms latency while simultaneously ingesting updates from the stream processing layer. This dual requirement — read-optimized serving with write-heavy updates — makes the feature store one of the most architecturally challenging components.

Data Layout and Partitioning

Features are organized by entity type and time window. Each entity (customer, card, device, merchant) has a feature vector that is updated in real time. The feature store uses a column-oriented layout within Redis, where each feature is a separate Redis key with a naming convention: {entity_type}:{entity_id}:{feature_name}:{window}. This allows targeted retrieval of specific features without loading the entire feature vector.

For velocity features, the store maintains pre-computed counters that are atomically incremented on each transaction. These counters use Redis's HINCRBY command to atomically increment multiple fields within a hash, ensuring consistency even under high write concurrency. The counters are organized into time buckets (e.g., one hash per 5-minute bucket for the 1-hour window) to support sliding window semantics.

Caching Strategy

The L1 in-memory cache within each scoring service instance uses an LRU eviction policy with a TTL of 10 seconds. This cache is particularly effective for features that are accessed frequently (e.g., customer's basic profile, merchant category) and change slowly. The cache hit rate is typically 40-60% for L1, reducing Redis load significantly. For L2 (Redis), the hit rate is typically 95-99%, with misses occurring primarily for new customers or rarely-used entities.

Feature Computation Patterns

The feature computation layer supports three patterns: (1) event-time features, computed from the transaction event itself (e.g., transaction amount, merchant country); (2) context-time features, computed from recent history (e.g., velocity counts, rolling averages); and (3) batch features, computed offline and loaded into the store (e.g., 30-day spending patterns, customer lifetime value). The stream processor handles patterns 1 and 2 in real time, while a daily batch job handles pattern 3.

C#
public class FeatureStore : IFeatureStore
{
    private readonly IDatabase _redis;
    private readonly IMemoryCache _l1Cache;
    private readonly FeatureConfig _config;

    public async Task<Dictionary<string, double>> GetFeaturesAsync(
        string customerId, string deviceId, 
        string merchantId, CancellationToken ct)
    {
        var featureKeys = BuildFeatureKeySet(
            customerId, deviceId, merchantId);

        var result = new Dictionary<string, double>();
        var cacheMisses = new List<string>();

        foreach (var key in featureKeys)
        {
            if (_l1Cache.TryGetValue(key, out double cachedValue))
            {
                result[key] = cachedValue;
                continue;
            }
            cacheMisses.Add(key);
        }

        if (cacheMisses.Count > 0)
        {
            var pipeline = _redis.CreatePipeline();
            var tasks = cacheMisses.Select(async key =>
            {
                var value = await pipeline.StringGetAsync(key);
                if (value.HasValue)
                {
                    var doubleVal = (double)value;
                    result[key] = doubleVal;
                    _l1Cache.Set(key, doubleVal, 
                        TimeSpan.FromSeconds(10));
                }
            });
            await pipeline.ExecuteAsync();
            await Task.WhenAll(tasks);
        }

        return result;
    }

    public async Task UpdateVelocityCountersAsync(
        string customerId, string cardNumber, 
        double amount, string merchantCountry)
    {
        var now = DateTimeOffset.UtcNow;
        var batch = _redis.CreateBatch();

        var windowConfigs = new[]
        {
            ("1m", TimeSpan.FromMinutes(1)),
            ("5m", TimeSpan.FromMinutes(5)),
            ("1h", TimeSpan.FromHours(1)),
            ("24h", TimeSpan.FromHours(24)),
            ("7d", TimeSpan.FromDays(7))
        };

        foreach (var (window, ttl) in windowConfigs)
        {
            var key = $"velocity:{customerId}:{cardNumber}:{window}";
            batch.HashIncrementAsync(key, "count");
            batch.HashIncrementAsync(key, "total_amount", 
                (long)(amount * 100));
            batch.KeyExpireAsync(key, ttl);
        }

        batch.Execute();
    }
}

8. Rule Engine & Fraud Rule DSL

While ML models provide the highest detection accuracy for complex patterns, business rules remain essential for encoding known fraud patterns, regulatory requirements, and edge cases that ML models may miss. The rule engine must be fast (evaluate all rules in under 10ms), flexible (business analysts can modify rules without code deployments), and auditable (every rule evaluation is logged for compliance).

Rule DSL Design

The fraud rule DSL is designed to be readable by business analysts while remaining efficient for machine execution. Rules are defined as structured expressions that combine conditions on transaction attributes with actions (score adjustments, flags, alerts). The DSL supports temporal operators (velocity windows, time-of-day), logical operators (AND, OR, NOT), comparison operators, and custom function calls.

DSL
// Rule: Block transactions from high-risk countries 
// at unusual hours
RULE "high_risk_country_night_fraud"
  DESCRIPTION "Transactions from sanctioned or high-risk 
               countries between midnight and 5 AM local time"
  PRIORITY 100
  WHEN
    transaction.merchant_country IN @high_risk_countries
    AND transaction.local_hour BETWEEN 0 AND 5
    AND customer.account_age_days < 90
  THEN
    SET risk_score += 0.4
    SET flags ADD "high_risk_geo_time"
    ACTION ALERT(priority: "high", category: "geo_anomaly")

// Rule: Velocity-based card testing detection
RULE "card_testing_velocity"
  DESCRIPTION "Multiple small transactions in rapid succession"
  PRIORITY 90
  WHEN
    velocity.count_1h >= 5
    AND velocity.total_amount_1h < 50.00
    AND velocity.unique_merchants_1h >= 3
    AND ALL(velocity.last_5_amounts, amt => amt < 10.00)
  THEN
    SET risk_score += 0.5
    SET flags ADD "card_testing_pattern"
    ACTION DECLINE(reason: "suspected_card_testing")

// Rule: Impossible travel detection
RULE "impossible_travel"
  DESCRIPTION "Transaction location physically impossible 
               given time since last transaction"
  PRIORITY 95
  WHEN
    geolocation.distance_from_last_tx_km > 500
    AND geolocation.seconds_since_last_tx < 3600
    AND geolocation.impossible_travel = TRUE
  THEN
    SET risk_score += 0.6
    SET flags ADD "impossible_travel"
    ACTION STEP_UP_AUTH(method: "sms_otp")

// Rule: New device with high-value transaction
RULE "new_device_high_value"
  DESCRIPTION "First transaction from a new device above threshold"
  PRIORITY 85
  WHEN
    device.is_new = TRUE
    AND transaction.amount > customer.avg_transaction_amount_30d * 3
    AND customer.total_devices > 5
  THEN
    SET risk_score += 0.3
    SET flags ADD "new_device_high_value"
    ACTION STEP_UP_AUTH(method: "push_notification")

Rule Evaluation Architecture

The rule engine compiles the DSL into an optimized evaluation tree at deployment time. Rules are organized into tiers based on execution cost: Tier 0 contains O(1) lookups (blacklist checks, whitelist checks) that execute in under 1ms. Tier 1 contains simple threshold comparisons that execute in 1-3ms. Tier 2 contains velocity checks and pattern matching that execute in 3-8ms. Tier 3 contains complex correlation rules that execute in 8-15ms. Evaluation proceeds tier by tier, with early termination if a high-confidence fraud signal is detected in an earlier tier.

Rules are versioned and deployed through a GitOps workflow. Analysts write rules in the DSL, submit them for review, and once approved, the rules are compiled and deployed to all scoring service instances. The deployment is atomic — all instances switch to the new rule set simultaneously using a feature flag mechanism. This ensures consistent rule evaluation across the fleet and allows instant rollback if a new rule causes unexpected behavior.

C#
public class RuleEngine : IRuleEngine
{
    private readonly CompiledRuleSet _ruleSet;
    private readonly IBlacklistStore _blacklistStore;
    private readonly IWhitelistStore _whitelistStore;

    public async Task<RuleEvaluationResult> EvaluateAsync(
        TransactionEvent transaction,
        CancellationToken cancellationToken)
    {
        var result = new RuleEvaluationResult();

        // Tier 0: O(1) lookups (1ms budget)
        if (await _blacklistStore.IsBlacklistedAsync(
            transaction.CardNumber, transaction.DeviceId,
            transaction.IpAddress))
        {
            result.AddTriggeredRule("blacklist_match", 1.0);
            result.HasHighConfidenceFraud = true;
            return result;
        }

        if (await _whitelistStore.IsWhitelistedAsync(
            transaction.CustomerId))
        {
            result.IsWhitelisted = true;
            return result;
        }

        // Tier 1-3: Evaluate compiled rules in priority order
        var context = new RuleContext(transaction);
        foreach (var rule in _ruleSet.GetRulesByPriority())
        {
            if (rule.Evaluate(context, out var ruleResult))
            {
                result.AddTriggeredRule(rule.Id, ruleResult.Score);
                result.ScoreAdjustments.Add(ruleResult.Score);
                result.TriggeredRules.Add(new TriggeredRule
                {
                    RuleId = rule.Id,
                    Description = rule.Description,
                    Score = ruleResult.Score,
                    Actions = ruleResult.Actions
                });

                if (result.TotalScore >= 0.9)
                {
                    result.HasHighConfidenceFraud = true;
                    break;
                }
            }
        }

        return result;
    }
}

9. ML Models for Fraud Detection

Machine learning models are the primary detection mechanism for sophisticated fraud patterns that rules cannot capture. The system deploys an ensemble of models, each specialized for different fraud types and data modalities. The models are retrained daily on the latest labeled data and validated against strict accuracy and latency requirements before deployment.

Model Architecture

Gradient Boosting Model (XGBoost)

The gradient boosting model is the workhorse of the ensemble. It processes 200 engineered tabular features and produces a probability of fraud. XGBoost is chosen for its strong performance on tabular data, fast inference speed (5ms on CPU for a model with 500 trees), and native handling of missing values. The model is trained with class-weighted loss to handle the extreme class imbalance typical in fraud data (less than 0.1% fraudulent transactions).

Deep Neural Network

The deep neural network (DNN) captures complex feature interactions that gradient boosting may miss. The architecture uses a TabNet-style approach with sparse feature attention, allowing the model to dynamically select which features to focus on for each transaction. The DNN processes both dense features (velocity counts, amounts) and sparse features (merchant category, device type, country) through separate embedding layers before combining them in a shared representation.

Sequence Model

The sequence model processes the customer's last 50 transactions as a time series. Each transaction is represented by its features, and the model learns to identify anomalous sequences — e.g., a sudden change in spending pattern, a burst of small transactions followed by a large one, or a geographic pattern that breaks the customer's typical behavior. The model uses a lightweight Transformer architecture with causal self-attention, processing the sequence in 15ms on GPU.

Graph Neural Network

The graph neural network (GNN) operates on the transaction graph, where nodes represent entities (customers, cards, devices, merchants) and edges represent relationships (transactions, shared attributes). For each transaction being scored, the GNN extracts a 2-hop local subgraph centered on the transacting entities and runs message-passing inference to propagate signals from neighboring nodes. This allows the model to detect patterns like: a card shared across multiple accounts (card pooling), a device linked to many different cards (device farming), or a merchant receiving payments from many newly-created accounts (merchant collusion).

C#
public class ModelEnsemble : IModelEnsemble
{
    private readonly XGBoostModel _gradientBoosting;
    private readonly DNNModel _deepNeuralNet;
    private readonly SequenceModel _sequenceModel;
    private readonly GNNModel _graphNeuralNet;
    private readonly MetaLearner _metaLearner;

    public async Task<EnsembleScores> PredictAsync(
        TransactionFeatures features,
        CancellationToken ct)
    {
        var gbTask = _gradientBoosting.PredictAsync(
            features.Tabular, ct);
        var dnnTask = _deepNeuralNet.PredictAsync(
            features.Dense, features.Sparse, ct);
        var seqTask = _sequenceModel.PredictAsync(
            features.TransactionSequence, ct);
        var gnnTask = _graphNeuralNet.PredictAsync(
            features.LocalSubgraph, ct);

        await Task.WhenAll(gbTask, dnnTask, seqTask, gnnTask);

        var modelScores = new ModelScores
        {
            GradientBoosting = gbTask.Result.Probability,
            DeepNeuralNet = dnnTask.Result.Probability,
            Sequence = seqTask.Result.Probability,
            GraphNeuralNet = gnnTask.Result.Probability
        };

        var metaFeatures = BuildMetaFeatures(
            modelScores, features);
        var finalScore = await _metaLearner.PredictAsync(
            metaFeatures, ct);

        return new EnsembleScores
        {
            ModelScores = modelScores,
            FinalScore = finalScore,
            FeatureImportances = gbTask.Result.FeatureImportances
        };
    }
}

Model Training Pipeline

Models are retrained daily using a pipeline that: (1) extracts labeled data from the past 90 days (confirmed fraud and confirmed legitimate transactions), (2) engineers features using the same feature definitions as the production feature store, (3) handles class imbalance using SMOTE oversampling and class-weighted loss functions, (4) trains each model with hyperparameter optimization using Optuna, (5) validates the model against holdout data with strict minimum recall and maximum false positive rate thresholds, (6) runs A/B test evaluation in shadow mode for 24 hours, and (7) promotes the model to production if it meets all quality gates.

10. Graph-Based Fraud Detection

Graph-based fraud detection is the most powerful technique for identifying organized fraud — money laundering networks, synthetic identity rings, and coordinated account takeover campaigns. These attacks involve multiple entities working together, and their relationships (shared devices, addresses, phone numbers, transaction patterns) form a graph structure that is invisible to individual transaction analysis.

Graph Construction

The transaction graph is maintained in real time using a streaming graph database. Each new transaction adds edges between the involved entities: customer-to-card, customer-to-device, card-to-merchant, device-to-IP, and so on. The graph is partitioned by entity ID for distributed storage, with edge replication across partitions for efficient traversal. The graph stores both structural information (who is connected to whom) and temporal information (when the connection was established, how frequently it is used).

Graph Features for ML Models

The graph store computes structural features that are fed into the ML models: PageRank scores for each entity (how "important" or "central" they are in the network), community detection scores (which tightly-connected groups they belong to), degree centrality (how many connections they have), clustering coefficient (how interconnected their neighbors are), and path-based features (shortest path between two entities, number of shared neighbors).

Money Laundering Detection

Money laundering follows distinct graph patterns: layering (moving money through multiple accounts to obscure its origin), structuring (breaking large amounts into smaller transactions below reporting thresholds), and funneling (collecting money from multiple sources into a single account). The system uses a combination of graph algorithms (PageRank, community detection, shortest path) and graph neural networks to detect these patterns. Suspicious patterns are flagged for immediate investigation.

Real-Time Graph Traversal

During transaction scoring, the system performs a 2-hop traversal from the transacting entities to collect graph-based features. This traversal must complete within 10ms, which is achieved through careful graph partitioning, edge caching, and limiting the traversal to the most relevant edge types. The traversal results in a local subgraph that is fed into the GNN model for scoring.

C#
public class GraphFraudDetector
{
    private readonly IGraphStore _graphStore;
    private readonly IGNNModel _gnnModel;
    private readonly ICommunityDetector _communityDetector;

    public async Task<GraphRiskSignals> AnalyzeTransactionGraphAsync(
        TransactionEvent transaction)
    {
        var entities = ExtractEntities(transaction);
        var subgraph = await _graphStore.GetLocalSubgraphAsync(
            entities, maxHops: 2, maxNodes: 500);

        var structuralFeatures = ComputeStructuralFeatures(subgraph);
        var communityInfo = await _communityDetector
            .DetectCommunitiesAsync(subgraph);
        var gnnScore = await _gnnModel.ScoreSubgraphAsync(subgraph);

        var suspiciousPatterns = new List<SuspiciousPattern>();

        if (structuralFeatures.SharedDeviceCount > 3)
        {
            suspiciousPatterns.Add(new SuspiciousPattern
            {
                Type = "device_farming",
                Confidence = 0.85,
                Description = $"Entity linked to {structuralFeatures.SharedDeviceCount} accounts via shared device"
            });
        }

        if (communityInfo.IsDenseCommunity &&
            communityInfo.CommunityAge < TimeSpan.FromDays(7))
        {
            suspiciousPatterns.Add(new SuspiciousPattern
            {
                Type = "fraud_ring",
                Confidence = 0.75,
                Description = "Dense recently-formed community detected"
            });
        }

        var layeringScore = DetectLayeringPattern(subgraph);
        if (layeringScore > 0.7)
        {
            suspiciousPatterns.Add(new SuspiciousPattern
            {
                Type = "money_layering",
                Confidence = layeringScore,
                Description = "Multi-hop money flow pattern detected"
            });
        }

        return new GraphRiskSignals
        {
            GNNScore = gnnScore,
            StructuralFeatures = structuralFeatures,
            CommunityInfo = communityInfo,
            SuspiciousPatterns = suspiciousPatterns,
            RiskContribution = CalculateGraphRisk(
                gnnScore, suspiciousPatterns)
        };
    }

    private StructuralFeatures ComputeStructuralFeatures(
        SubGraph subgraph)
    {
        return new StructuralFeatures
        {
            DegreeCentrality = subgraph.GetDegreeCentrality(),
            ClusteringCoefficient = subgraph.GetClusteringCoefficient(),
            SharedDeviceCount = subgraph.CountSharedDevices(),
            SharedIPCount = subgraph.CountSharedIPs(),
            SharedAddressCount = subgraph.CountSharedAddresses(),
            PageRankScore = subgraph.GetPageRank(),
            BetweennessCentrality = subgraph.GetBetweennessCentrality(),
            CommunityModularity = subgraph.GetModularity()
        };
    }
}

11. Entity Resolution & Identity Linking

Entity resolution is the process of determining that multiple records refer to the same real-world entity. In fraud detection, this means linking multiple accounts, devices, addresses, phone numbers, and email addresses to the same person. Without entity resolution, a fraudster who creates 20 accounts using different names but the same device appears as 20 separate customers, each with a clean history. Entity resolution collapses these into a single entity, revealing the coordinated nature of the fraud.

Resolution Techniques

The system uses a multi-pass approach to entity resolution. Pass 1 uses deterministic matching: exact matches on government IDs, phone numbers, or email addresses link records with high confidence. Pass 2 uses probabilistic matching: fuzzy name matching (Levenshtein distance, Jaro-Winkler similarity), address normalization and matching, and device fingerprint matching. Pass 3 uses graph-based resolution: entities that are closely connected in the transaction graph (frequent transactions between them, shared attributes) are likely related.

Each resolution technique produces a confidence score, and entities are linked when the combined confidence exceeds a threshold. The threshold is tuned to balance precision (avoiding false links) and recall (capturing all links). In production, typical precision is 98% and recall is 85%, meaning 98% of detected links are correct, but 15% of actual links are missed.

Entity Clusters

Once entities are linked, they form clusters — groups of accounts, devices, and identifiers that all belong to the same underlying person. The entity cluster becomes the unit of risk assessment: instead of evaluating individual accounts, the system evaluates clusters. A cluster with 10 accounts, 5 devices, and 3 addresses is inherently more suspicious than a single account with a single device, even if each individual account appears legitimate.

C#
public class EntityResolutionService
{
    private readonly IDeterministicMatcher _deterministicMatcher;
    private readonly IProbabilisticMatcher _probabilisticMatcher;
    private readonly IGraphResolver _graphResolver;
    private readonly IEntityClusterStore _clusterStore;

    public async Task<EntityCluster> ResolveEntitiesAsync(
        TransactionEvent transaction)
    {
        var candidateEntities = new List<EntityReference>();

        var deterministicLinks = await _deterministicMatcher
            .FindExactMatchesAsync(transaction);
        candidateEntities.AddRange(deterministicLinks);

        if (candidateEntities.Count == 0)
        {
            var probabilisticLinks = await _probabilisticMatcher
                .FindFuzzyMatchesAsync(transaction);
            candidateEntities.AddRange(probabilisticLinks);
        }

        var graphLinks = await _graphResolver
            .FindGraphConnectionsAsync(transaction, candidateEntities);

        var allLinks = candidateEntities
            .Concat(graphLinks)
            .Where(link => link.Confidence > 0.6)
            .GroupBy(link => link.TargetEntityId)
            .Select(g => new EntityLink
            {
                EntityId = g.Key,
                Confidence = g.Max(l => l.Confidence),
                LinkTypes = g.Select(l => l.LinkType).Distinct().ToList()
            })
            .ToList();

        if (allLinks.Count > 0)
        {
            var clusterId = allLinks.First().EntityId;
            var cluster = await _clusterStore.GetClusterAsync(clusterId);

            foreach (var link in allLinks)
            {
                await _clusterStore.MergeEntitiesAsync(
                    clusterId, link.EntityId, link.Confidence);
            }

            return await _clusterStore.GetClusterAsync(clusterId);
        }

        return await _clusterStore.CreateNewClusterAsync(transaction);
    }
}

12. Reputation Systems (Device, IP, Email, Phone)

Reputation systems assign trust scores to entities based on their historical behavior. A device that has been associated with 50 fraudulent transactions has a low reputation score, while a device that has been used for legitimate transactions for 2 years has a high reputation score. Reputation scores are used as features in the ML models and as inputs to the rule engine.

Device Reputation

Device reputation is computed from multiple signals: the device's age (how long it has been in use), its transaction history (ratio of legitimate to fraudulent transactions), its sharing pattern (how many different accounts use it), its technical characteristics (is it an emulator, rooted device, or jailbroken phone?), and its consistency (does the device fingerprint remain stable over time?). The reputation score ranges from 0 (known fraudulent device) to 1 (highly trusted device) and is updated after each transaction.

IP Reputation

IP reputation assesses the trustworthiness of the IP address used for the transaction. The system maintains a database of known bad IP ranges (Tor exit nodes, VPN providers, data centers, known proxy servers, IP addresses associated with past fraud). The IP reputation score considers: whether the IP is from a residential or data center range, whether it is associated with a VPN or proxy, its geographic consistency with the cardholder's location, its historical fraud association, and its risk category from threat intelligence feeds.

Email and Phone Reputation

Email reputation evaluates the trustworthiness of the email address associated with the account. Signals include: email domain reputation (is it a disposable email provider like tempmail.com?), email age (how long has this email been registered?), email validation status (does the MX record resolve? does the email receive mail?), email-breach associations (has this email appeared in data breaches?), and behavioral signals (does the email receive marketing emails from the same institution as the account?). Phone reputation follows a similar pattern, evaluating the carrier, line type (mobile vs. VoIP), age, and breach history.

C#
public class ReputationService
{
    private readonly IReputationStore _reputationStore;
    private readonly IThreatIntelligence _threatIntel;

    public async Task<ReputationScores> ComputeReputationAsync(
        TransactionEvent transaction)
    {
        var deviceTask = ComputeDeviceReputationAsync(
            transaction.DeviceId);
        var ipTask = ComputeIPReputationAsync(transaction.IpAddress);
        var emailTask = ComputeEmailReputationAsync(
            transaction.CustomerEmail);
        var phoneTask = ComputePhoneReputationAsync(
            transaction.CustomerPhone);
        var merchantTask = ComputeMerchantReputationAsync(
            transaction.MerchantId);

        await Task.WhenAll(deviceTask, ipTask, emailTask, 
            phoneTask, merchantTask);

        return new ReputationScores
        {
            DeviceScore = deviceTask.Result,
            IPScore = ipTask.Result,
            EmailScore = emailTask.Result,
            PhoneScore = phoneTask.Result,
            MerchantScore = merchantTask.Result,
            CompositeReputation = CalculateComposite(
                deviceTask.Result, ipTask.Result, 
                emailTask.Result, phoneTask.Result,
                merchantTask.Result)
        };
    }

    private async Task<ReputationScore> ComputeDeviceReputationAsync(
        string deviceId)
    {
        var deviceHistory = await _reputationStore
            .GetDeviceHistoryAsync(deviceId);
        var threatInfo = await _threatIntel
            .GetDeviceThreatInfoAsync(deviceId);

        double score = 0.5; // Start at neutral

        // Adjust based on history
        score += deviceHistory.LegitimateTransactionRatio * 0.3;
        score -= deviceHistory.FraudAssociationCount * 0.1;
        score -= deviceHistory.AccountCount * 0.02; // Penalize multi-accounting
        score -= threatInfo.IsEmulator ? 0.4 : 0;
        score -= threatInfo.IsRooted ? 0.2 : 0;
        score += Math.Min(deviceHistory.AgeDays / 365.0, 1.0) * 0.2;

        return new ReputationScore
        {
            Score = Math.Clamp(score, 0.0, 1.0),
            Factors = new Dictionary<string, double>
            {
                ["history_ratio"] = deviceHistory.LegitimateTransactionRatio,
                ["fraud_associations"] = deviceHistory.FraudAssociationCount,
                ["is_emulator"] = threatInfo.IsEmulator ? 1.0 : 0.0,
                ["device_age"] = deviceHistory.AgeDays
            }
        };
    }
}

13. Composite Risk Scoring

The composite risk score is the final output of the fraud detection system — a single number between 0 and 1 that represents the overall fraud risk of a transaction. This score is produced by combining signals from all subsystems: rule engine outputs, ML model scores, graph-based signals, reputation scores, and entity resolution information. The score must be calibrated so that the threshold can be tuned to balance fraud detection rate against false positive rate.

Scoring Architecture

The composite score is computed by a meta-learner that is trained on the outputs of all subsystems. The meta-learner is a simple logistic regression model that learns the optimal weights for combining different signals. This approach is more robust than hand-tuned weights because it adapts to changes in signal quality over time. The meta-learner is retrained weekly using the latest confirmed fraud decisions as labels.

Score Calibration

Raw ML model outputs are probability estimates that may not be well-calibrated — a model output of 0.7 does not necessarily mean a 70% probability of fraud. The system applies Platt scaling to calibrate each model's outputs before feeding them into the meta-learner. This ensures that the composite score is a meaningful probability estimate that can be directly interpreted and used for threshold-based decisions.

Decision Thresholds

The thresholds are configurable per merchant, per customer segment, and per transaction type. High-risk merchants (online gambling, digital goods) may have lower step-up thresholds, while low-risk merchants (grocery stores, utilities) may have higher thresholds. The thresholds are tuned by the risk management team based on the current fraud rate, false positive tolerance, and business objectives.

C#
public class CompositeScorer
{
    private readonly MetaLearner _metaLearner;
    private readonly IThresholdManager _thresholdManager;

    public FraudScoreResult ComputeCompositeScore(
        ScoringContext context)
    {
        var metaFeatures = new double[]
        {
            context.RuleResult.TotalScore,
            context.MlScores.GradientBoosting,
            context.MlScores.DeepNeuralNet,
            context.MlScores.Sequence,
            context.MlScores.GraphNeuralNet,
            context.ReputationScores.CompositeReputation,
            context.GraphFeatures.GNNScore,
            context.EntityCluster.ClusterSize,
            context.EntityCluster.FraudHistoryRate,
            context.Features.Velocity.TransactionCount1h,
            context.Features.Velocity.AmountZScore30d,
            context.Features.Geolocation.DistanceFromHome,
            context.Features.Device.AgeDays,
            context.Features.Behavioral.SimilarityScore,
            context.Features.Merchant.RiskScore
        };

        var rawScore = _metaLearner.Predict(metaFeatures);
        var calibratedScore = PlattScaling(rawScore);

        var thresholds = _thresholdManager.GetThresholds(
            context.Transaction.MerchantId,
            context.Transaction.CustomerSegment,
            context.Transaction.TransactionType);

        var decision = calibratedScore switch
        {
            var s when s < thresholds.ApproveThreshold 
                => FraudDecision.Approve,
            var s when s < thresholds.StepUpThreshold 
                => FraudDecision.StepUpAuth,
            var s when s < thresholds.DeclineThreshold 
                => FraudDecision.Decline,
            _ => FraudDecision.AutoBlock
        };

        return new FraudScoreResult
        {
            TransactionId = context.Transaction.TransactionId,
            RiskScore = calibratedScore,
            Decision = decision,
            Explanation = GenerateExplanation(metaFeatures, 
                context),
            ModelScores = context.MlScores,
            TriggeredRules = context.RuleResult.TriggeredRules
        };
    }
}

14. Whitelisting, Blacklisting & Consortium Data

Whitelisting

Whitelisting exempts trusted entities from fraud checks, reducing false positives and improving customer experience. Whitelist entries can be created manually by analysts (e.g., a known corporate account with high transaction volumes) or automatically based on long-term behavior (e.g., a customer with 5 years of clean history). Whitelist entries have configurable scopes (customer-level, device-level, IP-level, merchant-level) and TTLs (permanent, 30 days, 90 days). The whitelist is stored in Redis for sub-millisecond lookup and is synchronized across all scoring service instances.

Blacklisting

Blacklisting immediately blocks transactions from known bad entities. Blacklist entries can come from analyst decisions (confirmed fraud cases), consortium data sharing (fraud patterns identified by partner institutions), or automated detection (devices/IPs associated with multiple fraud events). Blacklisted entities are blocked at the earliest possible stage of the scoring pipeline (Tier 0 of the rule engine) to minimize latency impact. Blacklist entries support inheritance: blacklisting a device also blacklists all cards and accounts associated with that device.

Consortium Data Sharing

Consortium data sharing allows multiple institutions to share fraud intelligence while preserving customer privacy. The system participates in industry consortiums where fraud events are shared in a standardized, anonymized format. When a bank confirms a fraudulent transaction, the associated signals (device fingerprint, IP address, behavioral pattern) are shared with the consortium, allowing other participating institutions to proactively block similar fraud attempts. The data is shared using privacy-preserving techniques: k-anonymity (ensuring each shared record matches at least k other records), differential privacy (adding calibrated noise to shared features), and secure multi-party computation (computing aggregate statistics without revealing individual records).

15. Model Explainability (SHAP Values)

Explainability is critical in fraud detection for three reasons: (1) analysts need to understand why a transaction was flagged to make informed decisions, (2) regulators require documented reasoning for adverse actions (declining a transaction, closing an account), and (3) model developers need to understand model behavior to identify weaknesses and improve performance. The system uses SHAP (SHapley Additive exPlanations) values to explain individual predictions.

SHAP Values for Fraud Detection

SHAP values decompose a model's prediction into the contribution of each input feature. For a given transaction, the SHAP analysis shows which features pushed the risk score higher (positive SHAP values, e.g., "high velocity count contributed +0.15 to the risk score") and which features pushed it lower (negative SHAP values, e.g., "trusted device contributed -0.08 to the risk score"). The sum of all SHAP values plus the model's base prediction equals the final prediction.

The system computes SHAP values using the TreeSHAP algorithm for the gradient boosting model (which is exact and fast) and KernelSHAP for the neural network models (which is approximate but model-agnostic). SHAP computation adds approximately 5ms to the scoring pipeline, which is within the latency budget. The SHAP values are included in the alert payload so analysts can immediately see the top contributing factors.

C#
public class ExplainabilityService
{
    private readonly ITreeSHAP _treeShap;
    private readonly IKernelSHAP _kernelShap;

    public FraudExplanation GenerateExplanation(
        ScoringContext context, double[] shapValues)
    {
        var featureNames = GetFeatureNames();
        var featureContributions = featureNames
            .Zip(shapValues, (name, value) => new FeatureContribution
            {
                FeatureName = name,
                SHAPValue = value,
                Direction = value > 0 ? "increases_risk" : "decreases_risk",
                Magnitude = Math.Abs(value)
            })
            .OrderByDescending(fc => fc.Magnitude)
            .Take(10)
            .ToList();

        var triggeredRuleExplanations = context.RuleResult.TriggeredRules
            .Select(r => new RuleExplanation
            {
                RuleId = r.RuleId,
                Description = r.Description,
                ScoreContribution = r.Score,
                Conditions = r.MatchedConditions
            })
            .ToList();

        var graphExplanations = context.GraphFeatures.SuspiciousPatterns
            .Select(p => new GraphExplanation
            {
                PatternType = p.Type,
                Confidence = p.Confidence,
                Description = p.Description
            })
            .ToList();

        var narrativeExplanation = GenerateNarrative(
            featureContributions, triggeredRuleExplanations,
            graphExplanations, context);

        return new FraudExplanation
        {
            TopFeatureContributions = featureContributions,
            TriggeredRules = triggeredRuleExplanations,
            GraphPatterns = graphExplanations,
            NarrativeExplanation = narrativeExplanation,
            ModelUsed = context.UsedModel
        };
    }

    private string GenerateNarrative(
        List<FeatureContribution> features,
        List<RuleExplanation> rules,
        List<GraphExplanation> graphs,
        ScoringContext context)
    {
        var parts = new List<string>();

        if (features.Any(f => f.FeatureName.Contains("velocity")))
        {
            var velocityFeature = features.First(
                f => f.FeatureName.Contains("velocity"));
            parts.Add($"Unusual transaction velocity " +
                $"({velocityFeature.SHAPValue:+0.00;-0.00})");
        }

        if (rules.Count > 0)
        {
            parts.Add($"{rules.Count} fraud rule(s) triggered: " +
                string.Join(", ", rules.Select(r => r.RuleId)));
        }

        if (graphs.Count > 0)
        {
            parts.Add($"Graph analysis detected: " +
                string.Join(", ", graphs.Select(g => g.PatternType)));
        }

        return string.Join(". ", parts) + ".";
    }
}

16. Alert Generation & Prioritization

When a transaction is flagged for review, the system generates an alert that captures all relevant context for analyst investigation. Alert prioritization ensures that analysts focus on the highest-impact cases first, maximizing fraud recovery per analyst hour.

Alert Structure

Each alert contains: the flagged transaction details, the risk score and decision, the top SHAP feature contributions, triggered rules, reputation scores, entity cluster information, related transactions (last 30 days for the same entity cluster), the explainability narrative, and suggested actions (block card, request additional verification, close account). The alert is enriched with data from multiple sources to give analysts a complete picture without requiring them to look up information in separate systems.

Prioritization Algorithm

Alerts are prioritized using a scoring function that considers: fraud probability (risk score), financial exposure (transaction amount and pending amounts), analyst expertise match (some analysts specialize in certain fraud types), time sensitivity (recent transactions may still be reversible), and evidence strength (alerts with strong evidence are faster to resolve). The priority score determines the order in which alerts appear in analyst queues and the SLA for resolution.

C#
public class AlertService
{
    private readonly IAlertStore _alertStore;
    private readonly IPriorityCalculator _priorityCalculator;
    private readonly INotificationService _notificationService;

    public async Task<Alert> GenerateAlertAsync(
        FraudScoreResult scoreResult,
        TransactionEvent transaction)
    {
        var explanation = await _explainabilityService
            .GenerateExplanationAsync(scoreResult);

        var relatedTransactions = await _transactionStore
            .GetRelatedTransactionsAsync(
                transaction.CustomerId, 
                TimeSpan.FromDays(30));

        var priority = _priorityCalculator.Calculate(new PriorityContext
        {
            RiskScore = scoreResult.RiskScore,
            TransactionAmount = transaction.Amount,
            TriggeredRuleCount = scoreResult.TriggeredRules.Count,
            HasGraphSignals = scoreResult.GraphPatterns.Any(),
            RelatedFraudCount = relatedTransactions
                .Count(t => t.WasFraud)
        });

        var alert = new Alert
        {
            Id = Guid.NewGuid().ToString(),
            TransactionId = transaction.TransactionId,
            CustomerId = transaction.CustomerId,
            RiskScore = scoreResult.RiskScore,
            Priority = priority,
            Decision = scoreResult.Decision,
            Explanation = explanation,
            RelatedTransactions = relatedTransactions,
            SuggestedActions = DetermineSuggestedActions(scoreResult),
            CreatedAt = DateTime.UtcNow,
            SLA = CalculateSLA(priority),
            Status = AlertStatus.Open
        };

        await _alertStore.SaveAlertAsync(alert);

        if (priority == AlertPriority.Critical)
        {
            await _notificationService.NotifyCriticalAlertAsync(alert);
        }

        return alert;
    }
}

17. Case Management Workflow

The case management system provides analysts with tools to investigate alerts, make decisions, and track outcomes. It is the human-in-the-loop component that bridges automated detection with manual review. The workflow is designed to maximize analyst efficiency while ensuring thorough investigation.

Workflow Stages

Investigation Tools

Analysts have access to a rich investigation dashboard that displays: the flagged transaction and its full context, the entity cluster (all linked accounts, devices, addresses), a timeline view of recent activity, the transaction graph visualization, historical fraud decisions for the entity, and the model's explanation (SHAP values and triggered rules). The dashboard also supports side-by-side comparison with known fraud patterns, allowing analysts to quickly identify matches with previously confirmed fraud cases.

Decision Tracking

Every analyst decision is tracked with full audit trails: the analyst ID, timestamp, decision category (confirmed fraud, false positive, escalation), reasoning notes, and confidence level. These decisions feed directly into the ML training pipeline — confirmed fraud cases become positive training examples, and false positives become negative training examples. This creates a virtuous cycle where analyst expertise continuously improves model accuracy.

Automation Rules

The case management system supports automation rules that reduce analyst workload: auto-close alerts that are below a re-evaluation threshold after a cooling period, auto-approve transactions from entities with recent analyst approval, auto-decline transactions from entities with recent fraud confirmation, and route alerts to specialized analysts based on fraud type and transaction characteristics.

C#
public class CaseManagementService
{
    private readonly IAlertStore _alertStore;
    private readonly IDecisionStore _decisionStore;
    private readonly IFeedbackLoop _feedbackLoop;

    public async Task<AnalystDecision> RecordDecisionAsync(
        string alertId, AnalystDecisionRequest request)
    {
        var alert = await _alertStore.GetAlertAsync(alertId);

        var decision = new AnalystDecision
        {
            AlertId = alertId,
            AnalystId = request.AnalystId,
            Decision = request.Decision,
            Category = request.Category,
            Reasoning = request.Reasoning,
            Confidence = request.Confidence,
            Timestamp = DateTime.UtcNow
        };

        await _decisionStore.SaveDecisionAsync(decision);
        await _alertStore.UpdateAlertStatusAsync(
            alertId, AlertStatus.Resolved);

        await _feedbackLoop.ProcessDecisionAsync(
            alert.TransactionId,
            decision.Category == DecisionCategory.ConfirmedFraud,
            decision.AnalystId);

        if (decision.Category == DecisionCategory.ConfirmedFraud)
        {
            await UpdateEntityReputationAsync(
                alert.CustomerId, isFraud: true);
            await PropagateToConsortiumAsync(alert, decision);
        }

        return decision;
    }
}

18. Feedback Loop & Model Retraining

The feedback loop is the mechanism by which analyst decisions and confirmed fraud outcomes are used to improve the ML models. Without a feedback loop, models become stale as fraud patterns evolve. The loop operates on three time scales: real-time (updating reputation scores and feature stores within seconds of a decision), hourly (batch updating model training data), and daily (full model retraining and validation).

Data Labeling Strategy

The quality of the feedback loop depends critically on data labeling. Not all analyst decisions are equally reliable — a quick "approve" with no investigation is less trustworthy than a detailed "confirmed fraud" with investigation notes. The system assigns a confidence weight to each label based on: the analyst's track record (accuracy of past decisions), investigation depth (time spent, tools used), decision speed (too-fast decisions may indicate rubber-stamping), and consensus (decisions confirmed by multiple analysts or downstream evidence like chargebacks).

Model Retraining Pipeline

The daily retraining pipeline extracts labeled data from the past 90 days, with more recent data weighted more heavily. It handles class imbalance using a combination of SMOTE oversampling and focal loss. Each model is retrained independently, and the new versions are validated against strict quality gates: minimum recall at the operating threshold, maximum false positive rate, minimum precision, and no degradation in SHAP value consistency (ensuring the model's explanations remain coherent). Models that pass all gates are deployed to shadow mode for 24 hours of A/B testing before full promotion.

Champion-Challenger Framework

The system maintains a champion model (current production model) and up to 3 challenger models (new candidates). The challenger models run in shadow mode, scoring transactions in parallel with the champion but not making decisions. This allows the system to evaluate challenger performance against the same data without any business risk. After 24 hours, if a challenger outperforms the champion on all metrics, it is promoted. Otherwise, the champion remains and the challenger is archived.

19. Monitoring, Drift Detection & Observability

Monitoring a fraud detection system goes beyond standard infrastructure metrics. The system must track model performance, data quality, concept drift, and business outcomes in real time. A sudden drop in fraud detection rate or spike in false positives must trigger immediate investigation.

Key Metrics Dashboard

Model Drift Detection

The system monitors for two types of drift: data drift (changes in the distribution of input features) and concept drift (changes in the relationship between features and the target variable). Data drift is detected using the Population Stability Index (PSI) computed hourly on key features. A PSI value above 0.1 indicates moderate drift and triggers a warning; above 0.2 indicates significant drift and triggers an alert for model investigation. Concept drift is detected by monitoring model performance metrics (precision, recall, AUC) on a rolling 24-hour window. A sustained drop in any metric triggers an alert.

Observability Stack

The observability stack combines metrics (Prometheus + Grafana), logging (ELK stack), and tracing (Jaeger). Every transaction scoring request is traced end-to-end, with spans for each pipeline stage (feature retrieval, rule evaluation, ML inference, score aggregation). This allows rapid root cause analysis when latency spikes or errors occur. The logging system captures every decision (approve, decline, step-up) with full context, enabling post-hoc analysis of model behavior and edge cases.

C#
public class ModelDriftMonitor
{
    private readonly IMetricsStore _metricsStore;
    private readonly IDriftDetector _driftDetector;
    private readonly IAlertService _alertService;

    public async Task<DriftReport> CheckDriftAsync()
    {
        var report = new DriftReport();

        var featureDistributions = await _metricsStore
            .GetRecentFeatureDistributionsAsync(
                TimeSpan.FromHours(1));

        foreach (var (featureName, currentDist) in featureDistributions)
        {
            var baselineDist = await _metricsStore
                .GetBaselineDistributionAsync(featureName);
            var psi = _driftDetector.CalculatePSI(
                baselineDist, currentDist);

            report.FeatureDrift[featureName] = psi;

            if (psi > 0.2)
            {
                await _alertService.RaiseDriftAlertAsync(
                    featureName, psi, DriftSeverity.High);
            }
            else if (psi > 0.1)
            {
                await _alertService.RaiseDriftAlertAsync(
                    featureName, psi, DriftSeverity.Medium);
            }
        }

        var performanceMetrics = await _metricsStore
            .GetModelPerformanceAsync(TimeSpan.FromHours(24));

        foreach (var (modelName, metrics) in performanceMetrics)
        {
            if (metrics.Recall < 0.90)
            {
                await _alertService.RaisePerformanceAlertAsync(
                    modelName, "recall", metrics.Recall, 0.90);
            }

            if (metrics.FalsePositiveRate > 0.04)
            {
                await _alertService.RaisePerformanceAlertAsync(
                    modelName, "fpr", metrics.FalsePositiveRate, 0.04);
            }
        }

        return report;
    }
}

20. Security, PII Handling & Compliance

Fraud detection systems handle extremely sensitive data — credit card numbers, personal identification, transaction histories, device information, and behavioral patterns. Security and compliance are not optional features; they are fundamental architectural constraints that influence every design decision.

PII Handling

All Personally Identifiable Information (PII) is encrypted at rest and in transit. The system uses a tiered approach: card numbers are tokenized (replaced with non-reversible tokens) immediately upon ingestion, SSNs and government IDs are stored in a dedicated PII vault with field-level encryption, email addresses and phone numbers are hashed for lookup purposes but stored encrypted for full-text access, and behavioral data is anonymized by removing direct identifiers before storage.

Compliance Requirements

Access Control

The system implements role-based access control (RBAC) with four primary roles: Fraud Analyst (can view alerts and make decisions), Risk Manager (can modify rules and thresholds), Model Developer (can access training data and deploy models), and System Administrator (full access including infrastructure). All access is logged and audited. Analysts can only view data for their assigned business unit, and PII fields are masked for analysts who do not have explicit PII access authorization.

Data Retention

Transaction data is retained for 7 years for AML compliance. Alert and investigation data is retained for 5 years. Model training data is retained for 2 years. Feature store data for active entities is retained indefinitely; for churned entities, data is retained for 1 year after the last activity. Automated data lifecycle management pipelines handle deletion and archival according to these policies.

21. API Design

The fraud detection system exposes a gRPC API for high-performance transaction scoring and a REST API for management operations (rule deployment, alert management, model deployment, reporting). The gRPC API is the primary interface used by payment processors and is optimized for low latency.

Transaction Scoring API (gRPC)

Proto
syntax = "proto3";
package fraud.detection.v1;

service FraudDetectionService {
    rpc ScoreTransaction(ScoreTransactionRequest) 
        returns (ScoreTransactionResponse);
    rpc ScoreBatch(ScoreBatchRequest) 
        returns (ScoreBatchResponse);
    rpc GetExplanation(GetExplanationRequest) 
        returns (ExplanationResponse);
}

message ScoreTransactionRequest {
    string transaction_id = 1;
    string customer_id = 2;
    string card_token = 3;
    double amount = 4;
    string currency = 5;
    string merchant_id = 6;
    string merchant_category = 7;
    string ip_address = 8;
    string device_fingerprint = 9;
    GeoLocation geo_location = 10;
    map<string, string> metadata = 11;
}

message ScoreTransactionResponse {
    string transaction_id = 1;
    double risk_score = 2;
    FraudDecision decision = 3;
    repeated TriggeredRule triggered_rules = 4;
    repeated FeatureContribution top_features = 5;
    int64 latency_ms = 6;
    string explanation_narrative = 7;
}

enum FraudDecision {
    APPROVE = 0;
    SOFT_REVIEW = 1;
    STEP_UP_AUTH = 2;
    HARD_DECLINE = 3;
    AUTO_BLOCK = 4;
}

Management REST API

HTTP
// Rule Management
POST   /api/v1/rules              # Create new rule
GET    /api/v1/rules              # List all rules
PUT    /api/v1/rules/{id}         # Update rule
DELETE /api/v1/rules/{id}         # Delete rule
POST   /api/v1/rules/{id}/deploy  # Deploy rule to production
POST   /api/v1/rules/{id}/test    # Test rule against sample data

// Alert Management
GET    /api/v1/alerts             # List alerts (with filters)
GET    /api/v1/alerts/{id}        # Get alert details
POST   /api/v1/alerts/{id}/assign # Assign to analyst
POST   /api/v1/alerts/{id}/decide # Record analyst decision

// Model Management
GET    /api/v1/models             # List deployed models
POST   /api/v1/models/deploy      # Deploy new model version
POST   /api/v1/models/{id}/shadow # Start shadow deployment
GET    /api/v1/models/{id}/metrics # Get model performance metrics

// Reporting
GET    /api/v1/reports/daily      # Daily fraud summary
GET    /api/v1/reports/trends     # Trend analysis
GET    /api/v1/reports/analyst    # Analyst performance metrics

API Rate Limiting

The scoring API is rate-limited at 100,000 requests per second per client, with burst capacity up to 150,000 for 10-second windows. Rate limiting uses a token bucket algorithm with separate buckets for each client (identified by API key). The management API is rate-limited at 1,000 requests per minute per user. Rate limit headers (X-RateLimit-Remaining, X-RateLimit-Reset) are included in all responses.

22. Cost Estimation

Cost estimation for a fraud detection system must account for compute, storage, networking, and operational costs. Below is an estimate for a mid-scale system processing 50,000 transactions per second.

Annual cost is approximately $1.35 million. This represents roughly 0.001% of a payment processor handling $100 billion in annual transaction volume — a negligible cost compared to the potential fraud losses (which can reach 0.1% of transaction volume, or $100 million, without effective detection). The ROI of the fraud detection system is typically 50-100x the cost of the infrastructure.

23. Testing Strategy

Testing a fraud detection system is uniquely challenging because the "correct" answer is often ambiguous (was that transaction truly fraudulent?), the data distribution is highly imbalanced, and the system must handle adversarial inputs (fraudsters actively try to evade detection). The testing strategy must cover functional correctness, performance under load, model quality, and operational resilience.

Test Categories

Fraud Simulation Testing

The system maintains a library of simulated fraud scenarios — stolen card patterns, account takeover patterns, money laundering flows, synthetic identity behavior — that are replayed against the scoring pipeline daily. Each scenario includes expected detection results (which rules should trigger, which models should flag, expected score range). If any scenario fails to detect as expected, the test fails and deployment is blocked until the issue is resolved.

Performance Testing

Performance tests simulate realistic traffic patterns, including: steady-state load (50,000 TPS), burst load (100,000 TPS for 60 seconds, simulating flash sales), feature store degradation (simulate Redis latency increase to 20ms), model inference slowdown (simulate GPU contention), and partial failure (simulate one Redis node down). The test validates that latency stays within SLA under all conditions and that the system degrades gracefully under extreme load.

C#
[Fact]
public async Task ScoreTransaction_DetectsCardTesting()
{
    var customer = CreateTestCustomer(accountAgeDays: 30);
    var transactions = Enumerable.Range(0, 6)
        .Select(i => CreateTestTransaction(
            customerId: customer.Id,
            amount: 4.99,
            merchantId: $"merchant-{i}",
            timestamp: DateTime.UtcNow.AddMinutes(-30 + i * 5)))
        .ToList();

    foreach (var txn in transactions)
    {
        await _featureStore.UpdateVelocityCountersAsync(
            txn.CustomerId, txn.CardNumber, 
            txn.Amount, txn.Country);
    }

    var testTransaction = CreateTestTransaction(
        customerId: customer.Id,
        amount: 4.99,
        merchantId: "merchant-new",
        timestamp: DateTime.UtcNow);

    var result = await _pipeline.ScoreTransactionAsync(
        testTransaction, CancellationToken.None);

    Assert.True(result.RiskScore > 0.6,
        $"Expected high risk score for card testing, " +
        $"got {result.RiskScore}");
    Assert.Contains(result.TriggeredRules,
        r => r.RuleId == "card_testing_velocity");
}

[Fact]
public async Task ScoreTransaction_ApprovesLegitimateTransaction()
{
    var customer = CreateTestCustomer(accountAgeDays: 1825);
    var transaction = CreateTestTransaction(
        customerId: customer.Id,
        amount: 45.00,
        merchantId: "starbucks-001",
        deviceFingerprint: customer.KnownDeviceId,
        ipAddress: customer.HomeIPAddress,
        timestamp: DateTime.UtcNow);

    var result = await _pipeline.ScoreTransactionAsync(
        transaction, CancellationToken.None);

    Assert.True(result.RiskScore < 0.3,
        $"Expected low risk score for legitimate transaction, " +
        $"got {result.RiskScore}");
    Assert.Equal(FraudDecision.Approve, result.Decision);
}

24. Interview Q&A Deep Dive

System Design Questions

Q: How would you handle a sudden spike in transaction volume (e.g., Black Friday)?

A: The system uses auto-scaling groups for the scoring service, triggered by Kafka consumer lag and request latency metrics. The feature store uses Redis Cluster with read replicas that can be added horizontally. During predicted high-volume events (Black Friday, Cyber Monday), we pre-warm additional instances 2 hours before the expected spike. The system also supports graceful degradation: under extreme load, the scoring pipeline can skip Tier 3 (slow) rules and reduce the GNN inference to a single hop, reducing latency at the cost of slightly lower detection accuracy. The key principle is that some fraud detection is always better than no fraud detection — if latency exceeds the SLA, we degrade gracefully rather than reject transactions.

Q: How do you handle concept drift when fraud patterns change?

A: We monitor concept drift using two mechanisms: (1) real-time performance monitoring that tracks model precision, recall, and FPR on a rolling 24-hour window, and (2) Population Stability Index (PSI) computed hourly on key features. When drift is detected, the system triggers an automatic retraining cycle (normally daily) immediately. If the retrained model also shows degraded performance, the system escalates to the model development team for manual investigation. Additionally, the rule engine provides a safety net: even if ML models are affected by concept drift, manually-defined rules continue to catch known fraud patterns. The combination of automated retraining and rule-based fallback provides robustness against drift.

Q: How do you balance false positives with fraud detection rate?

A: The threshold is configurable and is tuned based on the business context. We use a cost-sensitive approach where we estimate the cost of a missed fraud event (typically 10-100x the transaction amount) versus the cost of a false positive (customer friction, potential churn, support costs). The optimal threshold minimizes total cost. In practice, we operate at different thresholds for different segments: high-value corporate transactions have lower thresholds (more aggressive detection) while low-value consumer transactions have higher thresholds (more permissive). The threshold is adjusted weekly based on the latest cost analysis and fraud rate trends.

Q: How do you ensure the system is not biased against certain demographics?

A: Fairness monitoring is integrated into the model validation pipeline. We measure detection rates and false positive rates across demographic groups (age, gender, location) and ensure the disparity between groups does not exceed defined thresholds. The model training process uses fairness-aware techniques: adversarial debiasing, equalized odds post-processing, and feature auditing to remove proxy variables for protected attributes. Additionally, we conduct quarterly bias audits using external auditors and maintain a model card documenting known fairness limitations.

Technical Deep-Dive Questions

Q: Why use a meta-learner instead of a single end-to-end model?

A: A meta-learner approach offers several advantages: (1) each sub-model can be independently trained, validated, and deployed — reducing blast radius of model updates, (2) different model architectures are optimal for different data modalities (tree models for tabular, neural networks for sequences, GNNs for graphs), (3) the meta-learner can be retrained quickly (minutes) when new labeled data arrives, while sub-models retrain on a daily schedule, and (4) it is easier to explain — we can identify which sub-model contributed most to a score, which is more interpretable than a single monolithic model. The downside is increased complexity, but for production fraud systems, the operational benefits outweigh the complexity cost.

Q: How do you handle new customers with no historical data (cold start)?

A: Cold start is handled through three mechanisms: (1) consortium data — if the new customer has a history with other institutions in the consortium, we can import relevant features, (2) proxy features — we use device reputation, IP reputation, email/phone reputation, and geolocation features that do not require customer history, and (3) a cold-start model variant trained specifically on new-customer data, which relies more heavily on non-customer features and applies a conservative default risk score. As the customer accumulates transaction history, the system transitions to the standard model. Cold-start customers typically receive slightly higher risk scores for the first 30 days, which is an acceptable trade-off.

Q: Walk me through what happens when a fraud analyst confirms a transaction as fraudulent.

A: When an analyst confirms fraud, the following cascade occurs within seconds: (1) the decision is recorded in the decision store with full audit trail, (2) the feedback loop updates the training data store with the new positive label, (3) the entity cluster's reputation is updated (all linked accounts, devices, IPs receive penalty scores), (4) if the fraud pattern matches known patterns, the rule engine is notified and may trigger related rules, (5) the consortium data sharing pipeline shares the fraud event (anonymized) with partners, (6) the entity may be auto-blacklisted if the fraud is severe enough, and (7) the confirmation is logged for the next daily model retraining cycle, where it becomes a positive training example. The entire cascade is designed to propagate the intelligence from a single analyst decision across all detection layers as quickly as possible.

Q: How would you design the system to handle cross-border transactions differently?

A: Cross-border transactions require additional scrutiny because they have higher fraud rates and more complex compliance requirements. The system applies cross-border-specific features: country risk score (based on FATF lists, sanctions, and historical fraud rates), currency mismatch detection, time zone analysis, and IP geolocation vs. card issuing country comparison. Rules are configured per country pair — transactions between low-risk countries (US to Canada) use standard thresholds, while transactions involving high-risk corridors (certain emerging markets) use stricter thresholds. The compliance layer also checks sanctions lists (OFAC, EU, UN) in real time and blocks transactions involving sanctioned entities. Country-specific features are pre-computed and cached in the feature store with daily refresh.

Architecture Questions

Q: Why not use a monolithic fraud detection model instead of an ensemble?

A: A monolithic model has three critical weaknesses: (1) it cannot process different data modalities optimally — tabular features, sequences, and graph data require different architectures, (2) it creates a single point of failure in the model update cycle — any training issue blocks all fraud detection, and (3) it is harder to explain — tracing a decision back through a single complex model is more difficult than tracing it through an ensemble of simpler models. The ensemble approach allows each model to be the best at its specialty while the meta-learner combines them optimally. The operational cost is higher (multiple models to maintain), but the accuracy and resilience benefits justify it.

Q: How do you handle the trade-off between feature freshness and latency?

A: Feature freshness is critical for velocity features (which must reflect the latest transactions) but less critical for behavioral features (which change slowly). The system uses a tiered freshness approach: real-time features (velocity, last transaction) are updated within 500ms via the stream processor, near-real-time features (reputation scores, entity cluster updates) are updated within 5 minutes, and batch features (30-day aggregates, model embeddings) are updated daily. The scoring service uses the freshest available version of each feature, with fallback to slightly stale data if the real-time update has not yet propagated. In practice, 500ms staleness for velocity features does not materially impact detection accuracy.

Q: How do you handle failures in the ML inference layer without blocking transactions?

A: ML inference failure is handled with a graceful fallback: if the ML ensemble fails to respond within 50ms, the scoring service falls back to rule-only evaluation. Rules alone catch approximately 60% of fraud, so this degraded mode is significantly better than blocking all transactions. The failed inference is logged and retried asynchronously, and the result is used to update the entity's risk score post-hoc. Additionally, the ML serving layer uses circuit breakers — if error rates exceed 5% on a single model, that model is temporarily removed from the ensemble and the remaining models compensate. The system is designed to be "always scoring, sometimes with ML" rather than "ML-dependent, always potentially blocked."