Skip to content
← All work
SOLUTION BLUEPRINTFintech · Remittance · South Asia / Nepal

Real-time fraud and AML screening for cross-border remittances

A blueprint for scoring every remittance for fraud and money-laundering risk in real time, so clean payments settle in a blink and only the risky ones reach a human. Fewer false alarms, faster payouts, a cleaner audit trail.

Illustrative impact based on published industry benchmarks — not results from a specific client.

~60%

Typical cut in false positives with ML (industry benchmark)

<300ms

Decision incl. sanctions/PEP check, leading platforms

2x

Fraud caught vs static rules, AI-assisted detection

~27%

Share of Nepal's GDP from remittances (World Bank)

The challenge

Remittances are the backbone of Nepal's economy, worth roughly a quarter of GDP, so the payment rails that carry them are a magnet for fraud and money laundering. The tools most operators use flag almost everything: rule-based transaction monitoring produces false-positive rates of 95 to 99% in typical deployments, which means analysts spend their days clearing alerts that turn out to be nothing while genuinely suspicious payments hide in the noise. That is slow, it is expensive, and it holds up honest customers' money. Nepal was placed on the FATF grey list in February 2025, and Nepal Rastra Bank's 2025 STR/SAR guidelines now expect fintechs, wallets and payment providers to run AI-assisted surveillance. The pressure to screen better, not just more, is real.

Our approach

Here is how we would build it. Every remittance streams in with its sender, recipient, amount and corridor. Instead of holding each payment in a manual queue, the system computes risk signals in real time: transaction velocity, device fingerprint, behavioural patterns and corridor risk. A machine-learning model trained on confirmed fraud and clean transaction history scores the payment, while a rules layer enforces hard policy checks and sanctions and PEP screening runs at the same moment, not as a separate slow step. The decision then branches. Low-risk payments clear and settle without a human touching them. Only high-risk ones are routed to an analyst, who confirms the case, files a suspicious-activity report to the FIU where needed, and feeds the outcome back so the model keeps learning. The compliance officer stays in charge of the judgement calls; the machine removes the drudgery around them.

Expected impact

Measured against published industry benchmarks, an approach like this is what good looks like. Machine-learning models trained on real outcomes typically cut AML false positives by around 60%, taking rule-based rates of 95 to 99% down toward 40 to 50%, so analysts spend their time on real risk. Leading real-time platforms return a screening decision, including sanctions and PEP checks, in under 300 milliseconds, fast enough to clear a payment before it settles. And AI-assisted detection has been shown to roughly double the fraud caught compared with static rules. For a Nepali remittance operator, that combination means honest payments move faster, fraud and laundering are caught earlier, and every decision leaves an audit trail that stands up to NRB and FATF scrutiny. These are cited industry figures showing what is achievable, not results from a specific NeuralYug deployment.

Most remittance fraud tools flag almost everything, then make a person clear the pile. This blueprint flips that: score every payment in real time, settle the clean ones instantly, and send only the risky ones to a human. Follow one payment through it below.

Following one remittance through screening

From transfer initiated to cleared — or held for review.

Data flow
Tap a step for detail
View:

Toggle to see the manual review queue collapse: with AI, every payment is scored and screened in real time, and only high-risk ones reach an analyst. Blueprint of a standard fraud + AML flow; figures in the case study are cited industry benchmarks.

  1. Remittance transaction (source): A cross-border transfer: sender, recipient, amount and corridor arrive in real time.
  2. Sanctions / PEP lists (store): Watchlists (sanctions and politically-exposed persons) the payment must be screened against before it clears.
  3. Manual review queue (human): Today an analyst opens each flagged payment and checks it by hand — the queue is where days are lost.
  4. Risk signals (AI): Velocity, device fingerprint, behaviour and corridor risk are computed for every payment in milliseconds.
  5. Sanctions / PEP screening (AI): Names are matched against watchlists at the same time, not in a separate slow step.
  6. ML scoring + rules (AI): A model trained on confirmed fraud and clean history scores the payment; rules add hard policy checks.
  7. Analyst review + SAR/STR (human): Only high-risk payments reach a person, who confirms and files a suspicious-activity report; the model learns from the outcome.
  8. Cleared / settled (sink): Low-risk payments pass straight through and settle without a human touching them.
Follow one remittance from initiated to settled. Toggle to 'With AI' and watch the manual review queue collapse. Hover a node to see what it does.

Screening simulator

Tune your volume and today’s false-alarm rate. See what real-time ML screening could reclaim.

20,000
97%

Rule-based transaction monitoring typically runs at 95–99%.

6 min

False alarms auto-cleared / day

0

Analyst-hours saved / week

0 hrs

New false-alarm rate

0%

down from 97%

Decision latency

<0 ms

incl. sanctions / PEP check

Fraud caught vs static rules · AI-assisted

~0x

Industry-typical projection, not a delivered NeuralYug result. Math uses cited benchmarks — ~60% fewer false positives, sub-300 ms decisions and ~2x fraud caught — on an assumed ~2% alert-trigger rate. Real numbers depend on data quality, corridors and model tuning. Nothing is stored; all figures compute in your browser.

Try it: set your daily volume and today’s false-alarm rate, then watch the analyst hours and auto-cleared alerts move. Figures are industry-typical projections from the cited benchmarks, not delivered NeuralYug results.

Why fewer alerts is the whole point

When 95 to 99 out of every 100 alerts are false, analysts drown and real fraud slips past. A model trained on confirmed outcomes learns the difference between an unusual-but-fine payment and a genuinely risky one, so the queue shrinks to the cases that actually need a human. That is where the speed, the cost saving and the better catch rate all come from at once.

How we'd build the screening system

None of this is exotic infrastructure. Every remittance streams in through an API gateway onto a Kafka and Flink pipeline, a feature store and a graph database feed a gradient-boosted scorer, a rules engine and an external sanctions and PEP service run alongside it, and a decision service settles the clean payments while routing the risky ones to an analyst console backed by PostgreSQL, which files STRs to the FIU. Tap any component to see what it does and the real tech behind it.

Real-time screening architecture

How we'd build it — components + data flow, ingest to STR filing

Architecture
Ingest & streamFeatures & scoringScreening & decisionCase store & reporting
Tap a component for detail

Blueprint topology built from standard components; tap any node for its role and the real tech. Illustrative, not a live deployment.

  1. Ingest API gateway (API, REST · gRPC): Every remittance enters here with sender, recipient, amount and corridor. Validates the payload, applies rate limits, and publishes each transaction as an event onto the stream — nothing sits in a manual queue.
  2. Event stream (Queue, Kafka · Flink): A durable log plus stream processing. Flink computes rolling signals — transaction velocity, corridor risk, device reuse — in the moment, so scoring sees fresh behaviour rather than a nightly batch.
  3. Feature store (Cache, Feast · Redis): Serves the same features online (for real-time scoring) and offline (for training), so the model behaves in production exactly as it did in testing. Low-latency reads keep the decision under the latency budget.
  4. ML risk scorer (Model / AI, XGBoost + graph features): A gradient-boosted model over behavioural features, enriched with graph features (shared devices, mule-network structure) from the transaction graph. Trained on confirmed fraud and clean history; outputs a calibrated risk score.
  5. Transaction graph (Data, Graph DB · Neo4j): Stores sender–recipient–device relationships. Graph features (community, shortest-path to known fraud) let the scorer catch laundering rings that per-transaction rules miss.
  6. Rules engine (Service, Policy DSL): Enforces hard policy the model must never override — amount thresholds, blocked corridors, regulatory limits. Runs alongside the score, not before or after it, so policy and ML both land on the decision service together.
  7. Sanctions / PEP screening (External, External · OFAC · UN lists): Fuzzy-matches sender and recipient against sanctions, PEP and watchlists in real time. Called through the decision service with retries and a circuit breaker; every hit is recorded for audit.
  8. Decision service (Service, Score + rules + screening): Combines the risk score, rule verdicts and screening result into one call, all inside a ~300 ms budget. Low-risk clears and settles automatically; high-risk is routed to an analyst with the evidence attached.
  9. Case store (Data, PostgreSQL): System of record for every decision, its reasons and the analyst's outcome. Row-level security isolates data; the immutable decision trail is what stands up to NRB and FATF scrutiny.
  10. Analyst console (Client, Next.js client): Where a compliance analyst reviews only the high-risk cases, sees why each was flagged, and confirms or clears it. Their outcome feeds back to retrain the scorer — the model keeps learning.
  11. FIU / STR reporting (External, External · goAML): When an analyst confirms suspicious activity, a suspicious-transaction report is filed to Nepal's Financial Information Unit. The case store holds the full lineage behind every filing.
The real-time screening architecture, ingest to STR filing. Tap any component for its role and the tech. A blueprint of standard components, not a live deployment.

Built with

Next.jsPythonReal-time stream processing (Kafka / Flink)Gradient-boosted + graph ML modelsRules engineSanctions / PEP screeningFeature storePostgreSQLCloud (AWS or GCP)

Frequently asked

Are these numbers NeuralYug's delivered results?
No. This is a solution blueprint. Every figure is a cited industry benchmark, framed as what is typically achievable, not a result NeuralYug delivered for a client. Real performance depends on data quality, corridors and how the model is tuned.
Does automating screening mean fewer compliance checks?
The opposite. Every payment is screened for fraud and against sanctions and PEP lists in real time, so nothing skips a check. Automation removes the manual clearing of false alarms; the hard judgement calls still go to a compliance officer, who files suspicious-activity reports where needed.
How does this fit Nepal Rastra Bank's rules?
NRB's 2025 STR/SAR guidelines expect fintechs, wallets and payment providers to run AI-assisted surveillance and to report suspicious activity. A blueprint like this is built around that: it screens in real time, keeps a full audit trail, and routes confirmed cases to a human for STR/SAR filing to the FIU.
#Fintech#FraudDetection#AML#NepalRemittance#NeuralYug
← Back to all work

Ready to build what's next?

Tell us about your project — we'll reply within one business day with a clear plan and a straight answer on fit.

Start a ProjectBook a Call
neuralyug@gmail.com · Kathmandu, Nepal