Transaction Risk

Transaction risk is the risk of loss attached to individual financial transactions: that a payment turns out to be fraudulent, is disputed or reversed, is processed wrongly, or loses value before it settles. In payments it most often refers to the risk score a bank, processor or merchant gives each transaction in real time before deciding to approve, challenge or decline it.

The term has more than one meaning. In US bank supervision, "transaction risk" was the name the Office of the Comptroller of the Currency (OCC) gave in the 1990s to the risk of losses from problems with service or product delivery, an idea that later supervisory materials generally fold into operational risk. In corporate finance, "transaction exposure" describes how foreign exchange risk affects a single deal between agreement and payment. This entry focuses on the payments meaning and explains the others briefly.

Think of a shopkeeper who knows most customers by sight. When a regular buys bread with a familiar card, there is nothing to think about. When a stranger tries to buy ten expensive phones in a hurry, using a card from another country, the shopkeeper becomes cautious and might ask for identification or refuse the sale.

Payment systems do the same thing automatically, millions of times a day. Each purchase or transfer is checked against what is normal for that customer, that device and that merchant. Most look ordinary and go straight through. A few look odd and get an extra check, such as a code sent to the customer's phone. A small number look so risky that they are stopped. Transaction risk is the measure behind that decision.

Banks, card issuers, payment service providers and merchants feed each transaction into rules and models, often within fraud management systems. Typical inputs include:

• Customer behaviour. Usual amounts, times, merchants and locations, compared with this transaction.
• Device and session. Signals such as a digital fingerprint of the device, IP address, and whether the login used multi-factor authentication.
• Velocity. How many attempts have come from the same card, account or device in a short time, measured through velocity checking; bursts of small attempts can signal card testing fraud.
• Payee and merchant. The type of merchant, its merchant category code, and whether the recipient account is new or linked to past fraud.
• Channel. Whether the payment is card-not-present, card-present, a bank transfer or an instant payment that cannot be recalled.

The output is a score that maps to an action: approve, step up with an extra check such as 3-D Secure, hold for review, or decline. Firms tune the cut-offs to balance losses against false declines, which annoy genuine customers and lose sales.

A simple way to express the money at stake is the expected loss on a transaction:

• $\text{EL}$ is the expected loss on the transaction.
• $p$ is the estimated probability that the transaction is fraudulent or will be lost, written as a decimal.
• $A$ is the amount at risk.

Worked example: a model estimates a 0.5% chance that a $400 online order is fraudulent. The expected loss is $0.005 \times 400 = 2$, or $2. If the merchant's margin on the order is $60, approving makes sense. If the same model gave a 20% chance, the expected loss would be $80, more than the margin, and the order should be challenged or declined.

In the European Economic Area, strong customer authentication is required for most electronic payments, but the regulatory technical standards (Delegated Regulation (EU) 2018/389) allow an exemption called transaction risk analysis. A payment service provider may skip strong authentication for a remote payment it judges low-risk in real time, provided its own fraud rate for that payment type stays below a reference level and the amount stays below a threshold. The thresholds are:

The real-time analysis must also check for abnormal spending, unusual device information, signs of malware, known fraud scenarios and abnormal or high-risk locations. The rule ties the right to reduce friction directly to how well a provider controls its fraud.

• Disputes and reversals. A card payment can come back as a chargeback months later, a theme covered in chargeback risk; ACH debits can be returned, creating a returned payment.
• Irrevocable instant payments. On rails such as FedNow or Faster Payments, funds move in seconds and cannot be pulled back, so the risk check must happen before sending; scams such as authorised push payment fraud exploit this.
• Processing errors. Wrong amounts, duplicates or misrouted payments, caught through reconciliation.
• Settlement timing. Between execution and final settlement, a counterparty may fail, which is settlement risk.
• Compliance. A transaction may involve a sanctioned party or suspicious funds, which sanctions screening and transaction monitoring are designed to catch.

Taken together, these strands make transaction risk one of the main components of payment risk, and the per-transaction view is how most payment fraud controls actually operate.

Scores are only as good as the data behind them. Fraudsters adapt to rules, new customers have little history, and models trained on past fraud can miss new schemes. Over-tight settings decline good customers, a cost that is real but rarely appears in fraud-loss figures. Transaction-level scoring also cannot see some threats, such as a genuine customer who has been talked into sending money by a scammer, which is why firms combine it with customer warnings and account-level risk management.

• Commission Delegated Regulation (EU) 2018/389 on strong customer authentication