Public blockchains expose information by design. Addresses, asset movements, transaction timing and smart-contract interactions can be observed by participants with access to the ledger. That transparency supports independent verification, but it conflicts with the conditions under which regulated finance normally operates.
A bank cannot reveal a client’s position to the market merely because settlement uses a shared ledger. An asset manager cannot expose its trading strategy before execution. A payment provider cannot publish customer identifiers or commercially sensitive flows. At the same time, these institutions may need to make relevant information available to compliance teams, auditors, courts or financial supervisors.
The institutional requirement is therefore not absolute secrecy. It is controlled visibility: the right information must be available to the right party, for a defined purpose, under an enforceable governance process. That requires several disciplines which are often compressed into the single word “privacy”. Confidentiality, data protection, identity, selective disclosure and auditability solve different problems. Treating them as interchangeable produces systems that may be cryptographically sophisticated but operationally or legally unusable.
Privacy is not one institutional requirement
Confidentiality concerns who can see transaction data. It covers values, counterparties, positions, contract terms and business logic. In capital markets, metadata can be as sensitive as the payload. A repeated pattern of transfers can reveal a funding need, an acquisition strategy or the activity of a particular client even when names do not appear on-chain.
Data protection concerns the lawful and proportionate processing of information relating to people. It includes purpose limitation, data minimisation, accuracy, retention, security and the ability to exercise data-subject rights. Encryption can support data protection, but it does not automatically satisfy it. Encrypted or hashed information may still be personal data if it can be linked to a person or made intelligible using information held elsewhere.
Identity establishes which legal or natural person stands behind an action, and with what authority. In regulated finance, a valid signature proves control of a key, not necessarily that the signer is an authorised employee, an eligible investor or a customer who has passed required checks.
Selective disclosure enables a party to reveal a fact, attribute or record to a particular recipient without making the entire underlying dataset public. Auditability is broader. It covers the ability to reconstruct events, verify controls, establish accountability and produce reliable evidence after the fact.
A system can perform well in one category and fail in another. A permissioned ledger may hide data from the public but give every consortium member excessive access. A zero-knowledge proof may demonstrate that a rule evaluated to true without showing whether the rule was legally correct, current or based on accurate data. An immutable audit log may preserve evidence while retaining personal information for longer than the applicable purpose permits.
Confidentiality must include metadata and business logic
Basic encryption protects a message or payload, but institutional transactions leak through more than content. Participants may infer relationships from addresses, timestamps, transaction frequency, gas consumption, contract calls, liquidity movements and changes in state. Address pseudonymity is especially fragile when a regulated intermediary already holds the connection between a wallet and a verified customer.
Institutional confidentiality therefore operates at several layers. Access controls determine who may join a network or call a service. Private transaction mechanisms limit distribution of data to involved parties. Encryption protects stored and transmitted information. Confidential smart-contract systems attempt to conceal inputs, state or logic. Network controls reduce leakage through infrastructure and operational telemetry.
The architectural choice changes the trust model. A private or permissioned ledger can restrict readers and validators, but its operators become trusted gatekeepers. A public chain with encrypted state or privacy-preserving execution can retain wider verification and settlement reach, although it introduces additional cryptographic complexity. A hybrid design may keep sensitive records in controlled systems while publishing commitments or proofs to a shared network.
No approach eliminates exposure. Permissioned validators may collude or be compromised. Encryption keys can be lost, stolen or compelled. Trusted execution environments depend on hardware, firmware and attestation chains. Zero-knowledge systems depend on circuits, proof implementations and, in some constructions, setup material. Confidentiality is consequently an end-to-end property rather than a feature that can be attached to the ledger alone.
Data protection is not the same as encryption
The European Data Protection Board’s final Guidelines 02/2025 on blockchain processing, published on 7 July 2026, recommend storing additional personal data off-chain beyond identifiers already present in transaction metadata. They also explain that public keys and other on-chain identifiers may be personal data when they can identify a natural person by means reasonably likely to be used.
This matters because the General Data Protection Regulation requires more than protection against unauthorised reading. Its principles include purpose limitation, data minimisation, accuracy and storage limitation. Blockchain replication and resistance to alteration can make rectification, erasure and retention controls difficult, particularly where many nodes hold durable copies.
Putting a hash on-chain does not necessarily remove the issue. A hash derived from predictable or low-entropy information may be susceptible to matching attacks. A commitment may remain linkable to an individual through off-chain records. Encrypting personal data can reduce exposure, but loss or deletion of a key does not by itself establish that the applicable legal requirements for erasure have been met. The effectiveness of any method depends on the architecture and the specific facts.
The EDPB’s analysis places architecture before mitigation. It asks whether a blockchain is necessary, whether a private or permissioned model would be sufficient, whether a zero-knowledge architecture is possible and which data can remain off-chain. It also connects those decisions to data-protection impact assessments, controller and processor roles, international transfers, retention and the practical exercise of individual rights.
This produces a clear distinction. Confidentiality asks whether an unauthorised party can read information. Data protection asks why the information is processed, how much is necessary, where it travels, how long it persists, who is accountable and what happens when a person exercises a legal right.
Identity must be attributable without becoming universally visible
Regulated transactions usually require an accountable identity layer. Customer due diligence, sanctions controls, market-access rules, investor eligibility and internal delegations depend on facts that an ordinary blockchain address does not contain. Publishing the underlying identity record on-chain, however, creates excessive disclosure and a durable correlation point.
A more granular model separates identity proofing, credential issuance, presentation and transaction authorisation. A trusted issuer can verify a person or organisation and issue a signed credential containing relevant attributes. The holder can then present an attribute or proof to a relying party. The ledger may record that an authorised credential or policy proof was used without receiving the complete identity file.
The revised European digital identity framework illustrates this direction. Regulation (EU) 2024/1183 requires European Digital Identity Wallets to enable selective disclosure of attributes. Its recitals also call for the integration of privacy-preserving technologies such as zero-knowledge proofs, through which a relying party can validate a statement without receiving the data on which that statement is based.
For institutional finance, identity also includes organisations, roles and mandates. A credential may need to establish that a legal entity is regulated in a specified jurisdiction, that a fund is eligible to hold an asset, or that an employee may approve a transaction up to a particular threshold. Those attributes change. Credentials therefore require expiry, revocation, status checking and reliable time references.
This creates a tension between privacy and correlation. A persistent identifier simplifies monitoring and investigations but allows activity to be linked across services. Pairwise or purpose-specific identifiers reduce correlation, although they complicate consolidated risk assessment. The appropriate visibility depends on the role and lawful purpose, not on a universal preference for either anonymity or identification.
Selective disclosure is a policy mechanism, not a synonym for privacy
Selective disclosure can take several forms. A party may release a complete record to one authorised recipient. A credential may reveal only selected attributes. A zero-knowledge proof may establish a statement such as eligibility, residency within an approved set, possession of a valid credential or compliance with a transaction limit without exposing the underlying value.
The Bank for International Settlements’ Project Mandala demonstrates an experimental compliance-proof model. Its first phase integrated peer-to-peer messaging, a rules engine and a proof engine, enabling jurisdiction-specific requirements to be checked before a cross-border transaction and a cryptographic proof of compliance to be generated. The BIS reported that zero-knowledge proofs and multi-party computation showed potential to improve data privacy while automating parts of compliance.
That approach can reduce unnecessary data sharing, but a proof answers only the proposition encoded into it. It does not establish that the proposition captures every legal obligation, that sanctions or eligibility data were current, or that the original evidence was authentic. The relying institution still depends on credential issuers, data providers, rule owners and software governance.
Selective disclosure also requires protection against inference. A proof that someone belongs to a very small eligible group may identify them indirectly. Repeated proofs can become linkable through identifiers, timing or transaction structure. Revealing several individually modest attributes may reconstruct a detailed profile when combined.
Proof systems also involve operational trade-offs. Proof generation can increase latency and computing cost. Complex circuits are harder to review and update. Some designs rely on trusted setup ceremonies, while transparent systems may produce larger proofs or require more computation. A vulnerability in a circuit or implementation can permit false proofs even when the underlying mathematics remains sound.
Auditability requires evidence, authority and process
Auditability is sometimes reduced to the observation that blockchains are tamper-resistant. That property can help preserve the ordering and integrity of recorded events, but it does not prove that an event was lawful, correctly classified or supported by accurate off-chain information. A durable record of bad data is still bad data.
Institutional auditability has at least three dimensions. Transaction auditability reconstructs what happened. Control auditability shows which policy, software version, credential and authorisation were applied. Governance auditability establishes who changed rules, granted access, invoked disclosure powers or overrode an automated outcome.
A privacy-preserving system must retain enough evidence to support all three without granting routine access to everyone. Possible mechanisms include encrypted audit records, role-based views, cryptographic commitments, signed policy artefacts, proof receipts and disclosure keys divided among several authorised parties. Threshold control can prevent any single administrator from unmasking a transaction, but it also adds key-management and availability dependencies.
Audit access is itself a sensitive operation. A robust design can define the legal trigger, authenticated requester, limited scope, approval path, tamper-evident record and retention policy for disclosed material. A universal viewing key offers simple investigations but creates an exceptional concentration of risk. Purely non-disclosable anonymity avoids that key but may be incompatible with an institution’s obligation to respond to lawful information requests.
FATF’s 2025 targeted update on virtual assets reported that 99 jurisdictions had passed or were in the process of passing legislation implementing the Travel Rule. Under FATF’s standards, originating virtual asset service providers must obtain and hold required originator and beneficiary information, transmit it to the beneficiary provider or counterpart, and make it available to appropriate authorities on request. FATF expressly states that the information need not be attached directly to the virtual-asset transfer.
The architecture determines who must be trusted
A closed permissioned network offers known participants, enforceable membership, predictable governance and direct control over data location. It can also fragment liquidity and interoperability, concentrate operational responsibility and expose sensitive information to more consortium members than a bilateral transaction requires.
A public blockchain provides common settlement infrastructure, broad availability and independent verification. Without additional privacy technology, it can also expose transaction history and make later containment difficult. Privacy layers can conceal state or prove correct execution, but bridges, sequencers, relayers, wallets and off-chain services may reintroduce trusted components.
Hybrid systems separate confidential execution from shared verification or settlement. Sensitive records remain within an institution, consortium or protected execution domain, while commitments, state roots or validity proofs reach a wider ledger. This can minimise disclosure without abandoning common infrastructure. It also creates a boundary whose synchronisation, finality, failure handling and legal meaning must be understood.
The BIS published the prototype report for Project Agorá on 27 May 2026. The project brings together eight central banks and more than 40 regulated financial institutions to test a multi-currency platform combining tokenised commercial-bank deposits with jurisdiction-specific ledgers for tokenised central-bank reserves. According to the BIS’s 2026 Annual Economic Report, the prototype preserved participation rules and domestic control over reserves, while privacy safeguards limited data sharing to relevant parties. The project remains experimental and moved towards real-value testing after the prototype phase.
Data localisation can constrain even sophisticated cryptography. The BIS observed in its 2025 Annual Economic Report that data-protection laws differ across jurisdictions and that the most stringent policy choices require data to be physically stored within the jurisdiction. A proof may reduce the transfer of raw data, but the systems producing and storing the source information remain subject to applicable local law, supervision and operational controls.
What the institutional requirement set contains
The requirements emerging from regulation, central-bank experimentation and production financial controls form a layered model:
- Confidentiality: transaction values, counterparties, positions, metadata and business logic are visible only to authorised parties.
- Data protection: personal data have a defined purpose, lawful basis, minimum scope, controlled location, retention period and accountable controller.
- Identity: participants, organisations and authorised roles can be established through governed credentials without publishing complete identity records.
- Selective disclosure: specific attributes, records or proofs can be presented to specific recipients for specific purposes.
- Auditability: authorised reviewers can reconstruct transactions, controls and governance actions using reliable evidence.
- Revocation and change: credentials, permissions, policies and keys can expire or be withdrawn without rewriting history.
- Operational resilience: key loss, unavailable proof services, compromised administrators and failed privacy components have defined recovery paths.
- Interoperability: privacy controls survive movement between ledgers, messaging networks, custody systems and conventional financial infrastructure.
These properties can conflict. Stronger confidentiality can reduce market transparency and supervisory visibility. More detailed audit records can increase privacy and retention risk. Frequent credential checks improve status accuracy but create correlation data. Public composability can increase information leakage. Closed governance can improve accountability while concentrating control.
Cryptography can change how these conflicts are managed. It cannot determine the legitimate purpose of processing, interpret every rule, verify every source fact or decide who may invoke exceptional access. Those remain legal, governance and operational questions.
Privacy for finance is controlled accountability
The most useful distinction is between secrecy from everyone and confidentiality within an accountable system. Regulated institutions require the latter. Their transactions must not expose clients or strategies to the public, competitors or unrelated network participants. Yet relevant evidence must remain available under defined authority.
That outcome is not delivered by a single privacy coin, private chain, viewing key or zero-knowledge proof. It comes from aligning ledger architecture, identity credentials, access controls, data lifecycle, proof systems, audit evidence and governance. Every mechanism moves trust somewhere: to consortium operators, credential issuers, hardware manufacturers, cryptographic implementations, key custodians, policy owners or legal authorities.
The decisive institutional question is therefore not whether a blockchain is public or private. It is who can learn what, under which conditions, with whose authorisation, for how long and with what evidence. A design that can answer those questions precisely has the foundations of financial privacy. One that cannot has only hidden data.