How CBDC enhances the role for Mojaloop in developing economies

Tuesday January 26, 2021
12:30 PM UTC

Session Leads: David Mangini (@DMangini)

Session Description: Central Bank Digital Currency (CBDC) has rapidly gained momentum in the global effort to move from physical cash to new forms of digital payments using legal tender. Central banks around the world, especially in developing economies are considering CBDDC to reach every segment of the society, especially those who are underserved by the private banking sector. With a CBDC, the Central Bank can be sure that sovereign currency over existing mobile networks is within reach of everyone as a tool to increase financial inclusion. This presentation will provide the context for CBDC and how Mojaloop is a powerful enabler to interconnect a new CBDC issued by the Central Bank to the mobile operators and other payment systems.

Session Slides

Session Recording

Please post questions, suggestions and thoughts about this session in this thread.

Post by clicking the “Reply” button below.


from From Eric Meniere to All Panelists: 01:31 PM
How would a GSMT Token look like in a USSD transaction? How many digits will be required from a Customer perspective?

Answer from @DMangini

Hello Eric, There are different deployment models so it might look different in different systems. The USSD would provide the basic transaction info, Payer, Payee, Amount. CBDC platform takes this info and executes the transaction and provides the confirmation. If using a denominated system, the Platform will use the eNotes in the user’s wallet and provide the exact amount automatically to complete the transaction. User does not have to be involved.

CBDC is “quantum value” money. Each token is denominated in a specific and unchanging face value. Mobile Money is account based money and is “continuous value”. Each account can be denominated in any value.

The challenge is in how to transfer a part of the money in my “wallet” to someone else… $152 is held (for one example) as … (1) $100, (2) $20, (1) $10, and (2) $1. I want to buy a bag of groceries for $72. I can’t do that with the bills I have, someone has to make change. If I rely on the payee to do it, they likely won’t have enough of the right notes to do it either. (Picture the clerk holding your $100 bill aloft and calling out, “Can anyone break a hundred?!”)

In CBDC systems we’ve studied, all change making must be done by a financial institution. That is, I must direct my institution to produce notes to cover the payment I want to make, while replacing the notes in my wallet with a different set of notes representing my remaining balance.

But in this case, there is no end-user value of holding a tokenized money note. It is much simpler and much easier to implement account based money.

So it seems the way to allow central bank money to collateralize inter-institution settlement is of high value; but trading CBDC between end users just adds friction and has no direct benefit… my account is still backed by central bank money, if the 100% reserve requirement of mobile money is denominated in central bank money (by holding bonds, e.g.).

It think this is the central unanswered question of value for end users.

There is also another issue with the inefficiency of settlement using large “stacks” of eNotes. In Myanmar, e.g., inter-bank settlement is actually done using stacks of bills! US$200,000 in Myanmar kyat is a stack of bills several feet high! All of those eNotes would have to change possession to complete a single bilateral settlement (or one leg of multilateral settlement). This is hugely inefficient.

Compare that to multilateral net settlement in account based money (including central bank money)… one transfer for each active participant (either a single credit or single debit).

This is the essential challenge with using CBDC in wholesale settlement arrangements.

I would love to discuss these two challenges further.

Many thanks for your excellent presentation!


That was a really interesting presentation, thank you David. It’s wonderful to see such an important subject being socialised in this manner.

I have a number of questions, which I hope you will give some consideration:

  1. Do you envisage Mojaloop being involved in a transaction between two people, customers of different DFSPs? Or as the translator between CBDCs and traditional fiat currency?
    a. If the former, how do you envisage this fitting into the three discovery/quote/transfer phases of a Mojaloop transaction?
  2. What do you think is the key competitor to CBDCs in developing economies? Physical cash or mobile money?
  3. Won’t we need cash in/cash out agents to exchange CBDCs for physical cash, as for mobile money?
  4. Why did you decide to issue your e-note in fixed denominations? And doesn’t this just perpetuate the physical cash need to ‘make change’?
  5. How do you envisage a customer’s CBDC holding being secured, so that only they can spend it?
  6. In your opinion, is there a potential issue with performance when a blockchain-based CBDC is used for retail transactions – potentially reaching multiple thousands of transactions per second?

Thank you again David. This a subject of deep interest to me, so I hope you will excuse the questions.


Let me provide a better answer here for this question from the Chat.
There are different deployment models so it might look different in different systems. The USSD would provide the basic transaction info, Payer, Payee, Amount. CBDC platform takes this info and executes the transaction and provides the confirmation. If using a denominated system, the Platform will use the eNotes in the user’s wallet and provide the exact amount automatically to complete the transaction. User does not have to be involved.

A key point in this which I sis not have time to explain is that CBDC is flexible to separate the instructions for the transaction from the movement of the value. Since the CBDC does NOT have to be held within the user’s mobile phone (can be held in a wallet repository at the Operator), all we need the user device for is to provide the transaction instructions. This allows ANY device to be used and maximizes the adoption within the existing ecosystem. The user device provides the instructions which the CBDC platform executes immediately upon authentication. The CBDC value is immediately moved from Payer Wallet to Payee Wallet and the notifications/confirmations are sent for immediate finality without further settlement.

Mobile devices in the industry today (even high-end phones) do not have adequate hardware/software security to trust that the CBDC tokens can be stored locally within the phone. That would also limit the scope of adoption that is possible since it would require having a phone of certain minimum capabilities. Of course, the obvious tradeoff here is that you cannot use CBDC off-line in this type of scheme that I have described.

Some Retail CBDC systems are blockchain based and some are not (like GSMT). So the exact mechanics of the value exchange would operate differently behind the scenes.

1 Like

Hello Miller, @millerabel

These are excellent points which we have focused on in great detail. Your instincts about discrete-denominated CBDC compared with continuous-value money (mobile, bank) are correct. The specific model of Retail CBDC that GSMT uses is discrete-denominated which means we had to solve the exact issue of providing change that you describe.
GSMT provides an “Autochange” function in which the wallet/distribution platform provides the exact-change needed to complete transactions. As transactions are initiated, the Operator Platform (GEM) makes the exchange of eNote denominations using the inventory of eNotes from the Operator’s Digital Safe in-flow. The result is that the merchant Payee always receives the exact amount in their wallet and the Payer receives the change eNotes back to their wallet.

I understand your point about no perceived value for the user in this mode. What not just use an account-based system. That is certainly an option depending on which set of objectives the solution is designed to achieve. Our approach to providing a Retail CBDC solution for central banks is to meet the needs of the central bank. In the hierarchy of needs and requirements, the needs of the central bank are a higher priority than the desires of the user. CBDC is a central bank initiative first and foremost. There are certain aspects of CBDC that favor value to the central bank and other aspects that favor value to the user. Central Bank requirements dominate but it is a balance since you need to meet user needs in order to support broad adoption.

In this context, the user needs for broad adoption is addressed by separating the transaction instructions from the transfer of value. The eNotes are not held within the user device (see other explanation above) and so we only need the user to provide their instructions. This opens the ecosystem to support CBDC payments without any limiting requirements for the user device, etc. Yes, in some ways, denominated CBDC is less efficient from he user’s view, but that does not interfere with their broad access to it. The higher inefficiency is addressed with proprietary optimization algorithms and some extra server horsepower where it can be scaled within the platform.

From the view of the central bank, having a denominated-token form of CBDC has several advantages. Our key requirement is to provide a solution within existing central bank operations with the least amount of policy and operational disruption. So certain choices are made to blend more seamlessly with the processes, policies, and controls that already exist within central banks to administer monetary policy, balance M0 money base and adjust currency supply to demand. Treat digital as close as possible to the physical banknote processes.

Let’s talk further. This is a fascinating topic.

1 Like

Thank you David, so from a feature phone user perspective it will be a familiar experience.

Similar to Paul Makin, I am curious to learn why fixed denominations for e-Notes? At least for settlement purposes e-Notes could be generated on the fly, with the transaction amount wrapped in the encrypted message together with the author’s e-signature, like single use digital tokens.

Hello Paul @PaulMakin

Great questions. Let me give a response here and I’m happy to discuss further.

  1. Mojaloop can provide the interoperability between any set of users not directly sharing the same platform. From my view, yes, it can link 2 users of CBDC who are each customers of different Operators (perhaps a bank, or an MNO, or payment provider). If both users want to transact in Retail CBDC, there is no exchange of currency types needed. If identified when the transaction is initiated that both parties want a CBDC exchange, then the Mojaloop Hub can help to facilitate the communication of the transaction instructions but the “Settlement” steps can be omitted.

Discovery plays a role to determine where to find the Payer and Payee. There may be numerous aliases for users in Mobile systems as well as across CBDC Operators. I think there may still be value in providing the “Quote” function but I have not thought that through all the way yet. Some Operators may use business models that will require a quote for some fees to be made transparent. So, Mojaloop is a great match.

  1. In developing countries CBDC is seen as a social good, offered in parallel with cash and not intended to replace mobile money. It is an alternative that is offered so that a greater segment of the population has something available to them. Cash is an obstacle in many villages and mobile money may be vulnerable to mis-management (extreme cases). The government would prefer that they have control over a payment means where they can issue direct benefit payments to the population (CBDC is their preferred tool for this).

  2. Yes! Agents are still valuable to provide cash-in and cash-out. Same function as the M-Pesa agents today. However, there should be less need for the cash-out once CBDC becomes common for merchants and shops to adopt. CBDC is cash, universally accepted and has legal acceptance so there should be broader use inherently and this reduces the cash-out which lessens the liquidity requirements for the Agents.

  3. Denominated CBDC is a choice for central banks that want a model that is the least disruptive to the policies, operations, and regulations that are already in place. Also, in some countries, it is a way to present a currency that is more visually familiar to the population which might help with acceptance and adoption. I have a further explanation of the dynamics of denominated-CBDC in my other answer in this discourse.

  4. The user’s CBDC is secured within individual User Wallets as a bearer instrument. If the CBDC token is stored in your wallet then you own it. The wallets in the GSMT system are secured within the Operator platform (centrally) given that the mobile industry does not yet offer secure capabilities within mobile phones to trust the phone to hold the money. I also said more about this in the other response. Centrally located wallets can be provided more comprehensive security than distributed security.

  5. Yes, I think there is a risk for blockchain-based CBDC to require long latency times to complete transactions depending on the consensus method chosen and the number of nodes involved in the transaction. Many DLT platforms will minimize latency by centralizing the authorization of transactions to a central “Notary” function. In the GSMT system, the validity checks on eNote integrity and user identity are centralized to speed things up. Also, optimization algorithms are used along with parallel processing and server horsepower to achieve transaction capacity.

The targets for transaction through-put are very high. Visa network already operates at multiple thousands of transactions per second. The US Federal Reserve has a target to try to reach 10,000 tps. This may require some further technology maturity.

Happy to discuss all of this further.

The use of fixed denominations is somewhat sub-optimal. It has a long history: DigiCash in the 1990s used ‘coins’, fixed value tokens that were exchanged between purses. You had to assemble the right value in coins in your purse before completing a transaction - if you needed to ‘break’ a coin, you had to submit it to a central institution, which would return you multiple lower value coins. It was a little painful.

Back in 2009, I led a project for the BMGF looking at physical smart banknotes - essentially a physical note (paper, foldable)that could be used in face to face or (with a mobile phone) for remote transactions. We rejected the idea of a fixed value as simply following the outmoded conventions of an old tech (cash), which was restrained by the tech available. So our smart banknotes had a display that showed the current value held. Spending involved touching your banknote to the vendor’s mobile phone. The idea died because we couldn’t get the tech to survive being crushed in someone’s pocket: folded, yes, crushed, no.

So I’m not convinced we need a fixed value!

Hi Eric @emeniere
Actually, it is not legal to generate eNotes on the fly outside of the central bank, although it may be technically possible. The central bank is the exclusive issuer of currency and the Operating institutions that support the distribution of the currency are NOT authorized to generate sovereign currency in most countries. Legally, that is treated as counterfeiting in many places. There is a notion of “delegated issuance” where the central bank will authorize currency from others, but this is legally unclear in many places.

I have explained that in our system of denominated CBDC, the exact change needed to mediate transactions are handled automatically within the Operator platform in-flow with the transaction execution. The inventory of eNotes in the Operator’s Digital Safe is used to provide the exact change. The Payee receives exactly the amount of eNotes due them and the Payer receives the change back into their wallet.

The goal with CBDC is to prioritize the needs of the central banks. They need to offer a currency that is familiar to the entire population, is accessible and conforms to the processes and policies in place. Our goal is to provide a solution that presents the least amount of disruption to the central bank as possible. A denominated currency has the option to be displayed visually on devices so that everyone in the population can see the money in their wallets in a familiar way; this is just an option but not required. More important is to match to the way central banks administer the M0 money supply throughout the life cycle of the physical currency. Issuance, circulation, matching supply with demand, etc.


David, aren’t you simply identifying a limitation of the chosen implementation, rather than of the concept of CBDCs per se? If instead of a token-based approach a value-based or wallet-based approach was adopted, wouldn’t many of these issues go away?

Thank you David.

Have you considered how a customer would spend their value? How do I stop someone else spending it? How is the user’s claim on the CBDC value authenticated?

Paul, @PaulMakin
Yes, These comments are more focused on the particular implementation of Retail CBDC that Giori Digital has focused on in this initial version of GSMT. The next version of GSMT will incorporate DLT in the architecture in a more similar token-transaction model as blockchain.

But, the fundamental CBDC concept is much more broad and accommodates many implementations. The core philosophy to approach the market, however, is that the needs of the central bank prevail, even in the circumstances where they are not exactly aligned to the preferences of users. Users may prefer anonymity, for example, but that is not in the interest of the government. It is a balance.

Interesting to look at the hybrid paper-digital banknotes. I have seen more than 1 scheme for using banknotes with digital information embedded. Some are chip based and some are not. For several key reasons, I personally do not think the banknote printing industry is expecting to move in this direction. There are some solutions that can work technically but not from a market view.

Hi Paul @PaulMakin
There is a major focus on securing access to the User Wallet. The eNotes are secured in the wallet, or the CBDC is associated with a wallet in a value-based system. Similar in purpose to having a wallet that holds the private keys to a crypto wallet. The goal is to ensure that only the wallet owner can access the wallet. So there is a priority to validate the integrity of the value tokens (eNotes) as well as to validate the Wallet Owner. Traditional or encrypted means to secure the wallet are appropriate.

Thank you for all of your replies @DMangini

This is when I wish this meeting was face to face! It would be so useful to be able to talk through the issues around a whiteboard.

Nonetheless, I’m really very interested in continuing this discussion between us, and maybe we could find a way towards the development of a proof of concept, integrating Mojaloop with a notional CBDC. I think that would be extremely valuable to the community.

Here’s hoping,

Thank you David, yes, I’d welcome the chance to discuss further.

As you may have noticed, Mojaloop is built on the principle of separating the transaction logic and details from the simple transfer of value. So it is natural and obvious for us to think of how we might map Mojaloop onto an environment that settles using CBDC while transacting in eMoney (e.g.).

That is, account-based value, denominated in commercial eMoney, but backed by 100% reserve in CBDC, is traded by end users through wallet platforms, and cleared by Mojaloop against the trust reserve and net settled, intra-day, or settled continuously throughout the day in gross.

Studying the cash-in and cash-out functions, and their effects on the trust reserve, is key to understanding this mapping, I think.

We might also contrast forms of claims on central bank money that exist today in digital form with CBDC, to better understand the value proposition. E.g. buying and selling treasury notes (interchanging commercial and central bank money) and the relative efficiency of these transactions compared to CBDC transactions.

Thanks for the very engaging presentation. I’d welcome further discussion!

Hi Paul, Thanks for sharing your experience.
In 2009, I launched a pilot with MetroPCS (US Wireless MNO), The Bancorp bank (settlement BIN), MasterCard (card payment rails/network) and MoneyGram (100,000 POS for cash-in/out). Every metroPCS Android phone was issued with a pre-loaded payment app (Neobank model) that allowed registered users to generate thousands of single use card numbers of any user defined value (tokens). The app UI prompted the user to type a transaction amount and a PIN (signing the transaction). In return the app computed (off-line) a card number acceptable by any Mastercard merchant accepting device worldwide (POS/ePOS/mPOS). The transaction amount was effectively used as a first encryption/decryption key for the token card (i.e. a shared secret between a payee and a payer), which was passed on by the merchant Acquirer to the Issuer (The Bancorp bank) together with the card number, as for every card transaction. Only the Issuer was equipped with our proprietary decryption capability to authorise / decline the transactions. This was even better a solution than 3D Secure or VBV, since the single card number could only have been issued by my device (secure key in SE) with my consent (PIN = 2FA). The equivalent of an electronic check (I believe checks are still a payment instrument accepted by most financial institutions and maybe even central banks :slight_smile: