By Darren Parkin
The Bank of England has revealed the details of more than 70 questions asked by applicants keen to win the contract to create a wallet for its CBDC experiment.
A total of 20 companies submitted applications for the £200,000 five-month project, with almost all handing in a series of questions before Christmas.
The bank has now released those questions complete with answers that offer a remarkable – and occasionally confusing – insight into the Bank of England’s thinking on a central bank digital currency (CBDC).
The initial phase of shortlisting for the tender ends on Friday, with the contract being awarded to the successful applicant on January 31.
Despite the tight turnaround for the project, 28 applications were initially made, although eight didn’t pursue the bid beyond the question stage. The completed applications are made up of nine SMEs and 11 ‘large’ companies.
According to its website, the bank wants to to develop a mobile wallet app, merchant website and a back-end server for the core ledger.
It is understood the contract is purely to establish a prototype for user experience testing – something reflected in many of the answers to the questions.
“The Bank would like to take this opportunity to clarify that we have not committed to whether the Bank will build a sample wallet or not,” read one response.
“We’re using this PoC to deepen our knowledge and understanding of how CBDC products could possibly interact with each other.”
While largely scoffed at by the cryptocurrency industry, there are plenty of backers for the concept of a UK CBDC.
One of its supporters – Gilbert Verdian, founder and CEO of Quant – believes a well-designed CBDC could help provide a real-time view of risks and currency outflows to help implement specific and targeted measures to prevent financial contagions from spreading further in the event of a crisis.
“A digital pound enables consumers and businesses to automate complex and cumbersome processes and implement logic into money,” he explained.
“It offers new efficiencies and faster workflows to better meet our needs as our living experience becomes increasingly digital.
“Many critics cite privacy and potentially overbearing government controls as barriers to implementation. They are missing that blockchain technology makes it possible to protect the privacy of individuals.”
He added that many countries were taking very considered approaches to adoption.
“Pilots involve extensive public and regulatory consultation, with business and institutional involvement, to ensure that CBDCs meet our democratic needs,” he said.
“Meanwhile, with Project Rosalind, the BIS Innovation Hub London and the Bank of England are looking to the future – testing how to issue, embed and settle CBDCs for retail payments use cases with industry participants.
“The project includes the private sector in an effort to innovate different payment use cases and applications that use retail CBDCs for a better experience.”
Questions asked by suppliers
1. With respect the question “Create the deliverables for this contract under Specially Written Software/New IPR as defined in Framework Schedule 6, Call-Off Schedule 6 (1%)”
For the avoidance of doubt, can you please provide a link to the framework schedules you are referring to?
All legal documents are published here: https://www.gov.uk/guidance/digital-outcomes-and-specialists-5-legal-documents. Please familiarise yourself with the legal documents. Especially the Core Terms, Joint Schedules, and Call-Off Schedules.
2. With respect your question “Create the deliverables for this contract under Specially Written Software/New IPR as defined in Framework Schedule 6, Call-Off Schedule 6 (1%)”
We assume that you require answers that are a simple “yes” to confirm compliance? Will suppliers who respond with short answers confirming compliance, be penalised (on the basis you are looking for a different type of answer)?
All deliverables must fall under ‘Specially Written Software’ or ‘New IPR’ as defined within the DOS5 Framework Terms and Conditions, so the Supplier must confirm they are happy to proceed on this basis. Suppliers will not be penalised for brevity however there must be no ambiguity.
3. Will Bank of England be open to receiving responses from suppliers, who use specialist partners, if it can be demonstrated that this will deliver a superior outcome for Bank of England?
Yes.
4. Please could you indicate the dates of the subsequent procurement stages?
Indicative timeline: Shortlisting/Part 1 Finished: 6th January 2023ITT Document released: 11th January 2023Presentations: 23/24/25th January 2023Award: 31st January
5. Please could you indicate the roles who would be on the evaluation panel?
The evaluators will be drawn from the CBDC Team, with a mix of technical and policy expertise.
6. Is there an incumbent supplier providing this / similar services in the Department?
No.
7. To what extent will the Authority provide staff to work with us on this project?
Please see the Existing Team section of the advert.
8. Can the Authority provide further information on the technology stack or technology preferences?
There is a preference for re-use cross platforms frameworks, e.g. Flutter, but this is not mandatory. For the frontend development there is a preference for a well-understood framework such as Angular or React. The backend / web server should also be in a common framework, C#, java, NodeJS.
9. Are there any specific knowledge transfer / capability uplift requirements that we can factor in to our plans?
Not as this time, however we expect some knowledge exchange with the successful supplier.
10. Is there a preferred Agile methodology you would like our team to use?
No.
11. What roles would you expect the supplier to deliver?
This is a delivery-driven project and the Bank is comfortable allowing potential suppliers to design their own bid. However, at a minimum the Bank would expect your bid to include software developers/architects and PMO staff. Dual roles are acceptable, however one person may only be billed for one day at a time.
12. In regards to questions 9: Is this being set up from scratch, or are you planning on using a partner e.g., Stripe/WeVe?
From scratch.
13. Why the work is being done. Bullet one seems to contradict the last bullet of key technical deliverables – please can you clarify.
The Bank would like to take this opportunity to clarify that we have not committed to whether the Bank will build a sample wallet or not. We’re using this PoC to deepen our knowledge and understanding of how CBDC products could possibly interact with each other.
14. Any additional info. to share related to more specs of what the ‘Digital Currency’ is or consists of? BOE products, actual currency, or something else?
This information is publicly available on the Bank of England website.
15. Is it possible to get a sense of the early market engagement results—as a summary specifically related to the wallet work?
The early market engagement consisted of a very high-level overview of what we were considering and was specifically concerning this sample wallet. We tested our assumptions around the project timelines and resource requirements.
16. What is BOE’s current infrastructure?
This information will be disclosed to the successful supplier. Everything needed to bid for the first stage of this tender has been disclosed.
17. To accelerate the PoC will all the data come from the core ledger API and store user data and transaction history, or do you expect the PoC to be mocked in some places? The scope for a PoC seems large if it isn’t mocked.
Not all data will come from the core ledger. User data and transaction history will need to be maintained in the backend of the solution. For clarity, no real user data will be used or stored.
18. Do you have a preference as to whether the Apps should be native, native cross-platform or hybrid cross-platforms?
There is a preference for cross-platforms apps where possible.
19. Do you have a preference on the UI framework used for the websites? (React Vs Angular)
No.
20. How much emphasis should be put on UI/UX during the PoC phase?
The Bank expects the frontend to be engaging and professional.
21. Is building a DevOps pipeline in scope for web and app?
We expect the project to be delivered using best software practices.
22. Can we use SaaS solutions to accelerate development or should all the technology components be deployed within the BoE?
A SaaS solution is unlikely to be appropriate for this contract as all deliverables must fall under ‘Specially Written Software’ or ‘New IPR’ as defined within the DOS5 Framework Terms and Conditions, so the Supplier must confirm they are happy to proceed on this basis.
23. Are there any specific security requirements for the Apps?
Biometrics, FIDO, MFA etc?No. However, authentication is an area of interest that will be explored during the user flows.
24. Are there any payment providers this solution needs to interact with during Alpha phase?
No.
25. Is this a mini MVP or a proof of concept what will be abandoned before the main solution build?
The solution should be re-usable for future experimentation, but at this point there is no expectation to go into production.
26. As part of the Wallet Management solution is the Bank of England expecting / requiring the wallet solution to be responsible for the storage of private keys (custodial wallet)
Are we right in assuming that we can simulate the functionalities and the storage of the custody solution such as the generation of private keys etc in the PoC or will this be supported completely by BIS Project Rosalind?
Not for the core ledger, however there may be for user authentication.
27. If available, would the BoE share the high-level conceptual architecture diagram of the CBDC platform mentioned in the ITT showing the other components other than the wallet itself?
The conceptual CBDC platform model has been released in previous Bank communications (https://www.bankofengland.co.uk/paper/2020/central-bank-digital-currency-opportunities-challenges-and-design-discussion-paper). For the scope of this POC the only relevant component is the API layer that will be provided by Project Rosalind.
28. The Bank mentions the following – ‘Payments can be done via account ID or QR code’. For QR code initiated payments, does the Bank expect both Payer and Payee initiated user journeys ? There can also be other user journeys E.G. online payment journeys via mobile or desktop. What are the user journeys that the bank is looking to support as part of the scope of this work?
For the scope of this POC we are considering Request for Payment initiated via QR code, but we are open to exploring other user journeys that can add value and could have a potential impact on the Rosalind API functionality. Online payment journeys are considered within the mobile and web app for the scope of this prototype.
29. What are the preferences/restriction for the technical stack for web application development?
For the frontend development there is a preference for a well-understood framework such as Angular or React.
30. In the context of Wallet Management, the following is mentioned ‘Sign up process (will not do KYC) including tiering and wallet type’. Can the bank clarify what it means by tiering in this context?Tiering referrers to different kind of wallets in the context of having different functionalities. For example, the POC might consider individual/business wallets.
31. With regard to the native OS systems iOS and Android, which devices (hardware) (mobile phones, tablets) should be supported in the PoC phase?
Specific devices will be agreed during Project Kick-Off.
32. Are APIs for integration already existing, or is their development also part of the scope?
It is part of the POC to develop a robust backend that integrates with the APIs available through the Project Rosalind.
33. Is the supplier expected to build alpha native apps which meet the requirements (wallet creation, wallet management, live payments) plus a website, merchant website and website backend? The title “Proof of Concept” would allude to these services not needing to be live but demonstrating viability.
Can you please expand on the detail, functionality and interconnectivity of the deliverables?
The detail will be expanded during the ITT phase of this tender. This tender is for a Proof of Concept and is purely to demonstrate viability and increase the depth of our understanding.
34. Will the mobile app support phones only or it will support tabs / iPads?At the moment, we consider mobile phones as the main device to test the POC.
35. Is there a requirement to host in App store?
No.
36. If APIs are ready for integration which interfaces are they supported? For example, REST API.
The Rosalind API is based on REST API standards.
37. Should multiple login session allowed for single user? (one mobile wallet instance & one web wallet instance at the same time)
More detail will be available after the shortlisting section of this tender.
38. Can wallet type configuration be changed later or fixed? (user can update to business or vice versa)
For simplicity, for this POC wallet types can not be changed. If a user needs a new wallet type, a new wallet can be created.
39. Who will be responsible for hosting? The cloud-based or on-premise solution is preferable?
We are expecting the selected vendor to host the development and test environment throughout the prototype. Through this period, we leave it up to the vendor to chose the most convenient hosting option for them. Once the project is finished, the listed deliverables will be deployed to Bank managed infrastructure.
40. What does “View Existing locks” mean under wallet management?
Locked payments are when the payee and payer agree that a payment only occurs based on a condition. This shows how many funds are currently conditionally locked by the user.
41. Under Payments we have a line item that says “Load and Unload CBDC wallet with commercial bank money” – does this mean the user has to first link their bank account to the wallet? However in the wallet management it is mentioned that user will not do KYC. Isn’t this a contradiction? OR only the KYC process is out-of-scope?
The KYC process is out of scope. Interoperability with other types of money and other accounts is also out of scope, therefore loading and unloading CBDC funds will be simulated via the API.
42. Is the eGBP designed to be in fixed denominations (£5,10,20,50) for users to interact in their wallet or should it be starting with lowest value (£1)
For the purposes of the POC, assume no fixed denominations.
43. Display notifications – Is it fair to assume that only in-app notifications will be considered as in-scope for this proposal?
No specific requirements – vendors to judge this as part of their proposal.
44. Are there constraints around tech stack that need to be used?
For the frontend development there is a preference for a well-understood framework such as Angular or React. The backend / web server should also be in a common framework, C#, java or NodeJS
45. Export transaction history – Is there any specific format (xlsx, pdf, csv) or approach (file download vs. email to registered email id)?
No specific requirements – vendors to judge this as part of their proposal.
46. Do we need feature parity between the web application and mobile app, or are there any feature that are specific to web / mobile?
Assume broad feature parity, yes.
47. “Ringfencing of funds for budgeting” – Please explain this feature? Is this like create different buckets/pots so that user can allocate certain amounts to each pots? And if a grocery pot were to be created, it can make payments only to grocery merchants. Is this the expected functionality?
This refers to the ability to label and separate funds for different purposes within one wallet.
48. Is there a preference on the mobile tech stack, i.e., Native platforms(Android, iOS) vs Cross platform tech choices(React Native, Flutter, etc.)
There is a preference for cross-platform apps where possible.
49. Offline payments are out of scope of this proposal – Is that a correct assumption?
Yes.
50. The document states – ‘…I need the Sample Wallet solution integrated into the eventual CBDC payments API” – what is the current state of this payments API?
The Rosalind API is the relevant API for the purposes of the POC, and details will be provided to the successful vendor.
51. Transaction history – Should we enable offline access for the recently fetched transaction history?
No specific requirements – vendors to judge this as part of their proposal.
52. Are there any specific functionalities / flows that you would like to be implemented as part of the merchant website POC.
Checkout flow at a minimum, that supports payment with both mobile apps and the browser based wallet.
53. How much data should we store in the intermediary data store while building the backend server as it’s better to have single source of truth?
At a minimum, we expect to be able to store user data and transaction history.
54. What is the data format and data contract for Ledger API, and approach to invoke these APIs – REST/HTTP, gRPC, etc.?
The core ledger API is a REST API. The API specification will be shared later on in the tender.
55. Do we need a provision for different date ranges for transaction history (1 month, 3 months)? Out of this how much should be async vs. sync – i.e., show the response to the user on screen vs. an email getting triggered once the report is ready.
No specific requirements – vendors to judge this as part of their proposal.
56. Do we need QR Code for P2B scenario as in case of P2P? We see QR code added to P2P, is our observation correct?
Yes we expect QR codes to feature in both P2P and P2B payments.
57. Two pre-market engagement events were held to sense-check high-level requirements and provide example budget ranges.
Who performed these engagement events?
Was this an external agency?
The Bank chaired these events.
58. The evaluation panel will be made up of which job roles please?
The evaluators will be drawn from the CBDC Team, with a mix of technical and policy expertise.
59. “Close wallet” is meant as closing the wallet view from the user interface or closing the wallet as closing the account and churning off from the service ?
Close wallet refers to closing the steps necessary to close the CBDC account.
60. In the wallet management section, one of the requirements is “View offline balance”. Can you please clarify this requirement given that offline payment was cited as out of scope in the earlier paragraph ?
Offline payments are out of scope, however we will require a UI placeholder for future use.
61. Offline is mentioned in the description. Can you confirm you’re expecting only to have offline balance on the interface, but no offline payment functionalities?
Offline payments are out of scope, however we are expecting to have an offline balance placeholder on the interface.
62. Can you please elaborate on what is expected on the “Wallet website” as features?
We expect the same features for the wallet website as we do for the mobile website.
63. On the timing, can you confirm the 5 months of the project are dedicated to build only ?
What are your expectations after this period ? Are you expecting support / run?
5 months for building and testing.
64. The description of your need is quite high level. How do you foresee the specification phase of the project? What will happen if we discover that what we have evaluated for the project regarding charges and perimeters is not in line with your expectations ?
This piece of work is experimental, and as such we don’t have detailed requirements. We expect to work with vendors who flexibly can adapt to the agreed high level scope.
65. It is not clear if among advance functionality we have only notifications about programmable conditional payment or the ability to add programmable conditional payments.
The wallet should be able to receive requests for conditional payments and prompt the user approve/deny those requests.
66. Freeze/Unfreeze is listed in both 1) Wallet management and 3) Advanced functionalities. What is the difference?
No difference, it’s the same functionality.
67. Under the “Essential” requirement: Create the deliverables for this contract under Specially Written Software/New IPR as defined in Framework Schedule 6, Call-Off Schedule 6. Please clarify if it is essential suppliers have done this, or it is essential that they can agree to it as part of the contract?
Essential they do this as part of this contract.
68. Will the presentation be on-site or virtual?
Virtual.
69. Can we assume that core ledger API provides service to fund the wallet by conversion from FIAT to CBDC?
Yes, you can assume that the API provides dummy functionality to enable this.
70. Should the presentation content be part of artefacts submitted with the RFP?
We would like a copy of the slides but only at the time of presentation; however you will be graded on the presentation you give virtually. The written proposal and the presentation are graded separately.
71. How do you intend to contract for this work?
We are using the Digital Outcomes and Specialists 5 framework to award this contract.
72. Can you clarify the relationship between the “Proposal Criteria” weightings (individual and total) and the weightings listed under “Evaluation”? We assume the total 80% for the former covers Technical Competence and Cultural Fit, with Price contributing the remaining 20%.
As per Evaluation weighting on the website (https://www.digitalmarketplace.service.gov.uk/digital-outcomes-and-specialists/opportunities/18948)
73. Is the core ledger API WEB3 compliant?
Web3 compliance is not relevant for the scope of this POC. Further details on the core API ledger will be given to suppliers brought forward to the next and final round.
The post Bank of England publishes list of questions asked by suitors for its CBDC wallet appeared first on CityAM.
