Tokenised bank money – Further comments on MiCAR (2)

In my previous article, I discussed the problems arising from the methodology and definitions of the European Commission’s proposed “Regulation on Markets in Crypto-assets” (MiCAR for short).¹ Article 2 in particular leads to questions of demarcation from the already regulated types of money, i.e. scriptural money and e-money. Today I would like to address one of the demarcation issues. Under what conditions are demand deposits held as decentralised accounts on the blockchain cryptocurrencies under MiCAR? Are these not e-money tokens (EMT)? Is the term “tokenised fiat money” already used in the literature not a contradiction in terms? Can an account be a token at the same time?

Tokenised bank money: Traditional deposit-taking or e-money tokens?

Many banks are currently planning the “tokenisation” of account-based deposits (keyword: tokenised commercial bank money or book money). This does not mean that the previous current accounts will be decentralised and placed on the blockchain instead of centralised account management. From today’s perspective, that would be “cool” and innovative, but not an efficiency gain. The goal is rather the additional creation of a programmable money that can be used within the framework of smart contracts. The expected use cases are many: machine-to-machine (M2M) payments, payments in the IoT world, micro-payments (pay-per-use), etc. The banks do not want to wait for the digital euro as CBDC (Central Bank Digital Currency), which has been announced for some time. Moreover, it is questionable whether the planned design of the digital euro (account-based and/or as a bearer instrument without required use of DLT) by the ECB is suitable as programmable money. The banks also want to prevent any FinTechs or BigTechs from getting too big a piece of the hoped-for pie.

If one now assumes that a bank or a group of banks offers the programmable money as crypto assets using DLT or similar technology (according to the MiCAR definition), the question arises whether and in which cases MiCAR must be applied or whether the previous regulations for conventional demand deposits apply. Unfortunately, MiCAR does not provide a clear answer to this. It only states that regulation should not be applied to crypto assets that qualify as deposits within the meaning of Art. 2(1)(3) of Directive 2014/49/EU. This directive refers to deposits (including demand deposits) that are covered by deposit guarantee schemes. A deposit is defined here as follows:

“A credit balance arising from amounts remaining in an account or from intermediate positions in the course of normal banking transactions and repayable by the credit institution in accordance with the applicable legal and contractual conditions, including a time deposit and a savings deposit, […]” (followed by a number of exceptions that are not relevant in this context).

Traditional deposit-taking?

A deposit at a bank is therefore usually account-based. The following question arises: Does an account have to be held centrally at a credit institution (central ledger) or do we continue to speak of a deposit in the sense of the above Directive if the credit is registered in a decentralised manner on a distributed ledger? Is the term “tokenised scriptural money” a contradiction in terms?

Now, the term “token” (unfortunately not defined in MiCAR), as well as “coin” (e. g. in the sense of a stablecoin), suggests a digital bearer instrument that changes hands digitally, similar to cash. In most cases, however, crypto assets are not bearer instruments, but rather a decentralised registration or account management and account balance validation by a multitude of instances (“validators”). The juxtaposition of “account-based” versus “token-based” often used in the relevant crypto publications is misleading, or at least confusing, unless one understands token-based to mean a “bearer-based digital asset”, as the ECB does in its “Report on a digital euro” (2020). As a rule, however, the DLT-based crypto assets referred to as tokens are (decentralised) account-based. ² The “tokenised” accounts planned by the banks are still accounts, but also in the sense of the above definition of deposits? “The only difference between a traditional account-based system and a blockchain is that the accounts are not kept in a central database but in a decentralised append-only database” (Chaum, Grothoff and Moser³). This clarifies the technical classification, but also the legal one?

In the history of money, scriptural money – and thus also demand deposits – have been subject to many technical innovations, from written entries in books (book money) to complete digitalisation on some back-end server. The accounts as a list of claims and liabilities between the bank and the account holder, however, have always been managed by the bank as the central instance – regardless of the technical design: Execution of payment transactions, cancellations, validation of the account balance, etc. With a DLT account, these tasks are now largely carried out by a large number of other parties, possibly without a contractual relationship with the crypto value issuer (non-permissioned ledger). The account management is virtually outsourced.

A multitude of questions arise, such as: What conditions does the bank have to fulfil and what obligations does it have to assume in order to remain in control? Is an overarching liable entity required as a “central issuer” if several banks are involved? Under which regulations do the new types of crypto service providers fall, which are listed in detail in MiCAR but missing in PSD2? In summary: Does a “distributed ledger account” fulfil the previous criteria of a traditional current account or is there – as an IMF Working Paper concludes – a “fundamental distinction between the two concepts“4 ? In short: Does the new wine fit into old wineskins?

Or e-money tokens after all?

The banks’ plans so far are that these DLT accounts will be offered for certain applications (e.g. in combination with payments resulting from smart contracts) and certain customer segments in parallel, but interoperable with the conventional current accounts. Without DLT, such a parallel account circuit (pre-paid via conventional accounts) is usually classified as e-money for regulatory purposes. Due to the definitional opening of e-money as a bearer instrument (the genuine “token”) around account-based e-money, the demarcation between account-based e-money and current accounts (demand deposits) is difficult in practice, especially if both account types are held at one bank. ⁵

Any interest (deposits: allowed; e-money: not allowed; by the way: what about negative interest?) is ruled out as a distinguishing feature in today’s world. For many supervisory authorities, the direct use of payment accounts in interbank payment transactions, e.g. through the direct use of interbank payment instruments such as SDD and SCT, is a criterion for the legal classification as demand deposits or scriptural money. E-money accounts, on the other hand, usually form a closed loop (with the exception of e-money in the form of prepaid credit cards). The use of e-money in interbank payment transactions can only take place via a bridge (de facto: exchange between two types of money through withdrawal from the e-money account and deposit on current account and vice versa). Under the realistic assumption that the decentralised DLT accounts form an island-like parallel circuit connected to the mainland via bridges, a supervisory classification as EMT is obvious and actually mandatory from a systemic perspective.⁶ The term “tokenised scriptural money” used today would be inherently contradictory, at least for the transitional phase of co-existence. Tokenised (commercial) bank money is not precise either but would fit better. The reinterpretation of the word “token” for decentralised DLT registrations of credit positions can unfortunately no longer be reversed in the crypto world.

What would be the technical and legal difference between a crypto asset that is exempted from MiCAR as a deposit under Art. 2 and an EMT issued by a bank that meets the requirements of MiCAR? Are they not the same product? Same product, same rules? Well, into which regulatory pot do these crypto assets in the form of account based DLT commercial bank money fall? Do the MiCAR requirements for EMT also apply to this product?

Another argument for classifying account-based DLT commercial bank money as EMT is MiCAR’s stated aim that “any definition of ‘e-money tokens’ should be as wide as possible to capture all the types of crypto-assets referencing one single fiat currency” (recital 10).

The answer to the question of classification is perhaps premature as long as the MiCAR is not available in its final version. Until then, there is still time for the banks to clarify this important question, because it is by no means a purely academic question. The classification as EMT would have considerable consequences for the issuing banks based on the current draft version of the MiCAR. Thus, according to Art. 43 (1b) of the MiCAR, several provisions of the EMD2 (Titles I and II) that are only relevant for e-money institutions when issuing traditional e-money (such as capital adequacy requirements) would also apply to credit institutions when issuing EMTs.

It is noteworthy that in a recently published report, the Deutsche Bundesbank classifies “tokenised commercial bank money” without discussion under “classical forms of money” and not as “crypto-tokens“, suggesting that MiCAR does not apply to this manifestation of scriptural money (book money).⁷ Are we perhaps engaging in a phantom discussion here?

P.S.: If you are also interested in the question under which conditions e-money is to be classified as traditional e-money or as an e-money token (EMT), read our 14-page commentary on MiCAR in the new double issue of the PaySys Report (No. 2-3/2021). ⁸

1 https://paytechlaw.com/kryptowerte-fiatgeld-anmerkungen-micar/

2 There is even the question of whether the usual DLT protocols are suitable for genuine digital bearer instruments. See ECB, Report on a digital euro, October 2020, p. 30.

3 David Chaum, Christian Grothoff and Thomas Moser, How to issue a central bank digital currency, SNB Working Papers 3/2021, p. 9

4 IMF Working Paper WP/20/254, Legal aspects of Central Bank Currency: Central Bank and Monetary Law Considerations, November 2020, p. 12.

5 See podcast “PayTechTalk” No. 58 with Christian Walz and Hugo Godschalk:
https://paytechlaw.com/paytechtalk-58-einlagengeschaeft/
The British regulator FCA has recently (18 May 2021) asked e-money issuers to explicitly inform their account holders about the difference between an e-money account and a current account (especially with regard to the different security requirements). For many account holders, the difference is obviously not sufficiently known.

6  The FinTech Council at the Federal Ministry of Finance assumes in its statement “The digital, programmable euro” (01/2020) that it will be classified as e-money. See p. 12-13. At the time of publication of this statement, however, the Commission’s MiCAR draft was not yet available.

7 See Deutsche Bundesbank, Digitales Geld: Optionen für den Zahlungsverkehr, in: Monatsbericht April 2021, p. 69f. and p. 72.

8 https://paysys.de/paysys-report/

Cover picture: Copyright © Adobe/Yuriy Mazur