Privacy Blockchains and Compliance: What Accounting Firms and CFOs Must Assess Now
A new generation of hybrid blockchains is reaching institutional scale, and each one presents a materially different compliance challenge. Chainalysis published a detailed breakdown on 29 July 2026 confirming that at least four distinct privacy models are now active in production, covering everything from Canton's fully private ledger to Aztec's zero-knowledge Layer 2. For any accounting firm or CFO whose clients touch digital assets, understanding these models is no longer optional: it directly determines whether your crypto accounting software stack and AML controls can actually see what is happening on-chain.
Why Institutional Demand Is Driving Privacy Chain Growth
Public blockchains such as Ethereum and Solana were built on openness. Any participant can read every transaction, trace wallet histories, and monitor counterparty activity. That transparency fuels liquidity and network effects, but it creates a problem for institutions moving large positions on-chain: they cannot control who sees their order flow, counterparty identities, or settlement details.
Chainalysis is clear that the institutional push for privacy is not about anonymity in the criminal sense. It is about data protection and counterparty confidentiality, the same expectations that govern traditional finance. In response, builders have produced a cohort of hybrid networks that give users selective control over what is visible, without abandoning the auditability that regulators and compliance teams require.
The largest of these is Canton. It describes itself as a "public permissioned" chain because participation is restricted. According to Chainalysis, citing CoinDesk, Canton already settles around six trillion dollars in institutional assets. That figure alone signals that privacy-chain compliance is an operational reality, not a future-state concern.
The Four Privacy Models: What They Are and How They Differ
Chainalysis identifies four architecturally distinct approaches. Each one requires different monitoring techniques, different access arrangements, and different analytical logic. There is no single skill set that transfers cleanly across all four.
Model 1: Need-to-Know Ledgers (Canton)
Canton conceals not just transaction amounts but the very existence of transactions from anyone who is not a direct counterparty or named stakeholder. The architecture works on a strict need-to-know basis: each party to a transaction receives only the slice of data relevant to their role.
Chainalysis uses a Delivery versus Payment settlement as an illustration. The bank receiving cash sees the cash leg; it sees nothing about the security being exchanged. The securities registrar sees the transfer of the asset; it cannot see the cash consideration. Compliance teams, regulators, and auditors are granted segmented access rather than full ledger visibility.
For accounting firms, this means your standard blockchain explorer approach is useless on Canton. Access must be negotiated at the infrastructure level, typically through the platform's permissioning layer, before any transaction data reaches your crypto bookkeeping software or audit workpapers.
Model 2: Opt-In Shielded Pools (Zcash)
Zcash operates as a public blockchain with transparent addresses, much like Bitcoin, but it also contains privacy pools within which sender, receiver, and amount are all encrypted. Users choose whether to transact transparently or within the shielded environment. Chainalysis notes that even the recipient of a shielded transfer does not automatically know where incoming assets originated.
Access requires a viewing key. Without one, a compliance team or auditor cannot decrypt shielded transaction details. Critically, Chainalysis confirms that it can identify and flag transfers into, out of, and between shielded pools, treating these as "protocol privacy" exposure events that surface in risk-based review workflows. Most Zcash activity remains transparent, which limits the practical blast radius for most institutional compliance programs.
Zcash's limited smart contract functionality also means it is unlikely to host complex financial products. Its compliance challenge is real but bounded, and it predates the current wave of institutional chain-building.
Model 3: Selective Privacy on a Public Chain (Solana Confidential Transfers)
Solana takes a different approach: selective privacy baked into individual token issuances on an otherwise transparent public chain. Token issuers can enable confidential transfers at the point of creation. When they do, the transfer amount and the sender and receiver balances are hidden, but the wallet addresses themselves remain visible.
Viewing keys are again the compliance mechanism: an auditor holding one can decrypt transaction details on demand. Chainalysis notes that Solana launched this feature in early 2025, paused it to patch bugs, and brought it back online in June 2026. The feature's intermittent status is itself a data point for compliance teams: any firm that onboarded Solana-based assets during the outage period needs to confirm exactly which transactions settled under which privacy settings.
For digital asset accounting software, this model is manageable if the correct viewing keys are held and documented as part of client onboarding. The risk appears when firms inherit token positions without inheriting the corresponding keys.
Model 4: Zero-Knowledge Execution (Aztec)
Aztec is the most opaque of the four. As an Ethereum Layer 2, it processes computations locally on the user's device and broadcasts only a cryptographic proof of validity to the network. Contract state, transaction logic, and all execution details are invisible to external observers. The only publicly legible signals are deposits and withdrawals at the Ethereum Layer 1 bridge.
There is no built-in auditor key or protocol-level backdoor. Compliance access depends entirely on application developers choosing to embed disclosure requirements into their smart contracts: for example, requiring users to share transaction data with a designated compliance provider as a condition of use. Without such design choices, assets inside Aztec are untraceable without the holder's voluntary cooperation.
Chainalysis confirms Aztec launched its alpha mainnet in early 2026 and is still early-stage, processing roughly one transaction per second. But its architecture sets the ceiling for privacy-chain opacity, and accounting firms should treat any client exposure to Aztec as requiring a separate, bespoke monitoring arrangement rather than assuming existing tooling will cover it.
Compliance Implications for Accounting Firms and CFOs
AML and Transaction Monitoring
The core message from Chainalysis is that no single monitoring approach covers all four models. A firm that has built its AML workflow around transparent public chains will find significant gaps when a client begins settling on Canton or transacting through Aztec. The monitoring techniques that work on Ethereum do not transfer to a need-to-know ledger, and those that work on Zcash do not transfer to a zero-knowledge execution environment.
Practically, this means compliance teams need a chain-by-chain inventory of which models their clients are exposed to, matched against a clear assessment of whether current tooling and access arrangements actually cover each one. This is the kind of gap analysis that should sit in a firm's annual AML risk assessment, not be discovered during a regulatory review. For context on how emerging cryptographic approaches are already being applied to this problem, see how FHE-based AML screening is reshaping confidential DeFi compliance.
FATF's travel rule and beneficial ownership requirements apply regardless of which chain a client uses. The obligation to know who is transacting does not relax because the ledger is private. For the latest regulatory baseline, the FATF targeted update on VASP obligations remains the authoritative reference.
Audit Trail and Record-Keeping Requirements
For auditors, privacy chains create a specific problem: the audit trail may not be accessible by default. On Canton, access is granted on a need-to-know basis. On Aztec, it depends on how application developers designed the disclosure conditions. On Zcash and Solana's confidential transfers, it depends on whether viewing keys were obtained and retained.
This has direct implications for how engagement letters and client onboarding procedures are written. Firms should now be asking: does the client hold viewing keys for all shielded positions? Have those keys been stored in a way that is accessible during an audit? Is the compliance access arrangement for any Canton or Aztec exposure documented in a written agreement with the platform or application provider?
Your crypto accounting software configuration also needs to reflect these distinctions. A position recorded as "on-chain" is not automatically verifiable in the same way across all four model types. The ledger entry may exist; the ability to independently confirm it is a separate question.
Counterparty and Sanctions Screening
Need-to-know ledgers like Canton solve the counterparty-identity problem for parties to a transaction by design: each participant knows its direct counterparty. But the compliance challenge shifts to the question of whether the permissioning layer's identity verification meets the firm's own AML standards and any applicable regulatory requirements.
For zero-knowledge models like Aztec, counterparty identification reverts entirely to the application layer. If the application does not require disclosure, the compliance team has no on-chain signal to work with. Sanctions screening against a wallet address that is never publicly visible is not a workflow problem that can be solved by better software alone: it requires a protocol-level design choice by the application developer.
What Firms Should Do Now
Immediate Steps
First, map current and anticipated client exposures to each of the four privacy models. This is not a theoretical exercise: Canton's six-trillion-dollar asset base and Solana's resumed confidential transfers mean these are active settlement environments today.
Second, review whether existing crypto accounting software and AML tooling has confirmed coverage for each model type. Coverage for transparent chains does not imply coverage for shielded pools or zero-knowledge execution environments. Vendor confirmation should be obtained in writing.
Third, update client onboarding and engagement letter templates to require disclosure of viewing keys and platform access arrangements as standard information. Treating this as optional creates audit trail gaps that are difficult to remediate retrospectively.
Fourth, flag Aztec exposures specifically for enhanced due diligence. Its alpha mainnet status, combined with its architecture's lack of a built-in compliance backdoor, places it in a different risk tier from the other three models. Any client activity there warrants a documented assessment of how transaction-level monitoring will be achieved.
Finally, ensure that your annual AML risk assessment explicitly addresses privacy-chain exposure. Regulators globally are moving toward an expectation that VASPs and their professional advisers can demonstrate chain-specific monitoring capability, not just a generic blockchain monitoring policy.
Source: Chainalysis
Frequently Asked Questions
What are the four privacy blockchain models that compliance teams need to understand?
Chainalysis identifies need-to-know ledgers (Canton), opt-in shielded pools (Zcash), selective privacy on public chains (Solana confidential transfers), and zero-knowledge execution environments (Aztec). Each requires a different monitoring approach and different access arrangements for compliance teams and auditors.
Does FATF's travel rule still apply when transactions are on a privacy blockchain?
Yes. The travel rule obligation to collect and transmit originator and beneficiary information applies to the institution conducting the transaction, not to the blockchain's technical design. A private ledger does not remove the obligation; it changes the mechanism by which the firm must satisfy it.
How do viewing keys work for audit and compliance purposes?
On Zcash and Solana's confidential transfer model, a viewing key is a cryptographic credential that allows its holder to decrypt transaction details that are otherwise encrypted. For compliance and audit purposes, firms need to obtain, securely store, and document viewing keys at client onboarding, because without them, shielded transaction data cannot be independently verified.
Is existing crypto accounting software sufficient for privacy-chain positions?
Not automatically. Software configured for transparent public chains may not have confirmed coverage for shielded pools or zero-knowledge environments. Firms should request written confirmation from their software vendors about which specific privacy models and chains are supported, and what access arrangements are required for each.
What makes Aztec a higher-risk exposure than the other three models?
Aztec has no built-in auditor key or protocol backdoor. Compliance visibility depends entirely on whether application developers have embedded disclosure requirements into their smart contracts. Without such design choices, transaction data inside Aztec is inaccessible without the user's voluntary cooperation. Combined with its early-stage mainnet status, this places Aztec in a distinct risk tier that warrants enhanced due diligence and a documented, bespoke monitoring plan.