
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 (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. There are four categories of activity: (a) out of scope entirely (often a matter of interpreting the 'perimeter'); (b) in-scope but benefiting from an exclusion (often with conditions, including registration); and (c) in-scope but carried out by people or entities who are not required to be authorised or registered; and (d) in-scope and requiring the service provider to be authorised/registered or appointed/registered as the agent of a firm with the right authorisation.
In this post, I'll skip what would be out of scope.
Activities in-scope but benefiting from an exclusion (often with conditions).
- 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.
- Technical service providers: the definition of ‘technical service provider’ has shortened but is effectively the same or potentially broader than being purely about technology or data processing ("a provider of services which, although not being payment services, support the provision of payment services, without entering at any time into possession of the funds to be transferred"), but, among other conditions, they will have liability for direct financial damage up to the value of each affected transaction for any failure to support the application of 'strong customer authentication' (multi-factor authentication) and any PSP of the payer who relies on a technical service provider to 'provide and verify' the elements of SCA will need to have an outsourcing agreement in place (which triggers other provisions and the EBA outsourcing guidelines). The competent regulator will be in the Member State in which the technical service is provided. Technical services offered jointly with payment services must also be subject to the restrictions on termination fees for the related payment services.
- Limited networks: there are still 3 classes of potential limited network, but the preamble is clarified to include 'electronic money-based instruments', which is apt to confuse; those limited to 'premises' include both physical and online stores; and those that can only be used for a very limited range of goods or services can include payment service users who are not consumers. It is also clarified that public sector instruments cannot be redeemable for cash. The reference to e-money in this context, and the exclusion of redemption for cash
- 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; and
- 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.
Activities in-scope but carried out by people not required to be authorised or registered
- Operators of payment systems and payment schemes: a 'payment system' means "a funds transfer system with formal and standardised arrangements and common rules for the processing, clearing or settlement of payment transactions", while a 'payment scheme' is not otherwise defined but a recital clarifies this to 'typically include four-party card schemes' (or what the Americans refer to as 'networks'), e.g. Visa and Mastercard - and 'payment card scheme' (along with 'processing entity') is defined by reference to the Interchange Fee Regulation. There is wording in the PSR to suggest that the term 'payment system' may be intended to cover 'payment scheme' in certain respects, but without duplicating the regulation of systemically important payment schemes. A 'payment system operator' is of course the legal entity legally responsible for operating the payment system. Essentially, regulated PSPs must have fair access to payment systems; and payment systems, payment schemes and processing entities are given specific rights to process personal data. Payment card schemes and processing entities must be transparent on fees 'imposed on' PSPs providing acquiring services.
- original manufacturers of mobile devices and electronic communication service providers: must grant fair access to PSPs and technical service providers acting on their behalf.
- Providers of electronic communication services and very large online platforms/search engines: must establish anti-fraud communication channels, educational measures and alerts. This also includes exchanging information with 'providers of hosting services' who may be subject to direct obligations in due course, if the Commission determines that is necessary.
- Currency conversion: the PSRs continue the requirement that payment transactions must occur in the currency agreed between the "parties" (conflating the contract of sale/supply of goods/services with the payment transaction itself). This covers scenarios where, for instance, a cardholder is offered a choice to pay for an item in a different currency to that of their card ('dynamic currency conversion') or the merchant quotes a price on its website in one or more different currencies to the normal currency in which prices are quoted ('price conversion'). In such cases, all charges and the exchange rate to be used for converting the payment transaction must be disclosed to the payer as both a monetary amount and as a percentage mark-up over an "aggregated mid-market exchange rate" provided by "a trusted administrator who meets applicable governance and control requirements, such as the IOSCO Principles for Financial Benchmarks". Some foreign exchange operators offer the merchant a 'spread' on these FX transactions.
Activities in-scope and requiring authorisation etc
- 'electronic money': this no longer includes "as represented by a claim on the issuer"
‘electronic money’ means electronically, including magnetically, stored monetary value as represented by a claim on the issuer which is issued on the receipt of funds for the purpose of making payment transactions and which is accepted by other natural or legal persons than the issuer;
There is no mention of the misunderstanding as to the meaning of "and which is accepted by other natural or legal persons than the issuer" that was sparked by an ECJ's preliminary ruling in February 2024, picked up in an EBA Q&A in January 2025 (and since then by the Central Bank of Ireland). As explained at length, the better interpretation is that e-money is stored monetary value issued for the purpose of enabling the e-money holder to pay an intended third party (such as a merchant), as the 'payee' - rather than the payee actually having to receive the actual stored monetary value directly.
The definition of 'funds' continues to include e-money and will extend to 'e-money tokens'.
- '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' (AIS): this definition is different to PSD2 and 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'). In a chain scenario, this would seem to mean that both entities in the chain will need to be authorised to provide an AIS - the entity that accesses the payment account(s) to transmit the data, and the other entity that actually provides the data to the payment service user. Under PSD2, there have been several ways for the intermediate entity to avoid the need for authorisation.
Where this leaves the situation where the AISP is being asked to send the data to, say, a lender with the payment service user's permission is not clear. 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.
Operational issues
- Strong customer authentication: definitions of "merchant initiated transactions" and "mail order, telephone order" transactions have been introduced for the purpose of clarifying how and when SCA should be applied.
- Currency conversion: the currency conversion charges for credit transfers and remittances will need to be expressed consistently as both a monetary amount in the currency of the payer’s account and as a percentage mark-up over an "aggregated mid-market exchange rate" provided by "a trusted administrator who meets applicable governance and control requirements, such as the IOSCO Principles for Financial Benchmarks" using the "same reference benchmark consistently and for exchanges made in both directions." References to ‘charges’ should also be read to cover currency conversion charges.
- Periodic penalty payments: regulators may impose a daily fine to be paid until compliance is restored for up to 6 months of at least 3% of the average daily turnover (annual divided by 365) for a legal entity and €30k for a natural person, though member states can increase these amounts.
- derogation for low value instruments: the threshold has doubled to €300 for these instruments generally, but remains at €500 for prepaid.
- where the payee's payment service provider is located outside the EEA, the estimated time for the funds of credit transfers and money remittance transactions to be received by the payee's payment service provider.
- as now, after receiving a payment order, a payer's PSP must provide/make available certain information, but information on the payee has been strengthened to include "the information needed for the payer to unambiguously identify the payee, including the payee’s commercial trade name and, where available to the payment service provider and if different from the commercial trade name, the payee’s legal name".
- among the information to be included in the framework contract (service agreement) in relation to payment instruments is "the length of a delay for any resulting increase in spending limits to come into effect and description of how the payment service user can modify the spending limits and adjust or opt out of the application of a delay period."
- the period in which a consumer can terminate without charge is reduced from 6 to 3 months.
- the notice period for the PSP to terminate an open-ended framework contract is increased from 2 to 3 months.
- the 'corporate opt-out' remains, but of course the regulatory references will change for contracts that include that opt-out now.
- there are extensive transparency requirements relating to charges by payment card schemes, processing entities and acquirers (as customers of payment schemes).
- the PSRs incorporate provisions dealing with 'open banking' interfaces for account information and payment initiation service providers, including availability and performance requirements.
...to be continued...