Above: Javed Samuel and Shiva Bissessar.

By Shiva Bissessar, Managing Director & Principal Consultant and Javed Samuel, CBDC & Blockchain Technical Lead, Pinaka Consulting. Originally published in the Central Bank Payment News/Currency Research publication, on October 31, 2022.

Much has already been written on the various considerations central banks must be mindful of as they immerse themselves in central bank digital currency (CBDC) research from a theoretical perspective. This article presents insights from the vantage point of the consultant in driving the execution of a CBDC pilot based on real-life practical experience.

Pinaka Consulting served the Eastern Caribbean Central Bank (ECCB) on its CBDC project, providing programme management and technical oversight in the design, development, implementation, and operationalisation of the DCash product.

With the DCash pilot now operational in all eight Eastern Caribbean territories, our focus shifts somewhat from execution to providing assistance in charting the CBDC strategic direction, inclusive of potential commercial deployment, while also maintaining technical oversight of enhancements, new features, and integration efforts.

Introduction

The factors motivating developing countries towards retail CBDCs are very different from those in more developed economies, where retail payment infrastructure may be more advanced. For example, the eKrona CBDC project in Sweden is partially justified as a way in which the Sveriges Riksbank can maintain influence given that a cashless society has been largely attained due to effective retail payment systems developed by third parties. On the other hand, developing countries may be drawn towards the known benefits of a cashless society, such as reducing cash usage, advancing financial inclusion, or a potential desire to stimulate innovation in the retail payment system.

These motivations, while unique to each country, have led to the Caribbean small states realising three operational retail payment CBDCs at present: the Central Bank of The Bahamas’ Sand Dollar, the ECCB’s DCash, and the Bank of Jamaica’s JAM-DEX. Additionally, the Central Bank of Haiti has expressed its commitment to developing its own CBDC, a digital gourde. These are amazing achievements for the Caribbean in pioneering practical and operational research in this sphere.

The role of the consulting partner, as distinct from the vendor, on a CBDC project ensures that good governance is practiced in maintaining a separation of duties and responsibilities. Keeping consulting and project management roles distinct from roles involved in software development assists with accountability and ensures the independence of necessary advice.

On the DCash project, the development, implementation, and operationalisation with stakeholder partners took two years from inception to its launch in March 2021, a global first within a monetary union. Over this period, the vendor would have had access to key internal and external stakeholders to map out requirements of the software and understand critical central bank operational processes which the software would be designed around.

This required harmonisation between the client, vendor, and consulting partner to ensure that what was being built was fit for purpose, securely designed, and properly implemented. The fact that the vendor was able to utilise this experience and position a very similar solution to other clients where it was deployed on an accelerated timeframe, with any necessary customisations serves as testimony to the success of the DCash project.

Within this piece we shall draw upon our experience within this consulting role and highlight key learnings from this engagement which can be applied to other similar CBDC engagements.

Planning & Governance

The consultants were given early access to initial project documents which allowed for review and critique of the intended goal, objectives, requirements, and constraints. This included insights into various initial stakeholder engagements which the bank ran prior to formal commencement of the software development phase.

Initial approaches towards the solution design and methodology for achieving the same were also shared by the vendor. The goal here was to foster a collaborative environment with all stakeholders that maximised the value of everyone’s expertise.

Project governance was led by the Chair of the internal Fintech Committee, which itself was composed of subject matter experts drawn from various organisational units within the Bank.

The Programme Manger role was part of the services provided by the consultants, whose responsibilities here included oversight of project execution and chairing regular update meetings with participants from the Fintech Committee and the vendor’s team.

The organisation of teams to work on deliverables was achieved under defined workstreams. Weekly meetings and more ad hoc working sessions were utilised as needed to tackle specific issues, calling upon additional stakeholders or other experts as needed to cover various areas.

For example, meetings with external regulators and other stakeholders were required to map out Know Your Customer (KYC) requirements for onboarding customers, as well as define an appropriate Anti-Money Laundering and Combating Financial Terrorism (AML/CFT) framework pertaining to wallet types, limits, and tiers.

The Technical Lead role was another component of the consultants’ remit which provided control and quality assurance over the release of software. This role required close coordination with the vendor’s development team in accordance with their agile software development sprint cycles as well as corresponding coordination with the Bank’s technical team.

The Technical Lead oversaw the construction, design, and implementation of the vendor’s CBDC solution. The technical design and architecture choices were closely scrutinised and, where necessary, compromises and/ or compensating controls were established to ensure that the vendor’s solution met the Bank’s documented requirements and followed secure development practice.

A key tool utilised in ensuring that requirements were satisfied was the requirement’s traceability matrix, which ensured the business requirements were in fact translated into actual deliverables in the final product. There was also iterative feedback provided to the vendor and the Bank during the design and implementation phase of the CBDC solution. Quality assurance was a critical part of this phase as the Bank ensured that the public product was user-friendly, secure, scalable, and efficient.

Key Design Characteristics

The product was developed as a private, permissioned, blockchain-based retail CBDC maintaining a two-tier architecture with financial institutions (FIs). The Bank maintains sole authority for CBDC creation and its life cycle. It is an account-based system requiring updates to the balances on the ledger as opposed to a token-based system where fund transfers are enacted by the movement of tokens between parties.

Important currency management operations pertaining to physical notes and coins have been maintained in the CBDC via the defined workflows of minting, issuance, redemption, and destruction. In addition to ensuring key workflows were mirrored from the notes and coins paradigm, operational controls were also reviewed, designed, and implemented to operate with the CBDC product.

Other requirements of the CBDC included the need to cater for financial inclusion, which was achieved by offering a lower-tier wallet with a corresponding lower threshold for proof of identification requirements. Compliance requirements were fulfilled with the appropriate use of identity verification software allowing for a completely remote onboarding user experience where the user is not required to physically visit the FI branch to obtain the service. The same tool allows for the establishment of wallet tiers based on transaction limits and ensures that transactional limits are observed as part of real-time monitoring.

Reporting requirements also needed to be met to ensure the performance of the product over time can be tracked. Offline payments capability was also desired within the feature set to be delivered. However, this was deprioritised to more readily obtain a working solution given various constraints. Offline payments capability remains an objective of the pilot and will be examined for inclusion going forward.

The software designed and developed as part of this project needed to function with various partners within the ecosystem, including end-users, merchants, FIs, and the Bank itself.

While this may have been the most prudent approach at the time, a more scalable approach would be to have the CBDC solution built to provide central bank currency management operations while also allowing for third-parties to integrate via APIs for interactions at the retail and commercial layers, as was put forward most recently by the Reserve Bank of Australia in proposing the eAUD.

However, a key constraint of the DCash project stipulated that no system integration would take place for the duration of the pilot. This reduced the risk of potential delays due to integration with third parties however it also meant that systems were to run in parallel to normal operations at the various stakeholder partners.

For this reason, web apps were developed for the Bank and FIs, and mobile apps needed to be developed for merchants and end-users. Despite this, it was always the intention of the pilot to foster innovation within the retail payment system. Eventual interoperability with third-party wallet providers and integration with core banking applications remain long-term goals.

Prescriptive Approach to Technical Issues

Security and privacy are critical areas for consideration in the CBDC sphere and require appropriate focus. Security considerations should include the prevention of counterfeiting, fraud, and double spending. Sensitisation is necessary as to the various methods adversaries may use, for example, deploying a variety of attacks utilising sophisticated phishing campaigns and malware to attempt to obtain credentials or private keys.

Necessary steps in managing risk include assessment of various risks, such as malicious actors seeking to leverage privileged access to attempt to steal digital assets, along with mapping out potential mitigations and compensating controls. Furthermore, given the national importance of CBDC, recognition is required that it may be a target for other nation-states to engage in espionage to access information or create mayhem on another nation’s critical payments infrastructure.

Central banks should ensure such issues receive the necessary consideration from their consultants, IT and Risk departments, and audit teams when embarking on the CBDC journey to ensure a robust approach towards information security is in place.

Key management is a critical component of a CBDC deployment as public key cryptography is used for verifying and signing transactions to ensure security in the payment ecosystem. Various key management solutions have been developed to support CBDC use cases, which simplify key generation and key distribution.

These key management solutions are an attractive attack target and have resulted in several vulnerabilities such as insecure key generation or compromised key distribution. Key management solutions should include key generation—including via a secure mechanism such as a hardware security module (HSM)—secure key distribution, key storage, key revocation, and key destruction.

Central banks should ensure that key management solutions implement security controls that meet the expectation of a critical payment system, including appropriate access controls on all keys.

CBDC also relies on cryptographic protocols to secure transaction data. These protocols, and the mathematical functions on which they are based, provide the core security of the system to protect against the alteration of data or double spending. Central banks and other institutions, in collaboration with the security community, must evaluate whether these cryptography protocols meet their needs. This analysis should include their risk factors, availability of computational resources, and performance requirements.

Given the national importance of CBDC, it is recommended that central banks use standardised cryptographic protocols that have undergone comprehensive testing and evaluation. Looking ahead, it is advisable to anticipate upcoming quantum threats. The incorporation of quantum-resistant protocols within CBDC deployments is a necessity.

Appropriate use of stakeholder engagement on security and privacy issues, in understanding requirements, and providing explanations to parties is essential in any CBDC undertaking. All CBDC applications and associated infrastructure should undergo rigorous and in-depth testing.

This should include comprehensive validation across all APIs, functional and non-functional tests, integration, security testing, and performance testing. Depending on deployment choices, other areas such as peer or node testing and smart contract verification may be required to provide the necessary security guarantees. Various scenarios, workflows, and simulated attacks should all be integral parts of the CBDC testing process.

Central banks should work with all relevant stakeholders during the quality assurance phase to ensure that as many design and implementation flaws are identified and addressed prior to the go-live deployment of the CBDC.

Another critical aspect for consideration is privacy, which requires harmony between data collection practices, the need for preserving consumer privacy, and observation of prevailing data protection laws and regulations. CBDC designs may permit central bank oversight into all transactions, amounts, origins, and destinations by default, which may not be the preferred approach. Some privacy questions that should be evaluated by CBDC include the following:

• What information should be required to open an account?
• What data should be protected? How should this data be protected?
• Should all, a subset, or no transactions be observable by the central bank?
• What information should law enforcement have access to and under what conditions?
• Should the payer’s identity be visible to the recipient?

All technical elements of a CBDC ecosystem need a high level of operational and cyber resilience. The core CBDC infrastructure may need to have an even higher standard of resilience than the rest of the platform. Hence, the implications of various deployment models, such as on-premises or cloud platforms, should be considered.

The role of the consultant would be to guide the central bank in achieving the most optimal resiliency within the CBDC platform given the stated requirements, constraints, and industry best practices. It may be necessary to build parallel processing infrastructure to duplicate functionality in multiple deployments to add resilience, despite the additional cost to ecosystem partners and other intermediaries.

Further, a CBDC system may need to be interoperable or substitutable with other systems to be able to serve as an additional payment method and provide further resilience to the payment system.

Other keys areas for consideration within the development of a blockchain-based CBDC may include:

• Design and review of blockchain protocols and workflows
• Blockchain consensus and transaction validation
• Smart contract analysis
• Crypto custody and wallet key management solutions

Operations Focus

FIs were given training on the software and were required to produce an operational readiness self-assessment to ensure that they factored into consideration how the provision of the CBDC service would be facilitated alongside existing operations. Merchants also received training on the mobile apps.

Service fulfilment processes were defined by the FIs since the CBDC customer is a client of the FI rather than the central bank. FIs were required to extend their existing service assurance channels to cover the new product, providing second tier level support to customers, while escalation to the vendor serves as the final tier of support.

A robust and clear change management process needed to be defined to ensure that updates to the CBDC applications and deployment within the production environment are carefully managed. Reporting of key metrics, including those centred on usage and uptake, ensures that the system is tuned to deliver on expectations over the long haul.

Conclusion

The proliferation of retail CBDC research, testing, and pilots globally demonstrates keen interest by central bankers and policy makers in understanding how this technology can be implemented to assist their mandate. Significant strides have been delivered by developing countries in this sphere, and the innovation found in the Caribbean and Eastern Caribbean should be examined closely by entities seeking to enter the foray despite variances in motivations.

With the existence of multiple CBDC deployments, the Caribbean may be well-poised to explore opportunities for collaboration on issues such as CBDC interoperability and cross-border transactions.

This case serves to provide the readership with a brief glimpse of the myriad issues they may be confronted with and suggest some practical ways they can seek to address them. In pursuing a CBDC pilot, effective governance is required and harmonisation between the central bank, vendor, and consultant is necessary. The work is nowhere near complete. The CBDC journey continues to the point where data, information, and results can be garnered from such projects and shared within the community for proper evaluation.