Response to consultation on ITS on the reporting on ARTs and EMTs denominated in a non-EU currency (MiCAR)
Question 1: Do you agree with the proposal included in the ITS on how issuers and CASPs should report on holders in Article 22(1)(a) of MiCAR? If not, please provide your reasoning and suggest an alternative approach
We support the reporting of unique identifier information for each holder by the CASP to the issuer to facilitate accurate reporting and avoid the double counting of holders and transactions. 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.
While CASPs and issuers may adopt measures to secure PII data, the nature of blockchain technology can result in holdings in cryptocurrency wallets being broadcast in aggregate on the blockchain.1 Where information such as PII that is not directly available on blockchains is collected and retained, this may pose serious privacy and security concerns. This is particularly the case where such information would link a person’s PII with their blockchain addresses, which, if accessed without authorisation, could reveal their entire blockchain transaction history.2 Privacy is a central tenet to a well-functioning internet3 and imperative to support user confidence of blockchain technology and to spur ongoing innovation.4
We respectfully request that the EBA only require the reporting of pseudonymous unique identifier information by CASPs to issuers and not PII.
1See p6-7 of CCI’s letter on Proposal of Special Measure Regarding Convertible Virtual Currency Mixing for a discussion of the risks consumers face which can partially be mitigated through the use of mixers.
2 https://cryptoforinnovation.org/wp-content/uploads/2022/08/CCI-Treasury-RFC-Response.pdf
3See II.B, https://api.a16zcrypto.com/wp-content/uploads/2023/05/a16z-TC-Van-Loon-Amicus-Briefing.pdf
4 See II, https://a16zcryptofrz.wpenginepowered.com/wp-content/uploads/2024/01/a16z-CVC-Mixing-Comment-filed.pdf
Question 2: Do you agree with the template S 02.00 - VALUE OF THE TOKEN ISSUED AND THE SIZE OF THE RESERVE OF ASSETS on how issuers should report the different values of the token issued in Article 22(1)(b) of MiCAR, and in particular do you agree with how the maximum value that would trigger the reporting obligation is defined? If not, please provide your reasoning and suggest an alternative approach.
We respectfully disagree that if the maximum value of tokens that have been issued over a preceding quarter exceeds EUR 100,000 on a single day then this should trigger enhanced mandatory quarterly reporting to the relevant NCA. While we acknowledge the policy objective to provide NCAs with timely data to oversee the use of stablecoins, including in determining whether a stablecoin is to be classified as significant, the additional burden resulting from requiring such reporting is not commensurate with the alleged benefit to the NCA in such ‘edge’ cases, particularly the lack of regard for the value of the token at the start and end of the reporting period.
We request that the EBA adopts an approach which takes greater account of the fluctuation in the value of the issued tokens over the course of the reporting period. For instance, only triggering mandatory reporting obligations if the token has exceeded the EUR 100,000 threshold for at least 25% of the reporting period and is either at or within 10% of the threshold at the end of the reporting period.
Question 3: Do you agree with template S 02.00 - VALUE OF THE TOKEN ISSUED AND THE SIZE OF THE RESERVE OF ASSETS on how issuers should report the size of the reserve of assets in Article 22(1)(b) of MiCAR, and with templates S 03.01 - COMPOSITION OF THE RESERVE OF ASSETS BY TYPE OF ASSETS AND MATURITIES and S 03.02 - COMPOSITION OF THE RESERVE OF ASSETS BY COUNTERPARTY/ISSUER related to the requirements specified on the RTS developed under Articles 36(4) and 38(5) of MiCAR? If not, please provide your reasoning and suggest an alternative approach.
NA
Question 4: Do you agree with templates S 04.01 - TRANSACTIONS PER DAY - AVERAGE, S 04.02 - TRANSACTIONS PER DAY - AVERAGE_EU and S 05.00 - TRANSACTIONS PER DAY THAT ARE ASSOCIATED TO ITS USES AS A MEANS OF EXCHANGE WITHIN A SINGLE CURRENCY AREA - AVERAGE on how issuers should report transactions under Article 22(1)(c) and (d) of MiCAR? In particular, do you agree to include a separate template (S 04.03 - TRANSACTIONS AND TRANSFERS PER DAY BETWEEN NON-CUSTODIAL WALLETS - AVERAGE) requesting information on transactions and transfers made between non-custodial wallets or other types of distributed ledger addresses where there is no CASP involved? If not, please provide your reasoning and suggest an alternative approach.
We respectfully disagree with the EBA’s interpretation that the scope of the reporting obligation covering transactions ‘within a single currency area’ includes Eurozone and non-Eurozone transactions and covers transactions where only one of the payer or payee is located within the Eurozone. We request that the EBA limits the reporting obligation to only those transactions where both the payer and payee are located within the Eurozone as we believe this to be the intention of the co-legislators in the primary legislation (see also our answer to Question 4 in response to the consultation on the draft RTS on the methodology for estimating quarterly non-EU stablecoin transactions).
We do not believe it is proportionate to require issuers to report transactions broken down by the holder’s country to NCAs. We respectfully request that the EBA removes the proposed requirement for issuers to categorise transactions into those made within a country, received to a country, and sent from a country. Instead, and in line with the approach in Article 22(1)(c), MiCAR, issuers should be required to only report the average number and average aggregate value of transactions per day during the relevant quarter without the holder’s country breakdown. This information will support NCAs when monitoring the concentration and related volumes of the transactions, including meeting the obligation for monitoring the significance of the activities of the issuer of the asset-referenced token on an international scale, such as the use of the asset-referenced token for payments and remittances.1 In the event that an ART or EMT is deemed significant, at that stage information can be requested from the issuer so that NCAs can determine whether they qualify to be a member of the supervisory college for the sART or sEMT.2
We request that the EBA does not proceed with its proposal to require issuers to report transactions and transfers between non-custodial wallets or between other types of distributed ledger addresses where there is no CASP involved. As the EBA acknowledges, issuers may have limited available information and would not necessarily know whether the transfer is made between addresses of different persons or between addresses of the same person. The issuer may therefore not be able to determine if a transfer qualifies as a transaction. The EBA has acknowledged that reporting of transactions and transfers between non-custodial wallets or between other types of distributed ledger addresses where there is no CASP involved will only be based on proxies and on a best efforts basis. Given that this reporting may be based on approximations and has a high degree of inherent unreliability/lack of comparability, we do not consider the additional burden resulting from requiring such reporting that would be imposed on an issuer to be commensurate with the benefit to NCAs. Mandating this without the necessary data risks undermining trust and confidence. It also makes comparability for NCAs and investors alike impossible given potential divergent interpretations.
1 Article 43(1)(e), MiCAR
2 Article 119(2)(I), MiCAR
Question 5: Do you agree with template S 07.01 - INFORMATION ON TRANSACTIONS how CASPs should report transactions of Article 22(1)(c) and (d) of MiCAR to the issuers? Do you agree with template S 07.02 - DISTRIBUTED LEDGER ADDRESSES FOR MAKING TRANSFERS ON BEHALF OF CLIENTS to be reported by the CASPs to the issuers? If not, please provide your reasoning and suggest an alternative approach.
The reporting by CASPs of the public distributed ledger addresses used for making transfers on behalf of their clients, will support issuer’s efforts in data reconciliation and data quality verification, but 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.
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. Non-custodial wallets are software tools that enable users to interact with blockchain networks by allowing them to sign and send cryptographic messages. 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 non-custodial 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 non-custodial wallet software, nor the non-custodial 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 due to challenges in defining all transactions with certainty.
1 See p7, https://api.a16zcrypto.com/wp-content/uploads/2023/11/A16z-Comment-Response-%E2%80%94-IRS-Proposed-Digital-Asset-Broker-Reporting-Requirements.pdf
Question 6: Do you agree that issuers should define and agree on one common harmonized format and file extension, that they request the CASPs to use for submitting the reports for them? If yes, please provide your suggestions for this common format and file extension.
We support the development of a common harmonised format and extension of the files that CASPs send to issuers to facilitate a smooth reconciliation of the data. We do not have specific suggestions for the precise format or extension that is used.
Question 7: Do you have any other comments on the ITS, the templates or instructions?
CCI appreciates that this proposal does not extend to algorithmic stablecoins. However, we nonetheless would like to take this opportunity to underscore just how different such stablecoins are, and highlight that the application of such reserve asset requirements would effectively ban algorithmic stablecoins — the best of which operate through over-collateralization by exogenous collateral — and signal hostility toward web3 applications that rely on algorithms to develop products and services.
CCI is aware that the EBA views crypto asset-backed stablecoins as distinct from algorithmic stablecoins (in accordance with MiCAR), but for the purpose of future regulatory consideration we include the following information about the benefits and risks of what are broadly considered algorithmic stablecoins. Algorithmic stablecoins have a number of highly beneficial characteristics. For example, because algorithmic stablecoins rely on assets that exist natively on a blockchain, they are generally free from off-chain counterparty risks that can arise from custodying assets with third parties, like banks. Without third parties, algorithmic stablecoins can achieve true decentralisation and provide users with alternative payment instruments. It is important to note that many of these benefits derive from the extent to which algorithmic stablecoins are decentralised in practice. To determine how decentralised an algorithmic stablecoin is, CCI would encourage regulators to evaluate whether it meets certain decentralisation thresholds such as that collateralization ratios cannot be changed in the absence of a decentralised governance process.
Any risks that may be posed in algorithmic stablecoins are distinct from those of other types of stablecoins and we hope that, in future rulemaking, stakeholders will calibrate rules accordingly. For example, the primary risk of algorithmic stablecoins is when such protocols do not have sufficient collateral to cover all outstanding stablecoins. However, over-collateralized stablecoins also exist and alleviate these issues. By ensuring that the protocol (i) always retains collateral in excess of outstanding stablecoins and (i) that such collateral is exogenous, over-collateralized algorithmic stablecoins actually achieve a degree of safety commensurate with fiat-backed products.
Exogenous collateral consists of collateral external to the issuing system whose value is not dependent on the success or failure of the stablecoin protocol. As we have seen in real-world cases, over-collateralized stablecoins backed by exogenous assets have demonstrated a high-degree of resilience to market shocks, and have exhibited relatively low risk. Algorithmic stablecoins that require overcollateralization using high quality collateral like bitcoin and ether remained stable and functioned uninterrupted throughout the recent downturn. Examples include DAI, RAI, and LUSD. While CCI recognizes that algorithmic stablecoins are not under consideration for this proposal, we appreciate this opportunity to provide a summary of just how different this category of stablecoins is, and why it will ultimately require unique treatment. We would encourage the EBA (and the European co-legislators) to consider studying these differences in stablecoin design in determining how each should be treated and welcome further opportunities to provide input.
In sum, while we wholeheartedly support regulation that prevents stablecoin issuers from taking on unreasonable amounts of risk, we believe that policymakers can protect users without such restrictive requirements. And they can do this by enacting narrowly tailored collateralization requirements that allow for the development of safe software code but prevent overly risky projects.