At Praxium Labs — Nepal's AI and automation consultancy — we see this pattern across most Nepali engagements. Banking fraud detection is the most-deployed ML workload in Nepali financial services and the easiest to justify with numbers — fraud loss reductions are measurable, the regulatory framework is supportive, and the data exists.
The transaction-scoring pipeline
- Transaction event: arrives from core banking system / card switch in real time
- Feature lookup: ~80–200 features from the feature store (customer history, device, location, recipient history)
- Model scoring: XGBoost / LightGBM model serves a 0–1 fraud-probability score in <50ms
- Decision logic: score above threshold → block transaction + SMS verification; medium score → allow + flag for review; low score → allow
- Case generation: blocked or flagged transactions create cases for the fraud-investigation team
- Feedback loop: investigator outcomes feed back into the training set
Features that work
- Velocity: transactions in last hour / day / week vs baseline
- Amount: z-score vs customer's historical distribution
- Time-of-day: deviation from customer's typical pattern
- Geography: IP / device location vs registered address
- Device fingerprint: new device, location of device, OS / browser
- Recipient history: has the customer sent to this beneficiary before
- Network features: degree of recipient account, age of recipient account, recent activity
Graph-based collusion detection
Some fraud patterns are invisible at the single-transaction level but obvious in the graph — money laundering, mule-account networks, organised card-skimming rings. A graph neural network or even simpler graph metrics (betweenness centrality, community detection) running on micro-batches (every 15 minutes) catches these. Significantly more complex to deploy than the per-transaction model; worth it at Tier-1 bank scale.
Latency budget
For card-not-present and online-banking transactions, total decision time should be <500ms end-to-end. Feature lookup: ~100ms. Model inference: ~50ms. Decision orchestration + audit logging: ~100ms. Network: variable. Keep this budget — fraud detection that blocks at 2 seconds frustrates customers more than fraud occasionally slips through.
Human-in-the-loop
High-confidence-fraud transactions are blocked automatically and the customer is contacted (SMS or call). Medium-confidence are allowed but flagged for next-day investigator review. Investigators have a dashboard showing flagged transactions, customer history, model rationale (SHAP explanation), and one-click actions (mark legitimate, confirm fraud, contact customer). This human feedback is what keeps the model accurate as fraud patterns evolve.
Drift and retraining
Fraud patterns shift fast — new attack types emerge monthly. Schedule: weekly partial retraining on the last 90 days of labelled outcomes, monthly full retraining on the last 18 months. Monitor: precision-at-K (top 1% of scored transactions; what fraction are actually fraud), recall on labelled fraud, and customer-friction metrics (false-positive rate on legitimate customers).
NRB compliance
Document: (1) the model and its training data, (2) the decision threshold and how it is set, (3) the customer redress process when a legitimate transaction is blocked, (4) fairness audits, (5) quarterly review by the bank's board IT committee. NRB inspections increasingly ask for this documentation in 2026. For related context, see our AI and Automation in Nepali Banking: State of Play post.
Investigator workflow tooling
A high-recall model produces hundreds of alerts a day. Without a strong case-management workflow, investigators drown. The discipline we apply for Nepali bank deployments:
- Single inbox per investigator with prioritised queue (highest risk score and oldest first)
- Case summary card: customer profile, last 30 days of activity, related parties, prior investigations — assembled automatically so the investigator does not lose minutes per case to context-switching
- One-click actions: block card / freeze account / contact customer / escalate to AML team
- Customer comms templates in Nepali and English so investigators do not draft from scratch
- SLA tracking at investigator and team level; alert when cases age past 4 hours
- Daily summary report auto-emailed to risk leadership: cases opened, closed, fraud confirmed, customer redress completed
Costing it for a Tier-2 Nepali bank
- Initial build (4–8 months): NPR 50–120 lakh including data engineering, model build, integration into card switch + mobile banking
- Annual run-rate (team + infra): NPR 60–180 lakh — typically 2–4 ML engineers + 1 data engineer + part-time DevOps
- Infra: NPR 8–25 lakh / year for the feature store, model serving, audit log retention
- Vendor alternatives: several international vendors (Feedzai, NICE Actimize) sell into Nepali banks; cost typically 2–5x in-house, faster to deploy. Hybrid setups (vendor for AML, in-house for fraud) are common
- Payback: typical Tier-2 bank deployment recovers cost within 9–18 months purely on direct fraud-loss reduction
Frequently asked questions
Can a smaller bank or finance company build this?
Yes for the per-transaction model — the math and tooling are the same. Where smaller institutions struggle is data volume (a bank with 50k customers has less signal than one with 5M) and team retention (data scientists move to larger firms). Solution: shared services or outsourced fraud-detection-as-a-service.
What about deep learning?
Useful for graph-based collusion detection. For per-transaction scoring, tree models remain SOTA on tabular fraud data. Most Nepali banks deploy XGBoost / LightGBM and add graph layers selectively.
False positives — what's acceptable?
Industry benchmarks: at the auto-block threshold, 5-15 legitimate transactions blocked for every 1 fraud caught is typical. Bank-specific calibration: a Tier-1 bank with strong support team can tolerate higher false-positive rates than a smaller one whose support team is overwhelmed.
Does the model need to know the customer's name / KYC details?
No — and it should not. Use customer ID, transaction features, device features. Names and demographics are sources of bias and add no predictive value. Keep the model PII-light by design.
How does this play with NRB AML reporting?
Different but related models. AML detection emphasises long-horizon patterns (cash structuring, gradual layering); fraud detection focuses on real-time transaction anomalies. Many banks run both pipelines, sharing features but not models.
Who can build this in Nepal?
Praxium Labs — Nepal's AI and automation consultancy, based in Lalitpur — designs and builds the systems described in this guide for Nepali businesses and for international teams hiring from Nepal. Start a project or see all services.