Response to consultation on Guidelines on templates to assist competent authorities in performing their supervisory duties regarding issuers’ compliance under MiCAR
Question 5: To note, templates U 01.00, U 02.00, U 04.01, U 04.02, U 04.03 and U 04.04 in these guidelines are the same templates as templates S 01.00, S 02.00, S 04.01, S 04.02, S 04.03 and S 04.04 in the draft ITS under Article 22(7) of MiCAR, only the tokens in scope of the reporting is different. Do you have any comments on the extension of the scope, compared to the draft ITS, to EMTs referencing to EU currencies for these templates related to number of holders; value of the token issued and size of the related reserve of assets; and information on transactions per day with these guidelines?
As noted in previous GDF responses to consultations from the ESAs on MiCAR RTSs and ITS, we are concerned that some requirements within the Consultation may go beyond what firms can reasonably report. While we appreciate for example in Annex II of the Consultation pg. 18 that some non-custodial transaction reporting should be completed on a “best effort basis” it would be helpful to further specify what good looks like for the issuers. GDF would agree, as noted in the Consultation that issuers may have limited information on these transactions and related holders involved in such transactions.
To this end, and to support compliant and effective reporting, we would encourage the EBA to instead consider how issuers can implement appropriate systems and controls to monitor orders, transactions, and other activities, that are tailored to the nature and scale of the business. This proportionality in reporting would be most welcome in order for regulators to receive accurate and appropriate data, which can then support them in effective supervision.
As discussed in previous MiCAR consultation responses, to require firms to ensure that their monitoring systems can analyse and detect any and all suspicious activities related to all DLT operations and transactions, be those custodial or non-custodial is in effect to mandate that they have supervision and risk management over the whole of the blockchain (as well as activities that occur off chain). GDF feels that this is neither proportionate, nor appropriate. Requiring firms to have in place continuous monitoring of all orders and transactions, regardless of whether they occur on or off a trading platform, is neither reasonable nor achievable. It may also have the unintended consequence of causing the EU to not be as competitive as a jurisdiction if firms view this as an unachievable compliance request. This would be equivalent to requiring a traditional retail bank to have risk monitoring systems for all activities taking place on the internet upon which its banking applications run. Instead of this approach, we would encourage the EBA to focus on issuer requirements which highlight how a firm is mitigating risk for their critical business services, and the data which they can reasonably maintain and report.
Question 6: Do you have any comments on template U 09.04 on how CASPs should report to issuers the cross-border transactions that are associated as a means of exchange?
As the TFR is set to come into force on January 1st, we would encourage the EU to be mindful of challenges that may exist in the initial implementation period for cross-border transactions. While 89% of material jurisdictions already have Travel Rule regulations in place or in process of developing them, we would note that there may yet be some coordination that will need to occur on a cross-jurisdictional basis in order to develop a harmonised regulatory approach that is aligned to the FATF Guidance. Engagement and support for this cross-border coordination would also support the EBA’s aims in creating a level playing field in developing MiCAR, while also aligning to global standards and developments.
However, we would note an additional point that while FATF is aimed at AML and KYC requirements, the proposed reporting requirements for this guideline are aimed to minimise risks from double counting. As such we would note that (1) it would be disproportionate to require CASPs to have AML and KYC data on individuals who are not their customers (rather these requirements should extend to customers only) and (2) this AML and KYC information should not be used for broader purposes as it is important to protect the Personal Data of consumers. This is further discussed in our response to Q7 below.
Additionally, GDF notes that one aspect which may require additional solutions from industry, as well as cross-border collaboration, is the appropriate factors which could be used to determine in what territory or jurisdiction an asset is trading. These factors would be different in crypto-asset markets than in a TradFi context where you have tickers listed on a particular exchange. This is not the case for most digital exchanges so a different approach may be required for consistent reporting. Furthermore, when considering location, as the blockchain is located in the ether this could be difficult to pinpoint. The IP address of miners/validator nodes could be located but would necessarily not provide the authorities with the relevant information needed to detect and prevent market abuse. Overall, we would suggest a different approach may provide more relevant information and data to the EBA such as the wallet address, or aggregated data where practical and available (this is further discussed under our response to Q7).
Moreover, the data on location is available only if the holder of the asset is a customer of the CASP. Using technological means could help identify the location of the holders that are not direct users of the CASP, but the data might anyway not be accurate. Furthermore, on the location, the EBA specifies that “the country of a transaction should be determined by the location of the holders involved in the transaction, the location of the originator and the location of the beneficiary of the transaction.” We would suggest amending this requirement, as issuers and CASPs can collect this information only if the holder is their customer. Furthermore, when considering other global requirements such as the Travel Rule, only the beneficiary’s name and wallet address is collected not their location, so the proposal goes beyond current industry best practice. On this basis, we would encourage the EBA to reconsider this requirement, and align it further to what firms can reasonably report as well as other existing global standards and principles.
Finally, GDF would also highlight the current work occurring in the FSB to promote alignment and interoperability across data sharing for cross-border payments[1]. Given that this work could support the EU in achieving their outcomes, we would encourage them to consider how their requirements might align to broader global efforts in order to support a level playing field and broader harmonisation.
[1] https://www.fsb.org/work-of-the-fsb/financial-innovation-and-structural-change/cross-border-payments/
Question 7: To note, CASPs templates U 08.00, U 09.01, U 09.02, U 09.03 and U 10.00 in these guidelines are the same templates as templates S 06.00, S 07.01, S 07.02, S 07.04 and S 08.00 in the draft ITS under Article 22(7) of MiCAR, only the tokens in scope of the reporting is different. Do you have any comments on the extension of the scope, compared to the draft ITS, to EMTs referencing to EU currencies for these templates related to information on holders; information on transactions; and information on token held by the CASPs with these guidelines?
As noted above, under Q5 GDF would encourage issuer reporting to be tailored to the nature and scale of the business, and also to be proportionate to broader EU and global requirements. Furthermore, we would note our support for the information reported to be utilised for regulatory purposes only and for this to be clarified in the templates.
Expanding upon this, GDF and its members have some concerns regarding the requirements within the templates and the requirements for CASP reporting. These are outline below:
- Retrospective Reporting: This type of reporting, from CASP to issuer goes ‘backward’ in the order of reporting. Given it appears to be retrospective, it would not be instrumental in the same way that ‘forward’ looking due diligence is (e.g., the travel rule which aims to prevent money laundering). Backward reporting to an issuer in this manner is relatively unprecedented across asset classes within wider financial services – not just the crypto and digital assets industry and GDF does not find this to be a suggestion that would benefit authorities in providing them with the relevant supervisory information.
- CARF Misalignment: The requirements as presented are not consistent with the OECD’s CARF[1]. CARF is focused on an entity’s customers, not counterparties. We would encourage alignment to CARF and the requirements that it sets out in order to support broader harmonisation.
- Competition Concerns: GDF would also note that the requirement for CASPs to transmit comprehensive transactional data to issuers may undermine EC competition policy. Notably, only 5 stablecoin issuers dominate 95% of the global market capitalisation in the stablecoin sector[2] all of whom are based outside the EU and are mainly pegged to $USD. As indicated by the EC[3] competition policy is intended to encourage companies to:
- offer consumers goods and services on the most favourable terms.
- be more efficient and innovative and reduce prices; and
- act independently of each other and be subjected to the pressures exerted by their competitors.
- As currently drafted, GDF feels that the proposal would undermine this policy, which could increase the concentration of market intelligence in the hands of a limited number of entities.
- Furthermore, under MiCAR, EMTs are considered equivalent to electronic money (Article 48(2)). As noted under the first concern above, there is no precedent in regulatory reporting concerning electronic or fiat money where service providers are mandated to relay all transactional details to the money issuers (and also relay the information backward rather than forward). This disparity raises questions about the proportionality of such reporting requirements for EMTs under both GDPR and competition law. GDF would encourage the EBA to adopt a more proportionate and appropriate response to the reporting requirements.
- Data Privacy Concerns: GDF would also note that the proposed data to be reported includes Personal Data, as defined in the GDPR. The GDPR is highly relevant in this context since most CASPs act in the capacity of data controller vis a vis their clients. We would note that the data to be reported includes critical elements such as the transaction hash, ledger addresses, crypto-asset account numbers of the payer or payee, transaction value and date, and the countries of the payer and payee. We also note that Annex IV of the ITS requires the CASP to disclose the name and passport number of the holders, which is highly sensitive information.
- Additionally, as noted previously, a CASP would only be able to comply with the requirement to report such information for their own customers who have been onboarded through a KYC/AML process. We note that as set out the requirements would not be proportionate to apply to CASPs as it goes beyond the scope of the data they can reasonably report.
- In the interests of complying with GDPR principles, GDF believes that this data goes beyond what would be needed in order to prevent double counting, and also puts personal data at risk. While we are supportive of pursing the outcome of minimised double counting, we believe that this can be achieved with less use of personal data.
- While we are supportive, and acknowledge, that CASPs will and should process Personal Data of their customers in the context of their AML-CFT obligations, we do not believe it should then follow that CASPs could, or should, use this information for other purposes. The purpose limitation[4] principle is a fundamental principle of the GDPR, and in this respect, we would encourage a more proportionate response to the reporting requirements that is also aligned to this principle.
- Cyber Risk: GDF would also highlight that in some cases, some of the information as set out in the current proposals as being a required provision to issuers may constitute foundational elements for decrypting information on blockchain networks. For example, the primary function of a hash is encryption and decryption of crypto messages. Any compromise of this data poses a considerable risk to crypto users' assets and Personal Data. This requirement to report such detailed data could result in heightening this risk.
Proposed Adjustments & Solutions
GDF remains supportive of the EU’s broader objectives and through our feedback we aim to support them in meeting appropriate supervisory outcomes (including data privacy requirements) and stimulating market competitiveness. In order to mitigate the risks identified in the current proposal for reporting requirements, GDF would raise the following as potential solutions to provide further guidance to industry, while also taking an appropriate approach to reporting that is aligned to broader EU and global standards.:
- We would encourage amending requirements to report names and passport data and would propose instead that CASPs report the appropriate aggregated data, necessary to meet the EBA’s statutory mandate, to each ART and EMT issuer for transactions occurring on their platforms. This approach would streamline the reconciliation process and reduce the risk of sensitive data exposure. In scenarios where transactions occur between a CASP and another market entity, CASPs could be required to only transmit data necessary for transaction reconciliation.
- GDF believes that issuers should be granted a status akin to other reporting entities such as Approved Publication Arrangements (APAs), Trade Repositories (TRs), and Approved Reporting Mechanisms (ARMs). This status would entail stringent safeguards, including robust systems, processes, controls, and organisational measures to ensure the segregation of issuer and CASP functions, as well as appropriate controls for data storage and processing.
- Furthermore, we believe it would also be beneficial for the ESAs to maintain comprehensive public list of ARTs and EMTs on their website, similar to the existing registries for APAs, ARMs, and TRs. NCA’s could also maintain local listings.
- GDF is also committed to continuing to work with CASPs to develop further industry standards as appropriate, with relevant stakeholders, including technical solutions based on innovative cryptography such as zero-knowledge proof mechanisms in order to fulfil MICA’s objectives while balancing user privacy.
GDF remains supportive of timely, proportionate, and appropriate reporting in order to support of the EBA being able to implement effective supervision.
[1] https://web-archive.oecd.org/temp/2023-11-10/642426-crypto-asset-reporting-framework-and-amendments-to-the-common-reporting-standard.htm
[2] https://coinmarketcap.com/view/stablecoin/
[3] https://competition-policy.ec.europa.eu/index_en
[4] https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2013/wp203_en.pdf
Question 8: Do you have any other comments on the guidelines, the templates or instructions?
Given the broader complexities of data sharing, especially on a cross-border basis, GDF would encourage the EBA to clarify that the data and information reported in the templates will only be used for regulatory purposes, and also to minimise where possible the sharing of sensitive Personal Data as set out in our above proposal under Q7. This is critical in order to comply with data sharing requirements and would ensure greater security of the data. Data security is a crucial part of consumer and investor protection, and a key EU wide requirement under GDPR, and we would encourage the ESAs to align MiCAR templates with broader EU data requirements in this regard. As noted under Q7 above this is especially critical when considering sharing of highly sensitive personal information such as ‘Names’.