On June 28, the European Commission published a regulatory proposal for the digital euro, a central bank digital currency (CBDC) for the Euro Area. In this proposal, the Commission suggested a way to design a digital euro and how to integrate it into EU laws. In this blog post, I will review the proposal with a focus on its privacy aspects.
Privacy focus
According to the proposal, the digital euro seeks to protect users’ privacy. The processing of personal data should be minimized. In this context, there are two different “payment methods” for the digital euro, each offering a different level of privacy: Offline payments that provide a higher degree of privacy and online payments that provide a lower degree of privacy. Broader privacy implications will be addressed by the European Data Protection Supervisor and the European Data Protection Board within the formal consultation in the legislative process that is currently ongoing.
How does this work exactly?
For offline payments, according to the proposal, the European Central Bank (ECB), national central banks, and payment service providers (PSPs) should not have access to personal data. One exception is that PSPs have access to data related to depositing and withdrawing money (so-called funding and defunding) on a device that allows offline payments, such as a smart card or a phone. This data includes user identities and transaction amounts. Here, the degree of privacy appears to be similar to the one of cash payments today, where banks only know how much money customers withdraw or how much they deposit, but they don’t know any payment details on cash payments itself (more details and a caveat below). This is generally good news.
For online digital euro payments, the degree of privacy is similar to online payments today. A vast amount of data is shared with PSPs that are involved, e.g., data on account owners, transaction amounts etc. Here, privacy is generally lower. In the proposal, it is argued that data is collected, because PSPs need to comply with regulation, e.g., related to sanction screening, anti-money laundering, and terrorist financing.
It is important to note that according to the proposal it is claimed that the ECB would not have access to any personal user data. As a result, the ECB would not be able to see how much money a user holds. This holds both for online and offline payments. However, PSPs can see substantial personal information for online payments.
Data access of PSPs and ECB in detail
Let’s dive deeper into which data PSPs and the central banks can observe (see Article 34 of the proposal for PSPs and Article 35 for central banks). PSPs perform tasks that involve processing personal data, related to:
- Enforcing limits, including verifying, if users already have accounts with other PSPs
- Funding and defunding of digital euro wallets
- Providing offline digital euro, including registration of device and funding
- Conducting transactions between CBDC wallet and bank account
- Compliance with sanction rules, anti-money laundering regulations, anti-terrorism financing, etc.
- PSPs are required to implement measures to ensure that the ECB, national central banks, or other providers cannot identify individuals.
The ECB and national central banks perform tasks that involve processing personal data, related to:
- Granting PSPs access to the digital euro settlement system and providing a channel for PSPs to exchange messages.
- Settlement of transactions involving the digital euro
- Assisting in verifying if a PSP user already has an account.
The last bullet requires further clarification. Since it is envisioned that there will be limits on the amount of digital euro holdings per person it is critical that citizens are prevented from opening multiple accounts with different PSPs. If this were not prevented, the limits on an individual level would become diluted.
While the proposal mentions that the ECB will not see personal data of the citizens only on specific situations, there are doubts about the practicality of this. How should the ECB support checking if a citizen already has an account, without knowing any personal information about that citizen? Here, the proposal needs to be clarified and strengthen data privacy. One way could be to use a distributed database that stores hashes of personal data of users, e.g., hash (last name, first name, date of birth, some random elements). Then, the ECB could support checking if a citizen is already registered, but would not gain insights into any personal data. Note that implications on data privacy laws need to be considered in more depth, as hashes are often classified as private data from a legal perspective.
An alternative solution would be to only allow the opening of one account, which would reduce complexities substantially.
Governance and privacy
Another crucial question that is often raised by opponents is how it can be ensured that major design elements, such as related to privacy, will not be changed over time. It needs very clear rules on governance and political procedures for changes in the design. Changing the design requires a democratic process, which also needs to include perspectives from society. To be clear: There should be a democratic process to establish a proper design and to change design elements. Further, it should be seriously considered to make (part of) the code open source, e.g., around the exact data that is recorded. Currently, the sentiment towards a digital euro seems to be rather negative. In order to be adopted, it needs clear benefits for users as well as guarantees on the actual degree of privacy.
Interaction of online and offline digital euro payments
To evaluate the proposal around privacy in detail one needs to understand further the interplay of online and offline payments. Can users always decide if they want to pay offline or online? Can a user also pay offline if he is online? Can both methods be chosen in the digital euro app? Will there be limits on offline (i.e., more privacy-preserving) payments? These are important questions that need to be addressed over the next months.
Privacy of hardware-based offline solutions
For offline payments, the European Commission seems to consider a hardware-based solution based on secure elements. In the proposal, it is said that PSPs, for offline payments, only see data related to funding and defunding and that privacy is similar to the one of cash payments today. However, here, one needs to double-down. To settle a payment and also as risk mitigation measures to detect compromised or broken devices some data needs to be collected, e.g., a wallet identifier, transaction amount etc.
Wallet identifiers can e.g. be static, i.e., they do not change over time, or dynamic, i.e., change with every transaction. This has a strong impact on privacy, of course. A dynamic identifier would be more privacy-preserving than a static one. It needs more information on the exact data flows of offline payments to analyze if the degree of privacy comes indeed close to the one of cash.
An alternative and secure solution that does not require the additional storage of (personal) data for risk mitigation purposes – and thus preserves privacy – is using privacy-enhancing technologies, such as zero-knowledge proofs (ZKPs). With ZKPs, a party can convince another party about a statement, without revealing any details about the statement. ZKPs are now recognized as proper tools around compliance and privacy, e.g., by the European Parliament, the European Data Protection Supervisor and the US Treasury.
In the context of a CBDC payment, a person could prove that it has enough money to conduct a transaction or that the amount a person receives is the same amount another person sends, without revealing the exact balance. ZKPs should be considered in the CBDC tech stack.
In the next few weeks, the Digital Euro Association will work on a more detailed assessment, which I am happy to share at a later stage.
Source: EU Commission: Regulatory Proposal on the Digital Euro
Acknowledgements
I would like to tank Anne-Sophie Gógl, Jonathan Knoll and Xavier Lavayssière for their valueable feedback.