AI in Banking: Fraud Detection and Risk Management in Practice

Your fraud model is grading its own homework

You only observe outcomes for transactions you allowed. Everything the model blocked produces no label at all, so each retraining cycle learns from a dataset shaped by the model's own past decisions.

The consequence is directional, not random. The model becomes progressively more confident about a world it helped create, and its blind spots persist because nothing in the data ever contradicts them. Credit has the same structure: declined applicants never demonstrate whether they would have repaid, so the scorecard is validated only on the population it already approved.

Most of what matters in bank fraud and risk modelling follows from this problem and the operational limits around it.

Your metrics will not show you this

Precision and recall computed on observed labels can look excellent while the denominator is quietly wrong. Accuracy is worse than useless, since a model that approves everything scores very well on a rare event and catches nothing.

Measures worth reporting instead:

Precision at your actual alert capacity, not at whichever threshold produces the best chart
Value-weighted recall, because a model tuned on case counts will cheerfully miss the expensive frauds
False positive rate per approved transaction, since declined legitimate payments produce complaints and attrition
Alert to case conversion, which tells you whether the model finds fraud or generates work
Label latency, because chargebacks arrive weeks later and recent performance is always partly unknown

Add drift monitoring on the input distribution. It moves before outcome metrics do, and when labels are both delayed and biased, a leading indicator beats a precise lagging one.

Buying unbiased labels

There is no clean fix, only choices somebody has to sign off on.

The direct approach is releasing a small randomised sample below the block threshold, accepting a budgeted loss in exchange for labels not conditioned on the model's own behaviour. It means knowingly allowing some fraud, so it needs explicit approval rather than quiet implementation by the data team.

Partial measures help too. Capture structured investigator outcomes with reason codes rather than chargebacks alone, so a closed alert records why. And retain features as they were at decision time; otherwise your training set describes a state that never existed.

Capacity sets the threshold, not the curve

The operating point is a staffing decision. If investigations can work a certain number of alerts per shift, that number sets your threshold, and every model improvement has to be expressed as more fraud caught within the same budget.

That reframes vendor evaluation. A demonstration at a flattering threshold tells you nothing. Ask for performance at your alert volume, on a period the model was not trained on.

Two things underneath the model that beat model choice

Entity resolution. If the same customer exists as three records across origination, cards, and digital banking, velocity features are wrong, network features are wrong, and investigation is slower. Fixing it usually produces more lift than any change of algorithm.

Network features. Shared devices, beneficiaries, addresses, and phone numbers linking apparently unrelated accounts carry substantial signal, particularly for mule networks. Teams reach for a more complex model when a graph was the better investment.

The latency budget decides the architecture

Real-time authorisation runs on a budget measured in milliseconds, which constrains which features can be computed in the path and how large a model can be.

Three consequences that get discovered late:

Features must be precomputed and served from a low-latency store, which introduces training and serving skew. A model underperforming in production relative to evaluation has usually hit this.
Fallback behaviour needs a documented decision. Defaulting to approve and defaulting to decline are both business decisions with owners and loss implications.
Anything that does not need to sit in the authorisation path belongs in a post-authorisation pipeline with a far larger budget.
Rules deserve more credit than they get

Machine learning versus rules is mostly a marketing frame. Rules are explainable to an investigator and a regulator without extra tooling, change within hours when a new pattern appears, and cost almost nothing to run. They are also brittle and accumulate into unmaintainable estates, which is a real problem rather than a reason to dismiss them.

The part a vendor rarely volunteers: if an organisation has no reliable data pipeline, no entity resolution and no case management workflow capturing outcomes, a well-designed rule engine plus that missing plumbing will outperform a model. Honest scoping means saying so before the statement of work is signed, not in phase two.

AML and credit are governed differently from fraud

Fraud detection protects the institution from loss and can be optimised against a loss curve. AML monitoring discharges a legal obligation, and supervisors expect demonstrable coverage of specified typologies. Using models to prioritise alerts from defined scenarios is broadly accepted and addresses the very high false positive rates typical of rule-based monitoring. Replacing scenario coverage with an unexplainable model is a far harder conversation, and the burden of proof sits with the institution.

Credit adds its own constraint. Adverse decisions affecting individuals commonly require specific reasons, which limits model choice unless reliable reason generation can be demonstrated. Removing protected characteristics from the feature set does not remove disparate impact, because correlated features act as proxies, so test outcomes across groups and repeat after every retraining.

Governance is the actual deliverable

For a regulated institution, the model is a small part of what has to exist: a model inventory tiered by materiality, development documentation covering assumptions and limitations, independent validation by people who did not build the model and can block deployment, monitoring thresholds with escalation paths, challenger models to catch degradation that absolute metrics miss, and change control that treats retraining as a change.

Two points about vendors. A third-party model does not transfer validation, monitoring or accountability, so contractual access to documentation and performance data has to be negotiated before signing. And the build-to-own principle applies here as it does to software: if someone else builds your models, you should hold the training pipelines, feature definitions, model artefacts and documentation. A model you cannot retrain, validate or explain without the original supplier is a dependency inside a regulated process.

Where a blockchain does not help

Our core business is blockchain engineering, so this is worth stating plainly. Fraud detection and risk modelling are data quality and governance problems. Nothing above improves by putting a model or its outputs on a distributed ledger, and any proposal that combines the two should be examined for whether it is solving a problem or adding a technology.

One narrow intersection is real. Fraud signals are more valuable when shared across institutions, and institutions resist sharing raw customer data with each other or with a single operator. Shared registries of confirmed mule accounts sit on that trust boundary. Even there, most working consortia run on conventional infrastructure with a trusted operator, and that is fine. A distributed design earns consideration only when participants genuinely will not accept a single operator, which is worth testing rather than assuming.

RWaltz is a blockchain and enterprise software development company building custom smart contracts, dApps, and tokenization platforms that integrate with existing business systems. We work to a build-to-own model: clients hold their keys, repositories, and intellectual property; engagements are scoped honestly, including the cases where a simpler approach is the better answer; and security review is treated as continuous rather than a single sign-off.

📖 Read the full blog: https://www.rwaltz.com/blogs/ai-in-banking-fraud-detection-and-risk-management-in-practice

Connect with RWaltz:

LinkedIn: https://www.linkedin.com/company/rwaltzsoftware
X (Twitter): https://twitter.com/rwaltzsoftware
Facebook: https://www.facebook.com/RWaltz-Software-PvtLtd-255590135349493
Telegram: https://t.me/RWaltzCrypto
GitHub: https://github.com/rwaltzsoftware
Clutch: https://clutch.co/profile/rwaltz-software
Website: https://www.rwaltz.com