Privacy Onchain: Confidential Transactions, Zero-Knowledge Proofs and Financial Privacy | EBC12

Summary

The panel examined how financial institutions can use blockchain while protecting commercially sensitive and personal data. Its central business message was that privacy is not one feature or technology. Organizations need to distinguish between who is allowed to see data and whether a system can verify a result without seeing the underlying information. Governance, security, and compliance should be designed around the specific use case.

Regulatory and operational priorities

• Supervisors assess an organization’s controls, not just its choice of technology. Key areas include data handling, information security, IT systems, data integrity, and internal controls.
• New startups may need closer examination because they may be unfamiliar with regulatory requirements. Established firms may have experience with national rules but still need to adapt to the MiCA framework.
• AML obligations remain central: privacy technology does not remove regulators’ need for transaction traceability and access. Companies must be able to explain how KYC/AML controls are integrated and how investigations are conducted.
• Outsourced or open-source compliance tools create additional operational risk. If a service is critical to the business, firms should invest in staff, security, and data-integrity controls, including under DORA-related risk management.
• Banks remain accountable for protecting banking secrecy when they use third-party DLT platforms. A platform breach can expose a bank to supervisory scrutiny and potential sanctions.

Privacy technology: capabilities and trade-offs

• Access control and selective disclosure limit which parties can view particular data. This can improve on broadly shared data, but the operator or infrastructure may still see transaction details.
• Zero-knowledge proofs (ZK) can prove a statement without disclosing the underlying data. The panel noted that complex financial workflows may make ZK costly or slow, particularly when transactions involve many stages and participants.
• Fully homomorphic encryption (FHE) allows computations on encrypted data, such as adding encrypted values without revealing them. It remains expensive and difficult to scale for demanding financial applications.
• Multi-party computation (MPC) splits information among multiple parties so no single party holds the full data. It enables collaborative analysis but introduces latency, cost, and governance questions about who participates and how participants are selected.
• No single approach is ideal today. Decisions involve trade-offs among confidentiality, performance, cost, key management, responsibility for computation, and oversight.

Business examples and use cases

• Cross-border financial-fraud detection: A solution for Japanese company Digital Platformer combined AI, blockchain, and MPC so financial institutions could analyze shared data without revealing their underlying records. The goal was to make fraud and illegal-activity detection easier, faster, and cheaper than relying only on each institution’s internal data.
• Red Cross crisis and aid payments: A stablecoin-based payment solution aimed to improve traceability and help ensure donations reach intended recipients. Access controls could govern the use of funds, vouchers, or aid, while privacy-enhancing technology limits disclosure of sensitive information.
• Collateral management: A bank could prove it has sufficient collateral to complete a transaction without exposing its portfolio to another bank or infrastructure provider.
• Auctions: Confidential computation could determine a winning bid without the operator seeing each participant’s offer. This illustrates how confidential computing differs from selective disclosure.

Infrastructure, product strategy, and market coordination

• The Eurosystem is working on Pontes, a project intended to connect DLT platforms to settlement in central-bank money. A panelist said a pilot was expected in the current quarter, with further development in 2027 and a regular service planned for 2028.
• The planned service is intended to operate 24/7 and provide settlement finality for tokenized central-bank money, including delivery-versus-payment transactions and currency transactions.
• A second Eurosystem project, whose name is unclear in the subtitles (“API” or “Upja”), was described as a longer-term effort to shape services with market participants and potentially provide interoperability and cash settlement across multiple DLT platforms.
• Fragmentation among DLT platforms is a practical market problem. The panel emphasized the need for interoperability, standardization, and industry dialogue rather than isolated platforms.
• A central-bank representative said settlement infrastructure generally does not need a complete view of all transaction histories. The design goal should be to disclose only the information required by each participant and function.

GDPR and architecture recommendations

Public permissionless blockchains present challenges under GDPR, particularly regarding the right to delete data and requirements related to jurisdiction and where data is processed.

One proposed approach is a hybrid architecture:

• Use a public network for traceability, audit, and access.
• Keep sensitive or deletable data in a private network or controlled storage.
• Apply privacy-enhancing technologies and access-control mechanisms between the two.

The panel cautioned that public chains should not contain personal data when deletion or jurisdictional requirements cannot be met. Distributed storage and privacy technologies may help, but architectural and governance requirements still need to be addressed.

A retail digital-euro example illustrated a privacy-by-design principle: the system should be built so operators do not need—and in some cases are not able—to inspect individual payment information.

Metrics and timelines cited

• Of 10 crypto companies licensed that year, the supervisor said only one paid serious attention to data technologies such as zero-knowledge proofs.
• One panelist reported more than eight years in blockchain and three to four years focused on privacy-enhancing technologies.
• Privacy technologies were described as having roots extending back to the 1980s. Broader practical adoption has been constrained by compute limitations, hardware performance, and the cost of generating proofs.
• Pontes timeline: pilot expected in the current quarter; further development in 2027; regular service planned for 2028, with 24/7 operation as a target.
• No revenue, margin, CAC, LTV, churn, or other company-performance KPIs were discussed.

Actionable takeaways

• Treat privacy as a use-case and system-design decision, not a generic blockchain attribute.
• Map what each participant, operator, bank, and regulator needs to see; disclose only what is necessary.
• Evaluate ZK, FHE, and MPC against performance, cost, latency, key management, and governance requirements before committing to a solution.
• Build privacy, security, data integrity, and internal investigation procedures into operating controls—not just the technical architecture.
• Assess third-party and outsourced services as critical dependencies, with clear accountability and security investment.
• In cross-platform initiatives, involve market participants early and prioritize interoperability and standards.
• For GDPR-sensitive applications, consider hybrid public/private designs and avoid placing personal data on systems that cannot support applicable deletion or jurisdictional requirements.

Presenters and sources

Panelists identified in the video metadata: Anja Blaj Zajc (EEI), Guillaume Dechaux (Consensys), Marine Krasovska (Latvijas Banka), Rainer Olt (Eesti Pank), and Shirly Valge (Dorchester Partners). The subtitles appear to contain transcription errors in some names and project labels.