> ## Content Index
> Fetch the complete content index at: https://transactionintelligence.net/llms.txt
> Use this file to discover other available public pages before exploring further.

# SCA gets a promotion
- URL: https://transactionintelligence.net/sca-gets-a-promotion/
- Published: 2026-09-08T05:45:23.000Z
- Updated: 2026-09-08T05:45:22.000Z
- Description: Strong Consumer Authentication is being moved into a directly applicable regulation, not just amended. Your transition plan needs to separate what the text specifies, what waits on the EBA, and what it assumes about the handover. The law leaves that last part implicit.
- Author: Matt Berryman
- Tags: Regulatory, Payments, #psr, #psd-3, #psd-2, #rts-sca, #eba-opinion, #eidas-2, #cjeu

Somewhere in your compliance plan there is a sentence that reads, roughly, "the existing RTS on SCA continues to apply until the EBA's replacement standards are adopted." It's a reasonable sentence, and the Commission wrote a version of it into the explanatory memorandum to the 2023 proposal. I went looking for it in the two compromise texts the Council published in April and it isn't in either of them.

That gap is the best way into this, because it exposes what most of the commentary has skipped past. SCA is not merely being amended. It is being moved, and the move changes more than any individual edit travelling with it. If you are planning the transition, the distinction that matters is between what the compromise text already specifies, what depends on technical standards the EBA has not yet drafted, and what your plan is assuming about the handover between the two. Those three need different treatment, and reading them as one SCA workstream hides which work you can start now and which you can only watch.

I have set out every provision discussed below, with its current address, its proposed address and what changed in between, as [the SCA relocation map](https://paymentslaw.eu/psd3-psr-transition/sca/?ref=transactionintelligence.net) on **paymentslaw.eu**. Keep it open alongside this if you want to follow the sources. It is, in effect, the SCA slice of the correlation table the compromise texts leave blank. What follows is what those changes mean for the decisions in an SCA programme.

## Where it lives today, and where it is going

Today SCA lives in three places: the obligation in [Article 97 of PSD2](https://paymentslaw.eu/psd-2/art-97?ref=transactionintelligence.net), a directive whose requirements reach firms principally through national transposition; the detail in RTS-SCA ([Delegated Regulation 2018/389](https://eur-lex.europa.eu/eli/reg%5Fdel/2018/389/2023-09-12/eng?ref=transactionintelligence.net)), directly applicable but drawing its authority from [PSD2 Article 98](https://paymentslaw.eu/psd-2/art-98?ref=transactionintelligence.net); and the interpretation in a decade of EBA Opinions and Q&As.

Under the package the obligation moves into [Article 85 of the PSR](https://paymentslaw.eu/psr/art-85?ref=transactionintelligence.net), a regulation, and direct applicability removes national transposition as a layer between the obligation and your firm. That is a narrower promise than it sounds. PSD2 was already full-harmonisation, most of the technical detail already sat in a directly applicable RTS, and nothing about a regulation stops one supervisor reading a sentence differently from another. What you lose is textual divergence. Interpretive divergence stays exactly where it is. PSD3 keeps the directive form for authorisation, and [Article 48](https://paymentslaw.eu/psd-3/art-48?ref=transactionintelligence.net) repeals PSD2 twenty-one months after entry into force.

If you implement SCA rather than litigate it, the relocation is the event. Everything else here is an edit to a system that has been picked up and set down on different legal ground.

## What moved up a level

What struck me most, reading the two texts side by side, is how much content climbed out of the RTS, or out of guidance, and into the legislative act on the way across.

The exemption criteria sat in [PSD2 Article 98(3)](https://paymentslaw.eu/psd-2/art-98?ref=transactionintelligence.net) as instructions to the EBA. Under the PSR they sit in [Article 85(11)](https://paymentslaw.eu/psr/art-85?ref=transactionintelligence.net) as part of the obligation itself, gaining a transaction-monitoring criterion and a consumer/non-consumer split. That same paragraph states exemptions are never mandatory, a principle that was implicit in the RTS and explicit only in EBA guidance, and it is now in the legislative act. The category rule follows the same path. That your elements must come from different categories was EBA interpretation, with [RTS Article 9](https://paymentslaw.eu/rts-sca/art-9?ref=transactionintelligence.net) supplying the technical safeguards, and [Article 85(12)](https://paymentslaw.eu/psr/art-85?ref=transactionintelligence.net) now makes it express, subject to a conditional exception for two inherence elements that I have [written about separately](https://transactionintelligence.net/when-something-you-are-becomes-something-they-can-make/) and will not reopen here. And merchant-initiated and mail-or-telephone-order transactions, never defined in EU payments legislation and the source of more exemption arguments than any other gap, get definitions in [Article 3](https://paymentslaw.eu/psr/art-3?ref=transactionintelligence.net), with their SCA treatment in [Article 85(2), (5) and (7)](https://paymentslaw.eu/psr/art-85?ref=transactionintelligence.net).

An RTS can be changed by the Commission on the EBA's draft, whereas Article 85 can only be changed by the co-legislators (the [primer on the four levels](https://transactionintelligence.net/lamfalussy-primer/) explains why that matters). The move locks these rules in a way the RTS never did. You gain certainty about the triggers, and you lose the ability to fix them quickly if they turn out to be wrong.

## What reopens

Everything that stays at the delegated level reopens. [Article 89](https://paymentslaw.eu/psr/art-89?ref=transactionintelligence.net) instructs the EBA to draft new technical standards covering SCA itself, the exemptions, credential protection, open-banking communication, and, more explicitly than in 2018, outsourcing agreements under [Article 87](https://paymentslaw.eu/psr/art-87?ref=transactionintelligence.net) and transaction monitoring.

The drafts are due twelve months after entry into force. The Commission then decides whether to adopt them, Parliament and Council scrutinise, and the Official Journal publishes. For all of that to finish before [Article 85 applies at twenty-one months](https://paymentslaw.eu/psr/art-112?ref=transactionintelligence.net), the process has nine months, against a February 2017 to March 2018 precedent for the same steps. Achievable, not comfortable, and nothing in the text requires it.

Every exemption you rely on today is drafted into that reopening: contactless and low-value thresholds, trusted beneficiaries, the corporate exemption, the TRA fraud-rate bands. [Article 89(3)](https://paymentslaw.eu/psr/art-89?ref=transactionintelligence.net) also adds the European Digital Identity Wallet, which [eIDAS Article 5f(2)](https://paymentslaw.eu/eidas/art-5f/?ref=transactionintelligence.net) will require qualifying PSPs acting as private relying parties, other than micro and small enterprises, to accept on the user's voluntary request where strong user authentication is required for online identification. None of this is hidden. It is where your implementation work will concentrate once the EBA consults.

## The transition the law does not spell out

Now back to that sentence in your compliance plan.

The PSR applies from twenty-one months after entry into force ([Article 112](https://paymentslaw.eu/psr/art-112?ref=transactionintelligence.net)), and [PSD3 repeals PSD2](https://paymentslaw.eu/psd-3/art-48?ref=transactionintelligence.net) the same date. Both texts say references to PSD2 elsewhere in force shall be construed as references to PSD3 or the PSR ([PSD3 Article 48](https://paymentslaw.eu/psd-3/art-48?ref=transactionintelligence.net); [PSR Article 111](https://paymentslaw.eu/psr/art-111?ref=transactionintelligence.net)). Delegated Regulation 2018/389 is such a legal act, and its [Article 1](https://paymentslaw.eu/rts-sca/art-1?ref=transactionintelligence.net) points at PSD2 Article 97, so the clauses could support continuity. So could general doctrine: implementing measures can survive repeal of their basic act where the successor provision and procedure correspond, and [Article 89](https://paymentslaw.eu/psr/art-89?ref=transactionintelligence.net) does succeed [PSD2 Article 98](https://paymentslaw.eu/psd-2/art-98?ref=transactionintelligence.net) through the same [EBA-and-Commission procedure](https://paymentslaw.eu/eba-regulation/art-10?ref=transactionintelligence.net), whose founding regulation says revoking a delegation leaves [standards already in force](https://paymentslaw.eu/eba-regulation/art-12?ref=transactionintelligence.net) untouched. What none of this supplies is an express rule: no saving clause for the 2018 RTS, no rule for where it conflicts with the new articles, no handover date. The correlation tables both clauses point to are absent from these compromise documents: Annex I of ST-8221-2026-INIT is a heading over an empty page, Annex III of ST-8222-2026-INIT is not in the document at all.

Contrast PSD2, where [Article 115(4)](https://paymentslaw.eu/psd-2/art-115?ref=transactionintelligence.net) delayed Article 97 until eighteen months after the RTS entered into force, which is why SCA landed in September 2019 rather than January 2018\. The PSR has no equivalent: [Article 85](https://paymentslaw.eu/psr/art-85?ref=transactionintelligence.net) applies on the [general date](https://paymentslaw.eu/psr/art-112?ref=transactionintelligence.net) whether or not new standards exist.

The intent is not in doubt. The Commission's 2023 explanatory memorandum says the EBA may amend existing standards and that, if it does not, they will remain in force. But a memorandum isn't binding, and other repeal-and-replace regulations preserve their earlier delegated acts in an operative saving clause, which makes this silence harder to explain away rather than easier. Continuity therefore rests on stated intent, reference conversion and doctrine. What remains open is which old provisions survive a conflict with the PSR, how references map without the tables, and when the replacement standards take over. A plan that does not say which of those three it has assumed an answer to is carrying a dependency it has not priced.

## What rides along

Several obligations make the journey without a PSD2 ancestor at all, and these are the ones most likely to land on your backlog. [Article 88](https://paymentslaw.eu/psr/art-88?ref=transactionintelligence.net) requires PSPs to provide, free of charge, an SCA means adapted to each customer's situation, including disability, age, low digital skills or lack of access to digital channels. Unless the user has agreed to mobile-only services, your SCA may not depend on possession of a smartphone. [Article 87](https://paymentslaw.eu/psr/art-87?ref=transactionintelligence.net) requires the payer's PSP to enter an outsourcing agreement with any technical service provider that both provides and verifies SCA elements, aimed by the recitals at pass-through wallets, and [Article 58](https://paymentslaw.eu/psr/art-58?ref=transactionintelligence.net) makes technical service providers and payment-scheme operators liable to the payee or either PSP for direct financial damage, proportionate to a failure within their contractual remit to provide the services necessary for SCA and capped at the transaction amount. A bounded liability, but one PSD2 did not itself impose.

Mobile teams should note [Article 51(4a) and (4b)](https://paymentslaw.eu/psr/art-51?ref=transactionintelligence.net): SCA plus a separate channel to activate an app that can initiate or consent to payments, and a four-hour delay on remote activation, which the user may adjust or opt out of, though any such change made while a delay is running is itself delayed. Onboarding and in-branch activation are excepted under 51(4e). And [Article 60(2)](https://paymentslaw.eu/psr/art-60?ref=transactionintelligence.net) extends the no-payer-loss rule to cases where either PSP applied an exemption, with the payee's PSP liable to the payer's PSP where it applied the exemption ([Article 60(3)](https://paymentslaw.eu/psr/art-60?ref=transactionintelligence.net)).

## What carries over unchanged

The list of what did not move is longer than the noise around this package suggests: the definition of SCA, dynamic linking, credential confidentiality, third-party reliance on the bank's authentication, the fifty-euro cap. The triggers in [Article 85(1)(a) and (c)](https://paymentslaw.eu/psr/art-85?ref=transactionintelligence.net) restate [Article 97(1)(a) and (b)](https://paymentslaw.eu/psd-2/art-97?ref=transactionintelligence.net), with one verb change, "places a payment order" for "initiates," aligning the trigger with the new MIT and MOTO definitions. One change is easy to miss, and I nearly did. [PSD2 Article 72(1)](https://paymentslaw.eu/psd-2/art-72?ref=transactionintelligence.net) required you to prove a disputed transaction was authenticated. [PSR Article 55(1)](https://paymentslaw.eu/psr/art-55?ref=transactionintelligence.net) requires you to prove it was authorised. The core of SCA is stable. It's the plumbing around it that has moved.

One anomaly rides ahead of the rest. [Article 85a](https://paymentslaw.eu/psr/art-85a?ref=transactionintelligence.net), the recurring-credit-transfer derogation, applies from entry into force rather than the general date. I covered it in the first essay \[LINK: Three numbers that no longer exist\], and it is the only SCA provision that will bind at entry into force rather than on the general application date. The note on 15 September maps every EBA deadline the package sets.

## What I would change in the plan

Three things, one for each of the categories I set out at the start.

**For what the compromise text already specifies**, run a gap assessment against the agreed wording now, and treat the eventually adopted text as a review point rather than a reason to wait. For each provision that touches you, write down the customer journey, the system or the contract it lands on, and who owns assessing it. The named triggers in [Article 85(1)(d)](https://paymentslaw.eu/psr/art-85?ref=transactionintelligence.net), the AISP obligation in Article 86(4), the outsourcing agreement in Article 87, the accessible SCA means in Article 88 and the app-activation rules in Article 51 are all specified well enough to assess today. Nothing about them depends on the EBA.

**For what depends on the replacement standards**, record which of your implementation choices rest on detail that is inside the [Article 89](https://paymentslaw.eu/psr/art-89?ref=transactionintelligence.net) mandate. Every exemption in the current RTS is, and so is the TRA regime, including the issuer-and-acquirer fraud-rate allocation the mandate now specifies. Being inside the mandate does not mean a threshold will change. It means a design decision may need revisiting, and you want that dependency visible before you commit to work that assumes the existing detail carries over unchanged.

**For the handover**, write down the basis on which the programme expects the 2018 RTS to operate between application of the PSR and adoption of its replacement, including any provision you can see conflicting with the new articles. That assumption needs an owner, and it needs a review trigger: a change in the adopted text, publication of the replacement standards, or an official clarification of the kind the compromise texts do not currently contain.

These are the questions I would take into the next planning meeting. They let you explain why one piece of work can proceed while another is waiting on something still to come, which is the distinction a single undifferentiated SCA workstream cannot make.

## What comes next

The trust triangle, the issuer, the merchant and the cardholder held together by a protocol, was built to satisfy [Article 97](https://paymentslaw.eu/psd-2/art-97?ref=transactionintelligence.net) as the [RTS](https://paymentslaw.eu/rts-sca?ref=transactionintelligence.net) specified it. On 22 September the next essay asks what happens to that triangle when the rulebook it was built against gets promoted into the PSR: which parts of EMV 3-D Secure were answering the RTS rather than the directive, and which of those answers the PSR will accept without renegotiation.

## Sign up for Transaction Intelligence

Independent essays on payments, behaviour and the quiet plumbing of finance.

Subscribe 

Email sent! Check your inbox to complete your signup. 

No spam. Unsubscribe anytime.