Why AI fraud checks can decline a payment you really made

Imagine buying a train ticket with your own card. The money is available, the details are correct, and the payment is declined. From your side, the transaction is straightforward. A fraud system has a harder job: deciding whether the activity resembles an authorised purchase without knowing everything you know.

Stripe’s Radar documentation describes models that draw on many signals and information across its payment network. Their output helps decide whether to allow, block, review or authenticate a transaction. That assessment is evidence about risk. It cannot establish, by itself, who is holding the phone or why an unusual purchase makes perfect sense to its owner.[1]

A checkout can have more than one decision-maker

First, a decline is not automatically a fraud verdict. Stripe distinguishes issuer declines, payments blocked by Stripe and invalid API requests. An issuer can consider matters including available funds, card details and spending patterns. A merchant-side block can stop a payment before an authorisation request reaches the card network. The same visible failure can therefore come from different points in the journey.[2]

The issuing bank can also have its own AI-assisted assessment. Visa Advanced Authorization supplies issuers with a real-time risk score; Visa Risk Manager lets them combine scores and transaction information with their own rules. A payment passing a merchant’s checks does not mean the bank has already agreed to it. There may be another decision, made with different information, still to come.[3]

For someone investigating a failed sale, identifying the point of refusal is the useful first question. Asking a merchant to change its fraud rule will not address a decision made later by the issuing bank. Conversely, a bank may never have received a payment that was stopped earlier.[2]

Why a small error rate can still affect many customers

The surprising part is the arithmetic of a rare event. Consider an invented batch of 100,000 payments. Exactly 100 are fraudulent and 99,900 are legitimate. Suppose a system blocks 90% of the fraud, while also blocking 1% of genuine payments. These are chosen assumptions, not measurements of Stripe, Visa or any bank.

The system blocks 1,089 payments, of which just 90 are fraudulent: about 8.3%. Most of the blocked transactions are genuine even though the system catches nine out of ten fraud attempts. There is no contradiction. The much larger population of legitimate purchases produces 999 mistakes from a seemingly small 1% error rate.

This example also shows why overall accuracy can mislead. The system makes the correct decision on 98.991% of payments. Approving every payment would score 99.9% accuracy in this invented batch, while catching no fraud at all. A higher headline accuracy number would conceal the disappearance of the protection the system was built to provide.

The useful measurements separate these questions. Recall asks what share of fraud was caught; precision asks what share of the flagged payments was actually fraudulent. The false-positive rate measures the share of genuine payments incorrectly flagged. Together, those definitions explain how a system can catch substantial fraud yet still inconvenience many more genuine customers.[4]

Nor does simply moving the decision threshold create new information. A different cutoff changes which payments receive which treatment. Improving the evidence or the model’s ability to rank risk offers a different route: distinguishing purchases that previously looked too similar.[1]

The system can ask for more evidence

EMV 3-D Secure provides a way to continue the decision. The merchant and issuer exchange information about the transaction, payment method and device. Some purchases complete authentication without an extra visible step. Others prompt the customer for additional proof, such as a one-time code or biometric authentication. This creates an option between accepting the initial risk assessment and abandoning the purchase.[5]

That extra step has its own purpose. In Stripe’s documented flow, successful authentication is followed by an attempt to charge the card; payment can still fail afterwards. Confirming the customer’s involvement and obtaining authorisation to move the money are connected, but separate, operations.[6]

For the train-ticket buyer, the useful outcome would be a short opportunity to supply the missing evidence and finish the purchase. For the system designer, the question becomes which uncertain cases deserve that opportunity. Treating every doubtful payment identically throws away the possibility that another observation could change the decision.[5]

Learning from mistakes is harder than it looks

Fraud systems cannot instantly consult a complete answer sheet. A study by Andrea Dal Pozzolo and colleagues explains the difficulty through a system mainly monitoring already-authorised transactions. Investigators provide relatively prompt feedback on a selected set of alerts. Many other transactions acquire a label only later, when a customer reports fraud or enough time passes without a dispute. Learning therefore involves delayed and unevenly selected evidence.[7]

Blocked payments create another problem. Stripe’s fraud primer notes that their eventual outcome is unknown: stopping a transaction prevents observation of what would have happened if it had gone through. A lower recorded fraud rate alone cannot reveal how many genuine purchases were lost. The absence of a later dispute is especially uninformative for a payment that never happened.[4]

The train-ticket example brings the measurement problem back to ordinary life. A successful fraud check needs to protect the account and let its owner use it. Understanding both outcomes requires looking beyond how many suspicious payments the system stops: which genuine purchases it disrupts, whether further evidence resolves uncertainty, and where the final decision actually occurs.

Report an error or suggest a correction