Council Post: The Awkward Truth About Banks And Blockchain Privacy

Ravi Chamria is the cofounder and CEO of Zeeve Inc.

getty

Banks and financial market infrastructure (FMIs) are getting serious about blockchain again, something that is becoming increasingly apparent in light of major announcements from global banks and financial institutions.

JPMorgan Chase, Citigroup, Bank of America and Wells Fargo are working on a shared tokenized deposit network. SWIFT is adapting to the changing payments environment, with more than 40 banks signed up for its MVP. Many other global banks are experimenting with tokenized MMFs, tokenized deposits and stablecoin support.

Banks are not just watching blockchain from the outside anymore. They are preparing for a more tokenized financial system.​ But in my conversations with banks and FMIs, one issue keeps coming up before these projects can move from controlled pilots to production, and that’s privacy. The awkward truth is that blockchain does not offer complete privacy inherently. Even when it offers privacy, it is often limited to the network level. ​

For banks, that is not enough. ​

Even If Banks Are Not On Public Chains, Privacy Is Still Limited​

It is easy to assume the privacy problem begins and ends with public blockchains. It does not. Public chains obviously create challenges because transaction data, wallet activity, balances and flows can be analyzed. That is why banks prefer private networks, permissioned chains or consortium chains. These networks control who can join, run nodes, validate transactions and access the system. ​

But access control is not the same as privacy. ​

Permissioned chains mostly solve network-level access. They answer who can enter the network. But banking privacy needs a much deeper answer. It needs to answer who can see what, at what layer, for what purpose and under what authority.​

Even if a bank is not on a public chain, sensitive information can still be exposed through surrounding infrastructure, like validators, RPC endpoints, observability systems and cross-chain messaging. The chain may be private, but the data may still not be private across the full infrastructure.​

This becomes more important when multiple banks are involved. In a consortium network, one bank should not be able to infer another bank’s client flows. A validator should not see all tokenized deposit movements. A client should not feel that using blockchain means exposing its business activity to other participants.​

The issue is not only public versus private chains. The real issue is system-wide privacy.​ Network-level privacy is useful, but it is only one part of the requirement. For banks, privacy has to be designed across all major surfaces of the blockchain network and the application layer.​

What System-Wide Privacy Requires ​

In banking, privacy cannot mean hiding everything from everyone. That would be impractical and non-compliant. ​

Banks need privacy with selective disclosure. Regulators, auditors, compliance teams and risk teams need visibility. But competitors, vendors, unrelated network participants and even some infrastructure operators should not see what they are not supposed to see.​

The goal is not anonymity. The goal is governed visibility, and this is only achievable through three specific layers of privacy.

Transaction privacy is the first layer. If a bank is tokenizing deposits or launching tokenized MMFs, any movement should not expose sensitive commercial data like token amounts, balances and counterparties to the whole network.​

But transaction privacy alone is not enough.​ Banks also need workflow privacy. That is because the business process around a transaction can reveal as much as the transaction itself. A tokenized payment may sit inside a larger institutional workflow such as collateral management, treasury movement, settlement or margin processing. Even if the token transfer is private, the workflow can still reveal the intent.​​

This is where a modular privacy layer becomes important. It should integrate with private chains, consortium networks or custom public-permissioned chains without forcing a bank to choose one specific network just to get privacy. ​This layer can support confidential transfers, private smart contracts, zero-knowledge proofs, selective disclosure, identity validation, access controls, compliance rules and private observability. Zero-knowledge proofs are useful because they let banks prove validity, eligibility or compliance without exposing the underlying commercial data. But these alone are not enough. Zero knowledge has to work with identity, governance, key management, policy rules, auditability and disclosure controls. ​

The ideal model must keep raw customer and institutional information off-chain wherever possible. Disclosure should happen only when required—to the right party and for the right reason.​

What Banks Should Do Now​

If a bank is tokenizing deposits on a blockchain or launching tokenized money-market funds, there are broadly three possible blockchain setups. ​

First, a private network can give a bank control, but it can also create an inefficient island, as it may not solve interoperability. ​

Second, institutional public networks can help banks start faster, and they also have privacy mechanisms such as permissioned data partitioning, private channels, ZK proofs or selective disclosure. But the tradeoff is customization. ​

Finally, consortium networks are where the privacy question becomes hardest, because interoperability also increases the number of parties that can infer sensitive activity. These chains may already have some controls—for example, encrypted token standards in custom chains and permissioned access in Fabric or Besu-like networks. But because multiple parties are involved, basic privacy controls will not be enough.​

Banks in this segment need to build or integrate separate privacy tools that can mask tokens, identities, contracts, ledger data and workflow information. The goal should be to cover all major surfaces of the blockchain network and application layer.​

This can be done in phases depending on the use case. Your first priority should be confidential asset transfers and access controls. The next should be protecting the processes around the transaction, which can include settlement logic, approval flows, collateral rules, netting calculations or treasury automation. Finally, privacy has to connect with identity, compliance rules and disclosure governance, with defined access paths for regulators and auditors.​

Without system-wide privacy, the next wave of bank blockchain adoption may repeat the same pattern as earlier pilots that never reached production. In banking, confidentiality is one of the conditions that determines whether blockchain-based financial infrastructure will work at all.​​


Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?