Privacy Architecture and Data Protection

CBDC TRANSACTION DATA

EVERY TRANSACTION RECORDS:

Mandatory Data:
┌────────────────────────────────────────────────┐
│ Sender identifier (account/wallet) │
│ Recipient identifier (account/wallet) │
│ Amount │
│ Timestamp │
│ Transaction ID │
└────────────────────────────────────────────────┘

Potentially Collected:
┌────────────────────────────────────────────────┐
│ Sender's device information │
│ Location (if available) │
│ IP address │
│ Merchant category code │
│ Payment reference/memo │
└────────────────────────────────────────────────┘

IF LINKED TO IDENTITY:
┌────────────────────────────────────────────────┐
│ Real name of sender │
│ Real name of recipient │
│ Complete transaction history │
│ Balance over time │
│ Spending patterns │
│ Income patterns │
│ Social connections (who you pay) │
└────────────────────────────────────────────────┘

• What you buy (health, politics, vices)
• Who you associate with
• Where you go
• Your financial situation
• Your habits and patterns

IDENTITY DATA IN CBDC

TIERED KYC COLLECTS:

• Phone number

• Possibly nothing else

• Full name

• Date of birth

• Address

• ID document number

• All above plus

• Proof of address

• Source of funds

• Employment information

• Enhanced verification

RETAINED DATA:
┌────────────────────────────────────────────────┐
│ Onboarding information │
│ Verification documents (or hashes) │
│ KYC decision records │
│ Update history │
│ Authentication credentials │
└────────────────────────────────────────────────┘

• Often 5+ years after account closure
• AML regulations require retention
• May be indefinite

LINKAGE:
Identity data + Transaction data = Complete financial profile
```

BEYOND TRANSACTION CONTENT

METADATA COLLECTED:
┌────────────────────────────────────────────────┐
│ Access times and patterns │
│ Device fingerprints │
│ App usage patterns │
│ Feature usage │
│ Error logs │
└────────────────────────────────────────────────┘

DERIVED DATA:
┌────────────────────────────────────────────────┐
│ Spending categories │
│ Behavioral patterns │
│ Risk scores │
│ Anomaly flags │
│ Predictive analytics │
└────────────────────────────────────────────────┘

Even "anonymized" data can be deanonymized
```

---

CBDC PRIVACY SPECTRUM

FULL TRANSPARENCY (No Privacy):
┌────────────────────────────────────────────────┐
│ Central bank sees ALL transactions │
│ Linked to verified identities │
│ Real-time monitoring │
│ Complete history available │
│ │
│ Like: Authoritarian surveillance state │
└────────────────────────────────────────────────┘

REGULATED VISIBILITY:
┌────────────────────────────────────────────────┐
│ Central bank can see if needed │
│ Access requires legal process │
│ Day-to-day privacy protected │
│ Audit trail for access │
│ │
│ Like: Bank accounts with legal protection │
└────────────────────────────────────────────────┘

TIERED PRIVACY:
┌────────────────────────────────────────────────┐
│ Small transactions: High privacy │
│ Large transactions: Full visibility │
│ Threshold-based approach │
│ Compliance where required │
│ │
│ Like: Cash for small, traced for large │
└────────────────────────────────────────────────┘

PSEUDONYMOUS:
┌────────────────────────────────────────────────┐
│ Transactions visible but not linked to │
│ real identity without additional steps │
│ Pattern analysis still possible │
│ Can be deanonymized with effort │
│ │
│ Like: Bitcoin (but with central visibility) │
└────────────────────────────────────────────────┘

ANONYMOUS (Cash-like):
┌────────────────────────────────────────────────┐
│ Transactions not linked to identity │
│ No central visibility of who paid whom │
│ Only aggregate data available │
│ Individual transactions private │
│ │
│ Like: Physical cash │
└────────────────────────────────────────────────┘
```

PRIVACY ARCHITECTURE OPTIONS

APPROACH 1: VISIBILITY BY DESIGN
┌────────────────────────────────────────────────┐
│ System architecture: │
│ - Central ledger sees all transactions │
│ - Identity linked at system level │
│ │
│ Privacy through: │
│ - Access controls (who can query) │
│ - Legal restrictions (when allowed) │
│ - Audit trails (who looked) │
│ │
│ Privacy is policy, not architecture │
│ Technical capability exists │
└────────────────────────────────────────────────┘

APPROACH 2: PRIVACY BY DESIGN
┌────────────────────────────────────────────────┐
│ System architecture: │
│ - Transaction data segregated │
│ - Identity data separate from transactions │
│ - Central bank can't see individual txns │
│ │
│ Privacy through: │
│ - Architectural separation │
│ - Cryptographic protection │
│ - Limited data collection │
│ │
│ Privacy is architecture, not just policy │
│ Technical limits on surveillance │
└────────────────────────────────────────────────┘

APPROACH 3: INTERMEDIARY SHIELD
┌────────────────────────────────────────────────┐
│ System architecture: │
│ - Central bank sees aggregate only │
│ - Intermediaries see their customers │
│ - No single party sees everything │
│ │
│ Privacy through: │
│ - Distributed visibility │
│ - No central transaction database │
│ │
│ Digital Euro proposed approach │
└────────────────────────────────────────────────┘
```

DIGITAL EURO PRIVACY DESIGN (PROPOSED)

PRINCIPLE:
"The ECB and national central banks would
not be able to see users' personal data or
link them to their transactions"

HOW IT WORKS:

For Online Transactions:
┌────────────────────────────────────────────────┐
│ INTERMEDIARY LAYER │
│ │
│ Bank/PSP sees: │
│ - Their own customers' transactions │
│ - Identity of their customers │
│ │
│ ECB sees: │
│ - Aggregate volumes │
│ - System statistics │
│ - NOT individual transactions │
│ - NOT personal identities │
└────────────────────────────────────────────────┘

For Offline Transactions:
┌────────────────────────────────────────────────┐
│ CASH-LIKE PRIVACY │
│ │
│ Device-to-device transfer │
│ No intermediary visibility │
│ No central bank visibility │
│ Like physical cash │
│ │
│ Limited to small amounts │
└────────────────────────────────────────────────┘

VERIFICATION CLAIM:
Architecture makes surveillance impossible
Not just policy—technical design

---

PRIVACY-ENHANCING CRYPTOGRAPHY

ZERO-KNOWLEDGE PROOFS (ZKP):
┌────────────────────────────────────────────────┐
│ Prove something without revealing details │
│ │
│ Example for CBDC: │
│ "I have sufficient balance" without │
│ revealing actual balance │
│ │
│ "This transaction is valid" without │
│ revealing sender, recipient, or amount │
│ │
│ Used in: Zcash, some research CBDCs │
│ Challenge: Computational overhead │
└────────────────────────────────────────────────┘

HOMOMORPHIC ENCRYPTION:
┌────────────────────────────────────────────────┐
│ Compute on encrypted data │
│ │
│ System processes transactions │
│ Without decrypting them │
│ Results still valid │
│ │
│ Challenge: Very computationally expensive │
│ Status: Mostly research stage │
└────────────────────────────────────────────────┘

BLIND SIGNATURES:
┌────────────────────────────────────────────────┐
│ Sign something without seeing content │
│ │
│ Bank signs token without knowing │
│ who will use it │
│ │
│ Original eCash (Chaum) used this │
│ Provides unlinkability │
└────────────────────────────────────────────────┘
```

ARCHITECTURAL APPROACHES

DATA MINIMIZATION:
┌────────────────────────────────────────────────┐
│ Collect only what's necessary │
│ Delete when no longer needed │
│ Don't store what you don't need │
│ │
│ Principle: Less data = less risk │
└────────────────────────────────────────────────┘

SEPARATION OF CONCERNS:
┌────────────────────────────────────────────────┐
│ Identity system ─┐ │
│ │ NOT directly linked │
│ Transaction system ─┘ │
│ │
│ Linking requires explicit process │
│ Architectural barrier │
└────────────────────────────────────────────────┘

DISTRIBUTED STORAGE:
┌────────────────────────────────────────────────┐
│ No single database with everything │
│ │
│ Intermediary A: Their customers only │
│ Intermediary B: Their customers only │
│ Central bank: Aggregate only │
│ │
│ Comprehensive view requires combining │
└────────────────────────────────────────────────┘

PSEUDONYM ROTATION:
┌────────────────────────────────────────────────┐
│ User has multiple pseudonyms │
│ Rotated regularly │
│ Harder to link transactions over time │
│ │
│ Reduces pattern analysis effectiveness │
└────────────────────────────────────────────────┘
```

PRIVACY TECH REALITY CHECK

ZERO-KNOWLEDGE PROOFS:
✓ Strong privacy guarantees
✗ Computationally expensive
✗ Complex to implement correctly
✗ Not mature for CBDC scale
Status: Research, limited deployment

HOMOMORPHIC ENCRYPTION:
✓ Theoretically powerful
✗ Very slow (orders of magnitude)
✗ Limited operations supported
✗ Not practical for real-time payments
Status: Research

BLIND SIGNATURES:
✓ Proven technology
✗ Requires online redemption eventually
✗ Limited functionality
Status: Usable for specific cases

THE HONEST ASSESSMENT:
Strong cryptographic privacy is possible
But at significant performance/complexity cost
Most CBDCs choose simpler approaches
Privacy often by policy, not technology
```

---

ANTI-MONEY LAUNDERING CONSTRAINTS

LEGAL REQUIREMENTS:
┌────────────────────────────────────────────────┐
│ FATF Standards require: │
│ │
│ - Customer identification (KYC) │
│ - Transaction monitoring │
│ - Suspicious activity reporting │
│ - Record keeping │
│ - Sanctions screening │
│ │
│ These apply to CBDC │
└────────────────────────────────────────────────┘

IMPACT ON PRIVACY:
Full anonymity not possible above thresholds
System must be able to identify users
Records must be kept for years
Law enforcement access required

THE TRADE-OFF:
Privacy ◄─────────────────────► Compliance
Can't have full anonymity AND full compliance

THRESHOLD APPROACH:
Below €X: Simplified due diligence (more privacy)
Above €X: Full KYC required
Aggregate limits prevent structuring
```

DATA PROTECTION REQUIREMENTS

GDPR (European Union):
┌────────────────────────────────────────────────┐
│ - Purpose limitation │
│ - Data minimization │
│ - Storage limitation │
│ - Right to erasure (with exceptions) │
│ - Data portability │
│ - Lawful basis required │
└────────────────────────────────────────────────┘

Applies to CBDC data handling
Creates privacy floor

CONFLICTS:
┌────────────────────────────────────────────────┐
│ AML: "Keep records for 5+ years" │
│ GDPR: "Delete when no longer needed" │
│ │
│ AML: "Monitor all transactions" │
│ GDPR: "Data minimization" │
│ │
│ Resolution: AML wins where applicable │
│ But GDPR applies to excess collection │
└────────────────────────────────────────────────┘

LAW ENFORCEMENT CONSIDERATIONS

LEGAL ACCESS REQUIREMENTS:
┌────────────────────────────────────────────────┐
│ Law enforcement may access records: │
│ │
│ - With warrant/court order │
│ - For specific investigations │
│ - Within legal framework │
│ │
│ CBDC must enable this access │
│ When legally required │
└────────────────────────────────────────────────┘

MASS SURVEILLANCE VS. TARGETED ACCESS:
┌────────────────────────────────────────────────┐
│ Targeted access (legal): │
│ - Specific suspect │
│ - Court approval │
│ - Limited scope │
│ │
│ Mass surveillance (concern): │
│ - Everyone monitored │
│ - No judicial oversight │
│ - Fishing expeditions │
│ │
│ Good privacy architecture: │
│ - Enables targeted access │
│ - Prevents mass surveillance │
└────────────────────────────────────────────────┘
```

---

PRIVACY IN LAUNCHED CBDCs

PATTERN:
Most launched CBDCs have limited privacy
Tiered approaches common
Full anonymity not available
```

PRIVACY IN PLANNED CBDCs

DIGITAL EURO:
┌────────────────────────────────────────────────┐
│ Strongest privacy commitment among major │
│ economy CBDCs │
│ │
│ Proposed: │
│ - ECB cannot see individual transactions │
│ - Offline = cash-like privacy │
│ - Online = intermediary sees, ECB doesn't │
│ - Privacy for small transactions │
│ │
│ Verification: To be tested in implementation │
└────────────────────────────────────────────────┘

UK DIGITAL POUND:
┌────────────────────────────────────────────────┐
│ Privacy is design priority │
│ Bank of England: No individual data │
│ PIPs (Payment Interface Providers) handle │
│ Still in design phase │
└────────────────────────────────────────────────┘

PATTERN:
Western CBDCs emphasizing privacy
But implementation will test claims
Architecture > promises
```

---

✅ Privacy and compliance are in tension—full anonymity isn't legally possible above thresholds.

✅ Architecture determines privacy more than policy—technical design limits what's possible.

✅ Intermediary shield can enhance privacy—distributing data limits central visibility.

⚠️ Whether privacy promises will be kept—implementation will test design claims.

⚠️ How privacy-enhancing tech will scale—ZKP and others face performance challenges.

⚠️ Whether tiered privacy will be eroded—threshold creep is possible.

📌 Trusting "we won't look" without architecture—capability tempts usage.

📌 Assuming regulation is the limit—laws can change.

📌 Believing "controllable anonymity"—often means controlled, not anonymous.

CBDC privacy is a design choice with real constraints. Full cash-like anonymity is legally impossible for significant transactions. But architecture can limit surveillance—the Digital Euro's intermediary shield is an example. The key question: is privacy enforced by design or merely promised by policy? Technical limits are more trustworthy than political promises.

---

Assignment: Design a privacy architecture for a hypothetical CBDC that balances compliance requirements with citizen privacy expectations.

Time Investment: 3-4 hours

---

End of Lesson 16

Course 58: CBDC Architecture & Design
Lesson 16 of 20