Strong customer authentication boundaries and SEPA Instant Credit Transfers under Regulation (EU) 2024/886

1. Introduction

Account-to-account payments initiated through a third party have moved from a regulatory novelty in 2018 to a routine payment method for e-commerce, subscriptions and business payouts across northern Europe. Their operational profile, however, is still poorly understood outside specialist teams. Product discussions tend to compare providers on conversion or user interface, while the parameters that actually determine success rates, settlement times and liability are set by regulation and by the payer's bank.

Two regulatory developments make a fresh analysis necessary. First, the RTS on strong customer authentication and common and secure open standards of communication have now been in application long enough for national supervisors and the European Banking Authority to have clarified most interpretive questions, including the allocation of responsibility for exemptions. Second, Regulation (EU) 2024/886 has made instant euro credit transfers a mandatory offering for payment service providers in the euro area, with staged deadlines for the rest of the Union, and has introduced verification of payee and a new model of sanctions screening.

This paper is structured as follows. Section 2 sets out the regulatory perimeter. Section 3 analyses the boundaries of strong customer authentication in payment initiation. Section 4 analyses the SEPA Instant Credit Transfer scheme and the obligations added by Regulation (EU) 2024/886. Section 5 describes the clearing infrastructure. Section 6 discusses interface standardisation through the Berlin Group NextGenPSD2 framework. Section 7 draws implementation conclusions for corporate integrators, and Section 8 states the limitations of the analysis.

2. The regulatory perimeter

PSD2 defines payment initiation services as services that initiate a payment order at the request of the payment service user with respect to a payment account held at another payment service provider. Article 66 gives payers the right to use such a service where the account is accessible online, and obliges the account servicing payment service provider (ASPSP) to treat orders transmitted through it without discrimination, other than for objective reasons.

Article 97 requires strong customer authentication where the payer accesses its payment account online, initiates an electronic payment transaction, or carries out any action through a remote channel which may imply a risk of payment fraud or other abuses. For remote electronic payment transactions, authentication must include elements that dynamically link the transaction to a specific amount and a specific payee.

The RTS give these obligations operational content. Articles 4 to 9 define the authentication code, dynamic linking and the independence of the authentication elements. Articles 10 to 18 set out exemptions. Articles 30 to 36 establish the common and secure open standards of communication, including the dedicated interface through which third-party providers access accounts, the contingency mechanism and the identification of providers by means of qualified certificates under the eIDAS Regulation.

Regulation (EU) 2024/886 operates on a different instrument: it amends Regulation (EU) No 260/2012 (the SEPA Regulation) and, in parts, PSD2 and the Settlement Finality Directive. It does not alter the RTS, but it changes the environment in which an initiated payment is executed. The proposals for a third Payment Services Directive and a Payment Services Regulation, published by the European Commission in June 2023, would further revise the open-banking regime; readers should verify their current legislative status before relying on any provision.

3. Boundaries of strong customer authentication in payment initiation

Strong customer authentication requires two or more elements from the categories of knowledge, possession and inherence, which must be independent so that the breach of one does not compromise the others. In the Nordic markets these elements are delivered almost entirely through bank-issued or bank-federated electronic identities: BankID in Sweden and Norway, MitID in Denmark, and the bank identifiers of the Finnish Trust Network in Finland. In Poland, banks rely primarily on their own mobile applications.

The first boundary concerns who performs authentication. In a payment initiated through a third party, the personalised security credentials are issued by the ASPSP, and it is the ASPSP that authenticates the payer. The initiating provider transmits the payment order and the information needed for authentication, but it does not decide whether strong customer authentication is applied. In particular, the decision whether to apply an exemption rests with the payment service provider that issues the credentials. An integrator cannot therefore design a flow on the assumption that a low-value or trusted-beneficiary exemption will be granted.

The second boundary concerns dynamic linking. Because the authentication code must be specific to the amount and the payee, any change to either after authentication invalidates the authorisation. This has practical consequences for flows in which the final amount is determined after the payer has confirmed, for example where fees or currency conversion are applied late. Such flows require either a new authentication or a different payment construction.

The third boundary concerns the authentication approach chosen by the bank. Under the redirect approach, the payer is sent to the bank's own environment. Under the decoupled approach, authentication takes place on a separate device or application, typically a banking app. Under the embedded approach, the credentials are entered through the third party's interface and passed to the bank. Article 32 of the RTS prohibits dedicated interfaces from creating obstacles to payment initiation, but it does not prescribe a single approach, and supervisors have assessed obstacles case by case. As a result, the same initiated payment can involve a materially different number of steps depending on the payer's bank.

Exemptions most relevant to corporate flows (RTS)

• Article 13 — trusted beneficiaries: a payer may add a payee to a list held by its bank; the bank decides whether to apply the exemption to later payments.
• Article 14 — recurring transactions: series of transactions with the same amount and payee require authentication only for the first.
• Article 15 — credit transfers between accounts held by the same natural or legal person at the same provider.
• Article 16 — low-value remote transactions: up to EUR 30, subject to cumulative limits of EUR 100 or five consecutive transactions since the last authentication.
• Article 17 — secure corporate payment processes: dedicated processes available only to non-consumer payers, where the competent authority is satisfied that they guarantee equivalent security.
• Article 18 — transaction risk analysis: available when the provider's fraud rate stays below reference rates; for remote credit transfers these are 0.015% up to EUR 100, 0.01% up to EUR 250 and 0.005% up to EUR 500.

For corporate integrators the Article 17 exemption deserves attention because it is frequently confused with general business-to-business use. It applies only to dedicated corporate processes and protocols, such as host-to-host connections, and requires the competent authority's satisfaction. It does not apply to a business payer that simply uses consumer-style online banking.

4. SEPA Instant Credit Transfers and Regulation (EU) 2024/886

The SCT Inst scheme of the European Payments Council has been available since November 2017. Until 2024 participation was voluntary, and reachability varied widely between countries and between banks. Regulation (EU) 2024/886 changes the scheme's position from optional to mandatory for providers that offer standard credit transfers in euro.

The regulation defines an instant credit transfer as one executed immediately, 24 hours a day and on any calendar day, and requires the payee's provider to make the funds available within ten seconds of receiving the payment order. Charges for instant transfers may not exceed charges for the corresponding standard transfer. Payment accounts must remain reachable at all times.

Verification of payee is the most visible new obligation for end users. Before the payer authorises a credit transfer, its provider must check whether the payee name matches the IBAN and report the result, including a close match or no match. The obligation applies to instant and standard transfers alike, regardless of channel. When a payment is initiated through a payment initiation service provider, the account servicing provider is not required to perform the check; instead the initiating provider must ensure that the payee information is correct. Non-consumers may opt out only when submitting multiple payment orders as a package.

The regulation also replaces transaction-level sanctions screening for instant payments with an obligation on providers to verify, at least daily and immediately after new or amended measures take effect, whether their own customers are subject to EU targeted financial restrictive measures. This removes a source of latency that had previously made ten-second execution difficult.

For non-euro Member States, the regulation provides later deadlines and a temporary derogation: a national authority may allow providers to limit instant euro transfers from accounts in national currency above a per-transaction limit of not less than EUR 25,000, for renewable one-year periods. Until 9 June 2028, providers in non-euro Member States are not required to offer instant transfers in their national currency on the same conditions. This is directly relevant to Swedish, Danish and Polish flows, which typically settle in domestic currency over national systems.

5. Clearing and settlement infrastructure

Two pan-European infrastructures process SCT Inst transactions. TARGET Instant Payment Settlement (TIPS), operated by the Eurosystem since November 2018, settles instant payments in central bank money on a gross basis. RT1, operated by EBA CLEARING since November 2017, provides a pan-European instant payment system for participating banks. To avoid fragmentation, the Eurosystem adopted measures in 2020 to ensure that providers adhering to SCT Inst and reachable in another clearing system are also reachable through TIPS.

Regulation (EU) 2024/886 also amends the Settlement Finality Directive so that payment institutions and electronic money institutions can participate in designated payment systems, and amends PSD2 so that such institutions may safeguard client funds in a central bank account at the central bank's discretion. Over time this may reduce the dependence of non-bank providers on sponsor banks for access to instant rails.

From the integrator's perspective, the rail determines finality. A payment initiated through an open-banking interface and executed as SCT Inst is final when the payee's provider confirms it within the scheme timeline. A payment executed as a standard SEPA Credit Transfer follows batch cycles, and a payment in Swedish kronor, Danish kroner, Norwegian kroner or Polish zloty follows the rules of the relevant domestic system. Confirmation messages from an initiating provider should therefore be read in light of which rail was actually used.

6. Interface standardisation: Berlin Group NextGenPSD2 XS2A

The RTS require ASPSPs to offer at least one interface for third-party access but do not mandate a technical standard. The Berlin Group NextGenPSD2 Access to Account (XS2A) framework has become the most widely adopted specification in continental Europe and is used by many Nordic and Polish banks, alongside national adaptations and proprietary APIs. In Poland, the PolishAPI standard developed by the national banking sector is also in use.

The XS2A framework defines services for account information, payment initiation and confirmation of funds, and supports the redirect, OAuth2-based, decoupled and embedded authentication approaches. Third-party providers identify themselves to banks using qualified website authentication certificates and, where used, qualified electronic seal certificates under the eIDAS Regulation, as required by Article 34 of the RTS.

Standardisation at the specification level does not guarantee uniform behaviour. Implementation options, optional fields, supported payment products and error semantics vary. An initiating provider's coverage claim ("connects to N banks") is therefore less informative than the distribution of authentication approaches, supported payment products and observed availability across the banks that matter to a specific merchant base.

7. Implementation implications for corporate integrators

• Map each target bank's authentication approach before estimating conversion; redirect and decoupled flows produce different user journeys.
• Design flows so that amount and payee are final before the payer authenticates; late changes break dynamic linking.
• Do not depend on exemptions. Treat any exemption granted by the payer's bank as an improvement, not as a baseline.
• Record which settlement rail was used for each payment and distinguish scheme-level finality from provider-level confirmation.
• Confirm how the initiating provider meets its verification-of-payee duty, and how name mismatches are surfaced.
• Plan refunds and payouts as new credit transfers, with references that allow automatic reconciliation.
• For Swedish, Danish, Norwegian and Polish flows, analyse the domestic instant system separately from SCT Inst.

8. Limitations

This paper describes the regulatory framework at the date of its last review and does not constitute legal advice. National transposition, supervisory guidance and scheme rulebooks change, and the proposed revision of PSD2 may alter the allocation of responsibilities described here. Vendor-specific observations are limited to publicly available information and are presented separately in the infrastructure ledger.