In traditional payments, transaction privacy is the default. Banks don’t broadcast your wire transfers to the world and payment processors don’t publish merchant transaction volumes in real-time for competitors to analyze. But on blockchain? Transparency is the baseline, and privacy is something you have to engineer.
While transparency is blockchain’s superpower for auditability and trust, it’s also a barrier to scaling institutional adoption of stablecoin payments. When every counterparty can see your spreads and your payment volumes, the competitive intelligence exposure becomes a non-starter.
We’re hearing this directly from the field. Regulated fintechs, banks and hedge funds are primarily concerned with:
- How to ensure compliance when leveraging privacy technology
- How to ensure compliance while preventing PII from being exposed on the blockchain, or identities from being used maliciously
Those companies now entering the space have different operational mandates to meet because they’re not building from scratch, but rather integrating crypto with existing infrastructure and compliance requirements. A B2B payment company can’t operate on a public chain where competitors see their transaction volumes and spreads. A trading desk can’t settle onchain when their position sizes and order flow are visible to the market. Corporate treasuries can’t manage stablecoin balances when competitors can track their cash management in real-time.
The players who care about privacy most are finally here. And they’re making it a condition of adoption.
Four types of privacy
Not all privacy is created equal. There are four distinct approaches, and institutions need to understand which one actually solves their problem.
- Private chains: Permissioned networks where only participants see transactions. Keep in mind that private does not equal privacy. It’s private because it’s permissioned, but all authorized participants on this chain can see each other’s transactions. This is pseudonymity, but regulators don’t love fully private chains with no visibility (more on that below). Privacy-native chains like Aleo, Aztec and Midnight are architecturally elegant, but require institutions to adopt an entirely new chain, build new integrations, and operate in smaller ecosystems. For enterprises already committed to Ethereum, Solana, or other major chains, this could potentially pose some challenges in the near-term.
- Masking amounts only (confidential transfers & private balances): The transaction graph is visible, you can see who sent to whom, but the amounts themselves are encrypted. This is the core premise of Solana’s confidential transfers. Sender and recipient addresses are public, but the amount is hidden from observers. Other protocols such as Zama are also building this foundation-native privacy, but the big question is adoption: will issuers like Circle enable it for USDC? Will wallets support it out of the box? A privacy feature nobody uses isn’t a solution.
- Masking addresses: Generally this can be thought of as two different use cases: privacy pools that break the link between sender and receiver, or stealth addresses that act as a sort of one-time deposit address to uphold receiver privacy by hiding only who is being paid.
- Privacy pools: deposits and withdrawals to/from the privacy pool are visible but not linkable, if done correctly. This means funds need to be pre-deposited and there’s enough traffic in the pool.
- Stealth addresses: the sender is visible but the receiver is hidden by generating a one-time deposit address derived from the recipient’s public meta address.
- Full anonymity: Both amounts and addresses are hidden. Some protocols working towards this are Aleo (using zero-knowledge proofs), Starknet’s private channels, Canton (using permissioned data partitioning), and Hinkal which supports in-pool private transfers that break the sender-recipient link, approaching full anonymity for parties operating within the pool.
Most B2B use cases, for example OTC settlement or treasury rebalancing, don’t necessarily need full anonymity. They need confidential transfers (masking amounts only). Why? Because in business relationships, everyone already knows who’s working with whom. The sensitive transaction information is the terms: the spreads, the volumes, the pricing. A PSP working with a major merchant doesn’t need to hide the relationship. They need to hide how much they’re processing and at what rates. That’s the competitive intelligence that matters.
Fully anonymity comes into play more for retail and B2C use cases, where consumers might want cash-like privacy. Payroll is a really good example here, considering most employees don’t want their wages exposed.
The payments compliance question (spoiler: it’s not a paradox)
To put this into perspective, traditional payments already comply with AML rules and safeguard the kind of privacy we are talking about here. So blockchain-based payment rails need to find a way to achieve the same.
Privacy is not the opposite of compliance, because privacy is not the same as anonymity.
A PSP running confidential transfers (amounts encrypted, addresses unlinkable) is not inherently in a worse compliance position than one operating on a transparent chain. They can still know their counterparty, screen sender and recipient, and maintain a complete internal record of every transaction, queryable by a regulator on demand. The privacy is from the market, not from oversight. But it doesn’t happen automatically. It requires deliberately building the compliance layer alongside the privacy layer, which is where most implementations fall short.
The actual obligations don’t change: know your counterparty, screen sender and recipient against sanctions and AML requirements, produce a complete auditable record for your compliance team, a counterparty’s, or a supervisor. What changes is how you satisfy them. And for some privacy architectures, that’s harder to build. Not impossible.
This isn’t a new problem. Regulators have never required compliance data to come from the payment rail itself. SWIFT messages aren’t public. Fedwire isn’t audited by reading wire traffic. The assumption that blockchain transparency is necessary for compliance is a crypto-native narrative, not a legal mandate. The obligation has always fallen on the institution, not the infrastructure.
One thing that is a design principle, not a debate: identity data never touches the chain. PII belongs in the hands of regulated parties and moves peer-to-peer when required. What the chain holds are proofs, i.e. cryptographic attestations that screening occurred, with the underlying data accessible offchain. Who holds the keys to that data, who can request disclosure, and under what conditions is where the real design work happens.
Now, while we can put all this under the “same risk, same rules” bucket, it is true that supervisors need to get comfortable with certain architectural solutions. For instance, the viewing key: a cryptographic credential that grants access to decrypt specific transactions, a wallet, or an entire asset class, depending on the architecture. A Financial Intelligence Unit (FIU) could get a key scoped to what they need, ensuring a third-party technology vendor proves regulatory technology without accessing the underlying PII and becoming a data processor.
This model is becoming more granular and more enforceable with selective disclosure on demand, compelled unmasking under due process, and verification without exposure. The technology is largely there. The supervisory acceptance is catching up.
This is also the difference from what failed before. Privacy protocols didn’t collide with regulators because they offered privacy. They collided because they offered full anonymity which made it impossible to screen counterparties, satisfy audits, or answer basic compliance questions. That was a design flaw, not a privacy flaw.
Privacy and compliance aren’t opposites. They’re both access control problems. The question is always: who has the right to see this, in what form, and when? It will be on the risk teams of regulated firms to understand and build comfort around these increasingly powerful and accessible technologies.
Where blockchain privacy becomes non-negotiable
The use cases where these concerns come into play are things like protecting trading strategies with address obfuscation, breaking transaction links between sender and receiver for global B2B payments, or protecting internal transfers and sweeping by hiding amounts. Let me make this concrete by looking at a few examples.
Merchant settlement
A payment processor managing stablecoin payments for merchants can’t operate when competitors can see their transaction volumes and reverse-engineer their pricing. With confidential transfers, they get what they actually need: the payment graph is visible (regulators can see who’s transacting with whom), but amounts are encrypted. Competitors can’t analyze their spreads. Merchants’ transaction volumes stay confidential. The PSP can demonstrate compliance through viewing keys without exposing commercial intelligence.
Pay-outs
Remittance providers operate in hyper-competitive corridors where pricing is everything. If a competitor can see that you’re processing $10M/month to the Philippines at a certain velocity, they can undercut your pricing and poach your customers. Confidential transfers let you operate on public infrastructure without giving away your competitive position. Regulators get viewing keys for AML screening. Your competitors get nothing.
Corporate treasury
A corporate treasury managing stablecoin balances for working capital can’t have their cash position visible to suppliers, customers, and competitors. It signals negotiating leverage, creditworthiness, and financial health. With confidential balances and viewing keys for auditors, they get the privacy they need while maintaining the audit trail their CFO requires.
Crypto trading
Market makers and institutional trading desks cannot operate in environments where order flow, position sizes, and settlement amounts are visible to the market. Front-running and adverse selection become structural problems. Confidential transfers with identity-based counterparty verification let them verify each other (satisfying KYC/AML), settle onchain, and keep trade details confidential from non-parties.
What do these use cases have in common? They don’t necessarily need full anonymity, they just need selective privacy: hide the amounts and balances from public observers, but maintain the identity layer for compliance and counterparty verification.
Why privacy at scale requires infrastructure, not just cryptography
The hardest part of privacy-preserving payments is the orchestration, key management, compliance integration, and user experience at scale.
Let’s consider what an institution actually needs to operate with confidential transfers.
Key management complexity
Privacy introduces new key types beyond standard spending keys. You need viewing keys (to decrypt your own transactions), potentially asset-level viewing keys (if you’re an issuer), and in some protocols, separate privacy spending keys. These keys have different security requirements. Institutions need infrastructure that manages these keys with appropriate governance, backup, and recovery to protect against both potential privacy and fund loss.
Orchestration across chains and protocols
Privacy implementations are fragmented. Solana confidential transfers work one way. Ethereum’s future privacy solutions will work another way. Privacy pools on each chain have different APIs and SDKs. An institution operating across multiple chains can’t cobble together point integrations for each one. Cross-chain interoperability is critical for scale.
Compliance integration
Viewing keys are only useful if they plug into your existing compliance stack. When a regulator asks for transaction history, you need infrastructure that can decrypt the relevant transactions, generate the audit trail, and deliver it in a format compliance teams understand without exposing more data than necessary.
User experience at scale
A payments company processing thousands of transactions per day can’t have privacy as a manual opt-in step that requires understanding cryptographic primitives. Privacy needs to be the default, handled transparently by the infrastructure across balance management, inbound funds discovery, managing policies, etc.
This is why “solving privacy” isn’t about picking the most advanced cryptographic protocol. It’s about building infrastructure that makes privacy practical, compliant, and scalable for institutions that move billions in payment volume.
Privacy as non-negotiable infrastructure
B2B payments are the proving ground for privacy. PSPs and remittance providers are enabling confidential transfers for merchant processing and cross-border flows. Corporate treasuries are starting to manage stablecoin balances with encrypted amounts. Trading desks are settling OTC trades with confidential transfers.
The enterprises that don’t have privacy infrastructure are facing a choice: build it themselves (complex, expensive, slow) or work with infrastructure providers that have already solved the orchestration, key management, compliance integration, and UX problems.
A lack of privacy is quickly amounting to more focus on it as a non-negotiable for stablecoin payments. This is a trend we’ll continue to see throughout the year, and the next big problem to solve for global onchain financial rails.
Contact our team to learn more about how Fireblocks is enabling privacy for institutional stablecoin payments.
