Privacy-preserving payment systems pose a challenge for AML compliance teams: you can either trace funds or you can't. Systems like Zerocash and Tornado Cash obscure sender, receiver, and amount by burning and recreating coins at each transfer. Traditional provenance analysis, like the graph traversal used on Bitcoin or Ethereum, becomes impossible. The cryptography doesn't differentiate between legitimate privacy and money laundering.
This creates a regulatory impasse. Full transparency defeats privacy. Zero visibility makes AML/CFT compliance impossible. You need a third option: bounded investigative capability that preserves privacy outside the scope of an active investigation.
Here's how to implement selective provenance controls in a private payment system without compromising the privacy model for uninvolved users.
Preparation Steps
Technical foundation:
- A private payment system using the spend-and-create coin model (Zerocash architecture or similar)
- Cryptographic capability to generate zero-knowledge proofs
- Authority to modify the core protocol (this isn't an overlay solution)
Regulatory clarity:
- Written scope definition: what constitutes a "bounded neighbourhood" for your jurisdiction
- Legal authority to freeze funds derived from designated illicit sources
- Documented threshold for when backward provenance becomes investigable
Operational requirements:
- Secure key management infrastructure for regulatory access credentials
- Audit logging system for every use of investigative capability
- Clear escalation path from SAR filing to provenance investigation
You're modifying core protocol behavior, not adding a compliance module. Treat this as a cryptographic engineering project with regulatory constraints, not a policy document with technical footnotes.
Step-by-Step Implementation
1. Define the bounded neighbourhood
Set a hop limit for backward provenance. When a regulator investigates Transfer T, they can traverse N hops backward through the transaction graph, seeing which earlier transfers contributed to T, through which intermediaries, and at what proximity.
The bound is a design decision with compliance implications. Two hops might satisfy immediate-predecessor requirements. Five hops could reveal a structuring pattern. Document your reasoning and get regulatory sign-off before implementation.
2. Implement selective disclosure proofs
Extend your zero-knowledge proof system to support conditional revelation. A standard Zerocash proof demonstrates "I'm spending a valid coin" without revealing which coin. Your modified proof must support "I'm spending a valid coin, AND if a regulator presents valid credentials for coins within N hops, I'll reveal the provenance link."
This requires:
- A cryptographic commitment scheme that binds each coin to its source transfers
- A proof system that can selectively open these commitments under regulatory authority
- A mechanism to prevent unauthorized parties from triggering disclosure
3. Build the freeze capability
When a regulator designates a coin as illicit, the system must prevent spending of that coin and any coins derived from it within the bounded neighbourhood. This requires:
- A revocation list mechanism that validators check before accepting a spend proof
- Cryptographic binding between a frozen source coin and its descendant coins
- A proof that demonstrates "this coin is not derived from any frozen source within N hops"
The freeze propagates forward through the graph within the bound but doesn't affect coins outside that neighbourhood.
4. Create the voluntary disclosure path
A coin holder must be able to reconstruct and reveal their full clear-text provenance graph when they choose. This serves two purposes: it allows cooperative investigation, and it provides an exit path for users who need to prove the legitimate source of funds.
Implement this as a separate proof type that reveals:
- All source transfers contributing to a specific coin
- Full transaction amounts
- The complete chain of intermediaries
The holder controls this disclosure. It's not a regulatory backdoor.
5. Implement access controls and audit logging
Regulatory access to provenance capabilities must be:
- Cryptographically authenticated (not just username/password)
- Logged immutably with timestamp, scope, and justification
- Subject to threshold approval (multi-party authorization for investigation triggers)
- Auditable by an independent party
Every use of backward provenance or freeze capability creates a compliance event. Treat these logs as you would SAR filings: protected, retained, and reviewable.
Validation
Test the privacy boundary:
Create a test coin five hops removed from a designated source. Verify that:
- A regulator investigating the source coin can traverse up to N hops (your defined bound)
- The test coin remains hidden if it's beyond N hops
- No information about the test coin leaks through timing or proof size
Verify the freeze propagation:
Designate a test coin as illicit. Create descendant coins at hops 1, 2, and N+1. Confirm:
- Coins within N hops cannot be spent
- The coin at N+1 hops remains spendable
- The freeze doesn't reveal information about unfrozen coins
Audit the disclosure mechanism:
Have a test holder voluntarily disclose their provenance graph. Verify:
- The revealed graph matches the actual transaction history
- No information leaks about other holders' transactions
- The disclosure can be cryptographically verified by a third party
Maintenance and Ongoing Tasks
Quarterly: Review the neighbourhood bound
Regulatory expectations evolve. AML/CFT guidance may expand the definition of "closely connected" transfers. Review your hop limit quarterly and adjust if:
- Regulators identify evasion patterns that exploit the bound
- New typologies emerge that require deeper graph traversal
- Your jurisdiction adopts new AML directives
Monthly: Audit investigative access
Review all uses of provenance capability. Flag:
- Investigations that approached the hop limit (may indicate the bound is too restrictive)
- Access attempts that failed authentication
- Patterns suggesting fishing expeditions rather than targeted investigation
Continuous: Monitor proof generation performance
Selective disclosure proofs are computationally heavier than standard spend proofs. Track:
- Proof generation time for users invoking voluntary disclosure
- Validator processing time for freeze-compliance proofs
- System throughput degradation under investigation load
If proof times exceed user tolerance (typically 5-10 seconds), you may need to optimize the cryptographic construction or adjust the neighbourhood bound.
As needed: Coordinate with regulators on freeze decisions
When you receive a freeze designation, document:
- The legal basis for the freeze
- The scope of the neighbourhood affected
- The expected duration of the freeze
Frozen coins create compliance liability. Maintain clear records of why each freeze remains active and establish a review process for lifting freezes when the underlying investigation closes.
This isn't a theoretical framework. It's a protocol modification that changes how your payment system handles regulatory oversight. The cryptography gives regulators exactly the capability AML/CFT rules require, backward provenance within a defined scope, while preserving privacy for everyone outside that scope. You're not choosing between compliance and privacy. You're implementing both.
