Who holds the exemption, and what each party must be able to prove
An SCA exemption is a payment service provider's right to execute a transaction without applying strong customer authentication. The exemption belongs to the provider, not to the merchant collecting the payment. Delegated Regulation (EU) 2018/389 places obligations only on providers; the payee appears in it only as an input to the risk analysis. A remote card transaction involves two providers. The payer's provider, the issuer, decides whether to authenticate. The payee's provider, the acquirer, can ask for authentication to be waived. Each has its own fraud rate, calculated on its own portfolio, and each answers to its own supervisor for its decision.
The merchant takes part through its acquirer. It configures an exemption request in its checkout flow, its provider passes it on, and the applicable ceiling is still the one set by the acquirer's portfolio. The ceiling is never calculated at the merchant level. A merchant with little fraud exposure loses the €250 band as soon as its acquirer's rate exceeds 0.06%. The reverse also happens: a merchant with heavy fraud exposure benefits from its acquirer's average rate as long as that rate stays below the reference rate. How a merchant sets up exemption requests therefore depends on an earlier contractual decision: which acquirer it signs its acceptance agreement with.
| Party | What it decides | What it must be able to prove |
|---|---|---|
| Issuer | Authenticate, apply its own exemption, or reject the one requested | Its fraud rate by transaction type (Art. 19), its transaction monitoring mechanisms (Art. 2), its quarterly monitoring data (Art. 21) |
| Acquirer | Pass on the merchant's exemption request, and allow or block it through the acceptance agreement | The same rate calculated on its acquired portfolio, the real-time risk analysis under Article 18(2)(c), and the annual audit under Article 3(2) |
| Merchant | Decide whether to trigger the request, by amount, issuing country, or product | Nothing to the supervisor, everything to its acquirer. It is not subject to the regulation but is contractually liable |
Real-time risk analysis is the assessment of fraud risk carried out while the transaction is in progress, before it is approved. Article 18(2)(c) rules out the exemption as soon as the provider detects any item on its list. The list covers abnormal spending by the payer, unusual information about the payer's device or software access, malware infection during the authentication session, and a known fraud scenario. Two more items concern geography: an abnormal location of the payer and a high-risk location of the payee. The list thus comprises six findings, all to be established during the transaction. The text lists facts to look for; it sets no score threshold. An engine that returns a single overall score without logging each of these six checks cannot demonstrate that none of the six items was detected.
Paragraph 3 of the same article lists the factors that feed this risk score, including the user's previous spending patterns, their payment transaction history, and the locations of the payer and the payee at the time of payment. The regulation thus names the model's inputs without prescribing how to combine them. Each provider is free to choose its model, but must be able to show an auditor how it works. The price of that freedom is traceability of the inputs.
- The ceiling depends on the acquirer's portfolio, not yours. The regulation targets the payment service provider, not the brand or the acceptance agreement.
- Ask for the rate, by transaction type. An acquirer that won't say where it stands in the annex table is selling an exemption it cannot promise will last.
- Get the band-exit clause in writing. Article 20 requires immediate cessation after two quarters above the threshold, and the contract must say who notifies whom, and how quickly.
- Check who bears the fraud. An exemption requested by the acquirer shifts the loss to the acquirer, and the pass-through clause decides what happens next.
- Tell exemptions apart from out-of-scope transactions. A merchant-initiated transaction, or one with a leg outside the EEA, does not count in the Article 19 denominator.
Calculating the fraud rate: numerator, denominator, and frequency
The Article 19 fraud rate is the value of unauthorized or fraudulent remote transactions in a period divided by the value of all remote transactions of the same type. The annex table compares this ratio with a reference rate to open or close an exemption band. Paragraph 1 puts the total value of unauthorized or fraudulent remote transactions in the numerator, whether or not the funds were recovered. The denominator is the total value of all remote transactions of the same type. The ratio is calculated by value, never by transaction count. In a portfolio of high-value carts, a single fraud can therefore weigh as much as a hundred small ones, and one isolated loss can push the rate above a reference rate.
The denominator includes only remote transactions authenticated with SCA or executed under one of the exemptions in Articles 13 to 18. Its scope is narrower than remote traffic as a whole. Out-of-scope transactions are excluded: merchant-initiated transactions, mail or telephone orders, and payments where the issuer or the acquirer is outside the European Economic Area. An acquirer with half its remote traffic in recurring subscriptions therefore calculates its rate on half its business, and each loss weighs that much more heavily in the ratio.
The numerator is worded more broadly and lacks the denominator's qualifier. The text refers to the total value of unauthorized or fraudulent remote transactions without repeating the restriction placed on the denominator. Two readings have coexisted ever since. The European Banking Authority answered the question in Q&A 2019_4702, published July 24, 2020. The issuer counts all unauthorized or fraudulent remote transactions, including those that were authenticated and those exempted by the other party. The acquirer does the same on its acquired portfolio. The Financial Conduct Authority reads the same Q&A more narrowly, limiting the numerator to transactions for which the provider bore the liability (CP21/3, January 2021, paragraph 4.14). The liability criterion does appear in the EBA's opinion on the implementation of the regulation, but that opinion also added the other fraudulent transactions the provider failed to prevent. A group operating on both sides of the Channel therefore documents two calculation methods for the same business.
The calculation frequency determines when the rate opens or closes an exemption band. The regulation refers to a rolling quarterly basis of 90 days, which suggests recalculating daily over the last 90 days. The European Banking Authority reads Article 19(1) together with Article 20(2), which refers to two consecutive quarters. Its answer calls for a single calculation per calendar quarter (Q&A 2018_4045). Internal monitoring can track a daily metric, which lets you fix a segment before the quarter closes. But the figure that opens or closes a band remains quarterly.
The rate is calculated by transaction type. The annex table distinguishes only two types: remote electronic card-based payments and remote electronic credit transfers. A provider that does both has two rates, and no more. The European Banking Authority explicitly ruled out calculating by amount band. A provider with a 0.10% rate across all its remote card payments can exempt only up to €100, whatever its loss experience on larger carts (Q&A 2018_4043, December 21, 2018). Segmenting internal reporting remains useful for management, but it creates no additional right under the regulation.
| Item | In the numerator | In the denominator |
|---|---|---|
| Remote transaction authenticated with SCA | Yes, if fraudulent | Yes |
| Transaction exempted under Articles 13 to 18 | Yes, if fraudulent | Yes |
| Merchant-initiated transaction (MIT) | Wording is open; document your interpretation | No |
| Mail or telephone order (MOTO) | Wording is open; document your interpretation | No |
| Transaction with one leg outside the EEA | Wording is open; document your interpretation | No |
| First-party fraud by the cardholder | No (EBA, Q&A 2018_4032) | Yes, the transaction stays in the flow |
| In-person payment | No, the calculation covers remote payments only | No |
| Funds recovered after the fraud | Yes, recovery doesn't remove it | Yes |
The bands, what they're worth, and the deadline to stop using the exemption
The exemption threshold value is the amount a transaction must not exceed to be exempted under transaction risk analysis. The annex table sets three: €100, €250, and €500. It pairs each with a reference rate per transaction type, for six rates in all. For remote card payments, the €100 band opens at 0.13%, the €250 band at 0.06%, and the €500 band at 0.01%. Remote credit transfers face stricter rates: 0.015%, 0.01%, and 0.005% for the same amounts. The bands cascade downward. A provider that meets 0.01% automatically meets the other two thresholds and can exempt up to €500.
| Exemption threshold value | Remote electronic card-based payments | Remote electronic credit transfers |
|---|---|---|
| 500 € | 0,01 % | 0,005 % |
| 250 € | 0,06 % | 0,01 % |
| 100 € | 0,13 % | 0,015 % |
A band's value is measured by the share of revenue from transactions below its threshold. A merchant with a €40 average cart gets all the benefit from the first band, and stepping down to 0.01% gains it nothing. An electronics retailer whose carts regularly exceed €300 is in the opposite position, because the €500 band then governs a large share of its revenue. The upfront assessment therefore looks at the distribution of transaction amounts, not at the rate itself. It comes down to adding up the euros collected below each threshold, a calculation that fits in a single query. That puts a value on each band before it is discussed with the acquirer.
Closing a band has effects beyond the exempted traffic. Traffic sent back to authentication loses some payers at the challenge step, and that friction is concentrated on the portfolio's highest-value carts. At the same time, the provider must submit a remediation plan to its authority, which ties up the very teams that need to fix the root cause. The rate takes a quarter to reflect the fix, because the calculation window is still 90 days. A fix deployed in March shows up in full only at the end of June. The reopening date therefore depends on when the quarter closes, not on when the fix ships.
The annual audit: what it checks and who can perform it
The audit required by Article 3(2) is a periodic review of the provider's methodology, model, and reported fraud rates. Under Article 19(2), the accuracy of the rate itself falls within this review. The audit assesses how the fraud rates are calculated and the resulting figures, and it ensures they are complete and accurate. The regulation thus makes the auditor the guarantor of the figure that opens the band. A provider that cannot rebuild its rate from its raw data will fail the review, however good its risk engine.
Article 3(2) describes an audit with three subjects: the methodology, the model, and the reported fraud rates. Article 19(3) spells out what the second covers, namely the method and any model the provider uses to calculate its rates. The review therefore examines how the figure is built before it examines the published value. The security measures themselves fall under the general audit in paragraph 1, which covers transaction monitoring under Article 2 and real-time analysis under Article 18. The two exercises are conducted separately and produce two separate reports.
Who may act as auditor depends on two overlapping regimes, according to the year. The annual audit can be performed internally. The auditor must have expertise in IT security and electronic payments and be operationally independent within or from the provider. In the first year the exemption is used, and then at least every three years, the audit must be carried out by an independent, qualified external auditor. The competent authority can require external audits more often. Under both regimes, the operational independence requirement rules out a review by the team that produces the figure.
The competent authority receives three separate deliverables. It is entitled to the full audit report on request, under Article 3(3). The method, the models, and the rates are documented in writing and made fully available to the competent authority and to the European Banking Authority, with prior notification, under Article 19(3). The results of the quarterly monitoring under Article 21 are subject to the same conditions. Each rests on its own legal basis, and none replaces the other two.
Article 21 monitoring is a periodic data record, kept by the provider and produced on request. It sets the level of detail the institution must maintain at all times. The data is recorded and monitored for each transaction type, split between remote and other transactions, at least quarterly. It covers three groups. The first is the total value of unauthorized or fraudulent transactions and the resulting fraud rate, broken down by SCA and by exemption used. The second is the average transaction value, broken down the same way. The third is the number of transactions exempted under each exemption and their percentage of the total.
- The written definition of the numerator and denominator, with the rationale for how out-of-scope transactions and first-party fraud are treated.
- The audit trail behind the figure, which must make it possible to rebuild a published quarterly rate from the original records, transaction by transaction.
- The Article 21 monitoring data, broken down by remote and in-person transactions and by exemption used, by value, average value, and count.
- Evidence of the real-time analysis for the six findings in Article 18(2)(c), any one of which rules out the exemption when detected.
- The log of breaches and notifications made to the competent authority under Article 20, with their dates and the measures announced.
- The external auditor's reports, for the first year the exemption was used and for the latest three-year cycle.
From regulatory reporting to internal monitoring: four figures that don't match
The fraud reporting that Article 96(6) of Directive (EU) 2015/2366 requires of providers is a statistic of fraud by payment method, submitted to the competent authority. It reports a different figure from the Article 19 rate. The competent authorities then forward it in aggregate form to the European Banking Authority and the European Central Bank. Guidelines EBA/GL/2018/05, as amended by Guidelines EBA/GL/2020/01 of January 22, 2020, set its format. Providers report to their national supervisor every six months. The supervisor then has six months after the end of the period to forward the aggregated data.
The two measures serve different purposes, so their scopes differ. Regulatory reporting covers all fraud, whether or not it falls within the scope of SCA and whichever party bore the loss. The Article 19 rate uses a narrower denominator and excludes first-party fraud. The Financial Conduct Authority spelled out this difference in its CP21/3 consultation, contrasting the Article 18 calculation with UK fraud reporting. A single institution therefore produces two different fraud rates for the same period, both correct, and the gap between them comes down to that difference in scope.
The guidelines require a breakdown as detailed as internal monitoring. Issuers and acquirers report separately, in two separate tables in Annex 2, and each unauthenticated transaction carries the reason SCA was not applied. The reason refers to the exemptions in Chapter 3 of the delegated regulation, or to the categories “merchant-initiated transactions” and “other,” added in 2020. Every six months, a provider therefore reports how its exempted traffic breaks down, exemption by exemption. A third party can compare that reported breakdown with the indicators actually carried in the messages.
| Metric | Scope | Frequency | What it drives |
|---|---|---|---|
| Article 19 rate | Remote transactions authenticated or exempted under Articles 13 to 18, by transaction type, at the provider level | Calendar quarter | The right to use the exemption, band by band |
| PSD2 fraud reporting | All reported fraud, within the scope of SCA or not, whichever party bore it | Half-year | Public statistics and the supervisor's attention |
| Network monitoring ratio | Fraud divided by the volume of a merchant ID, under each card network's own rules | Set by each network | Placement in a monitoring program and the related penalties |
| Internal rate by contract | Any breakdown: by acceptance agreement, product, issuing country, amount band | Continuous | Commercial decisions and exemption request settings |
Reconciliation means matching the reason for not applying SCA, as reported to the supervisor, with the decision actually made on each transaction. It requires data that many systems don't keep. The exemption requested and the exemption actually applied are two separate pieces of information, carried in two different messages. The request travels in the authorization message or the authentication message, depending on the setup, while the decision belongs to the issuer and shows up only in the response. Version 2.2 of the EMV 3-D Secure specification extended the threeDSRequestorChallengeInd field so the requestor can flag an exemption at the authentication stage (EMVCo, EMV 3-D Secure, specification v2.2.0). Storing both values in the same record as the transaction outcome is a prerequisite for any later reconciliation. Without them, the reported reason has to be reconstructed after the fact from the outcome alone.
The numerator keeps changing after the quarter closes. A fraud dispute arrives weeks or months after the transaction. Card network rules allow up to 120 days to file a dispute for most fraud reasons (Visa Core Rules, April 18, 2026 edition; Mastercard Chargeback Guide). A rate published three days after quarter-end is therefore structurally understated. Two practices coexist: publishing on a fixed date with a documented later correction, or delaying publication until a maturation window has passed. Record the choice in the method and keep it from one quarter to the next; otherwise successive rates stop being comparable.
- Keep the request and the outcome. The exemption indicator sent and the issuer's response are two fields, to be stored side by side with the transaction outcome.
- Lock down the numerator definition. A dispute reason code is not proof of fraud, and the mapping between dispute codes and fraud as defined in Article 19 should be decided once and for all.
- Measure the distribution of amounts below each threshold value, in euros collected, to know what each band is really worth before negotiating it.
- Date the numerator. A rate locked too early is an understated rate, and the chosen maturation window must be documented like the rest of the method.
- Track your acquirer's rate, not just your own. A merchant with no visibility into its provider's portfolio finds out a band has closed when its conversion drops.
- Separate merchant IDs by channel and risk level, so internal monitoring stays readable even when the regulatory rate remains global.
Elsewhere in the world. The same mechanism, elsewhere.
The scope of the fraud rate calculation that unlocks the transaction risk analysis exemption
In the European Economic Area, the fraud rate that governs the transaction risk analysis exemption is calculated as fraud over the period divided by the volume of transactions of the same type. In Q&A 2019_4702, the European Banking Authority specified that the numerator includes unauthorized and fraudulent transactions, regardless of which party ultimately bears the loss. The calculation is quarterly and is done separately for remote card payments and for credit transfers.
Delegated Regulation (EU) 2018/389, Article 19; EBA, Q&A 2019_4702
The UK carried the SCA technical standards into domestic law after leaving the EU. The Financial Conduct Authority takes a narrower view of the calculation, limited to unauthorized or fraudulent remote transactions for which the provider bore the liability, while presenting this as its adoption of EBA Q&A 2019_4702. It explicitly distinguishes this scope from that of its REP017 fraud report, which covers all fraud, whoever bears the loss and whether or not it falls within the scope of SCA.
FCA, CP21/3 “Changes to the SCA-RTS and to the guidance in Payment Services and Electronic Money – Our Approach,” January 2021, paragraph 4.14