DEV Community: Derek Francis

How Fintechs Are Using Machine Learning to Cut Payment Fraud Without Killing Conversion

Derek Francis — Tue, 23 Jun 2026 07:00:21 +0000

Machine learning has quietly become the default tool for payment fraud detection, and the reason is a trade-off every fraud team knows too well. Tighten the rules and you block more fraud, but you also block real customers who just wanted to buy something. Loosen the rules and conversion improves, right up until losses start eating the margin. Push too far in either direction and someone in a leadership meeting is going to ask hard questions.

For a long time, the lever for managing this was static rules. Block transactions over a certain amount from a certain region. Flag anything that looks unusual. Rules are easy to understand, which is their charm, and rigid, which is their curse. A rule cannot tell the difference between a genuine customer behaving slightly differently and an actual fraudster. It just sees a threshold and reacts. The result is a pile of false positives, which is a polite way of saying you annoyed your best customers.

And that is not a soft cost. Industry analyses have repeatedly found that the revenue lost to false declines runs at well over ten times the value of the fraud actually stopped, and roughly a third of wrongly declined shoppers never come back to that merchant. A blunt rule does not just leak money on the fraud side. It quietly bleeds it on the conversion side too.

This is where machine learning changed the conversation. Instead of asking whether a transaction crosses a fixed line, an ML model asks how this transaction compares to everything it has learned about normal and abnormal behavior. It weighs dozens of signals at once.
Spending patterns, device fingerprints, timing, location, the rhythm of how someone types or navigates. No human-written rule can juggle that many variables in real time. A model can.

The payoff is sharper decisions. A good fraud model can spot the subtle signs of account takeover while waving through a loyal customer who happens to be shopping from a new city on holiday. That is the dream. Fewer real frauds slipping past, fewer legitimate buyers getting rejected at checkout. Both numbers move in the right direction at the same time, which static rules could never quite manage.

But machine learning is not a magic switch, and pretending otherwise is how teams get burned. A few realities deserve respect.
Models drift. Fraud patterns shift constantly because the people committing fraud adapt. A model trained on last year's behavior slowly goes stale.

Without retraining and monitoring, your sharp detector quietly turns dull, and you might not notice until losses climb. The scale of this is well documented. A 2023 McKinsey survey found that around 40% of companies deploying AI models saw noticeable performance degradation within the first year, driven by exactly this kind of drift. Gartner has put the figure higher still, with a majority of enterprises reporting measurable model degradation inside twelve months and most failing to catch it early. In fraud, where adversaries adapt on purpose, that clock runs faster.

False positives still need a human story. Even a great model gets things wrong sometimes. What matters is the experience around the rejection. A smooth step-up verification, a quick way for a wronged customer to recover, a feedback loop that teaches the model from its mistakes. The model is one piece of a larger system, not the whole thing.

Explainability is not optional in finance. When a regulator or a customer asks why a transaction was blocked, "the model said so" is not an answer anyone accepts. This is not a preference, it is supervisory expectation. The Federal Reserve’s SR 11-7 guidance on model risk management requires regulated institutions to validate and explain the models behind their decisions, and the EU’s Digital Operational Resilience Act adds its own weight to model governance and accountability for institutions operating in Europe.

“The model said so” does not satisfy either. Fintechs need models whose decisions can be interpreted and defended. This is one of the reasons purpose-built AI & ML services for financial institutions tend to outperform generic, off-the-shelf fraud tools. The domain context, the regulatory weight, and the cost of a wrong call are simply different in payments than they are anywhere else.

The fintechs winning at this are not the ones with the fanciest algorithms. They are the ones who treat fraud detection as a living system. They tune for the business outcome, not just the accuracy score. They measure the cost of a blocked good customer alongside the cost of a missed fraud, and they optimize the balance rather than chasing one number.

Because in the end, fraud prevention is not really about catching every bad actor. It is about protecting the business while keeping the door open for the people you actually want to serve. Machine learning, used with judgment, is the closest thing the industry has found to threading that needle. The technology is impressive. The discipline is the moat. The fintechs that built that discipline early are the ones now posting authorization rates their competitors are still trying to explain, and that gap only widens from here.

Derek Francis

Derek manages content marketing at Opus Technologies, a domain-native engineering partner for banks, payment providers, and fintechs, and writes on the various aspects of financial institutions navigating change in a real-time, digital-first world.

Why Payment Data Pipelines Break Under Real-Time Load (And How Banks Fix the Latency Problem)

Derek Francis — Tue, 23 Jun 2026 06:45:34 +0000

Payment data pipelines fail in ways that ruin a payments engineer’s week, and the failures rhyme. The dashboards froze. Fraud scores arrived after the transaction had already cleared. Settlement reports came in stale. Nobody slept. The frustrating part is that the same data architecture had run fine for years. So, what changed?

The honest answer is that batch thinking does not survive contact with real-time payments. A lot of banks built their data foundations in an era when nightly jobs were good enough. Load the warehouse overnight, run the reports in the morning, move on. That rhythm worked when money moved slowly. It does not work when a customer expects an instant confirmation and a fraud engine has milliseconds to make a call.

Here is where things crack. Real-time payment rails push a constant stream of events instead of a tidy nightly dump. Your pipeline now has to ingest, transform, and serve data while transactions are still happening. Add ISO 20022 into the mix and the pressure climbs. ISO 20022 messages are rich. They carry far more structured detail than the old formats, which is wonderful for analytics and miserable for a pipeline that was never designed to parse that much context at speed. This is not a fringe concern either. Swift reported that by the time its MT/ISO 20022 coexistence period closed in November 2025, around 80% of daily traffic was already running on the ISO 20022 format, with more than 3.1 million of these messages exchanged every day. The rich-data era is the default now, not the roadmap.

Then there is the fraud-scoring window. Fraud models need fresh features. Account behaviour over the last few minutes, velocity checks, device signals. If your pipeline takes thirty seconds to surface that data, the fraud decision is already too late. You are essentially detecting fraud after the loss.

That gap between when data is created and when it becomes usable is the silent killer in most payment systems. And the cost of getting it wrong runs in both directions. Javelin Strategy & Research estimated that wrongly declined transactions cost merchants roughly $118 billion in a single year, against about $9 billion in genuine card fraud over the same period. When your features arrive late, you do not just miss fraud, you also misjudge good customers, and the second mistake is the more expensive one. So how do teams actually fix it? A few moves matter more than the rest.

First, separate the hot path from the cold path. Not every piece of data needs to move in real time. Fraud scoring and authorization need low latency. Quarterly trend analysis does not. Mixing both in one pipeline means the slow stuff drags down the fast stuff. Splitting them lets each run at its own pace.

Second, treat data domains as first-class citizens. Payments, cards, risk, and customer data each have their own shape and their own owners. When you map these domains deliberately instead of dumping everything into one lake, you get clarity, and clarity is what keeps latency predictable. This domain-driven approach is exactly the kind of foundation that strong data engineering services are built to deliver, especially in a payments context where the cost of a stale record is measured in real money.

Third, build observability in from the start. You cannot fix what you cannot see. Most pipeline failures are not sudden. They creep. A queue backs up a little, then a little more, until one Monday morning everything is an hour behind. Good observability catches the creep early, before it becomes a 2 a.m. incident.

Fourth, push governance into the pipeline rather than bolting it on afterward. In financial services, a fast pipeline that cannot prove its data lineage is a liability. Embedding governance and quality checks at the point of ingestion means you stay both quick and auditable. This is no longer just good hygiene. Under the EU’s Digital Operational Resilience Act, in force since 17 January 2025, financial entities can be fined up to 2% of global annual turnover for failures tied to operational resilience and data lineage. A pipeline that cannot show where a record came from and how it was transformed is now a regulatory exposure, not merely a technical one.

None of this is glamorous. There is no single product you buy that makes the latency problem disappear. It is architecture, discipline, and a willingness to stop pretending that batch habits scale into a real-time world.

The banks that get this right share one trait. They stopped treating data as something you store and report on later. They started treating it as something that flows, continuously, and engineered for that reality. The latency problem is rarely a hardware problem. It is a design problem. And design problems, unlike server crashes, can actually be solved for good.

Derek Francis