Tag: Financial Technology

Every large bank now runs anti-money-laundering (AML) and fraud-detection models that score millions of transactions daily. The marketing tells one story—detection rates climbing, false positives falling, model architectures getting smarter. But inside the engineering organizations that ship and operate these systems, a different story is told: the models work on the day they were built. What happens on day 200 is a harder question most banks answer poorly.

Few have answered that harder question as convincingly as Manu Subhashchandrabose, Director of Digital and AI Quality Engineering. His fraud- and AML-validation programs have set new benchmarks across the U.S. regional-banking sector, leading quality engineering behind a $200M+ multi-year core-banking transformation spanning six affiliate banks. The program went live with zero critical fraud-related defects and achieved 100% reconciliation accuracy on the data fraud models depend on.

The Blind Spot: Accuracy vs. Validation

Manu puts it bluntly: “Accuracy is not the real problem. Validation is.” A bank that confuses the two will fund a model team, ship a model, watch dashboards report 98% accuracy, and discover only after a regulatory examination that the 2% it missed was the 2% that mattered. The blind spot at the center of modern fraud detection is not in the model—it is in everything around it.

The Drift Banks Do Not Want to See

Fraud models are trained on yesterday’s behavior. Customers, criminals, upstream data feeds, rule libraries, and integration layers all shift continuously. The model does not. In the time it takes a quarterly compliance committee to meet, a behavioral fraud model can lose meaningful detection signal without producing any visible alert that something is wrong.

“Fraud models inherit the weaknesses of the systems around them,” Manu explains. “If data pipelines, ETL jobs, or integration layers are flawed, even the most accurate model becomes blind.”

His team built a data-lineage validation framework that traced every fraud-critical field from origin to model input, with reconciliation at each hop and threshold tests on the values. The result: 100% reconciliation accuracy on fraud-critical data, and model behavior stopped diverging across affiliate banks.

Why False Positives Are a Validation Problem, Not a Tuning Problem

Most banks treat AML false-positive rates as a tuning problem. Manu argues this approach is backwards. “Rules are outdated, undocumented, and inconsistent across systems. You can tune a threshold all day and never fix the fact that the underlying scenario library is missing cross-channel patterns, structured transactions, and country-specific triggers.”

His teams designed scenario-based testing for structured transactions, currency-transaction-report triggers, sanctions screening, and behavioral anomalies. One AML modernization program produced a 40% increase in scenario coverage and a 15–20% reduction in false positives—because the scenario library got correct, not because someone moved a threshold.

The Cloud Migration That Almost Broke a Fraud Stack

The riskiest moment in a fraud model’s life is when its inputs move. Cloud migration of core banking systems means shifting customer profiles, transaction histories, AML flags, and behavioral features into cloud-native pipelines. A single mis-mapped field can corrupt a feature and degrade a model in ways that look like normal variation in alert volume.

Manu led data-migration validation for one such cloud transformation. His teams built SQL-driven reconciliation across source and target, automated validation scripts on every batch, and data-quality dashboards that surfaced anomalies before the model team did. The program achieved 100% reconciliation accuracy on fraud-critical data and prevented post-migration degradation an accuracy-only regime would have missed.

Continuous Validation as a Discipline, Not a Project

The technical scaffolding is only half the story. The other half is governance. On the multi-year core banking transformation, Manu’s QA organization grew to 55 engineers across 10 teams. Quality gates were embedded in the build pipeline, and CI/CD integration accelerated AML rule deployment by 30–40% because rule changes were validated against a living scenario library on the way in rather than against a quarterly batch run.

“Models degrade over time,” Manu says. “Validation must evolve with customer behavior, transaction patterns, and emerging fraud vectors. Treat the model as a living system, not a static algorithm.”

What Regulators Are Now Asking For

The supervisory environment has moved in his direction. Examiners increasingly probe for model-validation evidence rather than accuracy summaries. The Anti-Money Laundering Act amendments and OCC guidance have raised the bar on explainability, traceability, and ongoing validation.

“Regulators are raising the bar,” Manu warns. “They are asking for explainability, traceability, and validation, not just accuracy metrics. The teams that can produce that evidence on demand are the ones that built it into the system.”

His programs reported a 35–50% reduction in fraud-related production defects and 85–90% automation coverage across AML, CTR, sanctions screening, and high-risk transaction monitoring. The number that matters most to him is the absence of a category: no fraud-related production defect required executive escalation at go-live. That is a validation outcome, not a tuning outcome.

The Misconception That Costs Banks the Most

The mistake Manu wants banking-technology leaders to stop making is treating a high accuracy score as a license to relax. “A model with 98% accuracy can still miss the 2% of transactions that cause millions in fraud losses. Accuracy is a snapshot. Validation is a discipline.”

Hire validation engineers alongside data scientists. Treat the ETL jobs that feed a model as part of the model’s surface area. Write scenario tests against regulatory expectations, not only against labeled datasets. Move validation left, into requirements and design, rather than treating it as a release-readiness checkbox.

For an industry that has spent a decade pouring money into model sophistication, the shift is not glamorous. It is plumbing, governance, and discipline. The banks that build it—the way Manu has built it, program after program—are the ones whose fraud stacks still work the day after the data shifts, the rule library changes, or the next examiner walks in. The banks that do not will keep reporting impressive accuracy on models that have quietly stopped catching the fraud that matters.