Real-Time Fraud Detection for a Top 20 Global Bank: From Failed Program to Production in 14 Weeks

22 Months and Two Failed Programs Later

When the bank's Chief AI Officer reached out to us in early 2025, the fraud detection AI program had already consumed 22 months of development time and two full SI engagements. The first attempt, a bespoke rule-engine hybrid, had been abandoned after 8 months when detection rates stalled at 71%. The second attempt, a major cloud AI platform implementation led by a global SI, had achieved 83% detection in controlled testing but failed to pass the bank's model risk management validation due to insufficient explainability documentation for SR 11-7 purposes.

The organization had a genuine urgency: card fraud losses in their Asia-Pacific markets alone were running at $2.8M per month. Their existing legacy system, a vendor-managed rules engine installed in 2014, was detecting only 69% of fraud events and generating a false positive rate of 1.4%. At their transaction volumes, 1.4% false positives meant 32,000 legitimate transactions declined daily, each one a customer experience failure.

The core problem was not technical. Both previous programs had the right data, the right platforms, and reasonably capable teams. The failure was architectural: neither program had been designed around the bank's specific model risk governance requirements from the start. Both had tried to retrofit explainability and audit trail capability after the fact, which is almost always fatal to a financial services AI deployment.

Four Constraints That Previous Programs Had Ignored

The first thing we did was conduct a structured failure analysis of both prior programs. This is standard practice for us when taking on a rescue engagement. You need to understand exactly why the previous attempts failed before committing to a new approach. In this case, four constraints had been systematically underweighted:

• SR 11-7 Model Risk Management compliance: Every model required documented pre-implementation conceptual soundness review, ongoing performance monitoring, and outcome analysis. The previous programs had produced model performance documentation but not the conceptual soundness documentation that the bank's Model Risk Management team required for sign-off.
• Sub-100ms inference latency: The bank's payment processing infrastructure required fraud scoring decisions within 85ms of transaction initiation. This ruled out several architectures that could have delivered higher accuracy but would have added latency.
• Multi-jurisdiction feature constraints: Eight markets meant eight different sets of permissible data attributes for scoring. What was legally available for fraud scoring in the UK differed from Singapore differed from Australia. Previous programs had built for a single feature set and then tried to strip features out market-by-market, causing severe accuracy degradation.
• Explainability requirements for disputes: When a transaction was declined, customer service representatives needed a human-readable explanation. Previous programs had produced model output but no interpretable reasoning layer for operational use.

Understanding these four constraints properly changed the entire architecture. We did not begin with the question "what model produces the best detection rate?" We began with the question "what model architecture can satisfy all four constraints simultaneously?"

Architecture-First, Compliance-In, Not Retrofit

Our approach was structured around a single principle: build SR 11-7 compliance into the model architecture and development process from week one, not as a final validation step. This sounds obvious. In practice, virtually every AI program in financial services treats regulatory compliance as a documentation exercise at the end of development. That is why programs fail.

Model Architecture: Gradient Boosted Ensemble with SHAP Explainability

We selected a gradient boosted decision tree ensemble (XGBoost base, LightGBM secondary) as the primary scoring layer. This decision was not about optimizing for detection rate in isolation. GBDTs produce inherently interpretable feature contributions that map cleanly to SHAP (SHapley Additive exPlanations) values, satisfying the explainability requirement at both the model validation level and the operational customer service level.

A secondary neural scoring layer was added for complex pattern sequences (card-not-present fraud chains across multiple merchants) where the GBDT ensemble showed weaker performance. The neural layer outputs were passed through a calibration module that converted raw probabilities to bank-interpretable risk bands, which the MRM team had pre-agreed as acceptable for the SR 11-7 conceptual soundness review.

Feature Engineering: Market-Stratified from Day One

Rather than building a single global feature set, we designed a market-stratified feature engineering pipeline from the outset. Each market had a defined permissible feature set reviewed by local legal counsel. A feature availability matrix was published in week two and became the governing document for all feature engineering work. When a feature was permissible in 6 of 8 markets, the model architecture accommodated its absence for the remaining 2 rather than treating it as a degradation.

Core features included: transaction velocity patterns (24h, 7d, 30d windows), merchant category sequence analysis, device fingerprint matching, geographic displacement scoring, and time-of-day behavioral anomaly detection. The real-time inference pipeline was built on Apache Kafka with a feature serving layer that pre-computed 180-day rolling behavioral baselines, ensuring that even complex feature lookups stayed within the 85ms latency budget.

Model Risk Documentation: Concurrent, Not Sequential

Every model development decision was documented concurrently with its implementation. The conceptual soundness documentation was written in real time by a practitioner who was simultaneously participating in the technical decisions. This is the single most important process change we made. It is also the most unusual: most programs treat documentation as a separate workstream handled by a different team at the end of development.

By week 10, the full SR 11-7 documentation package was complete, reviewed by the bank's MRM team, and approved in principle. This had never happened in either previous program, where MRM review was treated as a final gate that invariably identified documentation gaps requiring weeks of remediation.

Production Deployment: Blue-Green with Shadow Mode Validation

Rather than a direct cutover from the legacy system, we deployed the new models in shadow mode alongside the live legacy system for three weeks. Shadow mode means the new model scored every transaction but did not take action on those scores. This produced a 21-day comparison dataset showing exactly where the new model agreed with the legacy system, where it disagreed, and what the outcomes of those disagreements were.

The shadow mode data was the single most powerful artifact in the final MRM sign-off. Seeing 3.2 million real transactions where the new model would have detected $2.1M in additional fraud while generating 94% fewer false positives resolved every remaining internal skepticism about the program.