Central bank digital currencies (CBDCs) are going to happen. More than 90% of the world's central banks are working on them. The question now is how to stop too much surveillance while still providing the financial inclusion they promise. This article goes beyond the debate of "surveillance state" versus "financial innovation" and introduces a three-layer model that combines CBDCs with privacy-friendly credit systems. By designing for privacy and auditing from the start, we can achieve both inclusion and freedom. Threat Model (Balanced) To design effective systems, start by understanding the threats and vulnerabilities to protect against, like unauthorized access and data breaches. Identify risks and assess their impact. Define objectives, user experience, integration, and scalability. Balance protection with system capabilities to create robust systems that meet security and operational goals. What CBDCs Do Well Government-to-Person (G2P) payments: CBDCs excel at delivering social benefits, stimulus payments, and emergency aid directly to citizens. During the COVID-19 pandemic, countries struggled to distribute relief funds quickly. A CBDC infrastructure would enable instant, targeted payments to those who need them most. Government-to-Person (G2P) payments: Resilience: Unlike commercial payment systems that depend on private companies, CBDCs provide a public utility that cannot be shut down by corporate decisions. When a fintech company like Synapse collapsed in 2024, customers lost access to $265 million in deposits. A CBDC backed by the central bank would eliminate this counterparty risk. Resilience: Financial inclusion: For the 1.4 billion adults worldwide without bank accounts, CBDCs provide a way to access formal financial services. A central bank wallet doesn't need a credit history, a minimum balance, or monthly fees, which are obstacles that keep the poor out of traditional banking. Financial inclusion: CBDC Risks Panopticon: A state-run digital currency gives the issuer a window into every citizen's purchases. China's e-CNY demonstrates this risk: all transactions pass through People's Bank of China (PBOC) systems, making them traceable by design. The PBOC has developed tools to tag or freeze accounts for "illicit activity" a category that can be defined arbitrarily by the state. Panopticon: Programmable coercion: CBDCs enable governments to hard-code restrictions into money itself. Authorities could impose spending limits on certain goods (alcohol, luxury items), set expiry dates that force spending within a timeframe, or freeze accounts instantly without judicial oversight. As the Cato Institute warns, "once a surveillance infrastructure is built into the currency, it's virtually impossible to close that door in the future." Programmable coercion: What Open Ledgers Do Well Transparency: Public blockchains like Creditcoin create tamper-proof records that anyone can audit. This transparency builds trust and enables verification without requiring access to centralized databases. Transparency: Portability: Credit histories recorded on open ledgers can follow individuals across borders and institutions. A borrower in Nigeria who moves to Ghana can carry their payment history with them, rather than starting from zero. Portability: Decentralization: No single entity controls a public blockchain. This distributes power and reduces the risk that one actor, whether government or corporation, can unilaterally manipulate records or deny access. Decentralization: Open Ledger Risks Metadata leakage: Even pseudonymous blockchains can reveal patterns. If transaction amounts, timing, and counterparties are public, sophisticated analysis can de-anonymize users and infer sensitive information about their behavior. Metadata leakage: MEV (Maximal Extractable Value): In some blockchain systems, validators can reorder transactions to extract profit, potentially disadvantaging users. This creates fairness concerns and can undermine trust in the system. MEV (Maximal Extractable Value): The Three-Layer Model The solution is not to choose between CBDCs and open credit ledgers, but to combine them in a layered architecture that leverages the strengths of each while mitigating their weaknesses. Layer 1: Settlement Layer (CBDC Rails for Fiat Finality) The base layer uses CBDC infrastructure for final settlement. When a lender disburses a loan or a borrower makes a repayment, the actual transfer of value occurs through CBDC wallets. This provides: Instant settlement: No waiting for bank transfers or correspondent banking chains Regulatory compliance: Central banks can enforce anti-money laundering (AML) and know-your-customer (KYC) requirements at this layer Fiat stability: Loans and repayments denominated in the national currency eliminate FX risk for domestic transactions Instant settlement: No waiting for bank transfers or correspondent banking chains Instant settlement: Regulatory compliance: Central banks can enforce anti-money laundering (AML) and know-your-customer (KYC) requirements at this layer Regulatory compliance: Fiat stability: Loans and repayments denominated in the national currency eliminate FX risk for domestic transactions Fiat stability: Critically, the CBDC layer handles settlement but does not record detailed transaction metadata beyond what's necessary for compliance. The central bank sees that "Wallet A transferred 1,000 units to Wallet B" but does not automatically know that this represents a loan repayment, a purchase, or a gift. settlement Layer 2: Credit Layer (Creditcoin as Public Credit Ledger) The middle layer records loan and repayment proofs on Creditcoin, a public blockchain designed specifically for credit history. This layer provides: Immutable records: Once a loan is issued and repayments are made, the data cannot be altered or deleted Pseudonymous credit histories: Borrowers build verifiable track records without exposing their legal identities Cross-border portability: Credit histories recorded on Creditcoin are accessible globally, enabling international lending Immutable records: Once a loan is issued and repayments are made, the data cannot be altered or deleted Immutable records: Pseudonymous credit histories: Borrowers build verifiable track records without exposing their legal identities Pseudonymous credit histories: Cross-border portability: Credit histories recorded on Creditcoin are accessible globally, enabling international lending Cross-border portability: The credit layer stores loan hashes (cryptographic fingerprints of loan terms), disbursement timestamps, repayment amounts, and default flags. It does not store borrower names, addresses, or other personally identifiable information (PII). not Layer 3: Privacy Layer (Selective Disclosure, Encryption, ZK-Proofs) The top layer implements privacy-preserving technologies that allow verification without revelation: Selective disclosure: Borrowers control what information they share with whom. A lender might see "this borrower made 12 on-time payments totaling $5,000" without learning the borrower's name or address. Selective disclosure: Encryption at rest: Sensitive data stored by lenders is encrypted using keys controlled by the borrower. Even if a lender's database is breached, the attacker cannot read the encrypted data without the borrower's key. Encryption at rest: Zero-knowledge proof attestations: Regulators can verify compliance without accessing raw transaction data. For example, a regulator could verify that "all loans in this portfolio meet minimum creditworthiness standards" without seeing individual borrower details. The lender proves compliance using cryptographic proofs rather than exposing data. Zero-knowledge proof attestations: Reference Architecture Here's how the three layers work together in practice. Sequence Diagram (Illustration) 1. Lender disburses loan from CBDC wallet → CBDC layer: Transfer 1,000 units from Lender Wallet to Borrower Wallet → Credit layer: Record loan hash on Creditcoin 2. Borrower makes repayment → CBDC layer: Transfer 250 units from Borrower Wallet to Lender Wallet → Credit layer: Record repayment timestamp and amount on Creditcoin 3. Regulator/auditor verifies compliance → Privacy layer: Request ZK-proof that loan meets regulatory standards → Lender generates proof without revealing borrower PII → Regulator verifies proof confirms compliance 1. Lender disburses loan from CBDC wallet → CBDC layer: Transfer 1,000 units from Lender Wallet to Borrower Wallet → Credit layer: Record loan hash on Creditcoin 2. Borrower makes repayment → CBDC layer: Transfer 250 units from Borrower Wallet to Lender Wallet → Credit layer: Record repayment timestamp and amount on Creditcoin 3. Regulator/auditor verifies compliance → Privacy layer: Request ZK-proof that loan meets regulatory standards → Lender generates proof without revealing borrower PII → Regulator verifies proof confirms compliance Key Management Borrower keys: Each borrower holds a private key that controls their CBDC wallet and authorizes updates to their credit record. This key can be stored on a smartphone, hardware wallet, or managed by a trusted custodian (for users who prefer not to manage keys themselves). Borrower keys: Lender keys: Lenders hold keys that authorize loan disbursements and sign credit record updates. Multi-signature schemes can require multiple lender employees to approve large transactions, reducing fraud risk. Lender keys: Regulator keys: Regulators hold read-only keys that allow them to audit credit records and verify compliance without the ability to modify data or access encrypted PII. Regulator keys: Role-Based Access Borrowers: Can view their own credit history, authorize lenders to access it, and revoke access at any time Lenders: Can view credit histories for borrowers who grant permission, record new loans and repayments, and generate compliance proofs Regulators: Can audit aggregate statistics, verify compliance proofs, and investigate specific cases with proper legal authorization Public: Can verify the integrity of the credit ledger (that records haven't been tampered with) without accessing individual borrower data Borrowers: Can view their own credit history, authorize lenders to access it, and revoke access at any time Borrowers: Lenders: Can view credit histories for borrowers who grant permission, record new loans and repayments, and generate compliance proofs Lenders: Regulators: Can audit aggregate statistics, verify compliance proofs, and investigate specific cases with proper legal authorization Regulators: Public: Can verify the integrity of the credit ledger (that records haven't been tampered with) without accessing individual borrower data Public: Event Logs All system actions are logged: loan disbursements, repayments, access grants, access revocations, and compliance checks. These logs are cryptographically signed and timestamped, creating an audit trail that can be reviewed if disputes arise. Governance & Oversight Technology alone cannot ensure privacy and accountability. Governance structures must define who holds power and how it can be checked. Who Holds the Keys? Central bank: Controls the CBDC settlement layer, including the ability to freeze accounts for legitimate law enforcement purposes (with judicial oversight) Central bank: Creditcoin validators: A decentralized network of validators maintains the credit ledger. No single validator can unilaterally alter records; changes require consensus among multiple independent parties. Creditcoin validators: Borrowers: Control access to their own credit histories and can revoke lender access at any time Borrowers: Independent oversight board: A multi-stakeholder board (including privacy advocates, consumer protection groups, and industry representatives) reviews system design, monitors for abuse, and recommends policy changes Independent oversight board: Revocation and Incident Response How revocation works: If a lender's access key is compromised, the oversight board can vote to revoke it, preventing the compromised key from accessing borrower data or recording new loans. The revocation is recorded on-chain and takes effect immediately. How revocation works: Incident response: If a privacy breach occurs (e.g., encrypted data is exposed), the system triggers an automatic notification to affected borrowers. An incident response team investigates the breach, implements fixes, and publishes a public report (with sensitive details redacted). Incident response: Public Transparency Reports Every quarter, the system publishes a transparency report showing: Total number of loans issued Total repayment amounts Default rates by product type Number of regulator access requests and outcomes Number of privacy incidents and resolutions Total number of loans issued Total repayment amounts Default rates by product type Number of regulator access requests and outcomes Number of privacy incidents and resolutions These reports provide accountability without compromising individual privacy. Policy Checklist Policymakers designing CBDC-plus-credit systems should ensure the following minimum standards: Minimum Viable Privacy [ ]Transactions are pseudonymous by default (no automatic linking to legal identities) [ ]PII is encrypted and controlled by users, not stored in plaintext by service providers [ ]Regulators can audit compliance without routine access to individual transaction details [ ]Users can revoke third-party access to their data at any time [ ]Transactions are pseudonymous by default (no automatic linking to legal identities) [ ] [ ]PII is encrypted and controlled by users, not stored in plaintext by service providers [ ] [ ]Regulators can audit compliance without routine access to individual transaction details [ ] [ ]Users can revoke third-party access to their data at any time [ ] Open APIs [ ]System interfaces are publicly documented, allowing third-party developers to build compatible services [ ]No vendor lock-in: users can switch between service providers without losing their credit history [ ]Interoperability with other financial systems (traditional banks, mobile money, international remittances) [ ]System interfaces are publicly documented, allowing third-party developers to build compatible services [ ] [ ]No vendor lock-in: users can switch between service providers without losing their credit history [ ] [ ]Interoperability with other financial systems (traditional banks, mobile money, international remittances) [ ] Auditability Tests [ ]Independent auditors can verify aggregate statistics match on-chain data [ ]Compliance proofs can be checked without accessing raw data [ ]System logs are tamper-evident and retained for a defined period [ ]Independent auditors can verify aggregate statistics match on-chain data [ ] [ ]Compliance proofs can be checked without accessing raw data [ ] [ ]System logs are tamper-evident and retained for a defined period [ ] Red-Team Drills [ ]Regular security assessments by independent experts attempting to breach privacy protections [ ]Simulated attacks on key management systems [ ]Stress tests of incident response procedures [ ]Regular security assessments by independent experts attempting to breach privacy protections [ ] [ ]Simulated attacks on key management systems [ ] [ ]Stress tests of incident response procedures [ ] Public Bug Bounties [ ]Rewards for security researchers who discover vulnerabilities [ ]Clear disclosure process that protects researchers from legal liability [ ]Rapid patching of discovered issues [ ]Rewards for security researchers who discover vulnerabilities [ ] Rewards for security researchers who discover vulnerabilities [ ]Clear disclosure process that protects researchers from legal liability [ ] Clear disclosure process that protects researchers from legal liability [ ]Rapid patching of discovered issues [ ] Rapid patching of discovered issues Pilot Blueprint Theory is important, but implementation reveals the real challenges. Here's a blueprint for a pilot program. City-Pair Cash Transfer Scope: Enable instant cash transfers between two cities (e.g., Lagos and Accra) using CBDC settlement and Creditcoin credit verification. Scope: Participants: 1,000 users in each city, recruited through local mobile money agents Participants: Duration: 6 months Duration: Evaluation metrics: Evaluation metrics: Delivery time p95 (95th percentile): Target <5 minutes Privacy breach count: Target = 0 Complaint rate: Target <2% of transactions Cost per transaction: Target <$0.50 Delivery time p95 (95th percentile): Target <5 minutes Privacy breach count: Target = 0 Complaint rate: Target <2% of transactions Cost per transaction: Target <$0.50 MSME Loan Program Scope: Provide small business loans (up to $5,000) to micro, small, and medium enterprises using Creditcoin credit histories and CBDC disbursement. Scope: Participants: 500 businesses across Nigeria, Ghana, and Sierra Leone Participants: Duration: 12 months Duration: Evaluation metrics: Evaluation metrics: Time-to-fund p95: Target <24 hours Default rate: Benchmark against traditional microfinance (target: equal or better) Borrower satisfaction: Target >80% would recommend to others Credit line graduation rate: Target >60% of on-time borrowers receive limit increases Time-to-fund p95: Target <24 hours Default rate: Benchmark against traditional microfinance (target: equal or better) Borrower satisfaction: Target >80% would recommend to others Credit line graduation rate: Target >60% of on-time borrowers receive limit increases Evaluation Framework Both pilots should be independently evaluated by a research institution (e.g., MIT J-PAL, IPA) using randomized controlled trials where feasible. Key questions: Does the system actually improve financial inclusion (measured by new credit access for previously unbanked individuals)? Are privacy protections effective (measured by user surveys and technical audits)? Is the system cost-effective compared to alternatives (measured by cost per user served)? What are the unintended consequences (measured through qualitative interviews and complaint analysis)? Does the system actually improve financial inclusion (measured by new credit access for previously unbanked individuals)? Does the system actually improve financial inclusion (measured by new credit access for previously unbanked individuals)? Are privacy protections effective (measured by user surveys and technical audits)? Are privacy protections effective (measured by user surveys and technical audits)? Is the system cost-effective compared to alternatives (measured by cost per user served)? Is the system cost-effective compared to alternatives (measured by cost per user served)? What are the unintended consequences (measured through qualitative interviews and complaint analysis)? What are the unintended consequences (measured through qualitative interviews and complaint analysis)? Replace Fear with Design The CBDC debate has been dominated by fear: fear of surveillance, fear of losing monetary sovereignty, fear of technological disruption. But fear alone doesn't build better systems. If we architect for privacy and audit from day one, using layered designs that separate settlement, credit, and privacy functions, we can have inclusion and liberty. CBDCs can deliver the benefits of instant payments and financial access without becoming tools of oppression. Open credit ledgers can provide transparency and portability without exposing sensitive personal information. and The three-layer model presented here is not the only possible design, but it demonstrates that the trade-offs are not binary. We don't have to choose between privacy and inclusion, between innovation and regulation, between centralized efficiency and decentralized resilience. The decisions made today will shape the future of money for decades. Institutions and citizens alike must demand that digital currency systems are designed with privacy, transparency, and accountability as core principles, not afterthoughts. The technology exists. The question is whether we have the political will to use it wisely.
