> For the complete documentation index, see [llms.txt](https://www.mica.wtf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.mica.wtf/eu-level/soft-law/reports-and-advice/report-on-tokenised-deposits.md).

# EBA Report — Tokenised Deposits

|                 |                                                                                                                                                |
| --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| **Authority**   | EBA                                                                                                                                            |
| **Legal basis** | EBA mandate — banking law / MiCA perimeter                                                                                                     |
| **Status**      | In force                                                                                                                                       |
| **Source**      | [EBA (PDF)](https://www.eba.europa.eu/sites/default/files/2024-12/4b294386-1235-463f-b9b5-08f255160435/Report%20on%20Tokenised%20deposits.pdf) |

### Overview

This EBA report examines tokenised deposits — bank deposits issued in tokenised form on [distributed ledger technology](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/mica/distributed-ledger-technology.md) — and their interaction with existing banking, payments and [crypto-asset](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/mica/crypto-asset.md) frameworks. It aims to distinguish bank [deposit](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/dgsd/deposit.md) tokenisation from EMTs, ARTs and other MiCA-scope crypto-assets, and to identify any prudential or conduct questions raised by this product class.

### Key points

* Describes tokenised deposits and their typical business models (intra-bank, multi-bank, retail and wholesale).
* Analyses the legal qualification of tokenised deposits under the [deposit](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/dgsd/deposit.md), payments and banking acquis.
* Distinguishes tokenised deposits from EMTs and other MiCA crypto-assets — tokenised deposits remain deposits.
* Considers prudential, AML/CFT, conduct, payments and operational-risk implications.
* Highlights areas where supervisory clarification or future legislative work may be required.
* Complements EBA work on crypto-assets, digital finance innovation and EU digital euro discussions.

### Full document

Available on the [EBA website (PDF)](https://www.eba.europa.eu/sites/default/files/2024-12/4b294386-1235-463f-b9b5-08f255160435/Report%20on%20Tokenised%20deposits.pdf).

### Executive summary

As part of the European Banking Authority's (EBA) 2024-25 priorities on innovative applications, an analysis on the tokenisation of deposits by credit institutions has been carried out to identify existing cases, potential benefits and challenges, and actions the EBA and competent authorities may take to address any identified issues.

Tokenisation, in the context of financial assets, refers to the process of representing rights in a digital form, using [distributed ledger](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/mica/distributed-ledger.md) technology (DLT) or similar technology. Tokens can be represented directly on the DLT ('native tokens'), or they can represent 'off-chain' assets ('non-native tokens').

The tokenisation of a deposit, in the narrow sense of recording the deposit claim of a depositor against the [credit institution](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/crr/credit-institution.md) on the DLT instead of a traditional ledger (hereinafter referred to as a 'tokenised deposit'), does not per se alter the fundamental nature of the claim and thus its regulatory qualification as a deposit. At present, only one 'live' case of a tokenised deposit has been identified by the EBA in the European Economic Area (EEA), as a result of a survey to competent authorities and desk-based analysis. Other observed cases relate to tokenised forms of private money, such as [electronic money](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/emd2/electronic-money.md) tokens (EMTs) 1 or other tokenised assets.

Notwithstanding the limited use case to-date, there is a growing interest from credit institutions to deploy deposits on the DLT, with a commensurate increased attention from regulatory and supervisory authorities globally 2 .

Based on feedback provided by competent authorities, the EBA outlines in this report preliminary observations as to potential benefits and challenges of the use of tokenised deposits, which may vary depending on design parameters.

In the light of the assessment of tokenised deposits set out in this report, no immediate need to adjust the regulatory and supervisory framework has been identified, on account of the limited market presence and experience with such tokens to-date, and lack of evidence to inform any potential changes to such frameworks at the current time. However, the EBA has established the needs to (i) support the industry and competent authorities in adopting a convergent approach to [crypto-asset](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/mica/crypto-asset.md) classification, (ii) facilitate more consistent monitoring of potential tokenised deposit use cases in the EU, and based on empirical observations, (iii) carry out further targeted analyses as to the adequacy of the regulatory framework for deposits deployed on the DLT, following a riskbased approach.

To meet these needs, the report establishes indicative characteristics that may be used to distinguish tokenised deposits from EMTs issued by credit institutions under MiCAR. In 2025, the EBA will take steps to promote ongoing monitoring and dialogue between competent authorities and industry on tokenised deposits, including pursuant to [Article 97](/mica/title-vii-competent-authorities-eba-and-esma-art.-93-138/chapter-1/article-97.md) of MiCAR 3 , to keep under review the need for potential regulatory or supervisory actions.

1 As defined in [Article 3(1)](/mica/title-i-subject-matter-scope-and-definitions-art.-1-3/article-3.md)(7) of Regulation (EU) 2023/1114 of the European Parliament and of the Council of 31 May 2023 on markets in crypto-assets (MiCAR), OJ L 150, 9.6.2023, p. 40 -205.

2 See, for example, Bank of England PRA, Dear CEO Letter, Innovations in the use by deposit-takers of deposits, e-money and regulated stablecoins, November 2023 and Bank of Japan, Deposit Tokenization: Survey of Overseas Initiatives, August 2024.

More generally, the EBA recalls its observations of 2014 and 2020 4 on the absence of a harmonised definition of 'deposit' for the purposes of the application of the EU banking acquis (which regulate the activity of accepting deposits and other repayable [funds](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/mica/funds.md) from the public) and the need for further convergence. The EBA reminds the European Commission of the continued relevance of these observations. The observations are not relevant to the Deposit Guarantee Schemes Directive (DGSD) which provides a definition of 'deposit' for the specific purposes of that Directive and which, as observed by the EBA in 2019 5 does not require immediate amendment notwithstanding the development of innovative products.

3 [Article 97](/mica/title-vii-competent-authorities-eba-and-esma-art.-93-138/chapter-1/article-97.md) of MiCAR mandates the European Supervisory Authorities jointly to promote convergence on the classification of crypto-assets, including by issuing opinions to competent authorities and reports on the classification of crypto-assets, including those excluded from the scope of MiCAR.

4 See EBA Report to the European Commission on the perimeter of credit institutions established in the Member States, November 2014 and Opinion on matters relating to the perimeter of credit institutions, November 2014 and EBA Opinion on elements of the definition of [credit institution](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/crr/credit-institution.md) under Article 4(1), point 1, letter (a) of Regulation (EU) No 575/2013 and on aspects of the scope of the authorisation, September 2020.

5 EBA Opinion on the eligibility of deposits, coverage level and cooperation between deposit guarantee schemes, August 2019.

### 1. Introduction and purpose of the analysis

1. The European Banking Authority (EBA) has a statutory duty to monitor and assess market developments, including technological innovation and innovative financial services 6 . In February 2024, the EBA's Board of Supervisors (BoS) endorsed the EBA's priorities on innovative applications for 2024-25 7 , which include the monitoring of tokenisation, specifically with regard to tokenised deposits.
2. Tokenisation refers to the process of representing an asset as a digital record (token) on a common programmable platform, using distributed ledger technology (DLT) or similar technology (Financial Stability Board (FSB), 2023 8 and Bank for International Settlements (BIS), 2023 9 ). DLT is a technology that enables the operation and use of distributed ledgers. Each '[distributed ledger](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/mica/distributed-ledger.md)' constitutes an information repository that keeps records of transactions and that is shared across, and synchronised between, a set of DLT network nodes using a [consensus mechanism](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/mica/consensus-mechanism.md) ([Article 3(1)](/mica/title-i-subject-matter-scope-and-definitions-art.-1-3/article-3.md)(1) and (2) of MiCAR). Distributed ledgers can support smart contracts, which are self-executing programs triggered when a set of pre-defined conditions are met and enabling the automation of transactions/events.
3. Accordingly, for the purpose of this report, 'tokenised deposit' is to be understood as a deposit balance recorded on a DLT or similar technology. Such tokenised deposits may be 'native' or 'non -native'. Native tokens refer to tokens that can be issued, stored and transferred on the DLT but do not represent rights in relation to tangible or intangible assets or services outside the DLT. Non-native tokens are those that represent rights in relation to tangible or intangible assets or services that exist outside the setting of the DLT (e.g. a right to control assets recorded on a traditional ledger).
4. The acceptance of deposits and other repayable [funds](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/mica/funds.md) from the public characterises the activity of credit institutions in the EU and the consequent regulatory treatment under the Capital Requirements Directive and Regulation (CRD/CRR) 10 . In the EU only credit institutions are permitted to accept deposits and other repayable funds from the public 11 . Therefore, activities

6 Article 9(2) of Regulation (EU) No 1093/2010 (EBA Founding Regulation), OJ L 331, 15.12.2010, p. 12 -47.

7 EBA Work Programme 2024, September 2023.

8 FSB, The Financial Stability Risks of Decentralised Finance, February 2023 and FSB, The Financial Stability Implications of Tokenisation, October 2024.

9 BIS, The tokenisation continuum, BIS Bulletin No 72, Aldasoro, Doerr, Gambacorta, Garratt, Koo Wilkens, April 2023.

10 Directive 2013/36/EU of the European Parliament and of the Council of 26 June 2013 on access to the activity of credit institutions and the prudential supervision of credit institutions and investment firms (CRD), OJ L 176, 27.6.2013, p. 338 -436; and Regulation (EU) No 575/2013 of the European Parliament and of the Council of 26 June 2013 on prudential requirements for credit institutions and investment firms and amending Regulation (EU) No 648/2012 (CRR), OJ L 176, 27.6.2013, p. 1 -337.

11 'Credit institution' is defined in point (1) of Article 4(1) of the CRR as ' an undertaking the business of which is to take deposits or other repayable funds from the public and to grant credits for its own account ' . However, ' d eposit' and 'other

* involving tokenised deposits, since already regulated, are excluded from the scope of the EU's Markets in Crypto-assets Regulation (MiCAR) (see further section 3 of this report).

5. The objective of this report is to facilitate awareness among competent authorities of tokenised deposit cases and their potential benefits and challenges. The report is also intended to promote convergence among authorities in the classification of tokenised deposits as compared to [electronic money](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/emd2/electronic-money.md) tokens (EMTs), which are in scope of MiCAR.
6. To this aim, this report sets out a stocktake of projects observed both in the European Economic Area (EEA) and outside the EEA. It highlights expected use cases and potential benefits as well as possible challenges. The report also identifies a series of indicative characteristics that help distinguish tokenised deposits from EMTs issued by credit institutions.
7. The report is structured as follows: after describing the methodology used to carry out this analysis (Section 2), the report highlights the regulatory framework applicable to deposit-taking in the EU (Section 3). It then provides an overview of tokenised deposit projects and cases reported by EEA competent authorities to the EBA, and some examples drawn from outside the EEA (Section 4). On this basis, the following sections identify potential benefits and challenges (Sections 5 and 6). The report concludes with a summary of findings and next steps (Section 7).

### 2. Methodology

### 8. The report has been informed by the following:

* a. Survey to competent authorities: the EBA issued a survey on tokenised deposits to competent authorities in March 2024 ('the March 2024 survey'). The survey consisted of eight questions with the objectives to carry out a stocktake of approaches to national definitions of 'deposit', projects to tokenise deposits by credit institutions in the EEA, and to identify possible opportunities and risks, as well as any regulatory issue or supervisory challenges linked to the tokenisation of deposits. In total, 22 competent authorities responded to the survey.
* b. Interviews with national competent authorities (NCAs): where NCAs reported projects by credit institutions to tokenise deposits, interviews were carried out by EBA staff to discuss the use case with the NCA, and any specific opportunities and challenges identified.
* c. Interview with credit institutions on a project to tokenise deposits: EBA staff held a discussion with industry representatives on a project to engage in the tokenisation of commercial bank money held in bank deposit accounts.
* d. Market monitoring: the EBA conducts semi-annual Risk Assessment Questionnaires (RAQs) involving a sample of 85 banks. As part of the Spring 2024 RAQ 12 , the EBA included for the first time a question on bank expectations to engage in the activity of tokenised deposits in the short to medium term.
* e. Desk-based research: academic and institutional papers addressing the issue of tokenising deposits, including topic analyses of standard setting bodies, were reviewed and news monitoring carried out of projects to tokenise deposits by banks established outside the EEA.

9. Data limitations arise from the very few cases of tokenised deposits observed globally and in view of the novelty of the topic, on which publications are relatively scarce to-date.

12 See results of the Spring 2024 on the EBA website, Risk assessment Report, July 2024.

### 3. Overview of the regulatory framework applicable to deposit-taking

10. In recent years, the use of crypto-assets, and wider asset tokenisation, has gained momentum within the EU financial sector. Recognising the potential opportunities and risks, and after consulting both the EBA and the European Securities and Markets Authority (ESMA) 13 , in September 2020 the European Commission (EC) published its Digital Finance Strategy 14 accompanied by the legislative proposals for what became MiCAR and the Regulation (EU) 2022/858 (DLT Pilot Regime). 15
11. MiCAR establishes a bespoke regulatory regime for the issuing, offering to the public and admission to trading in the EU of crypto-assets, including asset-referenced tokens (ARTs) and EMTs 16 , and regulates the provision of crypto-asset services.
12. Excluded from the scope of MiCAR are crypto-assets that are non-fungible or qualify as specific types of financial product to which other regulation applies 18 . The list of excluded crypto-assets includes crypto-assets that qualify as financial instruments 19 and crypto-assets that are

Table 1. Key definitions in MiCAR 17

| Term                   | MiCAR definition                                                                                                                                                                                                    |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Crypto-asset           | A digital representation of a value or of a right that is able to be transferred and stored electronically using distributed ledger technology or similar technology                                                |
| Asset-referenced token | A type of crypto-asset that is not an electronic money token and that purports to maintain a stable value by referencing another value or right or a combination thereof, including one or more official currencies |
| Electronic money token | A type of crypto-asset that purports to maintain a stable value by referencing the value of one official currency                                                                                                   |

13 EBA, Report with advice for the European Commission on 'crypto -assets' , January 2019 and ESMA, 'Advice on Initial Coin Offerings and CryptoAssets' , January 2019.

14 European Commission, Digital finance package, European Commission communication, September 2020.

15 Regulation (EU) 2022/858 of the European Parliament and of the Council of 30 May 2022 on a pilot regime for market infrastructures based on [distributed ledger technology](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/mica/distributed-ledger-technology.md), OJ L 151, 2.6.2022, p. 1 -33.

16 More stringent requirements apply to EMTs and ARTs than for other types of crypto-assets in scope of MiCAR given the use of EMTs (or, in the case of ARTs, potential use) as a means of payment.

17 For the full list of definitions, see [Article 3(1)](/mica/title-i-subject-matter-scope-and-definitions-art.-1-3/article-3.md) of MiCAR.

18 [Article 2(4)](/mica/title-i-subject-matter-scope-and-definitions-art.-1-3/article-2.md) of MiCAR.

19 As defined in Article 4(1)(15) of Directive 2014/65/EU of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments (MiFID II), OJ L 173, 12.6.2014, p. 349.

'deposits' 20 , including structured deposits 21 , and cryptoassets that are 'funds' 22 (except where funds qualify as EMTs). This reflects the 'technology neutrality' principle of the EC: the mere act of digitally representing a value or right (including a financial product) as a crypto-asset does not change its regulatory qualification and, as such, it should remain regulated pursuant to the applicable sectoral regulation.

13. For the purposes of the exclusion from MiCAR, 'deposit' is defined by reference to Article 2(1), point (3) of Directive 2014/49/EU (the Deposit Guarantee Schemes Directive; DGSD) 23 :

'deposit' means a credit balance which results from funds left in an account or from temporary situations deriving from normal banking transactions and which a credit institution is required to repay under the legal and contractual conditions applicable, including a fixed-term deposit and a savings deposit, but excluding a credit balance where:

* (a) its existence can only be proven by a [financial instrument](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/mica/financial-instrument.md) as defined in Article 4(17) of Directive 2004/39/EC of the European Parliament and of the Council, unless it is a savings product which is evidenced by a certificate of deposit made out to a named person and which exists in a Member State on 2 July 2014;
* (b) its principal is not repayable at par;
* (c) its principal is only repayable at par under a particular guarantee or agreement provided by the credit institution or a third party.

14. This means that, when in the form of a crypto-asset, deposits as referred to in the DGSD are not regulated under MiCAR. Instead, the activity of accepting deposits from the public continues to be regulated by the CRD. However, the term 'deposit' is not defined for the purpose of the application of the CRD/CRR, as observed in an EBA 2014 Report 24 and in subsequent Opinions to the European Commission 25 . The CRD and CRR impose on credit institutions thorough prudential standards, including own funds, liquidity and leverage requirements, as well as requirements for effective governance and risk management, including operational risks. Moreover, credit institutions are required to contribute to Deposit Guarantee Schemes (DGSs) as a means to protect covered depositors 26 in case of failure.

20 As defined in Article 2(1), point (3) of Directive 2014/49/EU of the European Parliament and of the Council of 16 April 2014 on deposit guarantee schemes (DGSD), OJ L 173, 12.6.2014, p. 149.

21 'Structured deposit' is defined by reference to Article 4(1), point (43) of MiFID II.

22 'Funds' are defined by reference to Article 4, point (25) of Directive (EU) 2015/2366 of the European Parliament and of the Council of 25 November 2015 on payment services in the internal market (PSD2), OJ L 337, 23.12.2015, p. 35.

23 In the context of the 2019 Opinion on the eligibility of deposits, coverage level and cooperation between deposit guarantee schemes , the EBA considered that the definition of a 'deposit' needs not be amended in light of the development of innovative products by credit institutions. Indeed, the EBA deemed that the DGSD definition was already principles-based, and providing an exhaustive list of products would not be achievable.

24 EBA Report to the European Commission on the perimeter of credit institutions established in the Member States, November 2014.

25 See EBA 2014 and 2020 Opinions, op. cit.

26 Covered deposits are 'deposits' as defined in the DGSD, subject to a coverage threshold per depositor, see the European Commission website 's dedicated page.

### 4. Tokenised deposit cases identified in the market to-date

15. Following the notion of tokenised deposit identified above, the results of the March 2024 survey and market monitoring evidenced very few examples of tokenised deposits globally. NCAs reported one use case and one project to tokenise deposits in the EEA, mostly to facilitate settlement of securities for wholesale clients. Nevertheless, the Spring 2024 RAQ 27 evidenced a growing interest among the largest credit institutions in the EEA to engage in the activity of deposit tokenisation within the next two years or more. To facilitate market monitoring going forward, the EBA has developed a targeted questionnaire for competent authorities to use in the context of ongoing supervisory dialogue with credit institutions on projects to tokenise deposits by EEA-established credit institutions 28 .

### 4.1. Tokenised deposit projects in the EEA

16. Of the 22 respondent competent authorities to the March 2024 survey, two NCAs reported each a tokenised deposit project by a credit institution established in their jurisdiction, including one project explored by a consortium of several banks. Besides, the Spring 2024 RAQ to EEA credit institutions included for the first time a question on bank expectations to engage in the offer of tokenised deposits. It revealed that 17% of the 85 credit institutions surveyed expect to engage in the use of tokenised deposits in a horizon of one-two years or more.
17. Among the projects, only one was considered adopted. At the time when the use case was developed (before MICAR), the NCA confirmed the classification as a deposit (as opposed to emoney) (see text box).

### Text box: Tokenised deposit use case

An EEA credit institution has deployed its own private and permissioned DLT to enable the use of deposits and securities tokens on the same DLT platform (in order to achieve the atomic settlement of securities against funds, i.e. in a Delivery versus Payment (DvP) mode). The token evidences a claim against the credit institution and, as a tokenised deposit, could -in principle -pay interest. The protocol used is a transaction-based model (UTXO) combined with an account view.

27 EBA website, Spring 2024 RAQ report, op. cit.

28 The questionnaire encompasses questions (i) to map existing or projected cases to tokenise deposits by EEA credit institutions, (ii) to describe the project(s), for instance the prospected clients and the type of technology used, as well as (iii) to understand the overall engagement of the credit institution in other crypto-asset-related activities.

While tokens are technically created and transferred on the DLT, the legal rights of participants are derived from the account view in their wallet and the applicable contractual framework -not from the existence of, or ability to, directly control specific underlying tokens. As regards the legal claim of the depositor on the credit institution, there are no changes to the contractual relation between the credit institution and the deposit holder. The arrangement established by the issuing credit institution was held out as a deposit arrangement with functionality materially comparable to that of other existing arrangements that are plainly deposits. This use case therefore presents characteristics of a tokenised deposit as defined in this report.

The credit institution envisages issuing a restricted number of securities on the DLT platform, where access is restricted to a limited number of participants who are already clients of the credit institution. In the current first phase of deployment, the client is using the tokenised deposits for the purchase of securities at issuance only.

18. The other project is in a testing phase and is not yet confirmed as a tokenised deposit. It concerns the planned tokenisation of commercial bank money by a consortium of five credit institutions and industrial firms established in one jurisdiction. The conversion of funds held in the deposit account to a token would involve debiting a traditional bank account to be credited on the distributed ledger. Conversion back would involve burning the token and crediting the traditional bank account.
19. The consortium recently ran a proof of concept involving five companies (the clients) through three different sandboxes. The first test converted balances held by clients on traditional bank accounts into on-chain accounts to carry out transactions between accounts held with the same credit institution, and then between clients of different credit institutions, using the tokens. In the latter case, an interbank settlement happened on the Real-Time Gross Settlement (RTGS) system. A series of use cases were also tested to assess the feasibility of integrating the token into business processes and to automate payments for the delivery of goods, using smart contracts. A third series of use cases tested multi-currency payments.

### 4.2. Projects outside the EEA

20. Some banks outside the EEA have announced projects to develop tokenised deposits. However, certain cases do not typically involve the tokenisation of the deposit claim itself. Instead, they typically involve withdrawal of funds from the deposit account, which are then exchanged into a token for use on a transfer/payment rail, complementing the bank's existing infrastructure (as

is the case with the JPM Coin 29 ). The three following tokenised deposit cases have been observed.

21. In November 2022, UK Finance Limited (UK Finance) released a white paper on the creation of a Regulated Liability Network (RLN) 30 . The RLN concept aims to become a regulated Financial Market Infrastructure (FMI) that would operate a shared ledger to record, transfer, and settle liabilities of regulated entities such as central bank money, commercial bank money, electronic money and regulated crypto-assets 31 . In 2024, an experimentation phase involved 11 financial institutions. It tested the platform across one wholesale use case and four different retail use cases. It covered a range of different options, notably exploring various ways of tokenising deposits : in a first 'direct model', consumer liabilities are represented in either the traditional ledger or the distributed ledger. Hence, to calculate the total consumer deposit liabilities, balances on both ledgers must be summed. Alternatively, in the 'indirect model', the distributed ledger would function as a subledger of the traditional ledger, whereby the entirety of the liabilities of the bank to its retail customers is still captured by the traditional ledger. Among the findings, UK Finance argued that the tokenisation of deposits can be implemented so as to be neutral from a legal and regulatory perspective, relatively to deposits on traditional bank ledgers 32 .
22. In October 2023, J.P. Morgan declared it was awaiting US regulatory approval for the launch of a 'deposit token' 33 to be used for cross-border payments and settlements, claiming that the underlying infrastructure was ready for its deployment. Unlike the JPM Coin, which only allows transactions between institutional clients of JP Morgan, the deposit token aims to enable transfers involving clients of different banks, including for the settlement of securities running on the same blockchain as the deposit token.
23. Mastercard is also supporting various tokenised deposit explorations and projects. In June 2023, it announced the launch of a Multi Token Network (MTN), a blockchain network to support bank tokenised deposits, stablecoins and central bank digital currencies (CBDCs) 34 . In May 2024, a first live test of the MTN involving tokenised deposits and tokenised assets in collaboration with Standard Chartered Bank Hong Kong (SCBHK), Mox Bank and Libeara was carried out 35 . A proof-

29 In 2019, the US bank J.P. Morgan launched the JPM Coin on the private Quorum blockchain, a variant of the Ethereum

network. The JPM Coin was designed to allow institutional clients to transfer US Dollars held on deposit accounts with J.P. Morgan using a DLT. The purpose was to facilitate payments such as Delivery versus Payment (DvP) or Payment versus Payment (PvP). To use this facility, the client must have a deposit balance for the relevant sum which can be swapped into JPM Coins. JPM Coins can then be used to make transactions over the Quorum blockchain. A recipient can redeem the token at 1:1 ratio for fiat currency held by J.P. Morgan and transferred to the recipients (traditional) deposit account. While initially JPM Coin was designed to support transactions denominated primarily in US dollars, in June 2023, the investment bank expanded the capabilities of the JPM Coin to euro-denominated transactions.

30 UK Finance, The Regulated Liability Network, Whitepaper, November 2022.

31 UK Finance and EY, Regulated Liability Network UK Discovery Phase, September 2024.

32 UK Finance, UK RLN Experimentation Phase, Summary Report, September 2024.

33 Reported as such a 'deposit token' by J.P. Morgan. However, the report does not delve more into the differentiation between the terms 'tokenised deposit' and 'deposit token'.

34 Mastercard, Mastercard announces Multi Token Network (MTN) to scale and secure blockchain technology, Press release, June 2023.

35 Mastercard, Standard Chartered, Mox and Libeara successfully complete a proof-of-concept pilot on tokenized deposits and tokenized carbon credits through regulatory sandbox, Press release, May 2024. Mox Bank and Libeara are

of-concept pilot was run using tokenised carbon credits within the Fintech Supervisory Sandbox of the Honk Kong Monetary Authority. As a first step, a client of Mox Bank deposited funds into Mox bank account, which is tokenised through the Mastercard MTN. The client requested to buy a carbon credit. Mox requested that SCBHK tokenises the carbon credit through the tokenisation service provider Libeara. Ultimately, an atomic swap was performed between the tokenised deposit and the tokenised carbon credit on the MTN.

### 4.3. Design of tokenised deposits

24. Overall, it can be acknowledged that tokenised deposits may be deployed in different ways and the design choices can have an impact on potential opportunities and risks. Two design parameters are particularly relevant: (i) the ledger arrangement, and (ii) the nature of the claim/any other rights (e.g. to interest) represented by the token.
25. Regarding the ledger arrangement, a credit institution may opt to migrate fully to a single distributed ledger, or partially by adding a DLT layer to the traditional bank ledger. In a 'one -layer model', DLT -based deposits could be deployed in the form of native tokens, whereby the supporting distributed ledger serves as the primary record-keeping ledger. Alternatively, in a 'two -layers model', tokenised deposits would be non -native, whereby on-chain deposits would still necessitate a corresponding off-chain deposit bank account where the asset also exists outside the DLT, therefore requiring the implementation of reconciliation processes (see illustrations in diagrams in the Annex).
26. Regarding the actual representation of the claim, tokenised deposits could in principle be either 'account -based' or 'token -based'. In the cases observed to -date, the tokenised deposit is account-based, i.e. the claim of the deposit-holder is recorded on the DLT and bound to the identity of the account-holder, and, as a non-bearer instrument, the claim is not directly transferable to a non-client of the bank. However, a token-based model may also be contemplated, i.e. where the crypto-asset can be transferred from one person to another without the knowledge of the bank, akin to a bearer instrument. While the account-based model would resemble most conventional deposits recorded on traditional bank ledgers, the legal viability of a token-based model for deposits would need careful assessment against the applicable regulatory framework, and to determine its appropriate regulatory classification. Therefore, the remainder of this report concerns the account-based model of tokenised deposits.

subsidiaries of SCBHK. Mox bank is the SCBHK virtual bank. Libeara is a tokenisation platform launched by SC Ventures, Standard Chartered's innovation, fintech investment and ventures arm .

### 5. Main potential benefits

27. The use of tokenised deposits has the potential to offer some benefits compared to deposits recorded on a traditional ledger, in particular regarding programmability and efficiency, albeit the precise benefits may vary depending on the use case, on design parameters and should also be considered against the potential risks as identified in section 6. The main potential benefits summarised in this section are based on the responses to the March 2024 survey and deskbased analysis.

### 5.1. The use of programmability to make transactions more efficient

28. Reliance on DLT for recording and transferring deposit balances could permit to implement programmability, a new functionality currently not available in traditional banking systems.
29. Programmability refers to the ability to execute a code on the distributed ledger to automate actions. Programmability is often deployed using smart contracts. Such rule-based interactions between parties could remove the need for intermediaries to initiate and complete transactions, potentially also in use cases involving tokenised deposits. Programmability could potentially contribute to improving the efficiency of overall transaction processes, including potentially reducing costs and time 36 . The use of DLT could also facilitate atomic settlements using multiple tokenised assets, including for complex, multi-asset transactions 37 . Furthermore, integration of tokenised deposits in operational processes could allow to leverage these benefits and support the improvement or development of new integrated financial system infrastructures 38 .

### 5.2. Compliance with anti-money laundering and countering the financing of terrorism requirements

30. Following the principle of technology neutrality, requirements set out in the anti-money laundering and countering the financing of terrorism (AML/CFT) framework, such as Directive

36 The tokenisation of the payment leg (e.g. in the form of a tokenised deposit) coupled, for instance, with the tokenisation of financial instruments could enhance the DvP mechanism by allowing on-chain automated and real-time settlement.

37 FSB, The Financial Stability Implications of Tokenisation, op. cit.

38 See example of the RLN, op. cit. and Project Agora. With project Agora, the BIS is exploring how tokenisation of wholesale central bank money and commercial bank deposits on programmable platforms can improve the monetary system, building on a unified ledger concept. It seeks to bring public authorities and private financial institutions on a common unified ledger platform, which could overcome structural inefficiencies especially arising in cross-border exchanges (e.g. different legal requirements, operating hours and time zones). It suggests that a public-private programmable core financial platform could enhance the functioning of the monetary system and provide new solutions using smart contracts and programmability, while maintaining its two-tier structure.

BIS press release, Project Agorá moves to next phase and opens up call for private sector participation, April 2023, updated May 2024.

(EU) 2015/849 (AMLD) 39 and Regulation (EU) 2023/1113 (the Regulation on Transfer of funds and certain crypto-assets/FTR recast) 40 , should apply to deposits irrespective of the underlying technology used to record and transfer deposit balances. To some extent, reliance on DLT for tokenised deposits may facilitate compliance by the credit institution with these AML/CFT requirements, compared to deposits recorded on traditional ledgers.

31. Overall, financial institutions consider that the use of DLT can significantly enhance transparency and information sharing 41 , albeit the data may need to be coupled with other data in order to be useful for AML/CFT/wider compliance purposes. Tokenised deposits with cryptographic security would require secure private keys for access and transfers, which may make it more difficult for unauthorised parties to manipulate or steal funds, thus potentially reducing the risk of fraud (albeit private key theft is not unknown). Additionally, whenever an entry is approved by the system, all copies of the ledger are automatically updated and are immutable. The underlying DLT to record deposits could facilitate the traceability of the information, assuming a proper digital identification process has been set up, by recording the full chain of transactions from its onset.
32. At present, traditional payment systems might often rely on periodic manual reviews and delayed transaction processing. Real-time capabilities embedded into DLT-based systems for tokenised deposits could enhance the speed and effectiveness of AML/CFT measures, provided that the credit institution has advanced monitoring systems and adequate capabilities to react and process information in a timely manner 42 . The programmability could allow gateways to automate transaction screening on the DLT. For instance, a smart contract can automatically block a transaction order when it involves an unidentified or a blacklisted address. The obliged entity deploying the smart contract, including when relying on third party providers 43 , will remain liable for all customer due diligence and other AML/CFT obligations, and therefore responsible for possible breaches of such obligations.

39 Directive (EU) 2015/849 of the European Parliament and of the Council of 20 May 2015 on the prevention of the use of the financial system for the purposes of money laundering or terrorist financing, amending Regulation (EU) No 648/2012 of the European Parliament and of the Council (AMLD), OJ L 141, 5.6.2015, p. 73 -117.

40 Regulation (EU) 2023/1113 of the European Parliament and of the Council of 31 May 2023 on information accompanying transfers of funds and certain crypto-assets (AMLD), OJ L 150, 9.6.2023, p. 1 -39.

41 EBA Factsheet on the use of DLT, op. cit. See also EBA, Report on the prudential risks and opportunities arising for institutions from fintech, July 2018.

42 See EBA-ESMA-EIOPA, Joint Opinion On the use of innovative solutions by credit and financial institutions in the customer due diligence process, January 2018.

43 Article 25 of the AMLD.

### 6. Challenges in the deployment of tokenised deposits

33. Notwithstanding the potential benefits, tokenised deposits may also pose potential challenges, which may depend on the use case and design choices. The main challenges addressed in this section are based on the responses to the March 2024 survey and desk-based analysis.

### 6.1 Consumer protection: financial literacy and inclusion

34. Increasing the development of innovative financial services and tools can open up new opportunities for consumers, attract new clients and benefit unbanked individuals. However, these potential benefits can face limitations in cases where the level of technological and financial education of retail users is insufficient, which could outweigh advantages from the perspective of financial inclusion.
35. The use of tokenised deposits is likely to necessitate access to digital channels, and most probably appropriate hardware able to support applications allowing to access digital wallets. This may pose risks of financial exclusion consistent with wider challenges associated with digitisation of channels to access to financial services. Supplemental technological and financial literacy may be needed for consumers to become familiar with the use of tokenised deposits e.g., mechanisms regarding on- and off-ramps and transaction initiation using a tokenised deposit account. The use of tokenised deposits may also necessitate higher consumers awareness of inherent risks, notably in terms of operational risks and cyber security.
36. Additionally, the development of various forms of retail-facing crypto-assets, including EMTs, may create confusion for targeted retail users, as to the different levels of rights, protection (which comprises DGS eligibility) and risks of each type of crypto-asset. This risk of confusion may be exacerbated in the situation where the same credit institution may offer consumers access to multiple accounts for different types of tokenised products. Such risks would need to be managed with effective disclosures and information requirements coupled with financial education and consumer awareness actions. Additionally, monitoring efforts will be important, in particular regarding regulatory classification of crypto-assets, to ensure consistency in both the classification of retail-facing products and their associated disclosures.

### 6.2. Application of regulatory definitions

37. Competent authorities and credit institutions may face challenges in classifying crypto-assets, including the delineation between tokenised deposits and EMTs issued by credit institutions as both involve a claim of the 'depositor'/ 'token holder' against the credit institution. Indeed, competent authorities observed in their responses to the March 2024 survey that it can prove challenging to differentiate between a sight deposit that pays no interest and e-money issued

by a credit institution. By analogy, competent authorities may face similar challenges in the context of tokenised claims.

38. Based on NCA feedback, the elements set out in the table below can facilitate competent authorities in carrying out a case-by-case assessment and therefore in determining the regulatory status of each tokenised claim and the applicable regulatory framework. Importantly, the nature of the claim, the associated rights and protections established by regulation are different.
39. In the EU, a credit institution typically establishes a continuous contractual relationship with a client in order to accept deposits from a client 44 . Hence, ownership of the deposit is linked to the identity of the account-holder. In the case of EMTs, the ownership of an EMT is linked to possession of the token itself (as compared to e-money which may also be based on a continuous contractual relationship).
40. The claim on the credit institution in the form of a tokenised deposit, by representing bank account balances that are nominative, typically cannot be transferred to another individual 45 ; only the underlying funds, once withdrawn, can be transferred. A payment using tokenised deposits involves destruction of the claim on the bank of the sender, and creation of a new claim on the bank of the receiver, which is cleared by an interbank settlement frequently using central bank money 46 . Differently, EMTs are transferable private liabilities to other prospective holders, without altering the claim on the issuing credit institution; the balance-sheet of the bank is only updated at redemption 47 .
41. In terms of applicable regulatory requirements, the payment of interest on EMTs is prohibited under MiCAR 48 . Additionally, different regulations apply (e.g. DGS is applicable to eligible deposits, but not to EMTs 49 ).

44 In rare occasions, it should be noted that bearer deposits exist in some jurisdictions and do not necessarily contradict the requirement of a continual relationship. For instance, passbook deposits still exist in Austria, with a maximum balance of up to 15,000 euros. They are saving accounts that come with a physi cal notebook (the 'passbook'), therefore both the client and the bank maintain a ledger of transactions and balances. A passbook account requires in-person transactions at the bank. Nowadays, there are mostly traditional deposit accounts or online saving accounts in use.

45 On few occasions where the assignment of a deposit account to another person is possible, this usually requires the prior consent of the credit institution. Such a case could arise in the context of marriage where a person may wish to provide their spouse with access to a pre-existing bank account as either joint account holder or as a person who has a right of withdrawal of that account.

46 In the Eurosystem, TARGET2 is the RTGS.

47 See BIS, Stablecoins versus tokenised deposits: implications for the singleness of money, Garratt and Shin, BIS Bulletin No 73, April 2023.

48 [Article 50](/mica/title-iv-e-money-tokens-art.-48-48/chapter-1/article-50.md) of MiCAR. See also Recital 68 of MiCAR.

49 See Article 2(1)(3) of the DGSD, read in conjunction with Article 5.

Table 2. Characteristics delineating tokenised deposits from EMTs issued by credit institutions

| Crypto-asset Features                                                                                     | Tokenised deposit (account-based model)                                                              | MiCAREMT (issued by a credit institution)                         |
| --------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- |
| Claim against the balance-sheet of the credit institution                                                 | ✓                                                                                                    | ✓                                                                 |
| Use of DLT or similar technology                                                                          | ✓                                                                                                    | ✓                                                                 |
| Continuous contractual relationship between the credit institution and the client (deposit)/ holder (EMT) | ✓                                                                                                    | ×                                                                 |
| Transferable on secondary markets                                                                         | ×                                                                                                    | ✓ (bearer instrument 50 )                                         |
| Settlement asset                                                                                          | × 51                                                                                                 | ✓                                                                 |
| Value                                                                                                     | Nominal value of the official currency                                                               | Purported peg to an official currency                             |
| Repayable/Redeemable at par value                                                                         | ✓                                                                                                    | ✓                                                                 |
| Ability to pay interest                                                                                   | ✓                                                                                                    | ×                                                                 |
| Fixed maturity date                                                                                       | ✓ (for term deposits)                                                                                | ×                                                                 |
| Regulatory treatment 52                                                                                   | • CRD/CRRapplies. • DGScoverage under the sameconditions as traditional deposits. • AMLD applicable. | • MiCARandEMD 53 apply. • Not in scope of DGSD. • AMLDapplicable. |

### 6.3. Operational risks

42. The use of DLT for tokenised deposits introduces specific operational risks. Blockchains can be vulnerable to attacks (e.g. 51% attacks for a permissionless DLT) and failures (protocol and software vulnerabilities could potentially compromise the entire network) 54 . Outage in the blockchain-like technology could also affect the execution of transfers, and ultimately, increase operational risk.
43. Any specific operational risk will depend on the type of DLT used to deploy tokenised deposits and the 'application layer'. In general, the EBA observes that although the type of DLT used by financial institutions varies between use cases, there is a preference among credit institutions for permissioned solutions (compared to permissionless DLTs) to ensure that only prior authorised users are allowed to access the blockchain and instruct orders 55 . This may prove relevant in the case of tokenised deposits, for which credit institutions are expected to show a preference to use a permissioned DLT to limit access to actual depositor clients of the credit institution. Additionally, credit institutions may be more incentivised to opt for a permissioned DLT so that any bank holding exposures to such deposits could benefit from eligibility for Group 1a prudential treatment under the Basel Committee on Banking Supervision (BCBS) standard SCO 60 subject to meeting the conditions and in the terms established therein 56 .
44. Finally, credit institutions may externalise the provision of the underlying DLT infrastructure, which could increase critical third-party dependency risks. For instance, in the case of a shared or unified ledger, this may expand the number of credit institutions and other stakeholders relying on a same infrastructure provider and could complexify operational risk identification and management, both at individual and aggregate levels.

### 6.4. Liquidity management

45. The use of tokenised deposits may impact bank liquidity management to various extents. A few competent authorities conveyed that the use of tokenised deposits may also create additional liquidity management risks and challenges due to the potential for programmability.
46. The impact of tokenisation on deposit 'stickiness', so on bank liquidity management and the risks of bank runs, is yet to be assessed. Different variables could be considered: (i) the profile of users, who could be tech-savvy and/or wholesale clients, potentially more prone to rapid and/or large withdrawals; (ii) public confidence; and (iii) the volatility of deposits inherent to new features permitted by the use of DLT. In practice, credit institutions could constrain programmability options, for instance by limiting the amount of transactions that could be executed per on-chain deposit accounts. Hence, it is yet too early to express any definitive view on this topic, and further analysis of these variables will be needed as regulators and supervisors gain empirical evidence resulting from ongoing monitoring, to then inform any potential future

54 BCBS Working Paper, Novel risks, mitigants and uncertainties with permissionless distributed ledger technologies, August 2024.

55 EBA, Factsheet on uses of DLT in the EU banking and payments sector, April 2024.

56 BCBS, Prudential treatment of cryptoasset exposures, December 2022.

* adjustment of the prudential framework (such adjustments could be prescribed by the competent authority in the context of an exercise of supervisory discretion under Pilar 2 57 ).

47. By extension, it is too early to assess any potential wider impact of tokenised deposits on financial stability 58 . The use of DLT-based deposits will warrant further analysis as to potential additional financial system vulnerabilities triggered, such as due to potential increased interconnections, liquidity shortages resulting from programmability and operational fragilities.

### 6.5. Application of the anti-money laundering and countering the financing of terrorism rules

48. Credit institutions may require additional guidance as regards expectations toward the implementation of AML/CFT controls for DLT-based transactions initiated on-chain from tokenised deposit accounts.
49. Some competent authorities indicated that credit institutions may benefit from clarity as to whether such transaction would entail a movement of 'funds' or 'crypto -assets' for the purpose of AML/CFT. The FTR recast -applicable from 30 December 2024 -adapted the travel rule requirements to the specificities of crypto-assets, including the underlying use of DLT, with different types of information to accompany a transfer, and different layers of checks. For instance, while information accompanying a transfer of funds should include the payment account number identified by the International Bank Account Number (IBAN) for the transfer of crypto-assets, the public DLT address is recognised as a single identifier to perform the necessary AML/CFT checks. The FTR recast defines crypto-assets by reference to MiCAR, therefore excluding tokenised deposits from the definition of crypto-assets under the FTR recast. Therefore, it appears that the initiation of a transaction from a deposit account held off- or onchain wo uld entail a transfer of 'funds' for AML/CFT purposes. The application of the travel rule may benefit from clarification so as to avoid any inadvertent barrier to the use of tokenised deposits stemming from any perceived uncertainties.

57 In view of the very limited cases of tokenised deposits to-date it is not clear how competent authorities may choose to exercise such discretions. The EBA will continue to monitor this aspect with a view to promoting supervisory convergence.

58 FSB, The Financial Stability Implications of Tokenisation, op. cit.

### 7. Conclusion

50. As recalled in this report, tokenisation, in the sense of recording a deposit balance on a DLT, does not per se change the fundamental nature of the claim (the deposit), rather the ledger technology for recording the deposit. Hence, the acceptance of (tokenised) deposits from the public is regulated pursuant to the CRD/CRR following the 'technology neutrality' princ iple adopted by the European Commission.
51. The results of the March 2024 survey, the RAQ and observations drawn from wider market monitoring confirm that there is only one 'live' case and two reported projects of tokenised deposits to-date in the EEA. In view of the limited cases, the EBA considers it too early to make any observations regarding the adequacy of the current supervisory and regulatory framework. However, the EBA's RAQ results and desk -based analysis indicate a growing interest among credit institutions to engage in the tokenisation of deposits in the future, driven to a large extent by institutional client demand pointing to the need for ongoing monitoring by competent authorities and the EBA.
52. The tokenisation of deposits has the potential to offer some opportunities to make exchanges involving transfer of funds from on-chain deposit accounts more efficient, including through programmability functionalities. Some potential challenges, including in relation to regulatory classification, operational risks, and financial inclusion can also be identified. The development of tokenised deposits, and so of related benefits and challenges, as well as any regulatory or supervisory issues, deserves ongoing attention in the context of the continued digitalisation of the EU banking and payment sector.
53. In terms of next steps, the EBA encourages competent authorities to carry out regular market monitoring and knowledge exchange with regard to projects to tokenise deposits in their jurisdiction, by using a common template questionnaire developed by the EBA for use in the context of line supervision. This is important to gain a comprehensive overview of market developments, and to form a basis on which coordinated supervisory approaches can be fostered in the EEA.
54. The EBA will continue to monitor deposit tokenisation and will promote discussion between competent authorities at regular intervals. To this aim, the EBA will make available to competent authorities a questionnaire to facilitate market monitoring of projects by credit institutions to tokenise deposits. The EBA will also continue to engage with the industry to identify any need to issue guidance or recommendations to competent authorities with a view to fostering a consistent supervisory approach across Member States.
55. Any further empirical evidence collected as a result of ongoing monitoring will pave the way for more granular EBA analysis of tokenised deposits (or alternative integrations of DLT into deposittaking and payment activities), including operational and prudential risk management, DGS coverage, as well as consumer protection and financial education considerations. The EBA will

* continue to monitor experience acquired in the classification of crypto-assets, including pursuant to its roles under [Article 97](/mica/title-vii-competent-authorities-eba-and-esma-art.-93-138/chapter-1/article-97.md) of MiCAR and, where appropriate, take actions to promote convergence in classification.

56. More generally, the EBA recalls the ongoing relevance of its recommendations to the European Commission of 2014 and 2020 on the need for further convergence in the definition of 'deposit' for the purpose of the application of the banking acquis. However, the EBA has not identified a need to amend the DGSD definition of 'deposit' in view of the development of innovative products for the purpose of determining the DGS scope.

### Annex: Models for recording deposits

Banks may opt for various designs to integrate tokenised deposits into infrastructure systems.

* One approach is to replace the traditional ledger (Diagram 1) with a DLT (Diagram 2) on which the claim of the depositor (i.e. the deposit balance, taking into account any debits or credits) is recorded. From a client perspective there is no difference in terms of how funds are deposited or withdrawn -the only difference arises at the 'back office' with the type of ledger used to record deposit balances and the signifier (IBAN in the case of a traditional bank ledger, a DLT address in the case of the DLT).
* Another approach would be to maintain a traditional ledger to record the deposit balance. However, the client may be provided the possibility of debiting an amount of funds from the deposit balance on the traditional ledger, and crediting it in the form of a token available on a DLT. In this scenario the DLT-based token does not represent a deposit claim against the bank; instead, the token could represent a claim in the form of EMTs (Diagram 3). Hence, only funds held in the bank account on the traditional bank ledger would represent the deposit balance of the client.

Diagram 1. Deposit recorded on a traditional bank ledger

Diagram 2. Deposit recorded on a DLT ('native' tokenised deposit)

Diagram 3. Deposit account: funds withdrawn and 'converted' to EMTs

* Differently, a credit institution could provide a client the possibility to hold deposit balances (i.e. deposit claims) on two different ledgers (traditional and DLT), and the claims of the depositor client may be debited and credited between each different ledger (Diagram 4). In this scenario , the total deposit balance of the client would be the total of the balances recorded on the two ledgers (the traditional bank ledger and DLT).

Diagram 4. Deposits recorded on the traditional bank ledger and on the DLT

### Related

* [distributed ledger technology](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/mica/distributed-ledger-technology.md) — defined term used on this page
* [distributed ledger technology](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/tofr/distributed-ledger-technology.md) — defined term used on this page
* [transfer of crypto-assets](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/tofr/transfer-of-crypto-assets.md) — defined term used on this page
* [asset-referenced token](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/mica/asset-referenced-token.md) — defined term used on this page
* [electronic money token](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/mica/electronic-money-token.md) — defined term used on this page
* [financial instrument](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/mica/financial-instrument.md) — defined term used on this page
* [financial instrument](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/mifid-ii/financial-instrument.md) — defined term used on this page
* [competent authority](https://github.com/jakesenfti/micawtf/blob/main/spaces/definitions/mica/competent-authority.md) — defined term used on this page


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://www.mica.wtf/eu-level/soft-law/reports-and-advice/report-on-tokenised-deposits.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
