.png)
Key Highlights
- Payment risk management covers everything that can cost a payments company money or its licence over the life of a payment.
- Operational risk covers a card programme's own processes, systems and people, and fraud risk sits inside it.
- Dispute volume is not a measure of risk. For an issuer a chargeback is a conditional recovery against a loss already taken, and what survives failed representments, expired timeframes and transactions with no dispute right is the real fraud number.
- Worldwide payment card fraud losses reached USD 33.83 billion in 2023, and the Nilson Report projects USD 403.88 billion in cumulative losses over the following decade.
- Running a card programme means balancing fraud loss against cardholder experience and revenue. A new programme strikes that balance with the least data to tune it.
Payment risk management guidance is written for the company taking the payment. Read any guide on the subject and it addresses the merchant, the processor, the business worried about a returned ACH debit.
Merchants outnumber issuers by orders of magnitude, so that is where the vendors and the guidance have pointed. But the issuing side is not the merchant's problem viewed from a different desk. Different decision, different obligations, different party holding the outcome.
A company that issues cards sits on the opposite side of the same transaction. It approves or declines the authorisation. It funds the spend. It answers to the card network for how the programme behaves.
What Is Risk Management in a Payments Company?
Payment risk management is how a payments company identifies and contains the risks that can cause financial loss or regulatory failure across the payment lifecycle.
Operational risk is loss that comes from a company's own processes, systems and people failing. Fraud risk sits inside it.
Credit risk is loss when funded spend is never recovered. An issuer approves a transaction before the money settles, so the gap between authorisation and settlement is credit exposure.
Compliance and regulatory risk is exposure from failing an obligation, whether that is a licensing condition, a data requirement or an anti-money-laundering duty. The penalty here often exceeds the underlying loss.
Lifecycle does real work in the definition of payment risk management. A payment is authorised long before it settles. After settlement it stays open to dispute for a fixed window. Risk attaches at every one of those stages, and a control that works at authorisation does nothing about a dispute filed 90 days later.
What Are Examples of Operational Risk in Payments?
Operational risk shows up as the ordinary ways a payments business breaks. A duplicate settlement batch goes out. A reconciliation breaks and nobody notices for a week. A processor has an outage during a settlement window. A control is configured wrong and approves what it should have declined.
Fraud sits inside operational risk for a card issuer. A fraudulent authorisation is a control failure, and the loss lands the same way an outage or a misconfiguration does.
A chargeback is a process, not a risk category. An issuer raises one to recover a loss after fraud has already happened, and the outcome is conditional on scheme rules, evidence and timeframes. What the process fails to recover stays with the programme.
What Is Fraud Risk, and How Big Is It in Cards?
Fraud risk is loss from a transaction the legitimate account holder never authorised.
The numbers are large and still growing. As of September 2026 the most recent openly published figure is for 2023. Worldwide payment card fraud losses rose 1.1% that year to USD 33.83 billion, and the Nilson Report projects USD 403.88 billion in cumulative worldwide losses across the following ten years (Payments Dive, January 2025).
Set that against volume. Global card purchase and cash volume reached USD 51.920 trillion in 2024, up 1.0% on the prior year (Nilson Report, Issue 1298, December 2025). Fraud is a small fraction of throughput and a large absolute number. That is why it is managed as a rate rather than eliminated.
An issuer and a merchant both carry fraud risk, with the weightings inverted.
Concentration is the difference most often underestimated. A card programme shares a Bank Identification Number, so an attacker who works out the pattern is attacking every card in the range rather than one account. That is the mechanic behind a BIN attack, also called card enumeration.
Who carries the regulatory consequence depends on who holds the issuing permission. For most programmes that is a sponsoring licensed issuer rather than the brand on the card. BIN sponsorship is the arrangement that makes the split explicit.
What Does It Take to Build a Card Risk Function In-House?
Building a card risk function in-house takes four capabilities, and they have to work together rather than in sequence. A real-time decision at authorisation scores each transaction and declines suspected fraud before the money moves. A portfolio monitoring layer catches patterns no single transaction reveals. A dispute process investigates chargebacks and recovers what the evidence supports. Reporting tells the programme whether its decline rate is catching fraud or turning away good spend.
Each needs tooling and a person who has done it before. The tooling is procurable. The judgment is the constraint. Rules have to be tuned to a specific cardholder population, and tuning them takes either historical data from a comparable portfolio or the willingness to learn on live losses.
A card programme has three routes to real-time decisioning, portfolio monitoring, dispute handling and reporting, and the three are not priced or staffed alike.
Building a card risk function means the programme licenses a real-time monitoring platform, hires someone who has run card fraud before, then operates it in-house. This route gives full control over policy. It is also the only one that needs a standing team rather than a finished project, because attack patterns shift and rules go stale.
Licensing a fraud vendor buys the tooling and leaves the operation with the programme. The tool is one line of the cost. The engineering to integrate it and the person to run it are the other two.
Taking a managed fraud and risk function puts the fraud policy, the tooling and the operations with a third party, run against the programme's own cardholder population. Control over the rules is what gets traded away for not building anything.
Choosing between those three routes is the build-versus-buy question for a platform adding card issuing. A programme with the volume to justify a dedicated risk function will do better owning the discipline. A programme launching its first cards faces its highest per-transaction risk in exactly the period before it has enough history to tune against.
What Are the Limits of Any Payment Risk Programme?
No programme reaches zero fraud, and a programme claiming to has moved its losses somewhere else.
The core trade-off is unavoidable. Every control tight enough to catch more fraud also declines more legitimate transactions. A false decline costs revenue and cardholder trust rather than a fraud loss. Tuning is a choice about which of those two costs the programme prefers, made explicitly or by accident.
Two further limits apply. Controls decay, because attack patterns change and rules tuned to last year's behaviour lose accuracy against this year's. Portfolio data beats programme data, so a small programme's own history is a weak training signal in its first year regardless of tooling.
Fraud monitoring is a compliance obligation in its own right. Scheme rules and regulators both require it, but it is not AML monitoring. Fraud monitoring detects unauthorised use of the card, while AML and CTF monitoring detects illicit funds moving through transactions the cardholder fully authorised. Different typologies, different thresholds, different reporting duties. No fraud control satisfies AML obligations, and those sit with the programme owner.
How Reap Can Help
The hardest part of running a new card programme is knowing where to set the controls. Controls set too loose let fraud eat the margin. Controls set too tight decline good cardholders, which costs revenue and trust. Striking that balance takes portfolio data a new programme has not accumulated yet.
Reap Sentry is a managed card fraud management function for card issuing programmes. Reap owns the fraud policy, the tooling and the operations, and runs them against the programme's own cardholder population.
Because Reap issues the cards, the fraud rate on a client programme and the fraud rate on Reap's own BIN are the same number.
Reap is a Visa Principal Member and issues cards directly. The card issuing platform includes a real-time authorisation engine, embedded KYC, transaction monitoring and fraud tooling. Reap's risk specialists configure and operate the fraud controls for programmes on it.
Anti-money-laundering and counter-terrorist-financing obligations remain with the programme owner. Reap Sentry covers card fraud detection, loss management and Visa scheme compliance.
FAQ
What is payment risk management?
Payment risk management is the work of spotting and containing anything in the payment lifecycle that can cause a financial loss or a regulatory failure. For a card programme, fraud sits inside operational risk rather than beside it.
Is fraud risk the same as operational risk?
Fraud risk is a sub-category of operational risk. Operational risk covers loss from a company's own processes, systems and people failing, and a fraudulent authorisation that a control should have stopped is one of those failures.
Are chargebacks a type of payment risk?
No, as chargebacks are a process, not a risk category. An issuer raises chargebacks to recover cardholder losses from merchants, and the outcome is conditional on scheme rules, evidence and timeframes. Rising dispute volume is a symptom to read, not a risk to hold. The exposure sits in the fraud that generated the dispute and in whatever the process fails to recover.
What is card fraud management?
Card fraud management is the discipline of detecting and containing unauthorised transactions on cards a programme has issued. It covers real-time screening at authorisation, pattern detection across the whole BIN range, dispute handling and fraud reporting.
What is a BIN attack?
A BIN attack is a brute-force attempt to find valid card numbers. The attacker generates combinations against a known Bank Identification Number, then tests them with small transactions. Because a card programme shares a BIN range, one successful pattern exposes many cards at once. The attack is also called card enumeration.
Can a fraud control satisfy anti-money-laundering obligations?
No. Fraud controls decide whether a transaction is authorised by the legitimate account holder. Anti-money-laundering and counter-terrorist-financing obligations concern the source and purpose of funds and the identity of the parties. They attach to the licensed entity and the programme owner, and they need their own controls, records and reporting.
Conclusion
Payment risk management for an issuer runs across operational, fraud and scheme exposure, but fraud is the strand that dominates in practice. It concentrates at the authorisation decision, and across a shared BIN range where one programme's losses shape the network's view of every programme on it.
A card programme's real decision is who builds the four capabilities that manage fraud. It has to make that call at the point in its life when it has the least data to tune them with.
Disclaimer
The information provided in this material is for general informational purposes only and does not constitute legal, financial, tax, or business advice. It should not be interpreted as a recommendation, offer, solicitation, or inducement to engage with Reap’s products or services. Any use of Reap’s services is at the user’s sole risk and discretion.
Reap makes no representation or warranty, express or implied, regarding the accuracy, completeness, or reliability of the information provided. Services are governed exclusively by Reap’s applicable legal agreements. Service availability, features, and eligibility may vary by jurisdiction and are subject to regulatory, card network, and operational limitations.
All trademarks, logos, and brand names are the property of Reap and/or their respective owners. References to third-party platforms or services are for descriptive purposes only and do not imply endorsement, partnership, or affiliation.
Reap’s services and information are provided on an “as is” and “as available” basis, without warranties of any kind. Reap shall not be liable for any loss or damage arising from the use of, or reliance on, this information or its services.
