Search This Blog

Thursday, 30 April 2026

It's... PSD3 Time! Well, Almost...

Another year and another update on the third Payment Services Directive (PSD3) and its sister Payment Services Regulation (PSR). For evolutionary fans, I last summarised the content in detail in 2023, with an update last June. I'm working through a fresh update here, calling out any differences that I see as significant versus PSD2. I'm through the PSD3 directive and the main exclusions in the PSR. Timing wise, of course PSD3 will need to be implemented in each EEA member state (as with PSD2/EMD2) while the PSR will have direct effect. Both will apply together from some time in 2027/28 (18 months from publication in the Official Journal). There are various additional transition periods for existing payment/e-money institutions and those benefitting from exclusions/exemptions. This post is for information purposes. If you'd like legal advice, please let me know (or via Crowley Millar in Ireland, as this would be EU-related work).

In very broad terms, PSD3/PSR merges the e-money and payment services frameworks and:

  • improves non-bank payment service providers' access to payment systems and bank accounts
  • better facilitates 'open-banking' and consumer control
  • enhances enforcement powers
  • improves consumer information, rights and access to cash via retail shops and ATMs

There are really no newly regulated payment services, although "issuance of electronic money" is now called out and consolidated under the PSD (though I'm not yet clear on whether that includes directly related payment services, as opposed to those you might operate separately from your e-money features).

Changes introduced by PSD3

Annoyingly, the definitions are split between PSD/PSR with some tweaks. Most definitions are in the PSR, so the PSD cross-refers to those and so will all the national implementing regulations. However, the PSD does have a few definitions of its own, including:

  • "execution of a payment transaction" is now a thing in the PSD, apparently to differentiate it from a 'payment initiation service':
'execution of a payment transaction’ means the process starting once the initiation of a payment transaction is completed and ending once the funds placed, withdrawn, or transferred are available to the payee; 

  • the concept of ‘agent’  seems to be a source of potential regulatory creep, because you might argue that a 'technical service provider' is directly involved in the payment institution's provision of payment services - but perhaps that is now a (fuzzy?) line of demarcation: 

'agent' means a natural or legal person who acts in the name and on behalf of a payment institution in providing payment services, and who either enters into possession of funds on behalf of the payment institution or is directly involved in the payment institution's provision of payment services;

currently, an “agent” is a natural or legal person who acts on behalf of a payment institution in providing payment services; as distinct from, say, a 'distributor' in the e-money world, who does not carry on any payment services activity... wither that distinction?

  • anti-forum shopping: There's a requirement to explain where your firm or related firms have sought authorisation in other EU jurisdictions, and the reason for refusal; and certain information on any prior cryptoasset service provider authorisation.
  • initial capital: increases to €150k (from €125k) for most payment services, but reduces to €250k (from €350k) for e-money issuers, but is cumulative where you offer both e-money issuance and (unrelated?) payment services. There seem to be clues to the demarcation in the ongoing capital requirements at least.
  • e-money tokens: there are some provisions to try to dovetail and not overlap with MiCAR, particularly on safeguarding.

Changes introduced by the PSR

Here's where the differences start to get tricky.

  • Commercial agents: The exclusion for commercial agents in Article 2(2)(b) appears to be narrower, in that the agreement authorising the agent to negotiate or conclude the sale or purchase of goods on behalf of either the payer or payee must also "give the commercial agent a real scope to negotiate with the payer or payee or conclude the sale or purchase of goods or services". That's consistent with how the FCA, for example, has always interpreted the existing exclusion, anyway. But the new language begs the question whether there are any specific e-commerce platforms the authorities believe are unfairly outside scope. Recital 11/Article 2(7) requires the EBA to develop guidelines to pre-empt differing interpretations, so it will be interesting to see where these end up and who has to reconfigure their offering.
  • Several new exclusions highlight scenarios that perhaps some have realised are currently considered to constitute regulated 'payment services' - namely, retail stores dispensing cash where the customer is not obliged to buy any goods or services; or 
a crypto-asset service provider intermediating between a buyer and a seller where electronic money tokens are exchanged for other electronic money tokens or for crypto-assets, as well as the exchange of electronic money tokens for funds, including electronic money tokens, or crypto-assets carried out by a crypto-asset service provider acting in its own name as buyer or seller of those electronic money tokens

The latter takes some un-picking, but even absent this exclusion (which the recital at 29a says is intended to avoid the need for dual MiCAR/PSD authorisations) some authorities might well conclude that a cryptoasset service provider doing the above is not offering a 'payment service' by way of a distinct regular occupation or business activity, but is merely facilitating the exchange as an ancillary aspect of operating a cryptoasset exchange service, for example. The difference might be that a retailer accepting e-money payments can't actually do that, even technologically speaking, without the involvement of a regulated payment service provider. At any rate, a transitional provision also exempts this activity from PSD2.

  • 'initiation of a payment transaction': there appears to be some attempt to more clearly demarcate payment initiation and payment execution (see above), but this phrase does not appear in the definition of 'payment initiation service' (which still says 'place a payment order'). This phrase replaces 'payment order' in the definition of a 'payment instrument' (although 'remote initiation..." involves a payment order placed 'via the internet' (to differentiate from a blockchain? what about a mobile network, is the assumption that even in that case the internet is involved at some point or is the use-case intended to be covered by provisions relating to 'electronic communication services'?)
  • 'account information service': now seems to catch both an interim service provider as well as the service provider who deals with the customer:
‘account information service’ means an online service where a provider, accesses one or several payment accounts held by the payment service user with one or several account servicing payment service providers that are accessible online in order to provide a service of aggregation or consolidation of payment account data to the payment service user or to transmit the data to another entity that will provide that service to the payment service user;
Recitals 26 and 54 refer to scenarios where the data is being provided to an entity providing 'another service' (e.g. lending, accounting) but the definition is not clear on that distinction - merely referring to 'another entity' and 'that service' (the only one mentioned being an 'account information service'). Under Article 43, it is up to the account servicing PSP to maintain a dashboard showing the names of AISPs and PISPs who have been granted access to your payment account and the 'purpose of the consent' to use their service (based on data provided by the AISP/PISP), so it seems that purpose should also reveal any third party service provider to which payment account data is flowing via the relevant AISP.

 ...to be continued...

No comments:

Post a Comment