Digitale valuta van centrale banken (CBDC's): een praktische gids voor de infrastructuur achter digitaal geld

Digitale valuta van centrale banken (CBDC) wordt vaak besproken alsof het simpelweg "geld op een telefoon" is. De technische realiteit is echter complexer. Een bruikbare CBDC heeft een uitgifte- en afwikkelingslaag nodig, regels voor wie er toegang toe heeft, interfaces voor banken en betalingsproviders, gebruikerswallets of andere betaalmiddelen, privacycontroles, fraudebescherming, operationele robuustheid en – in sommige ontwerpen – offline functionaliteit. De technologie kan daarom beter worden begrepen als een betalingssysteem dan als een enkele app of grootboek.

De ontwikkeling van CBDC's is nog steeds wijdverspreid. In het onderzoek van de Bank for International Settlements (BIS) naar de periode 2024, gepubliceerd in augustus 2025, gaven 85 van de 93 ondervraagde centrale banken – 91% – aan dat ze een CBDC voor de detailhandel, een CBDC voor de groothandel, of beide onderzochten. De ontwikkeling van een CBDC voor de groothandel was over het algemeen verder gevorderd. Zie de resultaten van het BIS-onderzoek naar CBDC's in 2024 .

De basisprincipes van CBDC: wat wordt er nu precies gedigitaliseerd?

Een CBDC is centraal bankgeld in digitale vorm. Het belangrijkste verschil is niet of er gebruik wordt gemaakt van blockchain, maar voor wie het geld bestemd is en hoe de eigendomsrechten, registratie en toegang tot het geld zijn geregeld.

De praktische conclusie is simpel: "digitaal" betekent niet automatisch "blockchain". De BIS heeft al langer aangegeven dat de infrastructuur van een CBDC gebruik kan maken van een conventionele, centraal beheerde database of van gedistribueerde grootboektechnologie (DLT). De juiste keuze hangt af van beleidsdoelen, het operationele model, de vereisten voor veerkracht, doorvoer en governance, en niet zozeer van een voorkeur voor een bepaald modewoord.

De infrastructuur van de CBDC

1. Uitgifte, inwisseling en het kerngrootboek

Het kernsysteem moet inzicht geven in de hoeveelheid CBDC die bestaat, wie of wat bevoegd is om deze te verplaatsen, en wanneer transacties definitief worden. De centrale bank blijft verantwoordelijk voor de uitgifte en inwisseling, zelfs wanneer particuliere tussenpersonen de klantgerichte diensten verzorgen.

Een nuttig referentiemodel van de BIS Consultative Group on Innovation and the Digital Economy beschrijft vier kernprocessen in de detailhandel: het registreren van gebruikers, het creëren van CBDC via "cash-in", het vernietigen van CBDC via "cash-out" en het overdragen van waarde binnen het grootboek. De voorgestelde architectuur maakt gebruik van een hybride model dat de verantwoordelijkheden verdeelt tussen de centrale bank en particuliere intermediairs. Zie het BIS-architectuurvoorstel voor CBDC in de detailhandel .

Het ontwerp van het grootboek moet operationele vragen beantwoorden, zoals de volgorde van transacties, het voorkomen van dubbele betalingen, de definitieve afwikkeling, herstel na een storing, reconciliatie en controleerbaarheid. Deze eisen zijn van belang, ongeacht of de implementatie gebruikmaakt van een traditionele database, een DLT met toegangsbeheer of een andere architectuur.

2. Tussenpersonen en het tweeledige model

Veel ontwerpen voor digitale centrale bankvaluta's (CBDC's) voor de detailhandel gaan er niet van uit dat een centrale bank de dagelijkse servicebalie wordt voor miljoenen gebruikers. In plaats daarvan kunnen banken of aanbieders van betaaldiensten de klantregistratie, de distributie van digitale portemonnees, fraudebestrijding, accountherstel en eerstelijns ondersteuning verzorgen, terwijl de centrale bank het monetaire systeem beheert of controleert.

Dit tweeledige model behoudt ruimte voor concurrentie in de private sector, terwijl het onderliggende geld een verplichting van de centrale bank blijft. Het vermindert ook de noodzaak voor een centrale bank om alle klantgegevens te verzamelen. Het brengt echter wel extra werk met zich mee op het gebied van interfaces en governance: intermediairs hebben consistente regels nodig voor identiteitsverificatie, sanctiescreening, transactieberichten, foutafhandeling, geschillenprocedures en beschikbaarheid van diensten.

3. Identiteits-, toegangs- en compliance-diensten

De infrastructuur van CBDC moet bepalen hoe een persoon of instelling het recht bewijst om een ​​wallet of rekening te openen, te financieren, te gebruiken, terug te vorderen of te sluiten. In retailsystemen overlapt dit meestal met vereisten op het gebied van 'ken uw klant' (KYC), anti-witwaspraktijken (AML), sancties, fraude en consumentenbescherming.

Identiteit hoeft niet te betekenen dat de centrale bank de werkelijke identiteit van elke gebruiker kan inzien. Architecturen kunnen identiteitsgegevens die door een betalingsprovider worden bewaard, scheiden van transactie-identificaties die door het afwikkelingssysteem worden gebruikt. Het precieze privacymodel is zowel een beleidsmatige en juridische keuze als een cryptografische.

4. API's en de servicelaag

Application programming interfaces (API's) vormen de verbindende schakel tussen de monetaire kern en de diensten die gebruikers daadwerkelijk gebruiken. Een goed ontworpen API-laag maakt het mogelijk dat meerdere banken, wallets, winkeliers en fintech-aanbieders verbinding maken zonder dat elk een aparte integratie met het grootboek van de centrale bank nodig heeft.

Project Rosalind van de BIS Innovation Hub testte dit idee met behulp van een tweelaags retailmodel voor een CBDC (digitale valuta voor de detailhandel). Het prototype bood 33 API-eindpunten in zes functionele categorieën en testte meer dan 30 gebruiksscenario's. Het project concludeerde dat een API-laag verschillen in onderliggende ledger-ontwerpen kan abstraheren, maar dat deze wel consistent moet zijn met het privacy- en werkingsmodel van de CBDC. Zie het rapport van Project Rosalind .

5. Wallets, kaarten, acceptatie door winkeliers en andere eindpunten

Voor een CBDC in de detailhandel kan het eindpunt een bankapp, een speciale portemonnee, een smartcard, een betaalmethode voor een mobiele telefoon, een kassaterminal, een QR-code of een andere vormfactor zijn. Het eindpunt is niet de valuta zelf; het is een toegangsmechanisme tot het CBDC-systeem.

Ontwerpers moeten rekening houden met toegankelijkheid, het terugvinden van verloren apparaten, authenticatie, acceptatie door winkeliers, transactiebewijzen, limieten, toegankelijkheid voor mensen met een beperking en ondersteuning voor gebruikers die geen moderne smartphones bezitten. Zelfs een technisch sterk digitaal grootboek kan falen als openbaar betalingssysteem als deze eindpunten moeilijk te gebruiken zijn.

6. Offline betalingen

Offline CBDC is een van de lastigste infrastructurele problemen, omdat het systeem mogelijk waarde moet overdragen wanneer geen van beide apparaten de online ledger kan bereiken. Dit verhoogt het risico op dubbele uitgaven, compromittering van apparaten, verouderde saldi en inconsistente status.

Het BIS Project Polaris-handboek benadrukt dat er geen universeel toepasbaar offline ontwerp bestaat. Oplossingen kunnen bestaan ​​uit beveiligde hardware, opgeslagen waarde, apparaat-naar-apparaat-overdrachtsprotocollen, risicolimieten en latere synchronisatie met het online systeem. Zie het Project Polaris offline CBDC-handboek . De IMF-evaluatie van oplossingen met beperkte connectiviteit uit 2025 behandelt eveneens opgeslagen-waardekaarten en apparaat-naar-apparaat-benaderingen en benadrukt de afwegingen tussen vormfactor, cyberbeveiliging, privacy en gebruiksgemak; zie de IMF-evaluatie van CBDC's met beperkte connectiviteit .

7. Cyberbeveiliging, veerkracht en operationele controle

Omdat CBDC een cruciale nationale betalingsinfrastructuur kan worden, kan veerkracht niet achteraf worden toegevoegd. Het systeem heeft een gelaagde beveiliging nodig: sterk sleutelbeheer, netwerksegmentatie, veilige softwareontwikkeling, kwetsbaarheidsbeheer, toegangscontrole, transactiemonitoring, back-up en herstel, noodherstellocaties, incidentrespons en regelmatige tests.

Beschikbaarheidsdoelstellingen moeten ook afhankelijkheden buiten het centrale grootboek omvatten: telecomnetwerken, identiteitsdiensten, cloud- of datacenterinfrastructuur, tussenliggende systemen, acceptatie door handelaren en hardwarebeveiligingsmodules. Een CBDC die afhankelijk is van één kwetsbare externe component is niet robuust alleen omdat het grootboek gerepliceerd is.

8. Gegevensarchitectuur en privacy

Privacy is een infrastructurele eigenschap, geen louter beleidsverklaring. Ontwerpers moeten beslissen welke gegevens worden gegenereerd, waar ze worden opgeslagen, hoe lang ze worden bewaard, welke partijen transactiegegevens aan identiteiten kunnen koppelen en wat er wettelijk openbaar gemaakt mag worden.

Nuttige technieken zijn onder andere dataminimalisatie, pseudonieme identificatoren, scheiding van identiteits- en transactiegegevens, encryptie, toegangsregistratie en op rollen gebaseerde gegevensinzichtelijkheid. Geavanceerdere privacyverhogende technologieën kunnen in sommige ontwerpen geschikt zijn, maar ze moeten nog steeds fraudebestrijding, wettelijke verplichtingen, prestaties en operationeel herstel ondersteunen.

9. Interoperabiliteit en grensoverschrijdende verbindingen

Een CBDC bestaat zelden op zichzelf. De binnenlandse infrastructuur moet mogelijk verbinding maken met commercieel bankgeld, instant-betalingssystemen, kaartnetwerken, effectenplatformen of andere CBDC's. Interoperabiliteit omvat daarom meer dan alleen berichtopmaak: het kan compatibele identiteitsregels, openingstijden, liquiditeitsregelingen, valutamechanismen, juridische kaders en afwikkelingsmodellen vereisen.

Voor groothandel en grensoverschrijdend gebruik hebben experimenten zoals BIS Project mBridge en Project Icebreaker gedeelde platforms en onderling verbonden nationale systemen onderzocht. Dit zijn experimenten en geen universele blauwdrukken, maar ze laten zien waarom ontwerpkeuzes voor grensoverschrijdend gebruik gemakkelijker vroegtijdig kunnen worden aangepakt dan achteraf, nadat nationale systemen al zijn vastgelegd.

Gecentraliseerde database of DLT?

Het belangrijkste punt is dat geen van beide architecturen automatisch "digitaler" is. Een CBDC kan technologisch geavanceerd zijn zonder blockchain te gebruiken, en een DLT-gebaseerd systeem heeft nog steeds conventionele infrastructuur nodig voor identiteit, API's, monitoring, apparaten, ondersteuning en governance.

Hoe een CBDC-betaling in de detailhandel kan verlopen

1. Registratie: een bank of erkende betalingsprovider verifieert de gebruiker en maakt de benodigde digitale portemonnee, rekening, alias of inloggegevens aan.
2. Financiering: de gebruiker zet geld van een commerciële bank of contant geld om in CBDC, waardoor het corresponderende CBDC-saldo of de bijbehorende waarde wordt gecreëerd of toegewezen volgens de regels van het systeem.
3. Betaling: de gebruiker autoriseert een overdracht. De tussenliggende en centrale infrastructuur valideren het verzoek, passen limieten en controles toe en verwerken de overdracht definitief.
4. Meldingen en registratie: betaler en ontvanger ontvangen statusinformatie, terwijl het systeem alleen de gegevens registreert die vereist zijn door de gekozen architectuur en het wettelijke kader.
5. Inwisseling: de gebruiker kan CBDC terugwisselen naar een andere valuta, waarbij de corresponderende CBDC-representatie naar behoefte wordt verminderd of vernietigd.

Een offline betaling verandert stap drie aanzienlijk, omdat de definitieve online validatie mogelijk niet beschikbaar is op het moment van overdracht. Daarom vereist offline functionaliteit een specifiek ontwerp voor risicobeheer, hardware, synchronisatie en herstel, in plaats van een simpele schakelaar voor de "offline modus".

Praktische checklist voor het evalueren van CBDC-infrastructuur

• Aansprakelijkheid en governance: Wie geeft de CBDC uit, wie beheert elk onderdeel en wie is verantwoordelijk als er iets misgaat?
• Grootboek en afwikkeling: Wat houdt definitieve afhandeling in en hoe worden duplicaten, terugboekingen en terugvorderingen afgehandeld?
• Distributiemodel: Welke verantwoordelijkheden liggen bij de centrale bank en welke bij de banken en betalingsdienstaanbieders?
• Identiteit en compliance: Wie voert de KYC/AML-controles uit en welke informatie bereikt de centrale bank?
• Privacy: Worden gegevens geminimaliseerd en gescheiden op basis van rol? Kunnen identiteiten aan transacties worden gekoppeld, en door wie?
• Prestaties: Kan het systeem voldoen aan de verwachte piekvolumes van transacties en de vereisten voor latentie?
• Veerkracht: Zijn er meerdere faaldomeinen, noodherstelplannen en beproefde continuïteitsprocedures?
• Offline functionaliteit: is dit vereist? Zo ja, welke beveiligde hardware, waardebeperkingen, synchronisatie- en fraudebestrijdingsmaatregelen zijn nodig?
• Interoperabiliteit: Kan de CBDC samenwerken met bestaande betaalsystemen, banken, winkeliers en mogelijk ook met buitenlandse systemen?
• Toegangskanalen: Worden smartphones, simkaarten, gewone mobiele telefoons of ondersteunde kanalen aangeboden aan de beoogde doelgroep?
• Leveranciersstrategie: kunnen componenten worden vervangen of geüpgraded zonder dat de centrale bank gebonden raakt aan één leverancier?
• Operationele observeerbaarheid: Zijn monitoring, auditlogs, incidentdetectie, afstemming en ondersteuningsprocessen vanaf het begin goed ontworpen?

Wat onthullen de huidige projecten over de richting van de CBDC-infrastructuur?

Huidige projecten wijzen eerder op modulaire ecosystemen dan op één universele CBDC-stack. Het werk van het BIS aan de technische vereisten benadrukt interoperabiliteit, schaalbaarheid, gebruikersgericht ontwerp, beveiliging en gegevensprivacy als belangrijke vereisten; zie de technische vereisten op hoog niveau van het BIS . Het virtuele handboek voor CBDC van het IMF , bijgewerkt in november 2025, beschouwt CBDC eveneens als een gecombineerde uitdaging op het gebied van beleid, operationele aspecten, technologie, privacy, cyberweerbaarheid en adoptie.

Het digitale europroject is een actueel voorbeeld van hoe deze modulaire denkwijze wordt toegepast. Nadat de voorbereidingsfase in oktober 2025 was afgerond, is het Eurosystem overgegaan tot verder technisch werk. Het gepubliceerde architectuurwerk omvat gebieden zoals offline functionaliteit, veilige uitwisseling van betalingsgegevens, fraudebestrijding en risicobeheer, apps en software development kits, veerkracht en privacybeschermende verwerking. In augustus 2026 meldde de ECB dat er gewerkt werd aan offline functionaliteit en dat er gekeken werd naar veilige hardware in smartphones, waaronder ingebouwde Secure Elements en eSIMs, in aanloop naar een pilot die gepland staat voor de tweede helft van 2027. Zie de pagina over de voortgang van de digitale euro van de ECB en de update van de ECB over offline standaarden van 18 augustus 2026. Deze plannen zijn nog steeds onderworpen aan het Europese wetgevings- en besluitvormingsproces en moeten daarom worden beschouwd als ontwerpwerk voor het project en niet als bewijs van een definitief systeem.

De belangrijkste les: de CBDC-infrastructuur is een systeem van systemen.

Het grootboek is belangrijk, maar het is slechts één laag. Een operationele CBDC moet de uitgifte van geld, de afwikkeling, de tussenpersonen, identiteit, privacy, API's, gebruikersapparaten, acceptatie door handelaren, cyberbeveiliging, offline risico's, terugvordering en juridisch beheer coördineren. De meest geloofwaardige ontwerpen beginnen daarom met de vereisten en operationele rollen, en kiezen vervolgens de technologie die aan die vereisten voldoet – niet andersom.

Voor lezers die CBDC-voorstellen vergelijken, zijn de meest nuttige vragen concreet: Wie beheert het grootboek? Wie heeft toegang tot de gebruikersidentiteit? Wat gebeurt er als een bank of netwerk niet beschikbaar is? Kunnen gebruikers hun geld terugkrijgen na verlies van een apparaat? Hoe voorkomt het systeem dubbele uitgaven offline? Kunnen meerdere aanbieders verbinding maken via gemeenschappelijke interfaces? En kan de architectuur evolueren zonder de integriteit van het centralebankgeld in gevaar te brengen? Deze vragen onthullen veel meer over de kwaliteit van een CBDC-ontwerp dan het feit of het project het woord 'blockchain' gebruikt.