UK Presses On With Consumer Credit Reform

The Treasury has published its policy statement on the next steps in reforming Britain's complex consumer credit framework, following the consultation in May 2025. The Financial Conduct Authority has also announced that it will consult on its rules in due course (it seems likely there will be a fairly generous transition period with so much work to do). I have described the overall approach in more detail below based on the Treasury's executive summary. Broadly, however, the industry will still need to navigate between the Consumer Credit Act ("CCA") and related sets of rules, albeit the FCA rules are more accessible than the various CCA regulations. It is not clear whether and to what extent this will address some areas that had been left behind by interim regulatory evolutions (e.g. consumer hire). Please let me know if you require legal advice on the detail of the changes in due course.

FCA rules will replace various information disclosure requirements under Consumer Credit Act ("CCA") regulations relating to the three phases of consumer credit: pre-contract (e.g. Pre-Contract Credit Information, Agreement, etc.), post-contract (e.g. statements, copies, etc.) and collections (e.g. arrears and default notices, etc.). Security and guarantees (surety) will also be addressed in FCA rules.

Restrictions on enforcing defective agreements without a court order and other sanctions will be replaced by the FCA compliance/enforcement regime, but criminal offences will be retained. 

Other CCA requirements will also be replaced by FCA rules as follows (subject to FCA consultation): 

• Withdrawal rights (some parts retained); 
• Cancellation rights (some parts retained); 
• Early settlement and rebate rights; 
• Termination of agreements (including voluntary termination) (some parts retained); 
• Securities and sureties (some parts will be retained); 
• Credit-token agreements, acceptance and liability for misuse of credit tokens; 
• Agreement to enter future agreement void; 
• Liability for misuse of credit facilities; 
• Interest not to be increased on default; and 
• Statements by creditor or owner to be binding.

The following CCA concepts/provisions would be retained (with necessary amendments): 

• Consumer credit agreements, meaning of credit, running account credit, fixed sum credit, restricted used and unrestricted use credit, debtor-creditor-supplier agreements, and debtor-credit agreements; 
• Consumer hire agreements; 
• Linked transactions; 
• Cancellation: recovery of money paid by debtor or hirer, return of goods and goods given in part exchange; 
• Withdrawal from prospective agreement 
• Death of debtor or hirer; 
• Protected goods, recovery of possession of goods or land, summary diligence not competent in Scotland; 
• Ineffective securities; 
• Pawnbroking; 
• Negotiable instruments; 
• Land mortgages; and 
• Provisions under Judicial Control (including Time Orders, interest, etc.), 
• Ancillary Credit Businesses (including credit reference agencies), 
• Enforcement of Act and 
• Supplemental (including interpretation, definitions, etc.)

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 4 classes of potential limited network, but the preamble no longer mentions 'used in a limited way' and the first two limbs in PSD2 are blended into one. The reference to 'payment instruments' is clarified to include 'electronic money-based instruments', which is apt to confuse; those limited to 'premises' include both physical and online stores (some regulators interpreted premises to mean physical only); 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-based instruments yet the exclusion of redemption for cash is very confusing!

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

Other changes too numerous to mention, but including:

• 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;

• there are tighter rules concerning PSPs' access to bank accounts, including the reasons for refusal;

• the PSRs provide that:

A payment transaction shall not be deemed to be authorised where the transaction was initiated or modified by a third party who is acting without the consent of the payment service user, including by using the personalised security credentials of the payment service user fraudulently obtained

• there are requirements to enable users to set transaction limits and modify them on a delayed or immediate basis as they wish;

• the time for notifying a PSP of unauthorised or incorrect transactions increases from 13 to 18 months after the date of debit, with greater clarity around burden of proof and evidence that can be expected;

• there are various anti-fraud measures, including APP fraud reimbursement on certain conditions;

• there are advertising restrictions for very large online platforms; and

• there are more detailed transaction processing times, including for e-money tokens.

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

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. 

Have You Risk Assessed Your Chatbot? The General Product Safety Regulation

Amid the hype of agentic AI and people developing unfortunate relationships with chatbots, it's worth a reminder that the GPSR establishes safety obligations on manufacturers and their agents and other authorised representatives, importers, distributors, fulfilment service providers (e.g. warehouses) and online marketplaces who are targeting or otherwise participating in the EU consumer market, as well as Northern Ireland and the EEA (even if based outside the EU). This post is for information purposes. Let me know if you need legal advice, either via the UK or Ireland/EEA.

A 'product' could be any item, whether tangible, non-tangible or mixed nature, including software/AI applications, whether new, used, repaired or reconditioned, as of 13 December 2024 or since.

The GPSR does not legislate for product liability, which is dealt with under EU product liability legislation.

The European Commission has now issued detailed GPSR guidelines to help affected businesses to understand the requirements, including criteria for each category and how a business could fall into more than one. 

The UK government has also issued guidelines for businesses targeting or otherwise participating in the Northern Ireland market.

Manufacturers must perform and record an internal risk analysis before placing a product on the EU market (the guidelines include a template). Those based outside the EU will need to appoint a "responsible person" in the EU (who could be an importer etc) and disclose that on the product, packaging, parcel or an accompanying document. The 'responsible person' also has certain obligations, including notification of accidents. 

Safety recall and warnings to consumers should be done in a certain manner; and there is a Safety Business Gateway that firms (or their 'responsible person') must use to inform the authorities about dangerous products and accidents, depending where they sit in the supply chain.

This post is for information purposes. Let me know if you need legal advice, either via the UK or Ireland/EEA.

New Security Requirements For Digital Products - Hardware and Software

The EU's Cyber Resilience Act begins to apply from June 2026, ahead of full implementation in December 2027.

When designing, developing and producing any product with digital elements that is specified as 'critical' or 'important', the manufacturer will need to ensure that the product meets the essential cybersecurity requirements, carry out cyber risk and conformity assessments and comply with reporting obligations. 

Importers, distributors and 'open-source software stewards' also have specific obligations. 

The CRA itself is here, and the technical descriptions of 'important' and 'critical' products have just been published. 

There is also an initial set of FAQs that seems likely to evolve as implementation proceeds.

The full implementation time line, with links to relevant docs, is set out here.

This post is for information purposes. Please let me know if you need advice on it, whether you're based in or outside the EEA.

Tsunami Warning: The UK's FCA Consults On How It Will Regulate Crypto Activities

In April, the UK government published its proposed financial regulations for certain activities related to cryptoassets that will be supervised by the Financial Conduct Authority. Now, the FCA is consulting on the rules that it will apply. The consultation paper is a useful 'explainer' for those unfamiliar with FCA's approach to regulation and supervision, as many in the crypto world will be. There is a lengthy 'cost benefit analysis' in Annex 2 that's worth burrowing into for the specific impact of the rules on the crypto sector (as the FCA views it). The consultation ends on 12 November, with some items for comment by 15 October. Even more, activity-specific rules will be published for consultation on by year end as part of the FCA's 'crypto roadmap'.

The regulated cryptoasset activities will include issuing qualifying stablecoins, safeguarding qualifying cryptoassets and specified investment cryptoassets, operating a qualifying cryptoasset trading platform, intermediation and staking. 

FCA rules are very extensive and require firms to have appropriate systems, controls, processes, financial resources and expertise. For a sector that is very much anchored in libertarian, 'techno optimist' waters, this represents a tsunami...

 

EU Payment Services Reform: PSD3 & PSR Loom Larger

We are apparently nearing the next step in the evolution of EU payments law, with the publication of new versions of the proposed directive and accompanying regulation. The original proposals were published in June 2023, which I covered here. 

PSD3 will govern licensing and supervision of e-money and payment institutions, while the PSR will govern the operation of payment services (including those offered by banks). Of course, the directive will need to be implemented under the national laws of each member state, while the regulation will apply directly (though will likely require some local implementation).

Among the more revolutionary aspects are proposals for an anti-fraud framework. Regulated payment service providers (PSPs) will have to share fraud-related information and adopt a system to check IBANs against the corresponding bank account name before permitting transfers. 

The proposals also bring electronic communications service providers - internet service providers and messaging platforms - within scope for fraud prevention, specifically requiring them to "take all reasonable organizational and technical measures to detect and prevent fraud within their sphere of competence, in accordance with applicable Union and national law." 

ATMs will have to show all fees and exchange rates before each transaction. 

There are also proposals for more transparency on payment card scheme fees and rules that should help merchants compare acquiring services (as the UK's Payment Services Regulator was also seeking to achieve, before being subsumed into the FCA).

I will keep following developments until the new legislation is passed. It appears the legislation will take effect 24 months later.

Changes to UK Data Protection Regime

The UK's Data (Use and Access) Act 2025 (DUA) has been passed, though much of it is yet to take effect. There are some important tweaks to the UK's data protection laws (Data Protection Act 2018/UK GDPR and cookies regulation (PECR)). Firms will need to reconsider their privacy policies relating to research, (direct) marketing, cookies and AI in particular. There are now the same potential fines for cookie violations as for UK GDPR breaches - note that the Information Commissioner seems to care more about cookies and automatically scans for non-compliance. If you need legal advice on any of this, please let me know.

FCA Consults on Stablecoin & Custody Rules... Confusion Looms On E-money

The FCA has been preparing to regulate 'stablecoins' for a lot longer than other types of cryptoasset, and is currently consulting on the detailed rules for issuance/offer of qualifying stablecoins, the holding and management of the backing assets, and key information that issuers will need to disclose.plan to consult separately on proposals for managing cryptoasset firm failure, including qualifying stablecoin issuers. This (evolving) post is a summary for information purposes. If you would like legal advice on the potential issues and impact, please let me know.

Terminology

"Qualifying Stablecoin" is defined in a new section 88G of the FSMA (Regulated Activities) Order (RAO) as:

a 'qualifying cryptoasset' [see s88F RAO - this excludes a cryptoasset that is already a specified investment of some kind, e-money, a fiat currency, a central bank digital currency or used in a limited network (similar to the exclusion from e-money/payment services] that: 

(a) references a fiat currency; and 

(b) seeks or purports to maintain a stable value in relation to that referenced fiat currency by the issuer holding, or arranging for the holding of: 

(i) fiat currency; or 

(ii) fiat currency and other assets, 

irrespective of whether the holding of a fiat currency other than the one referred to in sub-paragraph (a) or other asset contributes to the maintenance of that stable value. 

However, this will not include a tokenised bank deposit (we'll discuss the concept of 'tokenised e-money' below].

"Issuing" a qualifying stablecoin in the UK involves the issuer only accepting (a) money; or (b) other qualifying stablecoins issued by FCA-authorised firms, in exchange for qualifying stablecoins they issue. Where issued in exchange for money, it follows that the stablecoin they might also qualify as e-money; and this is pretty much how the FCA is treating them, albeit as a distinct form. Unlike [other] e-money, qualifying stablecoins form a subset of qualifying cryptoassets; have a secondary market value [so does e-money, where it turns out too little cash is safeguarded], and the issuer can mint tokens before receipt of funds from token holders [like prepaid/smart cards?]. The FCA proposes to consult on guidance further clarifying the differences once legislation is passed.

"Creating" includes the technical design of a qualifying stablecoin on any form of DLT, including on private, public, permissioned or permissionless blockchains. Issuers must identify and manage the risks associated with 'creation' (the design and build of a qualifying stablecoin) before it is issued. This includes analysing the risks of the underlying DLT and making sure they can manage potential disruptions

"Minting" a qualifying stablecoin such that it first exists as an identifiable asset on the blockchain in a transferrable form - an issuer must always hold backing assets in amounts equivalent to the value of the stablecoins that have been minted (1:1 in a single fiat currency, regardless of how the backing assets might perform in the markets for those types of assets). The jury is out on whether multi-currency stablecoins will be permitted, as they introduce FX and liquidity risks and the fact that 'par' would be judged against a basket of currencies, yet redemption could only be in one, thereby crysalising losses/gains. 

"Burning" or permanently removing the stablecoin from circulation (on the blockchain). 

Backing Assets 

Only certain asset classes can be used to 'back' a stablecoin, including on demand deposits; and government treasury debt instruments that mature in one year or less. This is because the composition of the 'backing asset pool' must be able to meet requirements for redemption at all times and ensure that the qualifying stablecoin maintains stability.minimum ‘floor’, known as the on-demand deposit requirement (ODDR), for the proportion of backing assets that must be held in bank deposits that are available on-demand. The ODDR is set at 5% and will apply to all stablecoin issuers - both those who only use core backing assets and those who opt-up to use expanded backing assets (who would also need an appropriate backing asset risk management tools and comply with the backing assets composition ratio (BACR) that has a core requirement (CBAR) and an estimated 'daily redemption amount (DRA) for each of the up-coming 14 redemption days, by reference to the experience over the prior 180 redemption-day period, with increases in the CBAR for each redemption day where the actual DRA is at least 110% of the forecast DRA. The intention is that core backing assets should be sufficiently liquid to meet redemptions within the T+1 timeframe. Accordingly, in this context, short term deposits must be repayable on demand or have an immediate break clause attached to them. Issuers should ensure that they manage the portion of government debt instruments used to meet the BACR in a way that meets their redemption obligations.

However, with permission and additional controls, public debt of a longer residual maturity; assets, rights or money held as a counterparty to a repurchase agreements or reverse repurchase agreements; and some limited money market funds might qualify as backing assets.firms to determine their own compositions, based on factors including the redemption modelling they undertake on an ongoing basis. An appropriate backing asset composition will be driven in part by the maturity and liquidity of the underlying assets. This will be set against the requirement for firms to place a payment order for redeemed funds by the end of the business day following receipt of a valid redemption request

Statutory Trust Over Backing Assets

The FCA is still proposing a statutory trust over backing assets held by the issuer as trustee for the benefit of stablecoin holders as beneficiaries, so there would be a fiduciary duty between the issuer and stablecoin holders. This seems more consistent with a stablecoin being an investment instrument, rather than money-like, even though some rules are intended to redress this. It must also mean that the beneficiaries hold both a stablecoin and a beneficial interest in backing assets to the same value as that stablecoin - which surely adds up to two in economic/accounting terms?

The issuer must appoint an independent third party (not a group company), to safeguard the backing assets, which must be promptly segregated on receipt; and the third party must acknowledge in writing that safeguarded qualifying stablecoin backing assets are held on trust for the benefit of the stablecoin holders (rather than for the client issuer/trustee). This sounds like good news for the custody industry and expensive. 

If an issuer issues more than one qualifying stablecoin it must ensure that the backing assets for each stablecoin product are held separately and under separate trusts for the benefit of each separate group of stablecoin holders for each corresponding qualifying stablecoin pool.

The issuer retains the obligation to ensure that each set of backing assets are managed appropriately and the qualifying stablecoins are backed 1:1 with the backing assets at all times. 

There must be reconciliations of backing assets at least daily and to ensure shortfalls are topped up and excesses removed, or that qualifying stablecoins are minted or burned to ensure parity is maintained within 1 business day, failing which the issuer must alert the FCA the following business day (though the issuer won't be expected to publish or report the value daily, only monthly...).  This is said to be in order to address the risk that any redemptions while the stablecoin has de-pegged would exacerbate the shortfall (potentially resulting in a 'run' on the issuer); and that issuers (or other investors) could speculate by buying the stablecoins below par and waiting for the issuer to restore parity. The fact that the rules could leave a window of 4 trading days (including a weekend) seems to have escaped the FCA's attention...

The issuer must redeem its qualifying stablecoins to all qualifying stablecoin holders at par, with no minimum redemption amount of stablecoin per redemption request, to an account in the name of the holder by the end of the business day following receipt of the request. Any redemption fee must be 'commensurate' with the operational costs incurred for executing redemption (not costs and losses arising from the sale of assets in the backing asset pool); and must not exceed the value of the stablecoins being redeemed. So the par value is the value of one unit of the reference currency, multiplied by the number of stablecoins being redeemed, irrespective of the value of the backing assets - so the redemption value should not fluctuate in line with the performance of the underlying backing assets (as is the case with a fund).

Issuers can retain interest on backing assets, but cannot pass interest or dividends/benefits on the backing asset pool to qualifying stablecoin holders (directly or indirectly), further distinguishing qualifying stablecoins from funds or other investment products. 

The draft RAO distinguishes 'issuing a qualifying stablecoin' from the operation or management of a Collective Investment Scheme (CIS) or Alternative Investment Fund (AIF), of which Money Market Funds are a subset, but the FCA foresees the need to consult on the differences in due course... 

Stablecoins, E-money, Tokenised E-money and E-money Tokens

The FCA has always tried to adopt a technologically neutral and 'same risk, same regulatory outcome' approach to regulation. So crypto-tokens issued 1:1 in relation to the value of a single currency on receipt of funds and accepted as a means of payment by third parties have been treated as 'e-money tokens' and therefore e-money, such that the issuer would need to be authorised as an e-money institution under the E-money Regulations (EMRs). A reminder that e-money is defined as:

...electronically (including magnetically) stored monetary value as represented by a claim on the electronic money issuer which— 

(a) is issued on receipt of funds for the purpose of making payment transactions; 

(b) is accepted by a person other than the electronic money issuer; and 

(c) is not excluded by regulation 3 [limited network, low value telecoms billing for certain things];

This remains baked into the proposed changes to the RAO, since to be a 'qualifying stablecoin', a cryptoasset must also be a 'qualifying cryptoasset', which excludes e-money.

This is also reflected in the EU's Markets in Cryptoasset Regulations (MiCAR). In a recent opinion to delineate MiCAR and the Payment Services Directive (PSD2), the European Banking Authority has confirmed that a cryptoasset which aims to stabilise its value by referencing only one official currency is an "e-money token" (EMT); and Article 48(2) of MiCAR deems EMTs to be e-money, and therefore within the definition of ‘funds’ in Article 4(25) of PSD2. Article 70(4) of MiCAR then provides that cryptoasset service providers (CASPs) who provide PSD2 payment services related to their crypto-asset services, may either do it themselves or partner with a PSD2 firm, so long as either is authorised to provide the payment services. In addition, a custodial wallet that is held in the name of one or more clients and allows the client(s) to send and receive EMTs to and from third parties is a 'payment account' within the scope of PSD2. So, the following activities involving e-money tokens (EMTs) are also to be regarded as 'payment services' under PSD2: 

• the transfer of cryptoassets as a payment service, where they entail EMTs and are carried out by the entities on behalf of their clients; 

•  the custody and administration of EMTs.

However, the UK seems to have diverged from this now in relation to qualifying stablecoins that "seek or purport to maintain their value by reference to a single fiat currency" (which I'll call 'single currency stablecoins'). The FCA seeks to explain this on the basis that such single currency 'qualifying stablecoins' are somehow different from e-money because they "have a secondary market value... the issuer can mint tokens before receipt of funds from token holders...and [due to] their use case in cryptoasset trading." This fails to acknowledge that the criteria for stored value to qualify as e-money were ordained by regulation that does not really negate such characteristics: recently, the FCA itself revealed that, in their experience of e-money institution insolvencies, only about 20% of funds corresponding to e-money balances are safeguarded, implying that UK e-money may have decoupled from sterling (just as stablecoins can). In addition, in order to reflect the custom that customers' payment accounts are credited instantly with e-money they purchase online or over the counter, the trigger point for the "receipt of funds" by e-money institutions has been inferred by the FCA as occurring earlier than when the funds themselves actually arrive in the firm's actual bank account: the e-money issuer must merely have become 'entitled to' those funds. And e-money can be used in the course of cryptoasset trading, as the EBA has confirmed.

Yet the FCA has also said that: 

"we intend to regulate [qualifying stablecoins] as money-like instruments rather than as investment products. This means we would expect qualifying stablecoin issuers to offer all holders the right to redeem at par value, and the redemption value should not fluctuate in line with the performance of the underlying backing assets as is the case with a fund. We also propose to prohibit issuers from passing interest on the backing asset pool to qualifying stablecoin holders, further distinguishing qualifying stablecoins from funds or other investment products."

Note that while a qualifying cryptoasset need only "seek or purport to" maintain its value in a reference currency/asset in order to become a 'qualifying stablecoin', the FCA will then also require that the qualifying stablecoin maintain that value.

At any rate, there is now no mention at all of "e-money tokens" in the UK proposals for stablecoins or cryptoassets more widely. While a cryptoasset is not a 'qualifying cryptoasset' (and therefore could not be a qualifying stablecoin) if it is e-money (Art 88F(4), RAO), a new exclusion from the definition of "e-money" will also be added (via Reg 3ZA in the EMRs) to provide that the concept of “stored monetary value” is not to include: 

(a) qualifying stablecoin; 

(b) money or assets held as the backing assets or the stabilisation mechanism for a qualifying stablecoin; 

(c) a cryptoasset comprising or representing a claim for the repayment of a sum of money received by way of deposit, within the scope of article 5 (accepting deposits) [in other words, tokenised bank deposits - which reflects the carve-out of tokenised bank deposits from the definition of a 'qualifying stablecoin in Art 88G RAO].

So, could a cryptoasset ever be considered "e-money" in the UK? Well, by analogy with the definition of a tokenised bank deposit, perhaps a cryptoasset that itself comprises or represents "e-money" could also be considered e-money, so long as 'the stored monetary value' is not itself a 'qualifying stablecoin' (while recalling that a to be a qualifying stablecoin, a cryptoasset must also be a qualifying cryptoasset, which excludes e-money; and around the circle we go...). 

Of course, banks can issue e-money as distinct from 'accepting deposits'.

Not only is all this quite confusing, but having separate UK regulatory regimes for single-currency stablecoins and e-money also increases the jeopardy for getting the classification wrong at the outset (especially when opining on and operating under, say, the limited network exclusion) and addressing their uses and abuses in the market.

Are Pre-minted Tokens 'Qualifying Stablecoins'?

The FCA is concerned about the fact that issuers might "mint qualifying stablecoins" (the crypto-token that is not yet backed) before issuing them to the public and that if these tokens are not 'backed' from the time they are minted, there's a risk of unbacked qualifying stablecoins slipping into the market (as could a qualifying stablecoin that has been redeemed). I guess the simple answer to this risk is that neither a pre-minted (or redeemed) unbacked token is not yet (or any longer) a qualifying stablecoin, because it does not 'seek or purport to maintain' any value. 

Stablecoin Redemptions

The FCA proposes that a redemption must be for money (not other assets); and starts when a holder makes a formal request to redeem; and ends when "a payment order for the redeemed stablecoins has been submitted to the holder's desired [bank or payment] account." These rules will need to be tightened up. Of course, the payment order in this case would be submitted by the issuer to the safeguarding custodian to pay the fiat currency to the holder's account. The issuer does not submit a payment order directly to the holder's account. Equally, 'placing a payment order' begs the question of when the payment order is to be executed. It is possible to place a future-dated payment order...

There would also be exemptions, e.g. where redemption would breach a legal requirement (e.g. AML check, as the stablecoin has been transferred from the original recipient) or court order; or where a currency exchange is required (in which case the issuer should disclose the timing of when such requests can be executed, along with redemption fees that are 'commensurate' with the operational costs incurred (excluding costs/losses from selling backing assets).

Redemptions could be suspended "in exceptional circumstances" where necessary to protect the rights of holders or the integrity of the stablecoin: due to a failure in the underlying blockchain/infrastructure; insolvency of the issuer; or a sudden loss of confidence in the value of the stablecoin (a 'run'). The FCA wants "at least 5 working days' notice" of restarting redemptions, which means the suspension could last at least 6 working days.

Use of Third Parties

An issuer can use third parties to sell or redeem qualifying stablecoins and manage the backing asset pool, on its behalf. In each case, there are requirements to minimise the risk on the third party's failure. It must be clear when a third party is carrying out any issuance activity.

Communications/Disclosure

Issuers must publish the number of stablecoins issued and the backing asset composition at least once every three months (why not daily?); obtain independent verification annually of any statements they've made about the 1:1 ratio in the previous 12 months; along with e.g. technology used, third parties outsourced service providers and the redemption policy/process. 

Custody

Taking custody of a cryptoasset usually means taking control over it by holding or storing the means of accessing it (the private key) on behalf of the customer, but that doesn't mean it holds the customer's private key to the customer's own wallet. Instead, the custodian receives a transfer of the cryptoasset from the customer's wallet to its own wallet to which it has access with its own private key. 

Customers often leave the cryptoasset with the exchange they bought it on, which then also acts as a custodian. 

In a cryptoasset custody arrangement, the stablecoin holder may therefore have both legal and beneficial title, only beneficial title or just a right for the return of the stablecoin.  There is no registration of ownership in some kind of central register, as there is for traditional securities, for example, under Article 40 of the RAO. While there's a record of transactions on the blockchain, that is not a definitive record of ownership. There is some reliance, therefore, on the custodian's records and service terms that might defeat ownership interests or render customers only unsecured creditors of the custodian.

Therefore, custodians will have to segregate client assets from their own and ringfence them from other creditors' claims. This could be done in individual or omnibus wallets. Reconciliation must be done each business day; and the results held independently of other records (with notification to the FCA if this is not possible or there is a shortfall (in which case the client must also be notified). 

The custodian would also have to hold the cryptoassets in a (non-statutory) trust for the clients, as a bare trustee on receipt, recording the name of the client beneficiary in the firm's internal records that state the type of asset, quantity, the address where it is held, the nature of the client's claim to it and the identity of any third party that has capacity/control to effect a transfer. 

Whether such a trust persists in the event that the customer wants the cryptoassets put to a different use in some way (e.g. staking) remains to be consulted upon.

The CASS 7 rules will apply to any cash that is held for clients.

The FCA also wants to avoid the insolvency of crypto custodians altogether, by ensuring they wind-down in an orderly fashion:

Where necessary, we propose amendments to existing CASS provisions, to ensure we accommodate the unique characteristics of cryptoasset custody outlined above. We have considered feedback from DP23/4 and other publications. These include the IOSCO Policy Recommendations for Crypto, the Law Commission’s final report on digital assets and the Property (Digital Assets Etc.) Bill which clarifies that certain digital assets, such as crypto-tokens, can be recognised as property even if they do not fit into the two traditional categories of personal property in the law of England and Wales.

Other internal controls must also be maintained; and custodians will only be able to use third party service providers under strict conditions, including that the appointment must be "in the best interests of the client, and necessary for safeguarding, which firms must evidence in a written policy." 

Custodians may be held liable for negligence, breach of contract and breach of FCA rules. 

Specific disclosure requirements are being considered, but not Proof of Reserves (a cryptographically proved, independent audit process). Audit standards will also be consulted upon, along with regulatory reporting rules.

E-Money Tokens: The Difference Between MiCAR Payments & PSD2 Payments

I have a number of posts in the works on the UK's belated plans for cryptoasset regulation, but this one deals with the European Banking Authority's use of its 'no action' powers to minimise the overlap between the EU's second Payment Services Directive (PSD2) and the Markets in CryptoAssets Regulation (MiCAR), to minimise the burden of dual authorisation for firms. The distinctions summarised below should be applied in the exercise of national EEA payment authorities' supervision and enforcement policies until 2 March 2026, and selective supervision of certain aspects thereafter, while waiting for legislative clarity when PSD2 is replaced in 2-3 years' time. This post summarises the relevant distinctions for information purposes. If you need legal advice, please contact me via Crowley Millar.

EMT-based PSD2 Payments

Specifically, the European Banking Authority (EBA) has opined that the following activities involving e-money tokens (EMTs) should be regarded as 'payment services' under PSD2: 

• the transfer of crypto assets as a payment service, where they entail EMTs and are carried out by the entities on behalf of their clients; 
• the custody and administration of EMTs. 

In addition, a custodial wallet should be regarded as a payment account under the PSD2 where the wallet is held in the name of one or more clients and allows the client(s) to send and receive EMTs to and from third parties.

This is because Article 48(2) of MiCAR deems EMTs to be electronic money, so they come within the definition of ‘funds’ by virtue of Article 4(25) of PSD2. Article 70(4) of MiCAR then provides that CASPs who provide PSD2 payment services related to their crypto-asset services, may either do it themselves or partner with a PSD2 firm, provided that either is authorised to provide the respective payment services. But exactly which of the 8 payment PSD2 services applies is not quite clear.

Any firm undertaking these activities will need local authorisation under PSD2 from 1 March 2026, but even after that date, local regulators should not prioritise the supervision and enforcement of PSD2 provisions on safeguarding, disclosure of information on charges to consumers, the maximum execution time of payment transactions, unique identifiers (e.g. IBAN), or open banking (account information services and payment initiation services). Only the rules on strong customer authentication (two factor authentication) should apply (to custodial wallets and the initiation of EMT transfers), along with rules on fraud reporting and the cumulative calculation of 'own funds' (working capital) requirements.

EMT-based MiCAR Payments

Meanwhile, the EBA says that ‘exchange of crypto-assets for funds’ and ‘exchange of crypto-assets for other crypto-assets’ as defined in MiCAR should not be deemed PSD2 'payment services' by local authorities, nor where crypto-asset service providers (CASPs) intermediate the purchase of any crypto-assets with EMTs.

The EBA acknowledges that this advice "will result in a large number of EMT transactions not to be subject to the requirements of PSD2", but the aim is to minimise the burden of dual authorisation for CASPs.

This post summarises the relevant distinctions for information purposes. If you need legal advice, please contact me via Crowley Millar.