PSD2 SCA Exemptions and MITs: An Operator Guide

Under PSD2, strong customer authentication (SCA) applies to in-scope electronic payments unless a valid exemption or other applicable provision allows a different treatment. The Regulatory Technical Standards (RTS), Commission Delegated Regulation (EU) 2018/389, contains the operative conditions. This article is an implementation overview; applicability depends on transaction facts, geography, payment service provider roles, and current law.

A key terminology correction: merchant-initiated transactions (MITs) are not an SCA exemption. An MIT is initiated by the payee under a prior agreement and is treated differently from a payer-initiated transaction when the legal and scheme conditions are met. Do not count MIT alongside the RTS exemptions or label it an “MIT exemption.”

The RTS exemptions relevant to card product teams

The RTS provides several exemptions, each with its own conditions. Common card-not-present discussions include:

• Low-value remote transactions: Article 16 allows a PSP not to apply SCA for a remote electronic payment up to EUR 30, subject to cumulative value and consecutive-transaction limits since the last SCA. The RTS refers to a cumulative EUR 100 limit or five consecutive transactions, whichever occurs first. The payer’s PSP must apply and monitor the conditions; a merchant-side counter is not authoritative.
• Transaction risk analysis (TRA): Article 18 permits a PSP not to apply SCA to a remote transaction it identifies as low risk using the required monitoring and risk scoring, provided the applicable reference fraud rates and transaction-value ceilings are met. Article 19 defines fraud-rate calculation; Article 20 sets cessation and reporting duties when thresholds are exceeded. Check the current consolidated text and local competent-authority requirements rather than hard-coding a simplified “band” model.
• Trusted beneficiaries: Article 13 concerns a payee included on a payer-maintained trusted list after SCA, subject to the rule’s conditions and PSP handling.
• Recurring transactions: Article 14 applies to a series of transactions of the same amount and payee. The first transaction in the series is subject to SCA; subsequent ones may be exempt under the article. Do not assume an amount or payee change remains eligible.
• Secure corporate payment processes and other RTS cases: Applicability is narrow and depends on the exact article and payment arrangement. Do not turn a legal category into a generic “B2B exemption.”

Other exemptions exist in the RTS, including contactless point-of-sale and unattended terminals. The list above focuses on common online card discussions; it is not a complete catalogue. For every route, identify which PSP is applying the exemption and whether it is legally available for that payment.

Exemption request does not mean exemption granted

An exemption request is not a promise of frictionless authentication or authorization. The issuer may require SCA, and an issuer may decline a payment for unrelated reasons. Keep these outcomes distinct in data and reporting:

1. transaction was eligible under the rule the PSP applied;
2. an exemption was requested or applied by the relevant PSP;
3. the issuer accepted, rejected, or overrode the request;
4. authentication outcome, if any;
5. authorization outcome and final payment state.

The RTS places obligations on the PSP, including transaction monitoring and risk assessment. Merchants should obtain the acquirer’s exact supported flags, response codes, data requirements, and fallback behavior. Avoid claiming a fixed frictionless rate, authorization uplift, or guaranteed recovery from using an exemption; outcomes depend on issuer decisions, merchant mix, data quality, fraud performance, and integration.

MITs and stored credentials

A recurring renewal, an unscheduled credential-on-file charge, and a customer returning to use a saved card are not interchangeable transaction types. The initial customer-initiated interaction establishes the stored-credential relationship and any required authentication/consent. Later transactions need the correct scheme and processor indicators, original transaction references where required, and a documented contractual basis. Applicable SCA treatment should be confirmed with the acquirer and legal team; do not use an MIT indicator to bypass authentication on a payer-initiated checkout.

Build a state model for mandate/consent creation, credential storage, subsequent charge, customer cancellation, credential update, retry, and revocation. See recurring card payment lifecycle for the operational flow. Provider parameter names differ; follow the integration documentation for each route.

Implementation checklist

• Maintain a country/transaction matrix describing SCA scope, available exemption, legal condition, applying PSP, message flag, issuer response, and fallback.
• Store the customer agreement and evidence needed to support a recurring or MIT relationship; version the terms shown and record the initial authenticated transaction reference where applicable.
• Make the issuer’s result visible to the order state machine. Do not infer approval from an exemption request or authentication result.
• For TRA, monitor the applicable fraud-rate methodology, thresholds, windows, and cessation/reporting obligations; escalate before the allowed conditions are breached.
• For low-value, rely on the PSP’s applicable counter and define what happens when it declines the exemption or requires SCA.
• For a changed amount, payee, stored credential, or payment purpose, re-evaluate eligibility rather than carrying forward the old treatment.
• Test issuer override, step-up, soft decline, unavailable authentication, expired consent, and duplicate retry scenarios.
• Revalidate the rules when legislation, scheme rules, acquirer configuration, or the processor integration changes.

Worked example

A subscription service takes an initial monthly payment through a payer-initiated checkout. The service records the agreement, amount/currency basis, payment reference, authentication result, and stored-credential identifier returned by its provider. Before each renewal, it checks that the agreement is active and that the amount/payee treatment remains within the applicable recurring and scheme rules. It sends the correct subsequent-payment indicator and handles the issuer response. If the price changes or the customer cancels, the system re-evaluates the flow and stops future charges as required by the agreement and applicable law. The example does not establish eligibility for any particular merchant; legal and acquirer review is necessary.

For the protocol mechanics, see EMV 3-D Secure flows. For the primary rule text, consult the live EU RTS and applicable supervisory guidance. This is not legal advice.