Pitfall #1: the denominator
The denominator of a payment KPI is the population the numerator is measured against. The checkout funnel offers five of them, from the session that opens the payment form to the settled transaction. The statement “our authorization rate is 92%” means nothing until you name the population being counted, in other words 92% of what: attempts submitted to the network, customer attempts, captured transactions, or settled transactions. These five populations differ in size, in who owns them, and in the levers that move them. The same month of data yields rates more than 10 percentage points apart, depending on which population sits at the bottom of the fraction. This vagueness is by far the leading cause of fruitless meetings between merchants and their providers. Both sides bring accurate numbers that describe different populations.
| Denominator population | Volume | What it includes | What it excludes | Who controls it |
|---|---|---|---|---|
| Sessions reaching checkout | 10 000 | Every visitor who viewed the payment form | Carts abandoned earlier in the funnel | Product, UX, marketing acquisition |
| Customer payment attempts | 9 200 | Every form submission, including those the merchant's rules will block | Sessions with no attempt at all | Merchant (checkout flow, methods offered) |
| Authorization requests submitted | 8 615 | Messages actually sent to the network, including retries | Fraud engine declines and authentication failures: no authorization request went out | PSP + merchant configuration |
| Approved authorizations | 8 020 | Issuer approvals | Issuer declines, including retryable soft declines | Issuers (outside your control), data quality (within it) |
| Settled transactions | 7 985 | What is captured, then cleared: the basis for PSP billing and for network ratios | Authorizations that expired or were canceled before capture | Merchant (capture) + acquirer |
Same month, five populations: the resulting rates are not comparable (illustrative example, fictional figures)
Three rules for a dashboard that holds up
1. Never publish a ratio without naming its denominator in the column header. 2. Every KPI is tied to a specific decision and a named owner. If a two-point move triggers no concrete action, the metric is decoration. 3. The networks' monitoring ratios use different definitions from the merchant's own. Visa and Mastercard impose their own denominators (see below). The merchant therefore keeps two sets of numbers side by side: one for internal decisions, the other to track how close it is to the thresholds at which the networks enroll a merchant in a monitoring program.
Authorization rate ≠ payment success rate
The authorization rate divides approved requests by the requests actually sent to issuers: it is a network view. The payment success rate divides completed payments by all customer attempts: it is a customer view. These are the two most commonly confused metrics in the business. The second includes attempts the first ignores, notably those blocked by the merchant's own fraud engine and those lost during authentication. The consequence is counterintuitive, yet systematic. A fraud filter that blocks 5% of traffic upstream mechanically improves the authorization rate and lowers the payment success rate. It removes attempts from the first rate's denominator, while they stay in the second's. When the two curves diverge, that is not a measurement error: the gap quantifies the declines the merchant decided on itself, which makes it the most useful signal on the dashboard.
The three formulas, with numerator and denominator spelled out
# 1. AUTHORIZATION RATE (approval rate) - network view
number of authorization requests APPROVED
AuthRate = ---------------------------------------------------
number of authorization requests SUBMITTED to the network
Excludes: abandoned carts, upstream fraud engine declines,
authentication failures (no message was sent),
zero-amount account verifications (EUR 0.00).
Pitfall: retries inflate the numerator AND the denominator.
Publish two versions: first attempt / after retries.
# 2. PAYMENT SUCCESS RATE (completed payments) - customer view
number of payments COMPLETED (authorized, then captured)
SuccessRate = -----------------------------------------------------------
number of PAYMENT ATTEMPTS initiated by the customer
(including declines by the merchant's own rules, 3DS abandonments)
# 3. CHECKOUT CONVERSION RATE - business view
number of paid orders
ConvRate = --------------------------------------
number of sessions reaching checkout
# Over the same period: AuthRate >= SuccessRate >= ConvRate, always.
# A widening AuthRate - SuccessRate gap = internal declines are rising.The funnel in numbers: where the missing 20% goes (illustrative example)
Customer
10,000 sessions reach the payment form
Denominator for checkout conversion
Merchant
9,200 attempts submitted
800 drop-offs: payment method not offered, fees revealed too late, form too long
Fraud engine
8,970 attempts allowed through
230 internal declines, completely invisible in the authorization rate
3-D Secure
8,615 authentications completed
355 *challenges* abandoned or failed: no authorization request is sent
Issuers
8,020 authorizations approved
595 declines, some of them retryable SCA *soft declines*
Merchant
7,985 captures
35 authorizations expired or canceled before capture
Result
Authorization 93.1% · Payment success 86.8% · Conversion 79.9%
Three very different numbers from the same month of data
Always publish the first-attempt authorization rate
An aggressive retry policy inflates the “after retries” rate. Each new attempt adds one request to both the numerator and the denominator, which artificially boosts the metric. Retries also use up the attempt budget the networks allow on a declined transaction. In a subscription business, the gap between the first-attempt rate and the after-retries rate is the value your retry logic (dunning) delivers. Publish the two side by side: that gap is the only number that justifies investing in retry logic.
Reading declines: the code mix beats a single rate
The response code on an authorization request comes from the issuer and sits in field 39 of the ISO 8583 message. It tells you why the request was declined, whereas an overall rate only tells you how many were. A 1.5-point drop in the authorization rate doesn't tell you what to fix, while the distribution of decline codes points you straight to the work. The code often comes with a Merchant Advice Code, which says whether a retry is allowed. Tracking the share of the top five codes daily, segment by segment, replaces 10 dashboards on its own. It separates an issuer incident, concentrated on a few identifiers, from a configuration error, which hits every segment at the same moment.
| Code | Network description | What it really means | Retry? | Lasting fix |
|---|---|---|---|---|
05 | Do not honor | Discretionary issuer decline based on its own risk score: the catch-all remote decline | Possible, but rarely succeeds | Send richer data (address, email, transaction indicators), switch the affected segment to 3-D Secure |
51 | Insufficient funds | Insufficient funds: a temporary decline, not a risk decline | Yes, but later | Scheduled retry (next day, payday), no immediate repeat attempts |
54 | Expired card | Expired card among stored credentials | No, not until the credential is updated | Enroll in card updater services (Visa Account Updater, Mastercard Automatic Billing Updater), tokenize |
14 | Invalid card number | Wrong number… or a burst of stolen-card testing | No | Luhn check on the form, rate limiting, enumeration alerts |
65 (Mastercard) / 1A (Visa) | Soft decline: strong customer authentication required | The issuer rejects the requested exemption and requires authentication: the decline stems from the merchant's configuration, not the customer | Yes, once, via a 3-D Secure challenge | Narrow the exemption scope on this segment, check the automatic fallback to a challenge |
12 | Invalid transaction | A message field is inconsistent: merchant-initiated transaction indicator, currency, MCC, transaction type | Not until fixed | Field-by-field audit of the authorization message, side-by-side replay before and after deployment |
57 | Transaction not permitted to cardholder | The card product doesn't allow this use: prepaid, commercial card, usage restrictions | No | Offer another payment method, segment monitoring by card type |
04 · 41 · 43 · 59 | Pick up card, lost card, stolen card, suspected fraud | Final issuer decision | Never (Merchant Advice Code 03) | Stop retrying at once, retire the payment credential, investigate the fraud lead |
Common decline codes: what they really mean, and what to do
Retries are capped, counted, and billed
Visa caps reattempts on a declined transaction at 15 in 30 days for the same card, merchant, and amount. Every attempt beyond that is charged a fee (Visa's declined transaction resubmission rule, in effect since April 16, 2021, Visa Rules). Acquirers pass the fee on under a line item such as “excessive reattempts,” with a markup on cross-border traffic. Mastercard raised its fee per excessive attempt from $0.10 to $0.50 under its Excessive Authorization Attempts rule, effective January 2026. Retrying despite Merchant Advice Code 03, which means “do not try again,” costs you twice. The attempt is billed, and it adds to the monitoring program's counter. Exact thresholds vary by region, so get the written version from your acquirer.
Issuer, configuration, or product? The diagnostic tree
Every drop in payment performance falls into one of three families, and diagnosis must separate them before anyone fixes anything. An issuer problem is outside the merchant's control and calls for escalation to the acquirer, then to the network. A configuration problem comes from the merchant's own settings and can be fixed within hours once the faulty field is found. A product problem stems from the card base, pricing, delivery, or customer mix. The reflex to blame the issuer is wrong most of the time. What separates the three families is how the anomaly is distributed across segments. The more concentrated an anomaly, the easier it is to pin down. A genuine issuer incident hits one or two BINs and leaves every other segment flat. A configuration fault, by contrast, hits every segment at once, starting at an exact time that matches a dated change on the merchant side.
| Observed symptom | Assumption | Deciding test | Fix |
|---|---|---|---|
| Drop concentrated on one BIN or issuer, other segments flat | Issuer: scoring change, incident, platform migration | Same hour on day D vs. D−7, on that BIN alone; ask the acquirer whether other merchants in its portfolio see it | Escalate to the acquirer, then the network; with multiple acquirers, temporarily route that BIN elsewhere |
| Drop across all issuers, starting at a specific time | Configuration: deployment, certificate, missing field, wrong API version | Replay an authorization message from before and after the deployment, compare field by field | Roll back, then fix the faulty field (initiator indicator, amount, currency, MCC) |
Spike in 65 / 1A (soft declines) | Configuration: SCA exemption scope too broad | Soft decline rate by amount band and by country: it climbs exactly where the exemption is requested | Narrow the exemption scope, guarantee fallback to a challenge without the customer re-entering details |
Rise in 54 / 14 on subscriptions only | Product: aging stored credentials | Average age of declined credentials vs. average age of all stored credentials | Automatic card updating, tokenization, reminders to customers whose cards expire soon |
| Authorization rate stable, but payment success rate falling | Product / internal rules: the decline comes from the merchant | Break down attempts stopped before reaching the network (fraud engine, cart checks, limits) | Revise the rules, measure false declines with a control group |
Bursts of 14 / 05 on tiny amounts | Card enumeration attack (card testing), not a configuration problem | Distribution of amounts, IPs, and emails: a few cents, sequential numbers, disposable addresses | Rate limiting, CAPTCHA, temporary blocking; Visa monitors the enumeration ratio (see next section) |
Symptom → hypothesis → deciding test → fix
Without a shared clock, no correlation can be proven
Investigating a payment incident requires deployments, fraud rule changes, and KPIs to be timestamped on the same clock. That clock is UTC, to the minute. Half the investigations that end with “cause unknown” fail because the deployment log uses local time and the PSP report uses UTC. A two-hour offset is enough to hide the link between a change and the drop it caused.
Fraud, chargebacks, recovery: the ratios the merchant doesn't set
Here, the networks define the metrics, and their ratios are the ones that trigger penalties. Two distinct things are constantly confused. The fraud rate is built from issuer fraud reports, which the acquirer passes on as TC40 files (Visa) and SAFE files (Mastercard). The chargeback rate is built from disputes actually filed. Reported fraud does not always become a chargeback, and a chargeback is not always fraud. A substantial share of disputes involve non-delivery or goods not as described, and fixing those takes different tools than fixing fraud. Tracking the two series separately, each broken down by reason code, keeps you from answering a logistics problem by tightening the fraud engine.
The four risk formulas, each with its imposed denominator
# 1. FRAUD RATE, in basis points of VALUE (network view)
value of transactions reported as fraudulent by issuers
fraud_bps = ------------------------------------------------------- x 10,000
value of transactions SETTLED over the period
Source: TC40 (Visa) / SAFE (Mastercard) files, passed on by the acquirer.
This is NOT the merchant's chargeback file, and it arrives earlier.
# 2. CHARGEBACK RATE, by COUNT - two official denominators
Visa (VAMP ratio, monthly):
(TC40 fraud count + TC15 dispute count) / CNP transactions SETTLED in the month
Mastercard (ECM program, monthly):
chargebacks received in month M / transactions in month M-1
-> Same reality, two numbers. A month of strong growth FLATTERS the
Visa ratio (current-month denominator) and HURTS the Mastercard ratio
the following month, without a single dispute changing its nature.
# 3. RECOVERY RATE (not to be confused with the win rate)
Win rate = disputes won / disputes CONTESTED
Recovery rate = amount recovered / total amount of chargebacks RECEIVED
-> Only the second one hits the P&L. A 70% win rate on
10% of disputes contested = 7% actual recovery.
# 4. NET FRAUD LOSS (the number that pays the salaries)
net_loss = fraud chargebacks lost + dispute fees
+ goodwill refunds - amounts recovered
measured against revenue collected on the SAME transaction cohort.| Program | Monitored ratio | Threshold | Volume floor | Consequence |
|---|---|---|---|---|
| Visa VAMP, merchant (replaced VFMP and VDMP on April 1, 2025) | (TC40 fraud + TC15 disputes) ÷ settled card-not-present transactions, per month | Excessive: 1.50% since April 1, 2026 (previously 2.20%; the CEMEA region stays at 2.20%) | At least 1,500 fraud + dispute events in the month (CEMEA: 150 and $75,000) | Fees announced at $8 per event, remediation plan, immediate pressure from the acquirer |
| Visa VAMP, enumeration (card testing) | enumerated authorization attempts ÷ total authorization attempts | 20 % | About 300,000 enumerated attempts in the month | Enrollment in the enumeration track, per-attempt fees |
| Visa VAMP, acquirer portfolio | the same ratio, aggregated across the acquirer's whole portfolio | Above standard 0.50% · Excessive 0.70% | – | The acquirer may end the relationship well before the merchant hits its threshold: it is protecting its own ratio, not its client's |
| Mastercard ECM | chargebacks in month M ÷ transactions in month M−1 | 1.5% AND ≥ 100 chargebacks in the month | Both conditions must be met | Escalating monthly fines, Issuer Recovery Assessment, risk of a MATCH listing |
| Mastercard HECM (upper tier) | same | 3% AND ≥ 300 chargebacks | Both must be met | Much higher penalties; exit requires several consecutive months below the threshold |
| Mastercard EFM (fraud) | fraud chargebacks ÷ previous month's e-commerce transactions | 50 basis points AND ≥ 1,000 e-commerce transactions AND ≥ $50,000 in fraud AND under 10% of volume through 3-D Secure (50% in so-called regulated countries) | All four conditions must be met | Fraud program; in Europe, the 3-D Secure criterion effectively excludes PSD2-compliant merchants |
| TRA exemption: a regulatory threshold, not a network one | fraud rate of the PSP, by value (not the merchant's) | 0.13% up to €100 · 0.06% up to €250 · 0.01% up to €500 (RTS (EU) 2018/389, annex) | – | Above that, the PSP loses the right to exempt at that tier: challenges go up with no change at all on the merchant side |
Thresholds you don't choose: network monitoring programs, Visa VAMP thresholds applicable April 1, 2026, Mastercard ECM/HECM/EFM programs, and RTS (EU) 2018/389; status verified in July 2026
0,048 %
Card fraud rate in France, all channels, by value
Observatoire de la sécurité des moyens de paiement (OSMP), key figures for H1 2025 (published in January 2026); 0.053% for full-year 20240,129 %
Online card payment fraud rate (France)
OSMP, H1 2025: vs. 0.010% for in-person payments and 0.246% for non-internet remote payments0,302 %
Fraud rate on **unauthenticated** online payments (France)
OSMP, H1 2025 (0.386% in 2024)×17
Card fraud rate multiple when the counterparty is outside the EEA
EBA and ECB, *Report on Payment Fraud*, December 2025 (2024 data): EEA card fraud at 0.033% of valueTiming: June's fraud rate isn't known yet
Risk events tied to a transaction are reported after it, with lags that depend on their type. A fraud report reaches the merchant within days, a chargeback within weeks, and a statutory dispute up to 13 months later. A fraud rate computed on the date the files arrive mixes events from different origin months, and it systematically understates recent periods. The latest month always looks excellent, because its events haven't arrived yet. Any corrective measure seems to work immediately. This is the survivorship bias familiar from credit dashboards, and it has the same effect on payment metrics.
J
Authorization, then capture
The transaction enters the denominator of every ratio.
D+1 to D+3
Settlement and the *settlement* report
The final denominator of the network ratios, settled transactions, is locked in.
D+2 to D+30
TC40 and SAFE fraud reports
The issuer reports the fraud. The fraud numerator fills up, often before any chargeback.
D+30 to D+120
Chargebacks
The standard 120-day window to open a dispute with the network, counted from transaction processing.
Up to 540 days
Disputes with a deferred start date
For goods or services not received (Visa, reason code 13.1), the 120 days can run from the expected delivery date, up to 540 days after the transaction.
13 months
Statutory deadline, payer side
In France, the payer has 13 months from the debit to dispute an unauthorized transaction. The deadline drops to 70 days if the payee's provider is outside the EEA, and the contract can extend it to no more than 120 days (French Monetary and Financial Code, Art. L. 133-24).
The cohort rule, and revisions by design
Cohort analysis assigns every fraud and every dispute to the date of the original transaction. The date the reporting file arrived plays no part. The practice is to publish, each month, a revised version of earlier cohorts, stating how mature each one is, for example “May cohort, 92% mature.” Two consequences follow. A 30-day cohort cannot be compared with a 6-month cohort, and the effect of a rule change can only be judged between cohorts of similar maturity. Otherwise, an apparent improvement is just the lag between a transaction and its reporting.
Segment first: an overall rate tells you nothing
An overall rate blends populations with very different risk levels and behaviors, so its value depends on the weight of each. National fraud statistics show this at scale. In France, in H1 2025, the card fraud rate was 0.010% for in-person payments and 0.129% online, a ratio of 1 to 13 (OSMP). For online payments alone, it was 0.07% domestic, 0.24% to the EEA, and 0.55% outside the EEA. None of these values is “the” fraud rate on its own: each describes a different population. Segment first, then interpret a payment metric.
| Axis | What it reveals | Observed order of magnitude (source) | Decision it triggers |
|---|---|---|---|
| Cardholder country / corridor | Regulatory boundaries (whether strong authentication is mandatory), issuer behavior, local habits | Online fraud, France: 0.07% domestic, 0.24% France→EEA, 0.55% France→non-EEA (OSMP, H1 2025) | Local acquiring, corridor-based routing, differentiated fraud rules |
| Network (France's CB, Visa, Mastercard, others) | Brand selection on co-badged cards, interchange cost, authorization behavior | – | Routing priority, price arbitrage |
| Issuer / BIN | The only level at which an issuer incident becomes visible | – | Acquirer escalation, acquirer failover, A/B testing of message fields |
| Card type (debit, credit, prepaid, commercial) | Structural declines (57), insufficient funds (51), and above all cost | EU interchange caps: 0.2% on debit and 0.3% on credit for consumer cards (Regulation (EU) 2015/751, Arts. 3 and 4); commercial and non-EEA cards not capped | Pricing, promoting alternative methods, scheduled retries |
| Channel | The axis that outweighs all others | Card fraud, France: 0.010% in person, 0.013% mobile payments, 0.129% online, 0.246% non-internet remote (OSMP, H1 2025) | Anti-fraud budget, 3-D Secure scope, MCC choice |
| Authentication flow (challenge, frictionless, outside 3-D Secure, merchant-initiated) | The real effect of your SCA configuration, visible nowhere else | Fraud on unauthenticated merchant-initiated payments, France: 0.241% in H1 2025 vs. 0.314% in 2024 (OSMP) | Exemption scope, switching to challenge, fixing transaction indicators |
| Amount band | Exemption thresholds and the signature of card-testing attacks | TRA exemption regulatory tiers: €100, €250, €500 (RTS (EU) 2018/389) | Exemption bands, velocity limits, retry rules |
Segmentation axes: what each reveals, with sourced orders of magnitude
Measure the noise before you interpret
For a rate
p observed over n transactions, the 95% margin of error is roughly 1.96 × √(p(1−p)/n). An authorization rate of 90% measured on 200 transactions reads as 90% ± 4 points. A 3-point gap between two BINs of that size does not exist statistically: it falls entirely within the margin of error of each measurement. Telling 90% from 91% with confidence takes about 3,500 transactions in the segment. So set a minimum n by convention, group smaller segments under “other,” and open no investigation below that threshold. The published data also reveals a second, less intuitive effect. In France, the frictionless flow shows a lower fraud rate than the flow with strong authentication (0.054% vs. 0.089% with 3-D Secure, OSMP, H1 2025). That gap says nothing about how well strong authentication works. It reflects how the two populations are built: risk analysis routes the transactions it judges least risky to the frictionless flow. Two segments built by different selection rules are not comparable, because the observed gap reflects the selection rule as much as the flow itself.Total cost of acceptance: adding up what nobody adds up
The total cost of acceptance is the sum of everything a merchant pays to accept a payment, beyond the fee its provider invoices. It adds up fees, net fraud losses, dispute costs, and cash tied up in the payout cycle. It also includes the revenue lost to wrongful declines, the line most often missing from dashboards. The merchant service charge (MSC) is only the visible, invoiced part. The total is expressed in basis points of processed volume, the only unit you can compare across months, countries, or providers.
| Component | Type | Where to find it | Real lever |
|---|---|---|---|
| Interchange | Paid to the issuer; capped in the EU at 0.2% on debit and 0.3% on credit for consumer cards | Unblended detail in the acquiring report (Regulation (EU) 2015/751, Arts. 9 and 12) | Authorization data quality, card-type mix, corridor; the cap itself is not negotiable |
| Network fees (scheme fees) | Billed by Visa, Mastercard, and CB: often a dozen or so separate line items | Same unblended detail, line by line | Hard to negotiate but easy to audit: misqualification errors are common |
| Acquirer / PSP margin | The only truly negotiable item | Contract and monthly invoice | Competitive bidding, interchange++ pricing instead of a blended rate |
| Authorization fees | Billed even when the transaction is declined | Volume lines on the PSP invoice | Cut retries that cannot succeed, block enumeration |
| 3-D Secure authentication | Per-authentication fee, sometimes higher for a challenge | PSP invoice | Exemption scope, keeping in mind the cost of the declines it causes |
| Refunds and disputes | Fixed fee per refund and per chargeback (typically a few tens of euros per dispute, depending on the contract) | PSP invoice and dispute reports | Pre-dispute prevention, delivery quality, contesting only winnable reason codes |
| Foreign exchange | Markup on the rate (FX markup), separate from the reference rate | Settlement report, applied-rate column | Compare with the day's reference rate, negotiate the markup, collect in local currency |
| Cash tied up | Payout delay and rolling reserve | Settlement reports and bank statements | Negotiate the payout delay (D+1 vs. D+7) and the reserve percentage |
| False declines | The hidden cost: margin lost on good customers who were declined | Nowhere: it has to be estimated | Control group: let a share of borderline traffic through and measure the fraud that actually occurs |
Components of the total cost of acceptance, and where to find them
Total cost of acceptance in basis points (illustrative example, explicit assumptions)
Scope: 1 month, e-commerce, 100,000 settled transactions, average order 60 EUR
Settled volume = 6,000,000 EUR
DIRECT FEES
Interchange (0.21% weighted average) 12,600 EUR
Network fees 3,400 EUR
Acquirer / PSP margin (0.15% + 0.05 EUR / tx) 14,000 EUR
Authorization fees (0.02 EUR x 108,000 attempts) 2,160 EUR
3-D Secure (0.03 EUR x 92,000 authentications) 2,760 EUR
Refunds (900 x 0.20 EUR) 180 EUR
Disputes (180 chargebacks x 15 EUR) 2,700 EUR
FX markup (0.45% on 300,000 EUR) 1,350 EUR
-----------
Subtotal, fees 39,150 EUR = 65 bps
RISK LOSSES (cohort, after recovery)
Net fraud loss 11,000 EUR = 18 bps
COST OF CAPITAL
7-day payout lag + 5% reserve
~ 1,500,000 EUR tied up at 3.5% / year 4,375 EUR = 7 bps
-----------
TOTAL COST OF ACCEPTANCE 54,525 EUR = 91 bps
FOREGONE REVENUE (not a cost, but decisive in the trade-off)
600 estimated false declines x 60 EUR x 25% margin 9,000 EUR
-> the equivalent of 15 bps: tightening fraud rules
can cost more than the fraud it prevents.The right to unblended detail
Regulation (EU) 2015/751 requires the acquirer to show the merchant service charge, interchange fees, and scheme fees separately. The breakdown is by category and by card brand (Article 9, the unblending rule). The same regulation requires the acquirer to send the merchant, after execution, at least once a month and in an agreed format, the corresponding amounts for each transaction (Article 12). In France, breaching these obligations can lead to an administrative sanction (French Monetary and Financial Code, Art. L. 361-1). A blended rate remains lawful if the merchant has requested it in writing. It rolls the three components into a single number, so an increase can no longer be traced to interchange, the network, or the provider's margin. Get the unblended detail before a pricing negotiation starts, not during it.
The minimum dashboard: sources, cadence, alert thresholds
A working payment dashboard fits into about a dozen metrics and three reporting cadences. It draws on five data sources: PSP transaction reports, settlement reports, fraud files from the acquirer, dispute files, and bank statements. Transaction reports come via API or file transfer, and bank statements come in camt.053 format, or CFONB120 in France. The statements tie the numbers back to treasury. Analysis done outside these sources and cadences is a one-off study, not ongoing performance management.
Daily (15 minutes)
Volume, authorization rate on first attempt, mix of the top five decline codes, previous day's reconciliation breaks. The goal is to catch a break, not to explain a trend.
Weekly
The same metrics by segment (corridor, channel, authentication flow, top 10 BINs), 3-D Secure challenge rate and challenge abandonment rate, soft decline rate.
Monthly, after close
Network ratios recalculated with their denominators, revised fraud cohorts, total cost of acceptance in basis points, check of the unblended invoice detail.
Quarterly
Pricing renegotiation with evidence in hand, fraud rules revised on mature data, internal benchmarks updated by segment.
| Indicator | Source | Frequency | Alert rule | Decision |
|---|---|---|---|---|
| Authorization rate on first attempt | PSP transaction report | Daily | −2 points vs. the same weekday a week earlier, on a segment of ≥ 3,500 transactions | Open the diagnostic tree (code mix, deployments) |
| Mix of the top five decline codes | PSP transaction report | Daily | One code gains 5 points of share | Classify: issuer, configuration, or product |
| Customer payment success rate | Checkout log + PSP | Daily | Diverges from the authorization rate | Review internal decline rules |
| Reconciliation break, payout ↔ bank | Settlement reports + camt.053 / CFONB120 (France) | Daily | Any break still unexplained after 24 hours | Open an investigation, leave nothing in a suspense account |
SCA soft decline rate (65 / 1A) | PSP transaction report | Weekly | Increase concentrated in one amount band or country | Narrow the exemption scope |
| Challenge rate and challenge abandonment rate | 3-D Secure server reports | Weekly | Rising challenge abandonment | Renegotiate the scope, test delegated authentication |
| Fraud rate in basis points of value | TC40 / SAFE files via the acquirer | Monthly, by cohort | Trend reaching 70% of the network threshold | Remediation plan before enrollment, not after |
| VAMP and ECM ratios, computed with their own denominators | Dispute files + settled transactions | Monthly | 70% of the threshold, or event floor crossed | Alert the acquirer, switch on pre-dispute prevention |
| Dispute recovery rate | PSP dispute files | Monthly | Drop in amount recovered relative to amount received | Review evidence packages, target winnable reason codes |
| Total cost of acceptance in basis points | PSP invoices + unblended detail + settlement reports | Monthly | +3 bps with no change in mix | Billing audit, amicable demand letter to the acquirer |
| Estimated false declines | Control group + retries that succeeded | Monthly | Cost of false declines exceeds the fraud prevented | Relax the rules on that segment |
| Actual payout delay | Settlement reports + bank statements | Monthly | Average delay drifting, or withheld reserve rising | Contract renegotiation, cash-flow plan adjustment |
Twelve metrics, their source, their alert rule, and the decision they trigger
The three-question test, and the end of “good rates”
A dashboard does its job when it answers three questions without an extra query: (1) does the observed movement exceed statistical noise, (2) in exactly which segment does it occur, down to the BIN and the hour, and (3) who decides, and what concrete action follows. As for “normal” levels, there is no universal benchmark. An authorization rate depends on channel, country, average order value, industry, card mix, and exemption policy. The rates published by France's OSMP (0.048% in France, H1 2025) or by the EBA and the ECB (0.033% in the EEA in 2024) are market aggregates. They are not targets you can assign to any individual company. The benchmark a merchant can actually use is its own series by segment over a rolling 12 months, revised by cohort, and backed by an A/B test at every parameter change. A claim such as “the right rate is 95%,” with no denominator, segment, or period attached, is a sales pitch, not a measurement.