Glossary
PIP - Payment Interface Providers - payments
ESIP - External Service Interface Providers – non-payment value-add services
User - register with intermediaries to access CBDC
RTGS - Real-Time Gross Settlement - Existing infrastructure that holds accounts for banks, building societies and other institutions.
DLT - Distributed Ledger Technology – similar to blockchain functionality
PAN - Primary Account Number, with wallet IDs
Refs
- The digital pound https://www.bankofengland.co.uk/the-digital-pound (video – ha!)
- The digital pound: A new form of money for households and businesses? https://www.bankofengland.co.uk/paper/2023/the-digital-pound-consultation-paper
- The digital pound: Technology Working Paper https://www.bankofengland.co.uk/paper/2023/the-digital-pound-technology-working-paper (this)
Consultation
1 Do you agree that these six considerations are foundational technology considerations for CBDC? Are there additional or alternative technology considerations that the Bank should be focused on? Section 3
yes
2 Which privacy-enhancing technologies, or other privacy mechanisms, might support the proposed policy objectives, and how might they be used? Please see Section 3.1 of the Technology Working Paper.
It's ultimately impossible to say that privacy will be maintained as even one-way hashes can be defeated for the same reasons as other digital security techniques. I suspect the government will just require PIP/ESIPs to hand over information should they require it for any reason (eg to link someone's vaccine status, which it knows, with payment availability)
3 Are the provisional requirements and metrics discussed in the paper, particularly for uptime, transaction throughput and transaction speed, realistic and appropriate? Sections 3.3, 3.4
yes
4. Are there other significant components or activities that the Bank should consider in designing a CBDC? Section 4
It needs to ensure in law that it is never the only way to make any payment - even ones to the Government.
Likewise, Government funded social benefits and pensions should not require a BoE account to get access
5. Are there alternative models that might better address the technology considerations and technical requirements outlined in the Technology Working Paper? Section 4
The system is inevitably monolithic given the constraints on Distributed Ledger Technology. A constrained distributed system such as we already have in Banks & Building Societies (RTGS) is technically safer. It also helps ensure financial controls are not held by one entity which could be detrimental to citizens' freedom.
6. Other than those described in the Technology Working Paper, are there additional important factors to consider related to ledger design? Section 4.1
It should again be in law that BoE cannot choose not to pay (transfer funds to) entities it may not, for the moment, approve of (eg for their views on certain social issues). There will be payment controls eg for fraud, but these should be subject to judicial process.
7. What are the most appropriate approaches or technologies for collecting and analysing aggregate transaction data? Section 4.2
As stated in 4.2 this would be anonymous - but again that needs to be stated in law otherwise scope-creep is too tempting. By anonymous - not even the alias should be recorded in aggregates.
It needs to be stated what sort of data is being recorded in the system in total (as well as in aggregation) - is it just an alias, transaction ID and an amount, or a code representing the type and amount of the product or products themselves?
Recording product types must not happen as it leads to the possible imposition of quotas or bans on certain products for individuals. It would be easy to justify this eg for social security beneficiaries, and then all too easy to apply the technology to others when a change in government policy occurs.
8. Do you agree with the need for aliases (both well-known and disposable)? If so, should the alias service be hosted as part of the Bank-managed infrastructure, or should it be distributed across the CBDC ecosystem? Section 4.3
You have to reliably link to an individual account at some point, so this is a moot point in the end.
As mentioned in q5 it is better not to have a centralised system at all.
9. What features would a CBDC API require to enable innovative use cases? Section 4.4
The API needs to be very tight for all the privacy, security and performance reasons you cover. Also, as you mention, any changes must be strictly managed (as you're aware of change-control issues & costs). Innovation - eg in wallet function should be restricted to that layer.
10. Do you agree with the suggested list of devices for making payments with CBDC? Section 4.5
OK - but why do you need to specify this as you are just looking after the ledger and the PIPs manage the UI?
11. How viable is it to enable interoperability between CBDC and other forms of money using existing payments infrastructure? Section4.6
Ordinary B2B (gross) transactions should be routine, eg to pay off a credit-card bill. There should be no need to link a credit-card directly to a BoE one.
12. Is programmability and smart contract functionality an important feature of a CBDC system? If so, what is the best approach to enabling such functionality? Section 4.7
As in q7 any 'programmability' must not limit someone's ability to purchase anything, as we see in autocratic regimes, and which you seem to recognise is a potential problem. The basic premise must always be that the money belongs to the citizen, being held in trust by the bank, not the property of the bank being issued by the bank when it deems it appropriate.
Smart contract functionality should be managed by PIPs.
13. How important is offline functionality in a CBDC system? What are the most effective ways to implement offline capability? Section 4.8
This is a feature of any clearing system where settlement is not instantaneous, and so existing notions of appropriate risk can be employed (eg limits on a credit-card).
The best form is to preserve bank-notes.
Do you have any other observations, feedback or challenge related to the Technology Working Paper?
Overall I can't see in this WP or other of your literature any benefits to the citizen of implementing this system.
It will not provide any facilities that are not already present and will take a huge budget to implement.
It does seem like a desire to build something which other countries are doing - where their motives might be very different. They may need additional financial facilities, or more likely, want to control people in ever more intrusive ways.
Your best aim is to facilitate sound financial policies. Currently the 'trust' you want to engender for CBDCs is not even present in handling the nation's finances on the macro level.
Any CBDC should not undercut other payment options otherwise it will end up as the monopoly provider (ie a 2-4% transaction fee needs to be added). In any case this fee should cover the cost of the system – not the taxpayer
