Central bank digital currencies (CBDCs) are a revolutionary technology which can address a wide menu of policy priorities, from banking efficiency and financial inclusion, to fiscal transparency and mitigating organized financial crime. However, choices to achieve different policy priorities imply distinct and potentially incompatible designs of CBDCs which may inhibit cross-border interoperability at global scale. The issue of cross-border compatibility in CBDC design implies that today’s policy-driven design choices in CBDC projects constitute a collective action problem at the global level. In theory, this is a complicated, multi-level coordination issue facing decision-makers who are largely still learning on the job as they build these instruments. However, as I’ll argue in this post, this issue can be empirically mapped to identify specific junctures of (in)compatibility among current project choices, and to identify both economic and political implications of these (in)compatibility junctures among countries.
In theory, establishing cross-border interoperability among retail CBDCs is simpler when any two CBDCs share an identical architecture, infrastructure, and/or access design than if not. In theory, this ease of interoperability is compounded when more design features are shared, and by extension, interoperability issues become more serious when more design features are different for any two CBDCs. These two simple assumptions allow us to empirically map the contemporary state of retail CBDC interoperability at future scale given the publicly-announced design choices different central banks have made for their retail CBDC projects. Drawing on data from the Bank for International Settlements, there are 47 central banks pursuing retail CBDC projects. Among these, 33 have made atleast one design choice in architecture, infrastructure, access, or interlinkages; 25 have made a decision on any feature other than interlinkages. Given that the choice of interlinkages stands as a mediating variable determining the likelihood or possibility of interoperability issues, as it determines the potential for retail CBDC use across borders, I limit this exploratory analysis to only the first three design features outlined in the BIS work. These design features are summarized in table 1 below, from panel 3 of the BIS data.
Table 1: Summary of BIS Retail CBDC Project Data and Design Features
| Design Feature | Design Choice | Count |
| Architecture | Direct | 2 |
| Hybrid | 18 | |
| Indirect | 1 | |
| Undecided | 26 | |
| Infrastructure | Conventional | 6 |
| Hybrid | 6 | |
| Decentralized | 5 | |
| Undecided | 30 | |
| Access | Account | 5 |
| Hybrid | 7 | |
| Token | 4 | |
| Undecided | 31 |
When we measure interoperability within panels, we can easily map out which countries share a design choice along the three main features other than interlinkages. Furthermore, we can look for clusters of interoperability using a community detection algorithm on our network of shared CBDC design choices. The walktrap community detection algorithm simply looks for clusters of nodes – in this case, countries – where it is easy to get ‘trapped’ in loops along a walk of some number of pre-specified steps. Simply, a community in this case reflects a group of nodes who are more connected among each other than they are to other nodes in the network (internally coherent community structure). For the sake of illustration, we’ll limit the walk in our community detection algorithm to 5 steps, but we can flex this parameter later. As shown below, we can map out interoperability across all three panels of data, and across all three design features among projects with data in each of the panels, shown below in plots 1, 2, and 3:
Plot 1: Interoperability Network for Panel 1 Data
Plot 2: Interoperability Network for Panel 2 Data
Plot 3: Interoperability Network for Panel 3 Data
Two patterns are worth noting here. First, within each panel, there are distinct communities of interoperable CBDC projects when comparing each design feature. Within each panel plot, all nodes are laid out identically across design networks, for ease of comparing the communities identified in each. Simply, in each panel of data, there are unique communities of interoperable CBDCs in architecture, infrastructure, and access, respectively. This implies that the issue of CBDC interoperability is multi-dimensional even within a single segment of time, and requires careful technical solutions to ensure interoperability among projects which will inevitably employ atleast some distinct design features at a pairwise level. The second pattern to note here is the growing complexity of these networks as countries are added, and make more design choices, over panels of data. Although in part a byproduct of inductive community detection algorithm parameters, this implies that interoperability issues may actually become more complex as states pursue CBDC designs in similar patterns as they have with these past three panels of data.
These initial plots are arguably boring applications of network methods, though, as they simply offer an aesthetic projection of binary shared design features. To fully explore the system of interoperability at scale, we can consider aggregating these networks and lowering the bar for interoperability to be defined instead as sharing atleast one design feature of a retail CBDC. Plot 4 below depicts networks modeled in this fashion across all three panels, aggregating the above networks and reducing tie definition to one or more shared design features. The same community detection algorithm and parameters are applied, and show that over all three panels, there is a consistent three-community structure of low-interoperability clusters among CBDCs.
Plot 4: Interoperability Network for Any Shared Design Feature, All Panels
Notably, we can aggregate design choice covariates by cluster to assess whether there are meaningfully different patterns of design features by cluster when using this lower threshold for CBDC interoperability. To this end, I briefly coded each design feature with a simple value indicating the degree to which it varies from today’s status quo. For example, in architecture, an indirect claim system is status quo (resembling today’s two-tiered banking system) whereas direct claims are far more radical and challenge the structure of the contemporary banking system. In infrastructure, conventional centralized ledgers are more status quo choices than the decentralized alternatives being entertained in some projects. For access, account frameworks more closely resemble today’s status quo than token frameworks. In each of these cases, status quo choices receive a value of 0, hybrid choices receive a value of 1, and radical choices receive a value of 2. Table 2 below outlines the average score of all countries in each cluster, by each panel of data, organized by the least and most radical cluster by panel. As a note, the members of each cluster do not necessarily carry over across panels.
Table 2: Average Design Feature Score by Community, Across Panels
| Community | Panel 1 | Panel 2 | Panel 3 |
| Least Radical | 2.0 | 1.8 | 1.5 |
| Middle-Ground | 2.6 | 2.3 | 2.4 |
| Most Radical | 3.6 | 3.3 | 3.1 |
As noted in the table, there is a consistent spread in the average score for each community across all three panels of data. Notably, as the possible values for these average scores range from 0 (all status quo choices on all features for all members of a cluster) to 8 (all radical choices on all features for all members of a cluster), these averages range respectively from 18.8% to 45% of the possible maximum values for any given cluster. Notably, the spread between most and least radical clusters remains consistent across panels, approximately 1.6 (20% of the maximum possible spread). However, the baseline across clusters appears to drop across panels of data, suggesting the decisions have increasingly been made on status quo features as more states enter the fray and announce public decisions on design features.
The evidence here suggests strongly that an interoperability problem is already emerging among retail CBDCs, and that cross-CBDC interoperability may exist at the cluster level, and not simply at the pairwise or global levels. Furthermore, there remains ample room for this problem to either shrink with greater interstate coordination – especially with continued talks over soft and binding standards for CBDCs – or for the issue to grow as states continue designing CBDCs strictly around their respective domestic priorities. Clear next steps here involve mapping potential futures of interoperability at scale under different scenarios of CBDC design choices by countries, a topic which I’ll tackle in the next post.
Tim Marple 