AI/ML engineering · Banking
Real-time payment fraud detection
We build real-time payment fraud detection for banks and fintechs: risk scoring inside the payment flow, behavioural and device signals, detection of mule accounts and networks, and case management with a feedback loop so the models learn from confirmed fraud. The decision happens before money moves, and the rules, models and code are yours.
Checklist · Financial crime
AML, KYC and fraud system requirements checklist
A requirements checklist for transaction monitoring, fraud detection and document-based KYC systems: data, scenarios and models, alert and case handling, reporting, governance and security.- 01Eight requirement areas written as testable statements.
- 02What to ask for on data quality, lineage and model governance.
- 03Where real-time and batch monitoring each fit.
- 04Seven questions to put to any vendor or development partner.
Free download
Get it on screen in a few seconds.
What the system does, module by module.
- 01
Event capture
Payments, logins, device and session events, beneficiary changes and card events streamed into one real-time store. - 02
Feature computation
Velocity, amount, time, beneficiary age, device history and session behaviour computed on the fly from recent events. - 03
Rules and models
Rules for known patterns and machine learning models for the unknown, combined into one score with a documented decision strategy. - 04
Decision in the payment flow
Allow, step up, hold or decline decided before release, within the time budget of the payment scheme. - 05
Step-up and customer confirmation
Challenges and confirmation requests to the customer through the app or a call, with the result feeding the decision. - 06
Mule and network detection
Graph analysis of accounts, devices and beneficiaries to find mule accounts and organised networks that single-payment rules miss. - 07
Authorised push payment scam signals
Indicators of a customer being coached, such as new payees, urgency and unusual behaviour, with warnings tailored to the scam type. - 08
Case management and feedback
Analyst queues, outcomes labelled as fraud or genuine, and automatic feeding of labels back to training data. - 09
Monitoring and tuning
Detection rate, false-positive rate, customer friction and loss by rule and model, with controlled experiments for changes.
Reference architecture.
Standards and interfaces
What we design against.
- Payment scheme fraud requirements
- Latency budgets, response codes and risk-checking duties set by each instant and card payment scheme.
- Strong customer authentication
- Step-up rules and transaction risk analysis exemptions, with the evidence regulators expect.
- EMV 3-D Secure 2
- Risk data and challenge flows for card-not-present payments.
- Verification of payee
- Name-matching checks required or offered by payment schemes and regulation.
- Model risk management
- Validation, monitoring and change control for fraud models, as for any decision model.
- Data protection law
- Lawful use of behavioural and device data and limits on retention and automated decisions.
Data model
The core entities.
- Event
- Type, time, customer, device, channel and the attributes used for scoring.
- Customer baseline
- Typical behaviour, usual payees, devices and limits.
- Score and decision
- Score, rules fired, model versions, action and latency.
- Beneficiary and account
- Age, first seen, reports and links to other accounts and devices.
- Network edge
- Relationship between accounts, devices and payees with strength and time.
- Case and label
- Alert, analyst, outcome (fraud, genuine, unknown) and date confirmed.
- Strategy version
- Rule and model set, thresholds, owner, approval and live dates.
When custom development is the right call.
Controls designed in, not added later.
Strict latency and fail-safe
A defined fallback if the engine is slow or down: fail open with limits or fail closed, by payment type and amount.Protected data
Behavioural and device data encrypted and limited to the fraud team, with retention rules.Strategy change control
Rule and threshold changes are tested, approved and dated, with the ability to roll back.Adversarial resilience
Monitoring for attackers adapting to the rules, and models trained to be robust to evasion.Audit trail
Every decision stored with the features and versions behind it.
From discovery to a system you run.
- 01
Fraud landscape and data review
We review current fraud losses, typologies and the data available in real time, with the fraud, payments and channels teams. - 02
Architecture and latency design
The event flow, feature store and decision service are designed against the payment flow's latency budget. - 03
Rules and model development
Rules and models are built and tested on historical data, with step-up and customer communication designed alongside. - 04
Shadow mode
The system scores live payments without acting, so decisions can be compared with outcomes. - 05
Go-live and tuning
Decisions are switched on by payment type, with weekly tuning of thresholds using confirmed outcomes.
Relevant work
Where to see our work.
Common questions.
- How fast does the decision have to be?
- It has to fit inside the payment scheme's time budget alongside everything else in the flow. We design the feature store and decision service for that budget and set a defined fallback if a component is slow.
- Can the system detect authorised push payment scams?
- It cannot know a customer is being coached, but it can score the signals that go with it, such as a new payee, urgency, unusual amount and session behaviour, and then show a warning or hold the payment for confirmation.
- How do you find mule accounts?
- By graph analysis of how accounts, devices and beneficiaries connect, together with behaviour such as rapid in-and-out movement of funds, combined with rules and reports from other institutions where available.
- How does the model learn?
- Analyst and customer outcomes are labelled as fraud or genuine and fed back into training data on a schedule, with validation before a new model is promoted.
- Who owns the code and the models?
- You do. The code, the models, the strategies and the data stay yours.