Why Most SEA Banks Can't Use ML for Fraud — and Why That's Okay (For Now)

Every major fraud management vendor — from the global platforms to the nimble fintechs — now sells some version of hybrid ML-plus-rules scoring. Their pitch decks show elegant architectures where machine learning models and business rules work in concert, each compensating for the other's blind spots. The problem? That architecture assumes a level of data maturity, talent, and infrastructure that most Southeast Asian banks simply don't have.

This isn't a criticism of ML. It's a recognition that for the majority of banks in the region — digital banks still scaling, tier 2 and tier 3 institutions with lean fraud teams — the prerequisites for effective ML scoring haven't been met yet. And buying a hybrid system before those prerequisites exist doesn't give you hybrid performance. It gives you an expensive rules engine with a dormant ML module.

What Hybrid Scoring Looks Like When It Works

Hybrid fraud scoring layers multiple scoring signals — hard rules, business rules, and ML model output — then blends them through a weighted consensus with explainable attribution for every decision.

In a well-implemented system, the architecture works in distinct layers. Hard rules (sanctions lists, blocklists, regulatory flags) act as circuit breakers that override everything — these are non-negotiable. Business rules encode known fraud patterns: velocity checks, geographic anomalies, amount thresholds tuned to the bank's transaction profile. The ML model runs in parallel, scoring each transaction based on learned patterns from historical data, producing both a risk score and confidence measure.

The real sophistication is in the blending. A wire transfer might weight rules at 80% and ML at 20%, because wire fraud patterns are well-known and rule-codifiable. Card-not-present transactions might flip to 40% rules and 60% ML, because the attack surface is broader and pattern evolution is faster. When rules and ML disagree significantly — say a 30-point score delta — the transaction routes to manual review rather than forcing an automated decision.

This is what top-tier institutions like DBS Bank operate. DBS reported a 25% improvement in fraud prevention efficiency after integrating machine learning into their detection pipeline. But DBS employs hundreds of data professionals and processes millions of transactions daily across mature data infrastructure. The question for mid-market SEA banks isn't whether hybrid scoring is better — it demonstrably is. The question is whether they can get there from where they are today.

Five Barriers Between SEA Banks and ML-Based Fraud Scoring

The gap between vendor demos and operational reality comes down to five concrete barriers, each of which compounds the others.

1. Data Volume and Quality

ML models need labeled data — confirmed fraud cases and confirmed legitimate transactions — to learn meaningful patterns. A regional bank processing 1,000 transactions per day with a fraud rate of 0.1% generates roughly one confirmed fraud case daily. Even with a 90-day training window, that's fewer than 100 fraud samples — far below the threshold needed for statistical significance in model training. 87% of banks in the region cite data management as their biggest hurdle for AI adoption, according to industry surveys. Data sits in silos: the core banking system doesn't talk to the mobile app, which doesn't share signals with the card processing platform. Without a unified data layer, ML models can't access the cross-channel features that make fraud detection effective.

2. Regulatory Explainability Requirements

In November 2025, the Monetary Authority of Singapore (MAS) issued consultation guidelines on AI Risk Management, requiring financial institutions to ensure transparency and explainability proportionate to the risk materiality of each AI system. High-materiality systems — which includes fraud decisioning — need robust governance, independent validation, and explainability thresholds. Indonesia's OJK published its AI Governance Framework for Banking in April 2025, mandating that firms explain how AI is used from input to output with assured human-in-the-loop oversight. The Bank of Thailand issued AI Risk Management Guidelines in September 2025, calibrating human oversight requirements to the level of risk and impact. The regulatory direction across SEA is clear: if you can't explain why the model flagged a transaction, you can't use that model in production.

3. Talent Scarcity

A typical tier 2 or tier 3 bank in SEA runs its fraud operations with a team of two to five analysts. These are experienced investigators who know their customer base intimately — but they aren't data scientists. They can't tune hyperparameters, diagnose model drift, or interpret SHAP values. Hiring ML talent in Singapore, Jakarta, or Bangkok means competing with DBS, Grab, GoTo, and Sea Group for the same candidates, at salary levels that mid-market banks cannot match. The talent gap isn't closing; Southeast Asia faces a major skills shortage across technology roles, with data science among the hardest to fill.

4. Vendor Lock-In with Opaque Models

When a bank buys a cloud-hosted fraud solution with bundled ML, the model is typically a black box. The vendor trains it on pooled consortium data, deploys it to the bank's tenant, and provides a risk score without revealing the model architecture or training data composition. This creates two problems. First, the bank cannot meaningfully explain model decisions to regulators — "the vendor's model said 85" is not an acceptable explanation under MAS, OJK, or BOT frameworks. Second, switching vendors means losing all model history and starting cold. The bank doesn't own the model, doesn't own the training data pipeline, and often doesn't even own the feature engineering logic.

5. Infrastructure Cost

Running ML inference in real-time adds compute requirements that rules-only systems don't have. Model training pipelines need GPU resources. Model monitoring needs drift detection infrastructure. A/B testing frameworks need traffic splitting and statistical analysis tooling. For a bank whose fraud system runs on a modest on-premise server, the jump to ML-capable infrastructure is a significant capital expenditure — one that's hard to justify when the fraud team can't yet demonstrate what ML would improve, because they don't have the labeled data to prove it.

Rules-First Is Not Rules-Only

The pragmatic path isn't to wait for ML readiness or to buy an ML system you can't use. It's to deploy a strong rule engine that's architecturally designed to incorporate ML scoring when the prerequisites are met.

What does "ML-ready" architecture look like in practice? First, the rule engine runs ML models in shadow mode from day one. Every transaction gets scored by both rules and the ML model, but only the rule score drives the decision. The ML score is logged, compared against outcomes, and tracked for accuracy over rolling windows — 7-day, 30-day, 90-day. This builds the labeled dataset that ML needs, using the bank's own transaction patterns rather than generic consortium data.

Second, the system provides layer-by-layer explainability. When a transaction is flagged, the explanation shows exactly which rule triggered, what the ML model would have scored, and how the two signals compare. This satisfies regulatory explainability requirements even during the rules-only phase, and it builds institutional familiarity with ML outputs before they carry decisioning weight.

Third, the transition from rules-only to hybrid is evidence-based and human-approved. When the shadow ML model demonstrates consistent improvement — say, catching fraud cases that rules missed, or reducing false positives — the system generates a recommendation with supporting evidence: "Over the past 90 days, ML shadow scoring showed +0.03 AUC improvement and would have reduced false positives by 15. Recommend moving to 10% ML weight." A senior analyst reviews the evidence and approves or rejects. No automatic weight changes, no black-box promotions.

This approach directly addresses the regulatory explainability challenge. The bank can show auditors from MAS, OJK, or BOT exactly what the ML model contributes, because every score is decomposed into its rule and ML components with full attribution.

On-Premise Deployment as an ML Enabler

There's a less obvious advantage to starting with on-premise, rules-first fraud infrastructure: data sovereignty accelerates ML readiness.

When fraud data stays within the bank's own infrastructure, it accumulates in a form that's directly usable for model training. There's no data-sharing agreement to negotiate with a cloud vendor. No anonymisation pipeline that strips the features ML models need most. No cross-border data transfer questions when the regulator asks where customer transaction patterns are stored.

A bank running an on-premise rule engine with shadow ML logging is, in effect, building a proprietary training dataset tuned to its specific customer base, transaction patterns, and fraud typologies. After 12-18 months of accumulation, that dataset is far more valuable for ML training than any generic consortium model — because it reflects the bank's actual fraud landscape, not an averaged signal across hundreds of institutions in different markets.

Indonesia's OJK framework explicitly requires firms to maintain accountability for AI outcomes and ensure human oversight of automated decisions. Keeping the model training pipeline on-premise — where the fraud team can inspect training data, validate model behaviour, and maintain audit trails — makes compliance substantially easier than explaining a model trained on opaque cloud infrastructure managed by a third party in a different jurisdiction.

The Three-Year Window

SEA's real-time payment rails are scaling fast. Thailand's PromptPay processes over 40 million transactions daily. Indonesia's QRIS is expanding from retail payments to person-to-person transfers. Singapore's PayNow handles cross-border flows. Each of these systems generates transaction data at volumes that will, within two to three years, provide the statistical foundation for meaningful ML model training — even at mid-market banks.

The banks that deploy a rules-first fraud engine now, with shadow ML logging from day one, will be accumulating labeled fraud data throughout this growth curve. When their transaction volumes cross the threshold for statistically significant ML training — and they will — the transition to hybrid scoring will be a configuration change, not a platform migration. The evidence will already exist. The explainability infrastructure will already be in place. The fraud team will already be familiar with ML outputs from months of shadow-mode comparison.

The banks that wait for ML readiness before investing in fraud infrastructure will find themselves in a worse position: no rules, no data, and no institutional knowledge of their own fraud patterns. They'll be starting from zero at exactly the moment when real-time payment fraud is accelerating.

ML-based fraud scoring isn't a question of if for SEA banks. It's a question of sequence. And the sequence starts with rules.

Run-True Decision is building a fraud decision engine purpose-built for Southeast Asian banks. Talk to us to learn more.