Response to consultation on Regulatory Technical Standards on the use of ARTs and EMTs denominated in a non-EU currency as a means of exchange (MiCAR)

Go back

Question 1: Do you agree with the EBA’s proposals on how issuers should estimate the number and value of transactions associated to uses of an ART or of an EMT denominated in a non-EU currency “as a means of exchange”, as reflected in Article 3 of the draft RTS? If not, please provide your reasoning and the underlying evidence, and suggest an alternative approach for estimating the number and value of these transactions.

We agree with the EBA’s proposed approach for issuers to estimate the number and value of transactions of an ART as a means of exchange, by deducting from the total number and value of transactions, those associated with the exchange of the ART for funds or other crypto-assets with the issuer or a CASP.

As the EBA acknowledges, specific technical features of the underlying distributed ledger infrastructure used for transfers of ARTs or EMTs may prevent the issuer or a CASP from determining with accuracy which transactions are associated to uses of an ART or of an EMT denominated in a non-EU currency “as a means of exchange”. As such the estimates reported by issuers and CASPs should be understood to be on a best efforts basis.

Question 2: Please describe any observed or foreseen use cases where transactions involving two legs of crypto-assets, that are different from an ART, are settled in the ART, as referred to in recital 61 of MiCAR.

We have set out one example use case below.

  • The counterparties to a transaction involving two crypto assets (e.g., BTC and ETH) may agree to settle the transaction using an ART (e.g., a stablecoin pegged to USD or EUR) to mitigate volatility or for the simplicity of settlement. 

The extent to which such a use case represents means of exchange will need to be considered on a case-by-case basis.

Question 3: Do you agree with the EBA’s proposals regarding the geographical scope of the transactions covered by Article 22(1), point (d) of MiCAR, as reflected in Article 3(5) of the draft RTS? If not, please provide your reasoning and the underlying evidence.

We support the EBA’s proposal to exclude from the geographical scope of non-EU stablecoin reporting those transactions where both the payer and payee are located outside the EU, but respectfully request that the EBA expand this exclusion so that the reporting obligation only applies to those transactions where both the payer and payee are located within the Eurozone (see also our answer to Question 4).

Article 22(d), MiCAR requires the quarterly reporting of various estimated metrics covering transactions ‘within a single currency area’. We respectfully disagree with the EBA’s interpretation that a ‘single currency area’ as referenced in MiCAR includes a non-Euro Member State. We request that the EBA revises the scope of its transaction proposals to cover only transactions within the Eurozone.

Question 4: Do you agree with the EBA’s proposals on how issuers should assign the transactions in scope of Article 22(1)(d) of MiCAR to a single currency area, as reflected in Article 4 of the draft RTS? If not, please provide your reasoning and the underlying evidence.

We respectfully disagree with the EBA’s interpretation that the scope of the reporting obligation includes transactions where only one of the payer or payee is located within the Eurozone (i.e., the single currency area in the EU).  The reporting obligation in Article 22(1)(d) applies to transactions within a single currency area. This implies that both parties to the transaction (i.e., the payer and the payee) are located in the single currency area, otherwise the transaction would not be ‘within’ the area but partly outside. We consider the reporting requirements in Article 22(1)(a)-(c) to be consistent with the stated policy intention of ensuring “comprehensive monitoring over the whole ecosystem of asset-referenced tokens issuers” and “capture (ing) all transactions that are conducted with any given asset-referenced token” in Recital 60, MiCAR. 

Question 5: Do you agree with the EBA’s proposals on how issuers should calculate the value of transactions referred in Article 22(1), point (d) of MiCAR, as reflected in Article 5 of the draft RTS? If not, please provide your reasoning and the underlying evidence.

We do not have any comments on the EBA’s proposed approach to calculating the various transaction metrics. As set out in our other responses, we respectfully request that the EBA limit the scope of reported transactions to only those where both the payer and payee are located within the Eurozone.

Question 6: In your view, does the transactional data to be reported by CASPs to the issuer, as described in paragraph 43 above, cover the data needed to allow the issuer to reconcile the information received from the CASP of the payer and the CASP of the payee before reporting the information in Article 22(1), point (d) to the competent authority? If not, please provide your reasoning with details and examples of which data should be added or removed.

We disagree with the EBA’s proposal to require issuers to report transactions and transfers concerning non-custodial wallets and therefore, on the basis that we are proposing the removal of that requirement, we do not consider it necessary that CASPs should report to the issuer the public distributed ledger addresses they use for making transfers on behalf of their clients (see our response to question 9).

The reporting by CASPs of: (i) transactional information; and (ii) the public distributed ledger addresses used for making transfers on behalf of their clients, will not allow issuers to definitively identify whether an on-chain transaction involves a non-custodial wallet and therefore to comprehensively reconcile reported data. This is because a wallet address may belong to a CASP that is not within the scope of MiCAR or the TFR e.g., a non-EU CASP.

Question 7: Do you agree that, based on the transactional data to be reported by CASPs to the issuer as described in paragraph 43 above, issuers will be able to reconcile the data received from the CASP of the payer and the CASP of the payee on a transactional basis and in automated manner? If not, what obstacles do you see and how could these be overcome?

We support the reporting of unique identifier information for each holder by the CASP to the issuer for the purpose of avoiding the double counting of transactions reported by the CASP of the payer and the CASP of the payee. However, this unique identifier should be pseudonymous. Requiring CASPs to provide issuers with the personally identifiable information (PII) of their customers such as the originators address, personal document number, date and place of birth serves no net benefit over a unique pseudonymous identifier and would create a honey pot of information which bad actors may seek to exploit.  

Question 8: In your view, how can an issuer estimate, in the case of transactions between noncustodial wallets, or between other type of distributed ledger addresses where there is no CASP involved: (i) whether the transfer is made between addresses of different persons, or between addresses of the same person, and (ii) the location of the payer and of the payee? Please describe the analytics tools and methodology that could be used for determining such aspects, and indicate what would be, in your view, the costs associated to using such tools and the degree of accuracy of the estimates referred to above?

Issuers may seek to use the data available on the distributed ledger coupled with distributed ledger analytics tools to estimate transactions. 

Question 9: Do you consider the EBA’s proposals set out in recital 3 of the draft RTS and further explained in paragraphs 48-55 above as regards the reporting of transactions between noncustodial wallets and between other type of distributed ledger addresses where there is no CASP involved to be achieving an appropriate balance between the competing demands of ensuring a high degree of data quality and imposing a proportionate reporting burden? If not, please provide your reasoning and the underlying evidence.

We agree with the EBA that issuers should not be required to report transactions between non-custodial wallets or between other types of distributed ledger addresses where there is no CASP involved. However, we do not agree with the EBA’s proposal that issuers should be required to report information on the number of transfers between non-custodial wallets or between other types of distributed ledger addresses where there is no CASP involved. Furthermore, issuers should also not be required to report on a best efforts basis the number and value of such transactions.

We believe the EBA’s proposals risk seriously undermining the value of non-custodial wallets for users. These wallets are software tools that enable users to interact with blockchain networks by allowing them to sign and send cryptographic messages to blockchains. Non-custodial wallets are used as a convenient way to interact with blockchain networks, just as web users tend to use web browsers to access the Internet. With a self-hosted wallet, users are able to hold their private keys and digital assets, as well as send and receive digital assets in a peer-to-peer manner. Neither the provider of the self-hosted wallet software, nor the self-hosted wallet itself “effectuate” transactions on a user’s behalf.1

If the EBA continues to favour non-custodial transaction reporting requirements, it should only pursue such a policy if this can be justified through cost benefit analysis. This includes not undermining the value of the non-custodial technology for users, taking full account of security and privacy concerns, and assessing the resulting data to be of sufficient quality given that the EBA acknowledges such data is a rough approximation and unreliable given the challenges in defining all transactions with certainty.

1See p7, https://api.a16zcrypto.com/wp-content/uploads/2023/11/A16z-Comment-Response-%E2%80%94-IRS-Proposed-Digital-Asset-Broker-Reporting-Requirements.pdf

Name of the organization

Crypto Council for Innovation