Transaction and payment fraud
Scoring in the flow, with the threshold set by what a missed fraud costs against what a stopped customer costs.
AI Capabilities & Services
Fraud Detection
Real-time anomaly detection to flag and stop fraudulent activity.
The problem
Rules catch the fraud you have already seen. They are easy to explain, easy to audit, and easy for anyone patient enough to work around — and every new rule adds review load without removing the old one. Meanwhile the genuine signal is rare: a fraud rate of a fraction of a percent means a model can be right 99.8% of the time and useless, and an investigation team can be busy all day on cases that were never fraud.
Who this is for
- Fraud and risk teamsA queue ranked by expected loss, not by rule count
- Operations and claims managersFewer legitimate customers stopped, and faster clearance for the rest
- Compliance and auditA decision that can be explained to a regulator and to the customer it affected
What people use it for
Claims and liability assessment
Combining documents, images and history to flag claims that merit a human look before payment.
Application and identity fraud
Catching synthetic and duplicated identities at onboarding, where the cost of a mistake is lowest.
Internal and procurement fraud
Duplicate invoices, split purchases, vendor–employee overlaps and approvals that bypassed a control.
What it needs to work
- Transaction, claim or application records with enough history to contain known fraud
- Confirmed outcomes — the cases you investigated and what they turned out to be
- Your existing rules, because they encode years of institutional knowledge worth keeping
- Supporting context where permitted: device, channel, counterparty, documents or images
How it works
-
Score in the flow
Each case is scored as it arrives, alongside your rules rather than instead of them — the rules keep catching what they are good at.
-
Rank by expected cost
The queue is ordered by probability multiplied by amount at risk, so the investigator's first hour is spent where the money is.
-
Explain the flag
Every case shows what drove the score. An investigator who cannot see why will either trust it blindly or stop using it.
-
Human decision
A person decides. The model narrows and orders the work; it does not close cases, and on decisions affecting a customer it must not.
-
Feed the outcome back
Confirmed and cleared cases both return to the model. Fraud adapts, so a model trained once decays from the day it ships.
How we deliver it
-
Loss and data review
Where the losses actually are, what you already catch, and whether your labelled history can support a model.
-
Offline build
Models built and evaluated against history on the metrics that matter at a low base rate — precision, recall and the cost of each error.
-
Shadow running
Scoring live traffic without acting on it, so you see the review load and the catch rate before anything changes for a customer.
-
Threshold and go-live
You choose the operating point in cost terms, and it goes live behind monitoring with a defined rollback.
Where it runs
- On-premises or private cloud, where transaction data cannot leave your estate
- Real-time scoring in the payment or application path
- Batch review for claims, procurement and periodic checks
Security and governance
- Every score is explainable at case level, for the regulator and the customer
- A person makes every decision that affects a customer
- Model versions, thresholds and overrides are logged and auditable
- Performance is monitored by segment, so a model failing one group is visible rather than averaged away
Timeline
Set by the quality of your labels. Where investigated cases are recorded with outcomes, an offline model can be built and evaluated quickly and the real time goes into shadow running — which we do not recommend shortening, because it is where you learn the review load. Where outcomes were never captured systematically, that is the first phase, and no model can precede it.
What you receive
- A scoring model with performance measured on your data at your base rate
- An investigator queue ranked by expected loss, with reasons shown
- A threshold analysis in cost terms, so the operating point is a business choice
- Monitoring for drift and for performance by segment
- Documentation an auditor or regulator can follow
Related work
Published projects where we did this.
What this does not do
This will not find a fraud type that has never appeared in your data — novel schemes are caught by anomaly detection and by people, not by a model trained on the past. It does not replace your rules or your investigators; it orders their work. And it cannot fix a base problem: if outcomes are not recorded, there is nothing to learn from, and no amount of modelling substitutes for that.
Questions we are asked
Our fraud rate is tiny. Does that break the model?
It breaks accuracy as a measure, not the model. At a 0.2% base rate a model that flags nothing is 99.8% accurate, which is why we report precision, recall and the confusion matrix instead, and choose the threshold on what each error costs you.
Can we keep our existing rules?
Yes, and you should. Rules encode knowledge a model cannot learn from data alone, and they are trivially explainable. The model handles what rules are bad at: combinations, gradual change, and ranking.
Will it explain a decision to a customer?
It will explain it to your investigator, in the factors that drove the score. What is said to the customer is your decision and your wording — but you will have the substance to say something true.
About the figures on this page
This page describes capability and method. It does not publish accuracy figures, throughput numbers or delivery dates, because those depend on your data, your systems and your scope — and a number published here would be wrong for most readers. You get them, in writing and against your own data, at scoping.
A first call is a technical conversation, not a pitch: what you have, what you need, and whether this is the right approach at all.
Built on the Unified Intelligence Layer
Every InsAI product runs on the same four-stage backbone.
- 1
Data Integration
ERP · IoT · BIM · CRM
- 2
AI Models & Predictive Engines
Forecasting, detection, optimization
- 3
Automation & AI Agents
Acting on predictions, end to end
- 4
Real-time Dashboards & Decision Systems
From the floor to the boardroom
Fraud Detection
Real-time anomaly detection to flag and stop fraudulent activity.