AI for Payments Companies
Payments is the highest-volume, lowest-latency environment in financial services, which makes it the one place where infrastructure decisions constrain the model rather than the other way round.
Payments fraud has an obvious metric and a hidden one. Everyone measures fraud loss. Far fewer measure the good transactions declined to achieve it, which is usually the larger number and always the one merchants notice.
AI for payments covers real-time fraud and risk scoring, authorisation rate optimisation, merchant onboarding and portfolio risk, chargeback and dispute automation, transaction categorisation and enrichment, and settlement and reconciliation exception handling.
The two-sided cost of fraud decisioning
A fraud model has two error types with very different visibility. A fraud loss shows up in a report. A declined legitimate transaction shows up as a lost sale, an annoyed cardholder and a merchant considering another processor — and nobody reconciles it. Tuning on fraud loss alone reliably produces a system that is expensive in the direction nobody measures.
| Metric | Who feels it | Usually measured? |
|---|---|---|
| Fraud loss rate | You and the issuer | Always |
| False decline rate | The cardholder and the merchant | Rarely, and it is usually larger |
| Approval rate by segment | The merchant | Sometimes, and rarely by segment |
| Chargeback rate | You and the merchant | Always |
| Cost per decision | You, at scale | Rarely until infrastructure costs surprise someone |
| Latency at the tail | Everyone, at the worst moment | Almost never at the 99th percentile |
Quantify a false decline before tuning anything
Estimate what a declined legitimate transaction actually costs — the lost sale, the abandoned basket, the reduced future usage, the merchant's view of your approval rate — and put it in the objective function alongside fraud loss. It is an uncomfortable number to estimate and every threshold decision is being made against it implicitly anyway. Making it explicit is the single highest-return hour in a payments fraud programme.
Latency, which shapes everything upstream
Decide the budget before the model
A decision budget in the tens of milliseconds determines model class, feature availability, serving architecture and infrastructure cost. Teams that pick the model first and discover the budget later rebuild. See inference optimisation.
Features must be computable at decision time
Aggregations over a cardholder's recent behaviour are powerful and must be available within the budget, which means a feature store rather than a query. The classic production failure is a feature present in training and unavailable at inference — a leakage problem that looks like an engineering one. See feature store.
Design for the tail, not the mean
Mean latency is a comfortable number. The 99th percentile is what times out during peak traffic on the busiest shopping day of the year, and a timeout is a decline. Set the target at the tail.
Cost per decision compounds
At payments volume, a tenth of a cent per decision is a real line item. Model size, feature computation and serving architecture are commercial decisions rather than technical preferences. See inference cost optimisation.
Merchant risk, which is underwriting wearing a different name
- Onboarding risk is a credit decision. An acquirer takes settlement risk on a merchant, and predicting merchant failure or fraud at onboarding is genuine underwriting with thin data.
- Portfolio monitoring catches deterioration. Changing chargeback patterns, sudden volume growth, shifting basket mix and refund behaviour are early signals of a merchant heading toward trouble.
- Transaction laundering is a network problem. Prohibited activity processed through a legitimate merchant account is detectable through behavioural and network signal rather than declared category.
- Model both directions. Merchant risk models tuned only to reject cost you the good merchants that grow into your best accounts.
- Chargeback and dispute handling is document work. Assembling compelling evidence against scheme requirements is structured, high-volume and immediately measurable in win rate.
Fraud is deliberately outside the EU AI Act's high-risk credit category
Annex III excludes systems whose primary purpose is fraud prevention from the high-risk credit-scoring classification. That covers most of what a payments company builds. Merchant underwriting for credit exposure may be a different matter, and EU-regulated entities carry DORA obligations regardless — a hosted model provider in a real-time authorisation path is a third-party ICT dependency with concentration and exit-planning implications.
How an engagement runs
Latency budget and cost per decision are settled first, because they determine what can be built.
Constraints and metrics
Latency budget at the tail, cost per decision, and the two-sided objective including an estimated false decline cost.
Feature infrastructure
Real-time aggregations and network features available within budget, with train-serve consistency verified.
Build
Fraud or merchant risk models evaluated on both error types, with segment-level approval rates as a primary output.
Shadow at production volume
Scored live at full traffic, measuring latency at the tail and decisions against current outcomes.
Phased rollout and monitoring
By segment, with approval rate, fraud on matured cohorts, latency and cost monitored continuously.
What you receive
Higher approval rates at constant fraud loss, inside the latency and cost budget.
Two-sided objective
Fraud loss and false decline cost quantified together, with the trade-off made explicit.
Real-time feature infrastructure
Aggregations and network features computable inside the decision budget, consistent between training and serving.
Fraud and merchant risk models
Evaluated on approval rate by segment, not on fraud loss alone.
Latency and cost profile
Measured at the tail and per decision, not at the mean.
Dispute evidence automation
Assembled against scheme requirements, measured on win rate.
Monitoring
Approval rate, matured-cohort fraud, latency percentiles and adversarial drift.
Is this the right starting point?
Worth being direct. There are situations in payments where custom AI work is the wrong spend, and those are listed rather than buried.
Worth doing if
- Approval rates are a competitive issue and nobody has measured false declines.
- Fraud rules are being evaded faster than your team can write new ones.
- Merchant portfolio deterioration is noticed after the loss rather than before.
- Chargeback win rates are low and evidence assembly is manual.
- Latency or per-decision cost is constraining what you can deploy.
Do something else if
- You want fraud loss minimised with no view on declined good transactions.
- The real constraint is scheme rules or issuer behaviour, which a model does not change.
- There is no real-time feature infrastructure and no appetite to build one.
- Volume is too low for the false decline cost to be estimable.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
How do we improve approval rates without more fraud?
By making the trade-off explicit. Most payments fraud systems are tuned on fraud loss alone, which means every threshold decision is being made against an unstated assumption about what a false decline costs. Estimate that cost — lost sale, abandoned basket, reduced future usage, merchant perception — put it in the objective, and you generally find meaningful approval headroom at unchanged fraud loss.
What latency should we design for?
Whatever your authorisation path allows, measured at the 99th percentile rather than the mean. A tail timeout during peak traffic is a decline, and peak traffic is when it matters most. Set the budget before choosing a model class, because it determines feature availability, serving architecture and cost per decision — and discovering it afterwards means rebuilding.
Is payments fraud detection caught by the EU AI Act?
Generally not by the Annex III high-risk credit category, which explicitly excludes systems whose primary purpose is fraud prevention. Merchant underwriting involving credit exposure may sit differently. EU-regulated entities also carry DORA obligations regardless, and a hosted model provider sitting in a real-time authorisation path is a third-party ICT dependency with concentration risk and exit planning attached.
Can we detect transaction laundering?
Yes, and it is a network problem rather than a per-transaction one. Prohibited activity processed through a legitimate merchant account shows up in behavioural patterns — basket composition, timing, geography, cardholder overlap with known networks — rather than in the declared merchant category. It needs graph-shaped features and it is one of the clearer wins available to an acquirer.
How do we know our fraud model still works?
Measure on matured cohorts only, because fraud is discovered late and any recent-period figure flatters you. Monitor for adversarial drift specifically: unlike most model drift, fraud patterns change because someone is deliberately probing your defences, so the cadence of retraining and the sensitivity of drift detection both need to be higher than they would be elsewhere.
Related verticals
Organisations in payments usually share data, buyers or regulators with these. All fourteen are listed on the Financial Services & Insurance page.
AI for Fintech Companies
Fraud, onboarding, credit decisioning — plus the compliance evidence your banking partner will require.
Read more →AI for Retail Banking
Fraud, credit decisioning, servicing and AML — with reason codes and model risk evidence built alongside the model.
Read more →AI for Cryptocurrency and Digital Assets
Chain analytics, transaction monitoring and surveillance — built for the compliance regime that has now arrived.
Read more →Tell us what the problem looks like.
Thirty minutes, no charge, no deck. We will tell you whether this is an AI problem, a data problem, or a process problem — and we will say when the honest answer is to buy something rather than build it.