How Banks Use Data to Investigate Transaction Irregularities

Large banking datasets can reveal unusual payments, account relation­ships and opera­tional failures that manual reviews miss. They do not automat­i­cally identify fraud. A defen­sible anomaly inves­ti­gation combines analytics with data-quality controls, human review and evidence about the customer, trans­action and business process.

Define the irregularity before choosing a model

Specify whether the target is card fraud, account takeover, money laundering, insider activity, duplicate processing, sanctions exposure or a system error. Each problem has different labels, costs and acceptable false-positive rates. A vague objective produces alerts that are difficult to inves­tigate or defend.

Build a reliable data foundation

Document the source, owner, coverage period and limita­tions of trans­action, customer, device, channel and counter­party data. Standardise timestamps, currencies and identi­fiers. Resolve duplicate customers and missing values without hiding uncer­tainty. The European Banking Authority identifies data management, infra­structure, gover­nance and analytical method­ology as central pillars for big-data and advanced-analytics use in banking.

Create meaningful behavioural features

Useful signals can include trans­action velocity, amount deviation, new benefi­ciaries, geographic changes, device shifts, circular transfers and links to previ­ously reviewed accounts. Compare behaviour with the customer’s own history and an appro­priate peer group. Avoid treating nation­ality, location or another broad charac­ter­istic as a proxy for misconduct.

Combine rules and anomaly detection

Known typologies can be encoded as trans­parent rules, while unsuper­vised methods help surface unfamiliar patterns. A Bank for Inter­na­tional Settle­ments working paper proposes a layered machine-learning framework for payment-system anomalies that first separates typical from unusual payments and then analyses the unusual subset. The research is a method­ology, not proof that the same design fits every bank.

Connect accounts and counterparties

Graph analysis can reveal shared devices, addresses, benefi­ciaries, directors or wallets. Inves­ti­gators should validate whether a connection is meaningful: house­holds and legit­imate businesses often share infra­structure. Corporate links should be corrob­o­rated with registry and beneficial-ownership records.

Test alerts against source evidence

For each alert, retrieve payment instruc­tions, authen­ti­cation events, customer commu­ni­ca­tions, KYC files and account history. Determine whether the activity reflects fraud, a legit­imate change in behaviour or a processing problem. Our payment-fraud inves­ti­gation framework shows why autho­rization, deception and merchant disputes require different conclu­sions.

Measure performance honestly

Track precision, recall, false positives, missed cases, inves­ti­gation time and loss prevented. Validate models on later data and monitor drift as customer behaviour changes. Rare-event detection can look accurate while missing most harmful cases, so overall accuracy alone is misleading.

Malta Media’s report on AI-assisted payment intel­li­gence provides a current industry example. Product claims should be verified through technical documen­tation, independent testing and measured outcomes before they are repeated as fact.

Govern the system and preserve accountability

Record model versions, features, thresholds, overrides and reviewer decisions. Restrict access, protect personal data and test for bias. Automation should prioritise evidence for trained inves­ti­gators; it should not turn a statis­tical outlier into an allegation. Final reports must distin­guish the alert, the corrob­o­rating evidence and the conclusion reached.