CBDCs – the Holding Limit Trilemma

Anyone who has thought anyway seriously about Central Bank Digital Currencies (CBDCs) will quickly realise the importance of the ‘Holding Limit’ problem and the difficulty of solving it!

What is the Holding Limit problem?

The Holding Limit (HL) problem arises from the fact that, unless central banks wish to completely go it alone as regards the issuance of a CBDC [which they quickly find is infeasible], they have to reach some sort of working accommodation with the commercial banks in their jurisdiction as to shared operations.

In particular, there is the ‘bank run’ problem!

A CBDC is designed to provide ‘secure’ money for citizens (though the safety is often illusory, see below on bank guarantees) such that citizens will not, in a panic, take money from their usual bank accounts and move it into their ‘CBDC’ accounts, which they will have the right to do! Thus precipitating a ‘bank run’ and a knock-on failure of some commercial banks.

One of the most obvious ways to solve this problem is to set a limit as to the amount of CBDC that a citizen may hold – the holding limit - thus, theoretically at least, limiting the damage that a bank run may cause.

So far so good!

But what happens when a citizen, accidentally or deliberately, exceeds the holding limit of the CBDC?

Soft or Hard holding limits?

There are at least two ways of ‘enforcing’ holding limit excesses: soft limits, which entails merely stating that any amount over the holding limit will be considered not to be covered by the CBDC security promise (effectively ignoring the excess); or hard limits, actually doing something about the excess.

Obviously, soft limits are the easiest to police, provided that the is no strong belief that any and every excess will be honoured by the central bank, in the event of a crisis.

Hard limits imply taking some form of action is taken when a limit is exceeded.

One form of hard action is to charge citizens a ‘negative interest rate’ on any excess, making it costly to maintain an excess. Obviously, commonsense would indicate that such penalties would be levied only if the excess was long and persistent and not a result of say a temporary movement of funds, such as a large receipt or payment.

A more draconian but, nonetheless practical, action would be to ‘sweep’ the excess out of CBDC into a pre-specified commercial bank money account. The question then becomes – when is the money to be swept between accounts: immediately; or on a delayed basis, such as at the end of a business day?

And it turns out that the decision on how to handle ‘hard’ holding limit excesses has a significant effect on the operations of a CBDC.

Holding Limit – Some Perspective

Before considering the implications of immediate resolution of holding limit excesses, it is worth getting some perspective on what a holding limit is and what is its exact purpose.

A holding limit is a (somewhat) arbitrary number that is designed to represent the maximum amount that a ‘holder’ of CBDC may hold, in order to be eligible for a guaranteed reimbursement of their holding from the issuing central bank in the event of an economic disruption, where access to the CBDC held is rendered unavailable. Note it is NOT the amount that would be reimbursed but the reimbursed amount would be CBDC that was actually held at the time the disruption was officially acknowledged. A close analogy is the amount of money held in a customer’s bank account when a bank is declared insolvent, where a government/insurance guarantee may be triggered.

The CBDC holding limit then is a number that will ONLY be used in the rare instance of a failure of one or more financial institutions in a jurisdiction – it is certainly not something that should, in any way, be related to individual banking transactions in normal circumstances.

The holding limit concept is even less likely to be relevant when one considers that it is replicating the concept of ‘deposit insurance’, such as, for example: in the European Union where €100,000 of deposits is guaranteed in the event of a failure; or in the UK where ￡85,000 per ‘eligible person, per bank, building society or credit union’ is guaranteed; or in the USA where $250,000 ‘per depositor, per FDIC-insured bank, per ownership category’ is guaranteed.

In effect, this means that if funds are, for example, transferred from a guaranteed bank account in the European Union to a CBDC account where the envisaged holding limit is only €3,000 (as opposed to €100,000), then, in practice, a CBDC will be much less safe than a commercial bank account!

Hardly the declared objective of a CBDC?

But let’s stay with the fact that the holding limit is merely an arbitrary backstop that hopefully will never be used. And also remember that any holding limit must be designed to be flexible allowing the central bank to change the number up and down when and as needed (with an immediate impact on all holding limits).

Surely, as a mere backstop, ?the concept of CBDC holding limits could ?have little impact on overall CBDC systems design? Unfortunately not - at least as the case of the ECB' digital-Euro demonstrates!

CBDC Trilemma

A trilemma, such as that shown in the diagram, is a technique often used in economics and IT to illustrate trade-offs between design choices. In particular, showing how, with three exclusive and conflicting alternatives, it is often not possible to completely achieve all three desirable objectives, at the same time.

It should be noted that in all IT system designs, there are many more than three so-called nonfunctional requirements (NFRs) to be considered and when designing a system it is the ranking of the universe of these NFRs that will ultimately govern the success, or otherwise, of the chosen design.

Relative ranking of alternative design options is a form of multi-criteria decision making (MCDM) and in the diagram above the icosahedron (top right) shows different alternatives, often referred to as ‘ilities’, in multiple triangles. Done exhaustively, by comparing NFRs in different combinations should arrive at the relative desirability of various design choices, and hence should drive the resulting systems ‘architecture’.

The diagram above shows just one trilemma among many, illustrating the difficulty of reconciling three objectives, using the example of some of the design choices made by the European Central Bank (ECB) to implement the digital-Euro [1].

As the digital-Euro must be able to handle the payment needs of the population of the European Union (some 480 million citizens and some 31 million businesses) now and into the future, then ‘scalability’ will be a very, very desirable design objective. Furthermore, as the digital-Euro must be able to interact seamlessly with an enormous banking system (some 5,000 very different banks and 340,000 ATMs), then ‘interoperability’ (or the ability in interact with various components in a flexible manner) will also be an extremely desirable objective.

In fact, given the sheer size and impact of the digital-Euro project, scalability and interoperability would normally be considered essential objectives with, maybe, scalability being considered slightly more important.

The third objective 'Immediacy of resolution of holding limit excess’ refers to the ‘hard’ and ‘immediate’ sweep of excess funds described above and would appear on the face of it to be a minor matter compared to either scalability or interoperability.

But the devil really is in the detail!

Waterfalls

For the digital-Euro, the ECB is developing a so-called ‘waterfall’ process, which is a hard, sweep of excess funds from a CBDC account to a commercial bank account, immediately whenever a holding limit is exceeded.

For example, assume a citizen receives a payment that results in the CBDC balance exceeding the holding limit, of say €3,000, then the difference between the ending balance and the limit will immediately be transferred to the citizen’s bank account.

Sounds useful? Maybe or Maybe not?

Let us assume that a citizen elects to have their salary paid into their CBDC account. The average salary in EU[i] is some €26,136 per year or €2,178 per month which, if the existing balance is greater than €822, will result in an instant sweep payment of some variable amount from one account to another. However this is the average salary across Europe and the numbers are much larger in countries such as Germany, France, Italy and Spain, and so for those salaries each receipt will be accompanied by an instant automatic sweep of a pretty random amount of money from one account to another.

But that is small beer compared to dealing with the firms that receive most money in an economy – merchants! With millions of customers, merchants are on the receiving end of receipts in most economies.? However, the ECB have determined that the holding limit for merchants will be €0.00 (i.e., no effective HL) so all receipts of digital-Euro, e.g., for a cup of coffee or a newspaper, will be followed immediately with an outgoing payment , i.e. two movements for each consumer-related payment.

This choice effectively nearly doubles the number of transactions in the retail payment system – for NO discernible benefit. The design choice of a ‘waterfall’ therefore reduces the scalability of the overall system by (nearly) doubling the amount of work needed to complete real business transactions

But it is worse than that!

The ECB has also decided to implement what is called a ‘reverse waterfall’ which is planned to work as follows. When a citizen makes a request to make a payment from their CBDC account, the EU system will check if there are sufficient funds to make the payment, but, if not, will make a request to the related commercial bank account to transfer money into the CBDC account. That is two transactions will be needed to make a single payment, thus again reducing the scalability of the overall system.

Now one could argue that a reverse waterfall will only happen rarely, when the CBDC balance is overdrawn, but the opposite is more likely to be true! If a system will make a payment from the CBDC account by automatically sweeping from the citizen’s bank account, there is absolutely no benefit for citizens in pre-funding their CBDC account, especially if the sweep is automatic and cost-less.

So the most likely scenario is that citizens will prefer to use the liquidity benefits of the commercial bank account and when paying by CBDC, let the system take care of any interim payment.

In effect, this will mean three transactions for a CBDC payment to a merchant: (1) the reverse waterfall sweep from the citizen’s bank account to the CBDC account; (2) payment from the citizen’s CBDC to the merchant’s CBDC account; and 3) automatic sweep from the merchant’s CBDC account to the merchant’s commercial bank account.

THREE transactions instead of ONE!

So, even if some CBDC accounts are fully pre-funded by citizens, the ratio of transactions to real payments is likely to be >2:1 with a significant impact on the scalability of the system.

But what of Interoperability?

The impact of the ‘waterfall’ and ‘reverse waterfall’ concepts on existing commercial banking system is likely to be very significant.

Why?

In short, ALL payments related systems in ALL EU commercial banks will need to move towards real-time, 24/7 operations for the waterfall, and especially reverse waterfall, to work as envisaged by the ECB.

This, non-trivial exercise, is often called a core-systems replacement (CSR) and will be required for every system in the EU as the stated goal of the digital-Euro is to be EU-wide.

This need to go to real-time before the digital-Euro system will work as designed, greatly complicates the problems of Interoperability across the system, given the need to coordinate so many different system changes at the same time.

Conclusion

The somewhat arbitrary decision of the ECB to demand hard, immediate resolution of holding limit excesses when implementing the digital-Euro will diminish, probably significantly, both scalability and interoperability of the proposed system.

The designers of the digital-Euro have chosen to resolve the Holding Limit trilemma by sacrificing two essential systems requirements – scalability and interoperability - on the purely ideological altar of a rarely used stopgap measure – holding limits!

Given that much simpler alternatives are available, for example, by legislation, the design should be changed to promote scalability and interoperability.

?

References

[1] European Central Bank. 2023. “A Stocktake on the Digital Euro - Summary Report on the Investigation Phase and Outlook on the next Phase.” Ecb.Europa.Eu. Retrieved (https://www.ecb.europa.eu/paym/digital_euro/investigation/governance/shared/files/ecb.degov230116_eurogroupstocktake.en.pdf).

[2] European Central Bank. 2021. “Eurosystem Report on the Public Consultation on a Digital Euro.” Ecb.Europa.Eu. Retrieved (https://www.ecb.europa.eu/pub/pdf/other/Eurosystem_report_on_the_public_consultation_on_a_digital_eur

[i] See Statista