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 (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.

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.

• '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...

It's... The Moment of Truth For The UK Crypto Sector

Just like "the It's man" who introduced Monty Python's Flying Circus, the UK regulation of cryptoassets has been a long time arriving but is very suddenly upon us. For existing activities to be 'grandfathered' into the regime you must apply to the Financial Conduct Authority between 30 September 2026 and 28 February 2027. Working backward, it usually takes at least 3 months to prepare an application, so you'll need to be in a position to start that process in June. Yet the FCA has only just begun consulting on its "Perimeter Guidance" on where the boundary of the new regulatory regime lies. Comments are invited by 3 June 2026 with a view to the FCA finalising its interpretation "in September"... Below's a brief summary of the consultation for information purposes. If you need advice, please get in touch via Keystone.  Of course, this follows a similar though transitional issue throughout the EU/EEA under the Markets in Cryptoassets Regulation (MiCAR) for which the application window closes on 1 July 2026. For advice on that, please get in touch via Crowley Millar.

A key challenge for everyone in the crypto space is that 'bare' cryptoassets themselves have been largely unregulated since being popularised by the launch of bitcoin in 2009 (often referred to as 'exchange tokens' or 'utility tokens'). 

But some cryptoassets might have characteristics that also make them some kind of 'traditional' regulated instrument (usually referred to as 'security tokens' and 'e-money tokens').

So any firm which is already active in the crypto sector has to be careful in approaching the FCA for authorisation to carry on a new regulated cryptoasset activity in relation to a newly defined "qualifying cryptoasset" or "qualifying stablecoin" (or in the case of safeguarding, a “relevant specified investment cryptoasset”) that it has not already been carrying on an existing regulated activity for which it should already have obtained FCA authorisation. 

The FCA even sounds a clear warning about this, as well as getting the analysis right in relation to newly regulated activities:

2.8 Persons should consider the perimeter in relation to every activity they perform and should carry out an analysis on a case-by-case basis. Whether an activity is regulated will depend on the specifics of what a person is doing and their role in the relevant arrangements, whether the activity is carried on in the UK, whether it is carried on by way of business, and whether any exclusion or exemption applies. 

2.9 Anyone carrying on activities in relation to cryptoassets must consider the legislation and guidance carefully, and ensure that they have the appropriate permission for any regulated activities they carry on, or an exclusion or exemption... 

2.10 In cryptoasset markets, some terminology is used differently and business models do not necessarily map onto traditional financial services concepts. It might not be clear whether an arrangement is inside or outside the perimeter just from its name – what is important is the substance of the activity and the role performed by the person in question, not the terminology the market participants adopt. 

2.11 Persons should also consider this proposed guidance carefully where a service includes automated, blockchain-based or decentralised features. The fact that an arrangement involves smart contracts, public blockchains or some elements of decentralisation does not determine the perimeter position or place the arrangement outside of regulation. The question remains whether there is an identifiable person whose business includes carrying on the relevant activity in the UK. In that context, depending on the activity, considerations should include whether a person operates or maintains the service, sets key parameters, controls important aspects of how it functions, and/or receives fees or some other commercial benefit from the activity. As with any perimeter question, the analysis will depend on the facts. 

2.12 Carrying on a regulated activity in breach of the general prohibition has significant consequences. Contravention of section 19 of FSMA is a criminal offence that carries a term of imprisonment of up to 2 years, an unlimited fine, or both. A breach of the general prohibition means that agreements entered into by the unauthorised person carrying on regulated activity are unenforceable. There are also consequences for anyone who’s already authorised but who does not have the correct permission for the regulated activities they intend to carry on.

The consultation paper then goes on to explain the FCA's proposed interpretation of what constitutes the regulated instruments as well as the new types of regulated activity, including when they would be considered to be conducted 'by way of business' and 'in the UK' and how the exclusions might apply, as well as how all this relates to the existing registration regime for some types of cryptoasset service provider under the money laundering regulations and the financial promotions regime.

If you need advice on such things for the UK, please get in touch via Keystone.

Of course, this follows a similar though transitional issue throughout the EU/EEA under the Markets in Cryptoassets Regulation (MiCAR) for which the application window closes on 1 July 2026. For advice on that, please get in touch via Crowley Millar.

Of Agentic Commerce, Prompt Injection and Authorised Push Payment Fraud

I've posted separately on prompt injection (among the risks associated with generative/agentic AI) and UK payment service providers' refund obligations for authorised push payment fraud (among other forms of potential redress). But I don't think I've explained the clear link between the two, and the implications for the full 'magic' of 'agentic commerce'... This post is for information purposes only. If you need legal advice (e.g. legal analysis in the context of modelling/testing the tech), please let me know.

Authorised push payment fraud (APP fraud) occurs where you are tricked into paying someone you did not intend to. As mentioned, there are limited APP fraud reimbursement requirements for payment service providers who facilitate payments using certain UK payment systems, for example, and there may be other grounds for recovering your money, initially at the expense of your payment service provider.

Agentic commerce describes a scenario where some kind of 'agentic AI' tool (or 'bot') is deployed for the purpose of enabling the automation of product search, selection, purchase and payment. Such tools may be 'native' to an open generative AI platform or made available by a retailer or retail marketplace within that platform, as the recent failure of Walmart's trial of OpenAI's Instant Checkout has demonstrated, leading OpenAI to phase out its own bot and leave the retailers to handle product selection, purchase and payment.

The challenge for guarding against APP fraud in such an automated scenario is that AI agents ultimately cannot distinguish between legitimate and adverse 'prompts', which might be inadvertently introduced either directly or indirectly via an authenticated agent by an authenticated user. 

There are innumerable ways that an adverse prompt could find its way to a user's device, and then to the AI agent, but here are some recent examples. And the prompt may cause the agent or another system or programme to behave adversely, with a fraudulent purchase and/or payment to an unintended payee being only two examples.

Of course, UK payment service providers do have obligations to guard against APP fraud, whether they are part of the reimbursement schemes or not - and even extended mandatory processing times to allow for suspect transactions to be investigated. And anyone making a payment from a UK bank or payment account will be familiar with a number of hoops to be gone through except in a limited number of own-account payments, even after multi-factor account log-in.

Where payment service providers are acting as merchant acquirers, it is likely they their acquiring agreements push the risk of fraudulent transactions, chargebacks and refund onto the merchant. But there is still the job of monitoring and managing the risk that the merchant won't be able to reimburse the payment service provider...

One challenge will be whether the adverse prompts will be able to beat the 'hoops' or trick the user into overriding them, or override them in an automated fashion. Equally, a payment service provider might argue that the consumer has lost any right of reimbursement due to 'gross negligence' in not adhering to a certain 'standard of caution' in its use of an AI agent, for example.

At any rate, the need to meet such challenges would seem to count against the full promise of a 'magically' automated agentic commerce experience... or make it potentially enormously expensive to support without necessarily knowing whether unforeseen claims might suddenly surge.

 

Buy Now Pay Later Regulation To Start In July

Finally we have a date for the extension of consumer credit protection to certain 'buy now pay later' agreements. There has been a long delayed consultation process, which I've covered on this blog, resulting in a final Policy Statement issued today. As is typical, the FCA has made a few, fairly minor, changes to the approach that it consulted on in July 2025. Firms that aren't already regulated will be able to register for temporary permission between 15 May 2026 and 1 July 2026, and will have 6 months from 15 July to apply for full authorisation. If you need advice on the new regime, including whether you fall into it, please let me know. 

Broadly, BNPL is interest-free credit for a consumer's purchase of goods or services that is repayable within 12 months in no more than 12 instalments. This has benefited from an exemption from consumer credit regulation that the government has now limited to situations where the retailer or merchant ("supplier") is providing the credit directly to the customer. This means that such agreements will be regulated where a third party lender is involved ("deferred payment credit" or "DPC"). 

That market for DPC is already highly concentrated: three firms account for over 90% of the volume. But by regulating the product, the FCA thinks that other regulated firms might now offer it. I doubt it, but I suppose any unregulated firm that chooses to become regulated in order to offer DPC might decide to offer other types of regulated consumer credit.

Unlike with other forms of consumer credit (including various "exempt agreements" that do not include BNPL), the supplier will not need to be authorised as a credit broker in order to introduce the consumer to a DPC lender.

Ultimately, this is intended to benefit consumers. The FCA wants them to have fewer late payments to be treated better treatment when in financial difficulty. That means information to help them understand the risks of "deferred payment credit" as well as their rights, obligations and the protection available. This means they should have a better chance of being able to afford what they borrow, miss fewer repayments and be charged fewer late fees. Lenders should also end up being more supportive where the borrower encounters financial difficulty. 

If the impact of increased regulation of 'payday lending' is anything to go by, the extension of regulation into this space should mean fewer DPC than that aspect of the BNPL market today.

New UK Rules on Handling Data Protection Complaints

Among the recent changes to UK privacy law, UK controllers of personal data will need to update their privacy policies, processing agreements and related procedures by June this year to include a process for handling complaints about a breach of the UK's  data protection law and regulation, including by providing a complaint form which can be completed by data subjects electronically. This post is for information purposes only. Please let me know if you need any drafting or advice on how to comply.

Controllers must acknowledge receipt of a complaint within 30 days and, "without undue delay" take appropriate steps to respond and inform the complainant of the outcome. That includes making enquiries into the subject matter of the complaint, "to the extent appropriate", and informing the complainant about progress. 

The Information Commissioner has consulted on guidance on complaints handling requirements.

What if we already have a complaints procedure?

Some service providers are already required to have complaints handling policies and processes (e.g. financial services firms), and it's common for a customer to complain about more than one issue at the same time, so it's best to sweep up data protection complaints in the same process. 

Will we need to report the number of complaints received etc?

There's also the potential for the ICO to require controllers to report the number of complaints they receive in a given period, which may be in the pipeline. 

What other changes have been made?

The Information Commissioner has also issued more general guidance on the changes made under the Data (Use and Access) Act 2025, including changes relating to 'legitimate interests'.

This post is for information purposes only. Please let me know if you need any drafting or advice on how to comply.