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.

Can EU Payment Institutions Really Hold Balances and Operate Prepaid Card Programs?

The European Banking Authority has issued some questionable guidance on how it interprets the definition of 'electronic money' in light of an odd preliminary ruling from the European Court of Justice in ABC Projektai UAB v Lietuvos bankas back in February 2024. I doubt them both and would suggest the ABC case can be restricted to its facts could not be relied upon for the principle that the EBA claims; while the EBA guidance is not binding in any event. But your mileage may differ and I may be wrong - by all means let me know. It's all a bit complex and I've summarised my understanding below for information purposes only. If you're after legal advice, please ping me via Crowley Millar as it's principally an EEA issue. Somehow, I don't see the UK adopting these interpretations... suddenly, a Brexit benefit?

How is E-money Defined in EU law?

The definition of e-money is in the second E-money Directive (EMD2), which is implemented by statute or regulations by each member state (and the UK prior to Brexit) and is intertwined with definitions in the second Payment Services Directive (PSD2) which governs payment services more generally, including those that involve e-money as the form of 'funds':

“electronic money” means electronically, including magnetically, stored monetary value as represented by a claim on the issuer which is issued on receipt of funds for the purpose of making payment transactions as defined in [the second Payment Services Directive (PSD2)], and which is accepted by a natural or legal person other than the electronic money issuer; 

‘payment transaction’ means an act, initiated by the payer or on that payer’s behalf or by the payee, of placing, transferring or withdrawing funds, irrespective of any underlying obligations between the payer and the payee.

'payee' means a natural or legal person who is the intended recipient of funds which have been the subject of a payment transaction"; 

‘payment order’ means an instruction by a payer or payee to its payment service provider requesting the execution of a payment transaction;  

‘acquiring of payment transactions’ means a payment service provided by a payment service provider contracting with a payee to accept and process payment transactions, which results in a transfer of funds to the payee;

In other words, e-money is 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. 

There's some protection for the e-money account holder, in terms of a requirement to immediately redeem any unspent e-money and repay the funds on demand; and safeguard the corresponding amount of cash until the e-money is spent, for example.

Of course, there has to be a mechanism for getting the stored value to the payee. It's possible, in a wallet-to-wallet e-money system that the payee will be another e-money account holder with the same issuer, in which case, the e-money issuer will simply debit the payer's account and credit the payee's account. But that use-case is very difficult to scale (trust me), so e-money issuers also issue debit cards that draw on the e-money balance to enable it to be spent with any merchant who accepts that brand of card (so-called 'prepaid cards'). Most commonly, these cards are issued under membership of the major card schemes. A merchant payee will have contracted with another payment service provider (the 'acquirer', in the case of a card transaction) to do what's necessary at its end to process payment transactions involving the payer's means of payment - the prepaid card that draws on the payer's e-money balance - and transfer the resulting funds to the merchant's own account. 

I mean, it wouldn't be great, would it, if the protection of immediate redemption of unspent value could be lost because the value is technically available via a card and doesn't pop out as the actual original e-money at the other end... (in fact, that 'e-money' status that is lost immediately within the issuer's own systems as the first step in the payment flow) so, as the FCA explained in its guidance under UK E-money Regulations implementing EMD2 pre-Brexit:

The fact that the device on which monetary value is stored is made available, for example, on a plastic card that also functions as a debit or credit card or is a mobile phone does not stop that monetary value from being electronic money. [FCA perimeter guidance ("PERG") 3A.3, Q11]

The real significance of requiring that e-money must be 'accepted by persons other than the issuer' is to avoid regulating 'basic gift cards', for example, which are issued and redeemed by a merchant to enable its customers to purchase only the goods or services that it offers. The FCA also explains this by saying that: 

"...these basic gift cards do not initiate payment orders; payment for the goods or services is made by the customer to the retailer of the goods in advance, when the card is purchased from the retailer." [PERG 15.5 Q40]

The stored value in some electronic travellers cheques is also not considered e-money (PERG 3A.3, Q13).

And there's an express exemption from the definition of e-money and payment services for payment instruments that are only accepted within 'limited networks' of third party payees, which we don't need to cover here.

The ABC case

ABC was a payment institution authorised in Lithuania. As a payment institution, ABC was not authorised to issue e-money, but it could provide the following payment services: execute payment transactions, including: transfers of funds on a payment account with the user’s payment service provider or with another payment service provider; direct debits, including one-off direct debits, and payment transactions through a payment card or a similar device; and/or credit transfers, including standing orders. It could also offer money remittance. 

Under (Lithuania's implementation of) PSD2, any funds that ABC received from customers had to be the subject of a specific payment order, which had to be executed within specific time limits; and those funds could not be held longer than necessary to process the transaction. Under guidance of the Lithuanian regulator (approved by the European Commission), this meant that the funds held in ABC’s payment accounts without a payment order would be regarded as 'deposits', 'other repayable funds' or 'electronic money'. If it wished to issue e-money, ABC would have needed to be authorised as an e-money institution, necessitating higher initial and ongoing capital requirements based on the amount of e-money issued and outstanding. If it wished to accept deposits, ABC would have needed to be authorised as a credit institution with much higher capital requirements still.  

As it turned out, ABC had been allowing customers to deposit funds without a payment order and to hold balances in its payment accounts for long periods, so the Lithuanian regulator revoked ABC's authorisation as a payment institution, for going beyond the scope of that authorisation by issuing e-money.

The question for the ECJ was whether ABC's activities actually amounted to issuing e-money, which the ECJ said it did not, based on findings that:

• 'direct debits', for example, contemplate a payment institution receiving funds "in advance" of receiving a payment order (missing the obvious point that the direct debit instruction involves a (future dated) payment order under Article 78). 

• the rules on safeguarding funds held beyond a business day suggest that PSD2 contemplated there being no corresponding payment order in place (whereas the need for safeguarding arises because PSD2 contemplates both future dated payment orders and longer time limits for processing some payment transactions, as well as the fact that some may fail, as well as to preserve funds in the event of issuer insolvency or malfeasance).

• for funds received by the institution to constitute e-money (my emphasis): 

"47. the issuance of electronic money [must be] distinct from the mere entry in a payment account in that, inter alia, before being used for the purposes of such a payment, such money must be electronically ‘stored’, which implies that it has been issued beforehand, that is to say, converted into a monetary asset separate from the funds received, and that its use as a means of payment is accepted by a natural or legal person other than the electronic money issuer..." 

"48. ...in order for an activity to come under the issuance of ‘electronic money’, within the meaning of Article 2(2) of that directive, it is at the very least necessary that there be a contractual agreement between the user and the electronic money issuer under which those parties expressly agree that that issuer will issue a separate monetary asset up to the monetary value of the funds paid by the user. However, transferring and holding funds on a payment account without immediately mandating payment transactions up to the value of those funds does not mean that the user of the payment service has given his, her or its express or tacit consent to the issuance of electronic money." 

"49. It is not apparent from the documents before the Court that ABC Projektai converted some of the funds which it received into electronically, including magnetically, stored money which could be used by a network of customers who would accept it voluntarily. On the contrary, all the indications are that the funds in question were deposited in payment accounts and could be used solely to execute payment orders from the users concerned."

In other words, the court held that: 

• (in paragraph 47) as a matter of legal interpretation, the use of the stored value had to be accepted as a means of payment by third parties (consistent with the FCA's view, for example) [- not that the 'actual stored value had to end up with the payee']; 

• in this case, there was no explicit agreement with users that ABC was issuing stored value on the basis that it could be used to pay third parties (in paragraph 48) - [whereas the fact that the value in the payment account could be used for payment transactions means it could and would indeed be accepted by third parties];  

• (in paragraph 49) in this case, there was no evidence that any particular 'network' of third parties had accepted that they could be paid using the 'stored money' in ABC's payment accounts. The funds could simply be used to 'execute payment orders' (i.e. to request the execution of a payment transaction, according to the definition) - [again, missing the point that this implicitly means that third parties were indeed accepting this];

• By receiving and holding funds that were not the subject of a payment order but could simply be used for payment transactions at a later date, ABC was not issuing e-money, but merely providing a payment service under PSD2. Therefore, it did not need authorisation as an e-money institution under EMD2. 

In other words, I interpret the court as dealing with the interpretation of the final part of the e-money definition in paragraph 47; and referring to the lack of evidence in paragraphs 48 and 49. I do not read paragraph 49 to colour or restate what was already plainly stated in paragraph 47.

However, from an evidentiary (and logical) standpoint, the court simply ignored the notion there would eventually be an intended recipient of the funds (payee) who must thereby have accepted the means of payment afforded to the payer by ABC.

Mind blown!

Fortunately, it should be possible to restrict any application of the ABC case to its fairly narrow facts.

EBA Guidance on the definition of e-money in the context of prepaid cards

While the ABC case was ongoing, there was also a pending request to the EBA for regulatory guidance from a bank (credit institution) that was planning to issue e-money that customers could spend on prepaid debit cards issued under the major card scheme rules. The EBA accepted that the presentation of such a card as a means of payment at a merchant checkout triggers a series of payment transactions, including the debit of the customer/payer's account associated with the card, and a series of debt-creditor obligations that are net-settled from the payer's card issuer/account service provider, to the card scheme, to the card acquirer and ultimately to the merchant payee. 

In other words, in the case of the major card transactions there is never a direct payment of funds from the cardholder's payment account to the merchant's payment account (often referred to as 'account-to-account' or 'A2A' payments). 

The bank claimed that it's application to become an e-money institution [let's put aside why it applied] had been wrongly rejected because the local regulator interpreted the wording at the end of the definition of e-money “accepted by a natural or legal person other than the electronic money issuer” as requiring that a party other than the issuer must accept the electronic money as a means of payment by becoming a holder of the actual electronic money (meaning that the payee must also have an agreement directly with the same e-money issuer to accept that e-money as payment). 

"The local regulator thus takes the view that there is no issuance of electronic money in a situation where no third party (payee) becomes the holder of the issued e-money (other than the EMI’s customer holding the e-money)." 

In answering this question, the ECB cited the strange decision in ABC v Lietuvos as the basis for agreeing with the local regulator, meaning that prepaid card programs do not involve the issuance of e-money!

In light of the reasoning of the Court, the last condition of the definition of electronic money (acceptance by a natural or legal person other than the electronic money issuer) should be understood as entailing the transferability and voluntary acceptance of electronic money as a separate monetary asset, and not simply as the reception by the payee of funds resulting from redeemed e-money. The submitter states that the payees (merchants in this case) are paid in scriptural money. Therefore, in accordance with the Court’s ruling in case C 661/22 and the reasoning outlined above, there is no acceptance of electronic money by a party other than the issuer in the case in question. 

This paragraph of the EBA guidance of course, misconstrues what the ECJ said in paragraph 47 of the ABC case, which was only that the stored value (in this case, any balance on the prepaid card) must have been "issued beforehand, that is to say, converted into a monetary asset separate from the funds received, and that its use as a means of payment is accepted by a natural or legal person other than the electronic money issuer...". In other words, applied to this case, the court would only have meant that the use of the value on the prepaid card must be accepted as a means of payment, not that the e-money itself must be accepted (consistent with FCA guidance cited above). 

That paragraph of the EBA guidance also ignores the fact that the merchant who accepts a card payment is the 'payee' because that merchant is the "intended recipient of funds which have been the subject of [the multiple] payment transaction[s]" triggered by the presentation of the card, as contemplated by recital 68 of PSD2:

The use of a card or card-based payment instrument for making a payment often triggers the generation of a message confirming availability of funds and two resulting payment transactions. The first transaction takes place between the [payer's card] issuer and the merchant’s [payee's] account servicing payment service provider [to pay for the goods/services], while the second, usually a direct debit, takes place between the payer’s account servicing payment service provider and the issuer [to pay the payer/cardholder's bill, though they may be the same account for a debit card]. Both transactions should be treated in the same way as any other equivalent transactions. 

The next paragraph of the EBA guidance then continues as if the payee is somehow required to have a customer agreement with the e-money issuer, when that would only be the case where the payee already held such an account and the transaction occurred within the e-money issuer's system (as a wallet-to-wallet or account-to-account payment): 

Furthermore, with regard to the question of whether the payees must be in a contractual agreement with the electronic money issuer, recital 18 of the EMD2 lays out redeemability as an intrinsic feature of electronic money, by stating that “electronic money needs to be redeemable to preserve the confidence of the electronic money holder”. In that respect, Article 11(3) of the EMD2 establishes that the conditions of redemption should be stated in the contract between the electronic money issuer and the electronic money holder. Article 11(7) further establishes that “redemption rights of a person, other than a consumer, who accepts electronic money shall be subject to the contractual agreement between the electronic money issuer and that person”. Consequently, the acceptance of electronic money whereby the person who accepts electronic money becomes a holder of electronic money, should therefore be understood to require a contractual arrangement with the electronic money issuer. 

The [prepaid card] scenario described in the question therefore fails to meet all of the criteria of the definition of electronic money.

Again, mind blown!

Fortunately, this is only guidance...

Virtual IBANs (vIBANS) Explained

The European Banking Authority has put together a helpful overview of the six main ways that virtual International Bank Account Numbers (vIBANs) are being issued and used throughout Europe (and the UK). The EBA clarification is welcome, as there is confusion as to whether a vIBAN represents/creates a corresponding payment account, or just operates as a unique reference number to track payments. Not only does this confusion fail to fix underlying problems, such as IBAN discrimination, but it can also trigger many other compliance and commercial challenges. There is also concern as to whether vIBAN schemes are adequately supervised and transparent, including from a financial crime standpoint... Please let me know if I can help you navigate any issues you have regarding vIBANs under existing regulation, or under the proposed controls relating to them.

What's a vIBAN?

You will likely have seen your own unique IBAN - the string of letters and numbers that relates to your current account (the most common type of payment account). IBANs are used in about 80 countries, including the UK and EU, and each IBAN has some letters to denote the country where the bank account is based. They are usually used for international or 'cross border' payments, instead of the 'account number and sort code' for domestic payments. 

Tracking incoming payments is not really a consumer problem, but some businesses need to receive many payments from many different customers into one current account (to pay for, say, purchases or deposits). Usually, the business gives each customer a unique reference number to include in each payment order, along with the bank account number, so the company knows who paid. The trouble is that many customers don't include their unique reference number when making the payment from their bank, so the business receiving the payment has to spend time figuring out ('reconciling') who made the payment while the funds sit in 'suspense'. That means extra cost and delay in processing transactions, and that's usually a problem for both the business and the customer concerned.

Where a business has a really big corporate customer, it might make sense to a separate bank account (and related IBAN) just for that customer. But that would usually prove very costly for lots of consumers or smaller business customers. 

Enter the vIBAN! 

Instead of the additional reference number with the IBAN, the business gives each customer one unique account number to make the payment to. That a unique number looks like an other IBAN but is really just a unique number that the issuer uses to receive and move the funds to the business's actual IBAN and bank account. It's literally a virtual IBAN.

In many cases, the vIBAN may be issued/controlled by an intermediate payment service provider which holds a database matching each vIBAN with a customer number given to it by the business. When the money comes into the relevant IBAN account for that business, the intermediary electronically reports who made the payments in a way that the business can then match with its actual customer database. 

The business could also make payments to customers using the same process, but in reverse. 

Each vIBAN can also be limited to a particular type of transaction, like 'top-ups' to an e-money account or prepaid card.

One confusing aspect of the EBA report is that it refers to the actual bank account associated with the IBAN as the 'master account' which implies that each vIBAN is itself an account when that is not the case.  There is only one actual bank account involved in an IBAN/vIBAN arrangement. If there has to be a reference to a 'master' at all, then it would be more helpful if the IBAN itself were referred to as the 'master IBAN' to differentiate it from the vIBANs associated with it (there is also the concept of a 'secondary IBAN' that refers to the actual bank account).    

Do vIBANs have other uses and benefits?

vIBANs have other benefits besides solving the main payment-tracking problem. 

Sometimes, for example, local banks or businesses in one country will refuse to make payments to an IBAN that has a different country code (so-called 'IBAN discrimination'). So a supplier based outside that country will arrange for local vIBANs to be presented to its local customers, so they or their bank won't refuse to pay. IBAN discrimination is banned in the EU and UK under the Single Euro Payments Area (SEPA Regulation), but the rule is not always enforced in practice. 

The same set up that defeats IBAN discrimination is also used to establish a more cost-effective global payment network. That's because the ability to receive and make payments locally in many different countries usually requires a network of different local payment service providers, but they can all be controlled by one corporate team. That team can manage payments for external customers or internal payments among the companies in the same corporate group, and can also keep balances in different currencies to minimise foreign exchange exposures and conversion costs.

What are the risks/concerns relating to vIBANs?

Possibly the easiest concern to understand is that people making payments (and their payment service providers) are nervous about not being able to tell the difference between an IBAN and a vIBAN. Only the recipient/payee and the PSP(s) issuing the vIBANs know the difference and there may not be any direct customer relationship between the PSP that issued the vIBAN and the end-user. As described above, the initial 'payee' may in fact be an intermediary PSP and not the PSP of the actual intended end-payee. That could interfere with the need to verify the actual payee (and efforts to stop 'Authorised Push Payment' fraud). Similarly, the use of vIBANs may impede the transparency requirements around payer and payee under Funds Transfer and SEPA/ISO standards.

At the regulatory/technical level, some regulators (indeed vIBAN issuers!) don't understand that vIBANs as really just reference numbers. Sometimes vIBANs are also confused with a 'secondary IBAN' which, like the original or 'primary IBAN' also identifies an actual bank account. Some regulators also seem to believe (or there is contractual/operational confusion which suggests) that a vIBAN necessarily implies or creates a distinct, extra payment account (rather than just the data showing which end-user made/received a payment). Unfortunately, that analysis would also mean there is a direct customer relationship between vIBAN issuer and the end-user, which would trigger a lot of related contractual and compliance requirements and confusion over customer's rights (including deposit guarantee schemes), regulatory supervision and complaints. 

However, even if the vIBAN were to be considered an 'identifier' of the actual bank account under the associated IBAN, where the end-user is not the named holder of that bank account then the account could not be deemed that end-user's payment account. The EBA is concerned that this may mean an end-user somehow lacks a payment account and the related regulatory protection that brings. But, of course, the vIBAN itself is just a reference number that the end-user quotes when initiating a payment order - and a payment order could only be initiated in relation to a source payment account from which the relevant funds are to be drawn to fund the payment transaction.

Some regulators agree that vIBAN issuance is not itself a regulated banking/payment service activity, so cannot provide the basis for an institution to open a branch in another member state (host state) under passporting arrangements. Other regulators allow vIBAN to constitute an activity enabling passporting or requiring local authorisation/agency. This means that institutions need to check the regulators view on both sides of each border they wish to 'cross' by issuing vIBANs.

The EBA has also found that some regulators have effectively banned cross-border issuance of vIBANs, by requiring that there must be no divergence between the country code of the vIBAN and the country code of the IBAN of the actual payment account. While those regulators point to ISO technical standards for their view, the EBA has explained that the European Commission does not share that interpretation, nor is it consistent with the SEPA Regulation.  

There's also some risk that a PSP issuing vIBANs might be facilitating the operation of an unauthorised payment service business, depending on the nature of the business being operated by the immediate customer and services offered to end-users (i.e. is that customer offering one of the specified 'payment services' as a regular occupation or business activity). 

There is also the potential for failures in fraud reporting where a payment is made to a vIBAN in one country, but actually means the payment has been routed to a payment account with an IBAN in another country.

Are separate vIBAN controls needed?

Some regulators' concerns about vIBANs might be addressed if those same regulators were to tackle IBAN discrimination in their jurisdictions - so that vIBANs aren't needed as a 'band aid' or 'sticking-plaster' for that problem. 

For anti-money laundering purposes, it's especially important for the issuing PSP to understand the payee's business, the scenario in which the vIBANs are being used, and the type of end-users able to use the vIBANs and the rationale for the payments being received (or made). This becomes more critical where the end-users are based in another jurisdiction.

In turn, the payment services regulator in the country where the vIBAN arrangement is deployed needs to know that: vIBANs are being issued; the issuing PSP has the right risk assessment, customer due diligence and transaction monitoring controls in place (including where another PSP or business is actually allocating the vIBANs to the end users); and that suspicious transactions involving vIBANs can be detected, reported to the correct country authority and readily traced. Again, this becomes more important where the end-users to whom vIBANs are issued are based in another ('host') jurisdiction to the ('home') jurisdiction where the IBAN and bank account are based.

Some PSPs have already lost their licences over failure to comply with existing controls in the vIBAN context, but the EU's new AML Regulations will explicitly require the 'account service' PSP that offers the underlying payment account to which the IBAN relates to be able to obtain customer due diligence information on end users to whom the associated vIBANs are issued 'without delay' and in any case within five working days - even where vIBANs are issued by another PSP. 

In addition, the next anti-money laundering directive (AMLD6) will require all national bank account registers to hold information on vIBANs and their users. 

The EBA has also included an Annex listing the factors that may increase or reduce the risk of money laundering or terrorist financing.

Please let me know if I can help you navigate any issues you have regarding vIBANs under existing regulation, or under the proposed controls relating to them.