Prototype for building and testing Interoperability with Digital Pound and existing and future Payment Systems

Tender description

Which phase the project is in Alpha Existing team The project team from Bank will be comprised of a Solution Architect, a Functional Manager and a Project analyst. The Bank engineering team will provide the API to simulate platform core ledger. Supplier's team should provide the resources to develop and deploy the interoperability prototype in a Bank's experiment cloud environment which is separate to the Bank's core infrastructure. Regular workshops and design discussions will be expected through the length of the project to manage and stay in the right direction. Address where the work will be done Remotely from within the UK. Working arrangements The supplier will work from their offices (within the UK) but during same hours as Bank of England team to maximise knowledge transfer and integrate with team development processes: Monday to Friday, starting work by 9.30am, 7 hours per day + lunch time. There may be ad-hoc requests for in-person meetings at the Bank of England's location in Threadneedle Street. All travel and subsistance expenses will require prior approval. Provide more information about your security requirements: No security clearance needed Latest start date 2024-06-24 Enter the expected contract length: 4 months Extension period: 2 months Special terms and conditions All expenses must be pre-agreed between the parties. All vendors are obliged to provide sufficient guarantees to implement appropriate technical and organisational measures so that the processing meets the requirements of GDPR and ensures the protection of the rights of data subjects. For further information please see the Information Commissioner's Office website https://ico.org.uk/for-organisations/data-protection-reform/overview-of-the-gdpr/ Special terms and conditions Create the deliverables for this contract under Specially Written Software/New IPR as defined in Call-Off Schedule 6 Write the term or acronym: API Write the term or acronym: PET Write the term or acronym: KYC Write the term or acronym: AML Write the term or acronym: PII Write the term or acronym: CI Write the term or acronym: IaC Write the term or acronym: FPS Write the term or acronym: NFR Write the term or acronym: GDPR Write the term or acronym: EMV Explain the term or acronym: Application Programming Interface Explain the term or acronym: Privacy Enhancing Technology Explain the term or acronym: Know your Customer Explain the term or acronym: Anti money Laundering Explain the term or acronym: Personally Identifying Information Explain the term or acronym: Continous Integration Explain the term or acronym: Infrastructure as a Code Explain the term or acronym: Faster Payments System Explain the term or acronym: Non Functional Requirement Explain the term or acronym: General Data Protection Regulation Explain the term or acronym: Europay, Mastercard and Visa Are you prepared to show your budget details?: Yes Indicative maximum: 250000 Indicative minimum: 150000 Confirm if you require a contracted out service or supply of resource Contracted out service: the off-payroll rules do not apply Summary of work Bank of England requires a generic and extensible prototype to demonstrate how interoperability could work between a potential Digital Pound and existing and future payment networks, whilst protecting user privacy. This will be using an FPS scheme simulation as the first example of an external payments interface. Where the supplied staff will work No specific location (for example they can work remotely) Why the work is being done A design principle for the potential future digital pound is to allow convenient interoperability with other forms of money. Within the design phase, the Bank is commissioning and experiment into how interoperability could be achieved using existing infrastructures, whilst meeting certain pre-requisites (user privacy, low participant burden, extensibility with payment systems and seamless UX). The supplier will build a prototype which will simulate interaction with interbank payment system and interoperate with the digital pound. A simulated core platform will be provided which is based off of the Project Rosalind API created by the BIS innovation hub. It must ensure that any contained PII is not accessible by the digital pound platform. The first infrastructure integration to test will be a simulation of Pay.UK's FPS scheme. The supplier will be required to undertake this integration, testing and report findings covering areas including: • Privacy: Approaches used to ensure PII is protected during interoperating • Messaging: Mapping of message flows in appropriate standards keeping it extensible to other payment systems • Security: Meeting the security requirements of interbank payment systems • Network topology: Interaction options between ecosystem participants. • NFRs: Expected performance levels analysis This must also deliver a UI to demonstrate the submission, flows and reporting of simulated payment transactions. The business problem you need to solve The engagement should deliver: • Functional prototype: Demonstrating the end-to-end flow of interoperability transactions between commercial bank money and a digital pound wallet. We expect the test payment transactions to flow in the appropriate messaging standards between simulated commercial bank accounts and digital pound wallet clients and use Rosalind API to interact with the core ledger. The prototype is expected to be securely built, deployed and accessible within Bank's cloud environment following smooth DevSecOps deployment processes. It should demonstrate: ○ On-ramp and Off-ramp transactions between commercial bank money and Digital Pound money ○ Automated scheduled transfers ○ Private (from the central bank) handling of PII data while still meeting KYC/AML obligations ○ Confirmation of Payee of commercial bank and digital pound users ○ Request to Pay of commercial bank and digital pound users ○ Extensibility to interoperate flexibly with other payment infrastructures including cash network • FPS scheme simulation capability to process the transactions between commercial bank money and digital pound money • High level design and architecture of the Interoperability module • Feasibility report and analysis of the proposed approach, explicitly around how the approaches to meet the pre-requisites of privacy, seamless UX, low participant burden and extensibility to other payment schemes. First user type: Commercial Bank Account Holder First user type: Digital Pound Wallet Holder First user type: Digital Pound Technology team member First user type: Digital Pound Technology team member First user type: Digital Pound team member Enter more details about this user type: This project is a prototype and no real users or real money will be used in this project. Without any PII being visible to the Central Bank: As a UK commercial bank account holder I need to be able to transfer money into my digital pound wallet and into a merchant’s digital pound wallet so that my wallet is topped-up and I can also make a purchase Enter more details about this user type: This project is a prototype and no real users or real money will be used in this project. Without any PII being visible to the Central Bank: As a Digital Pound wallet holder I need to be able to transfer money into my UK commercial bank account and into a merchant’s UK commercial bank account so that I can make payments and purchases Enter more details about this user type: This project is a prototype and no real users or real money will be used in this project. Without any PII being visible to the Central Bank: As a digital pound Technology team member I want to demonstrate interoperability between commercial bank money and digital pound money along with understanding the technical feasibility of interoperating so that I can satisfy privacy, seamless UX, low participant burden and extensibility requirements Enter more details about this user type: This project is a prototype and no real users or real money will be used in this project. Without any PII being visible to the Central Bank: As a digital pound Technology team member I want to understand the design and architectural considerations involved around building a future Interoperability module Enter more details about this user type: This project is a prototype and no real users or real money will be used in this project. Without any PII being visible to the Central Bank: As a digital pound team member, I want to understand how wallet holders will on and off ramp cash for digital pounds, so that I can satisfy functional requirements for monetary uniformity Questions and Clarifications 1. 68. Cloud sandbox environment with the necessary controls and segregated to the other networks will be provided to the selected supplier. Bank technology team will work with the selected supplier's team to get the environment setup for their use. 68. Bank uses Github, Azure, Terraform, Docker, AKS, Jenkins, Jira etc. and we're continuously extending our tool set. The supplier will work with the Bank's engineering team to build the appropriate pipelines for the solution around these tools. Last Updated: 3 May 2024, 15:54 2. 67. Problem to be solved - Are the cloud landing zones available with all the pre-requisites like networking, access controls, security ? Or there is work required in this space before applications/environments can be hosted 67. Cloud sandbox environment with the necessary controls and segregated to the other networks will be provided to the selected supplier. Bank technology team will work with the selected supplier's team to get the environment setup for their use. Last Updated: 3 May 2024, 15:53 3. 66. Essentials - 10. NFRs Does BoE have any performance test framework in place to evaluate performance NFRs (like latency , volume etc.) under load conditions? If yes, will supplier be expected to align to same? 66. Supplier will be expected to deliver such capabilities. Last Updated: 3 May 2024, 15:52 4. 65. Essentials - 10. NFRs Can you clarify if question 10 of Stage 1 if you are looking for techniques to assess NFR or details of approaches to optimize them based on NFR outputs? 65. Refer to Q16. (A potential future Digital pound system must be able to handle high volume of interoperability payment transactions. The interoperability prototype along with the feasibility report analysis should indicate the credible expected performance metrics of their solution should it be deployed in production. We expect the report to at least include transactions throughput and transaction latency from initiation to completion of the prototype and techniques on optimising and enhancing the performance in order to support several thousand tps in the future. We understand this is a prototype and therefore performance will be limited but the credible route to high performance must be demonstrated.) Last Updated: 3 May 2024, 15:51 5. 64. Problem to be solved - What delivery methodology do other teams operate under and will supplier be expected to follow/align to common a common cadence? 64. The selected supplier will be responsible for the delivery methodology of the prototype collaborating with the Bank's team. Regular workshops and design discussions will be expected through the length of the project to manage and stay in the right direction. Last Updated: 3 May 2024, 15:49 6. 63. Problem to be solved - Where do you expect the solution to be deployed? Containers, Cloud VMs, PaaS Services? 63. Supplier will be provided access to the Bank's Microsoft Azure sandbox where the prototype will be built and deployed. We would expect the solution to be packaged as containerised apps and deployed into our Azure Kubernetes Service (AKS) instance where possible. Any aspects of the solution that cannot be feasibly containerised could make use of other Azure resources so long as they can be provisioned using an IaC approach. Last Updated: 3 May 2024, 15:47 7. 61. Problem to be solved - What Cloud Environment is the bank using? 61. Bank is using Microsoft Azure hosted sandbox environment. Last Updated: 3 May 2024, 15:44 8. 60. Problem to be solved - Will the functional prototype expected to become a future production ready service or will elements of the solution be used to design a future instance? 60. The scope of this prototype is purely experimentational and proof of concept. This will not lead to a decision towards building a future digital pound or its design. Should it be successful the design may be incorporated into a future digital pound but no code will be. Last Updated: 3 May 2024, 15:43 9. 59. In the context of validating NFRs, will test data be provided or will it need to be created as part of the prototype by the suppliers? As part of the seamless UX goals, will access to all relevant user groups be provided? 59. It will need to be created by the supplier. Last Updated: 3 May 2024, 15:42 10. 58. The prototype is focused on demonstrating interoperability between existing elements of the Bank's ecosystems and external partners. To what extent should the prototype be extendable or re-usable? 58. FPS scheme is the first external payments interface for this prototype and it is expected to extend interoperability with other existing and future payment networks using ISO20022 standards. The prototype is expected to be able to be operated, and extended by the bank for the the rest fo teh Digital Pound's design phase. Last Updated: 3 May 2024, 15:41 11. 57. In the bid document there is mention of the Bank cloud environment. Which core technology is it underpinned by? 57. Bank is using Microsoft Azure hosted sandbox environment. Last Updated: 3 May 2024, 15:40 12. 56. Will the prototyping work require a senior architect from the supplier or will the Bank of England provide this role? 56. Bank project team will be comprised of a Solution Architect, a Functional Manager and a Project analyst. Supplier's team should provide the necessary resources to design, build and deploy the prototype. Last Updated: 3 May 2024, 15:39 13. 55. Will the simulated core platform be provided by the Bank of England or is the supplier expected to provide this? 56. Bank project team will be comprised of a Solution Architect, a Functional Manager and a Project analyst. Supplier's team should provide the necessary resources to design, build and deploy the prototype. Last Updated: 3 May 2024, 15:25 14. 55. Will the simulated core platform be provided by the Bank of England or is the supplier expected to provide this? 55. Bank project team will be comprised of a Solution Architect, a Functional Manager and a Project analyst. Supplier's team should provide the necessary resources to design, build and deploy the prototype. Last Updated: 3 May 2024, 15:25 15. 54. Can we assume that the request to pay functionality will need to function both between digital pound wallets for both requestor and sender, and between digital wallets and commercial accounts? 54. Yes Last Updated: 3 May 2024, 15:15 16. 53. Have you defined your functional requirements for monetary uniformity? If so what are they? 53. The value of the digital pound never deviates from par. At a high level, this is because digital pounds are trusted, are available on demand with sufficient ease and in sufficient quantities, and are able to be exchanged without friction. Last Updated: 3 May 2024, 15:13 17. 52. Are there any considerations we need to make around this project towards the ongoing RTGS work at the BOE? Will the RTGS renewal project be providing any architectural inputs that our designs need to accommodate such as any changes resulting from the renewed RTGS core ledger and settlement engine due in Autumn this year? 52. We do not expect the changes underway in RTGS will have a material effect on this experiment as RTGS integration is out of scope of this project. Last Updated: 3 May 2024, 15:07 18. 51. Please specify what you mean by 'Cash Network'? From examining the Rosalind API endpoints and use cases no cash use case has been described. Will we be expected to generate the required APIs and processes to enable cash withdrawals? 51. Cash Network is deliberately not specified. We require a cash on and off ramp capability and are open to vendors proposals for approaches to providing this capability. Extensions for the required suitable API endpoints will be expected for this project. Interoperability between digital pound and cash network can be proposed via conceptual payment flows, logical architecture and supported documentation. Also refer to Q1. Last Updated: 3 May 2024, 15:06 19. 50. In addition to FPS, what are the other potential future payment networks the solution need to interoperate with? 50. Digital pound will need to interoperate with bank deposits, cash and future forms of private money, such as stablecoins. We consider all current and future interbank infrastructure potential extensions to the interoperability of the prototype being developed here. Last Updated: 3 May 2024, 14:30 20. 50. In addition to FPS, what are the other potential future payment networks the solution need to interoperate with? 50. Digital pound will need to interoperate with bank deposits, cash and future forms of private money, such as stablecoins. We consider all current and future interbank infrastructure potential extensions to the interoperability of the prototype being developed here. Last Updated: 3 May 2024, 14:30 21. 50. In addition to FPS, what are the other potential future payment networks the solution need to interoperate with? 50. Digital pound will need to interoperate with bank deposits, cash and future forms of private money, such as stablecoins. We consider all current and future interbank infrastructure potential extensions to the interoperability of the prototype being developed here. Last Updated: 3 May 2024, 14:30 22. 49. Will the proposal need to consider offline payments made and model the impact to the overall ledger? If so will we be provided with the controls used as part of the offline payments aspect of the Rosalind API? 49. Offline payments are not considered relevant for the purpose of this experiment. Last Updated: 3 May 2024, 14:29 23. 48. It is stated within the BIS paper on the Rosalind API development that extensibility provided by the platform API build created issues ('compromised') with user experience and potentially created issues for adoption. Were there any payment related learnings we should be aware of 48. That section of the report referred to the part that different wallets used aliases in different formats. For this experiment that is irrelevant and you can assume a consistent way of addressing wallets. Last Updated: 3 May 2024, 14:27 24. 47. Can you confirm that the 750 character limit applies 'per question' for all 10 questions in the 'Essential Skills & Experience' section under Stage 1? 47. The limit is per question. To clarify that is 750 characters x 10 (the number of questions in this section) Last Updated: 3 May 2024, 14:26 25. 46. The 'Nice-to-have skills & experience' section under stage 1 (page 9) of the Attachment (Statement of Requirements) is noted as 'not specified', is that correct? Or should there be something for us to respond to in this section? 46. We have only highlighted essential skills & experience for this experiment. Last Updated: 3 May 2024, 14:25 26. 46. The 'Nice-to-have skills & experience' section under stage 1 (page 9) of the Attachment (Statement of Requirements) is noted as 'not specified', is that correct? Or should there be something for us to respond to in this section? 46. We have only highlighted essential skills & experience for this experiment. Last Updated: 3 May 2024, 14:25 27. 45. How should extensibility to other payment infrastructures (e.g. Cash network) be demonstrated? Is it enough to be conceptual rather than demonstrated via physical prototype? 45. Extensibility to other payment infrastructures like Cash network can be proposed via conceptual payment flows, logical architecture and supported documentation. Last Updated: 3 May 2024, 14:23 28. 44. or the prototype, will Confirmation of Payee / Request to Pay services be extended to support digital wallet accounts? If so, will this be provided as part of the engagement, or are we as a supplier expected to provide mock services to demonstrate this? 44. The supplier should supply mocked services and propose how to integrate them. Change to those servcie should be as little as possible and clearly called out. Last Updated: 3 May 2024, 14:22 29. 43. Is the expectation to deliver customer UI's only, or is there an expectation to deliver any operational/colleague UI's? 43. User interface is not the prime focus for this experiment but demonstration of payments flow via a suitable interface is expected from the proposed solution. The UI's prime purpose should be to trigger and demonstrate payment flows while showing what information each party sees in the payment flow to demonstrate that PII isn't visible to the Digital Pound Platform Last Updated: 3 May 2024, 14:21 30. 42. The user stories make reference to both customer journeys and merchant journeys. Should the prototype cater for both journeys with the same UX, or should separate UX be developed for each journey? 42. This is up to the supplier to achieve the best results Last Updated: 3 May 2024, 14:20 31. 41. Does low participant burden extend to end user (customer) experience for the prototype? 41. Low participant burden relates to the intermediaries (PIPs etc) in the digital pound payment ecosystem and the seamless UX refers to the end users. Last Updated: 3 May 2024, 14:19 32. 40. We assume that the focus of the prototype will not be on creating a detailed view of the User Experience such as the detailed functionality of the user wallet to simulate interactions between users and their PIPs/Banks. Is this correct? 40. Whilst not the prime focus of this experiment, demonstration of simulated payments flow via a suitable interface is expected from the proposed solution. The prime focus as outlined in the spec is that seamless interoperability is achieved without the Digital Pound platform seeing user's PII Last Updated: 3 May 2024, 14:18 33. 39. Will the PoC seek to test performance through investigating throughput and transaction times for high volumes of transactions? 39. Refer to Q16. (A potential future Digital pound system must be able to handle high volume of interoperability payment transactions. The interoperability prototype along with the feasibility report analysis should indicate the credible expected performance metrics of their solution should it be deployed in production. We expect the report to at least include transactions throughput and transaction latency from initiation to completion of the prototype and techniques on optimising and enhancing the performance in order to support several thousand tps in the future. We understand this is a prototype and therefore performance will be limited but the credible route to high performance must be demonstrated.) Last Updated: 3 May 2024, 14:17 34. 38. Should it be assumed that the FPS system will be unchanged functionally or can changes be proposed as part of the PoC if this could provide benefits such as reduced burden for participants? 38. Changes to FPS are outside of control of this project. We are open to proposals with suitable extensions as long as project pre-requisites are achieved and solutions demonstrate interoperability both with and without the proposed changes. Last Updated: 3 May 2024, 14:15 35. 37. Can you provide information on the "Bank's experiment cloud environment" and the supplier for this environment? 37. The prototype will be built and deployed to Bank provided cloud sandbox hosted on Microsoft Azure. Last Updated: 3 May 2024, 14:13 36. 36. Is it possible to propose changes to the Rosalind APIs and/or the functionality provided by the Bank's core digital pound system or must they remain in current form? 36. Response: We are open to suitable extensions of Rosalind API for the needs of CBDC<->commercial-bank-money Interoperability payments. Refer to Q1. (Rosalind API focused on CBDC->CBDC payments with temporary fund and defund apis for testing purposes. The goal of this project is to focus on the CBDC<->commercial-bank money payments and therefore we expect new or extended APIs could be developed for this purpose.) Last Updated: 3 May 2024, 14:12 37. 35. Will the PoC involve third parties such as banks participating in the transactions and/or will the scope include creating simulation of bank environments and their roles in the transaction flow? 35. Participants like commercial banks and digital pound intermediaries along with digital pound wallets and commercial bank money accounts are expected to be simulated in order to demonstrate the interoperability payment transactions flow through the payment ecosystem. Last Updated: 3 May 2024, 14:11 38. 34. The following Special Term or Condition is included: “Create the deliverables for this contract under Specially Written Software/New IPR as defined in Call-Off Schedule 6”. Can the sub-contractor create the Functional prototype and the FPS Scheme simulation deliverables using sub-contractor pre-existing IP, assuming there is no license fee for usage of the IP in the prototype? 34. No, the deliverables cannot be created using the supplier's existing IP. New IP created under this call-off will be owned by the Bank. Last Updated: 3 May 2024, 14:10 39. 32. Is expected contract length 4 months or 2 months? 32. 4-6 months Last Updated: 3 May 2024, 14:09 40. 33. Is it possible for the sub-contractor to conduct work from offices in the UK, as well as use resources with highly relevant key skills remotely from outside the UK 33. All work must be conducted from within the UK. Last Updated: 3 May 2024, 14:09 41. 31. Will the sub-contractor who create the deliverables for this contract, including feasibility report, be excluded from bidding for any of the future contracts related to Digital Pound? 31. No, this is not our intention. Last Updated: 3 May 2024, 14:08 42. 30. Are there any specific standards or schemas that should be used or extended as part of the simulation of commercial bank account activity and FPS? 30. Use of common industry messaging standards (ISO8583 and ISO20022) or proprietary standards are expected for the exchange of information within the scope of the prototype. Last Updated: 3 May 2024, 14:07 43. 29. With the use of a digital pound wallet, who will be liable party responsible for the custody and storage PII records upon the completion of KYC & AML compliance check? 29. End-user PII data should be protected from Bank's environment i.e. Platform API at all times. Intermediaries will be the responsible participants for conducting KYC/AML checks and storing of PII Last Updated: 3 May 2024, 14:06 44. 28. Could you please elaborate on the Privacy Preserving goals and requirements? Which standards of PETs are you advocating for and do you expect an approach which is inline with the existing KYC/AML processes? 28. We expect the solution to propose use of one or more Privacy Enhancing Technologies (we are not advocating for any particular types of PETS) for handling of PII sensitive data which should not be accessible by the digital pound platform whilst intermediaries and FPS meet their regulatory KYC/AML requirements. Last Updated: 3 May 2024, 14:05 45. 27. What forms of money (other than integration with Rosalind API and FPS) should be taken into consideration when proposing the architecture of the interoperability solution? 27. Digital pound needs to interoperable with commercial bank deposits, cash and future forms of money. The interoperability module will need to be capable of delivering this capability in the future. For this tender, we have requested interoperability with bank deposits via FPS to be demonstrated. We have also requested the vendor to provide an indication of how the interoperability module could be used to provide a cash on/off ramp by interoperating with cash. Last Updated: 3 May 2024, 14:04 46. 26. Could you please elaborate on the security requirements of interbank payment systems expected for the prototype? 26. We expect the prototype to follow industry best practices for secure software development. An optimal solution will include a reasonable selection of security controls, along with documentation on secure handling of PII data, secure transmission of payment messages, robust user access procedures etc. Last Updated: 3 May 2024, 14:03 47. 25. Could you please elaborate on the transaction performance metrics requirements ? 25. Refer to Q16 (A potential future Digital pound system must be able to handle high volume of interoperability payment transactions. The interoperability prototype along with the feasibility report analysis should indicate the credible expected performance metrics of their solution should it be deployed in production. We expect the report to at least include transactions throughput and transaction latency from initiation to completion of the prototype and techniques on optimising and enhancing the performance in order to support several thousand tps in the future. We understand this is a prototype and therefore performance will be limited but the credible route to high performance must be demonstrated.) Last Updated: 3 May 2024, 09:48 48. 24. What are the existing components that the development will use as a baseline to build the prototype? Is it fair to assume that the Wallet & Ledger capabilities will be provided as part of the simulated core platform based off Project Rosalind API created by the BIS innovation hub? 24. Project Rosalind API will be provided which will act as the interface to core ledge. These will be both be supplied to the supplier and will be based off Rosalind. No wallets will be supplied as this is expected to be part of the UI to show what different participants see. The prototype will need to deliver the simulated capability of end-user wallet messaging along with the other components involved. Refer to Q1. Last Updated: 3 May 2024, 09:47 49. 24. What are the existing components that the development will use as a baseline to build the prototype? Is it fair to assume that the Wallet & Ledger capabilities will be provided as part of the simulated core platform based off Project Rosalind API created by the BIS innovation hub? 24. Project Rosalind API will be provided which will act as the interface to core ledge. These will be both be supplied to the supplier and will be based off Rosalind. No wallets will be supplied as this is expected to be part of the UI to show what different participants see. The prototype will need to deliver the simulated capability of end-user wallet messaging along with the other components involved. Refer to Q1. Last Updated: 3 May 2024, 09:47 50. 23. Could you confirm that access to Rosalind APIs are ready for consumption and will be accessible to the project team during the start of the engagement? 23. Instance of Rosalind API will be provided on Bank's sandbox environment, although extensions to the API could be made for the purpose of this experiment. Refer to Q1. Last Updated: 3 May 2024, 09:46 51. 22. Would it be possible to share the reference architecture for Rosalind Project & Pay.UK's FPS scheme? (This will help us conceptually design the solution and estimate the required efforts.) 22. Details on Project Rosalind could be found at https://www.bis.org/about/bisih/topics/cbdc/rosalind.htm FPS: https://www.wearepay.uk/wp-content/uploads/2023/08/Pay.UK-Faster-Payments-Service-Principles-Aug-2023-v-7.7-Final.pdf Last Updated: 3 May 2024, 09:45 52. 22. Would it be possible to share the reference architecture for Rosalind Project & Pay.UK's FPS scheme? (This will help us conceptually design the solution and estimate the required efforts.) 22. Details on Project Rosalind could be found at https://www.bis.org/about/bisih/topics/cbdc/rosalind.htm FPS: https://www.wearepay.uk/wp-content/uploads/2023/08/Pay.UK-Faster-Payments-Service-Principles-Aug-2023-v-7.7-Final.pdf Last Updated: 3 May 2024, 09:45 53. 21. Any specific use case and scenarios need to be demonstrated in the interoperability Prototype? Should we plan to include use cases that are not part of interoperability? (Such as transferring digital pounds between wallets or a wallet and a merchant, or using FPS to transfer funds between commercial bank accounts) 21. The prototype should demonstrate the Interoperability use cases as highlighted in "The Business Problem" section of the opportunity spec. There is no requirement to demonstrate CBDC↔ CBDC payments or commercial bank ↔ commercial bank payments. Last Updated: 3 May 2024, 09:44 54. 20. “Publicity” • Will publicity be allowed subsequent to contract completion? 20. The Supplier shall not in any way, without the prior written consent of the Buyer (which the Buyer may withhold in its absolute discretion): (i) make any announcements or publicise this Agreement or its contents or the fact that the Supplier is providing services to the Buyer; (ii) use the Buyer’s name or brand in any promotion, marketing or announcement of orders; or (iii) conduct itself in such a way as to imply or express any approval or endorsement by the Buyer of any products or services of the Supplier. Last Updated: 3 May 2024, 09:43 55. 19. Is, “a Bank’s experiment cloud environment” to be provided by the vendor? 19. Bank will provide the cloud environment used to build this prototype. Last Updated: 3 May 2024, 09:42 56. 18. Is there a schematic that reflects the target POC? 18. This will be shared with the stage-2 shortlisted candidates. Last Updated: 3 May 2024, 09:41 57. 17. Qn4: Does the prototype proposal explain the approach to provide FPS scheme simulation in order to achieve the goals of the project? - What kind of FPS scheme simulation is expected during the POC phase? 17. Refer to Q9 (The proposal should include the simulation approach of FPS scheme along with the message communication between end-user's wallet, Digital Pound intermediary, commercial bank and FPS scheme. Ideally the simulator will be hosted on the Bank's cloud environment to allow use and extension after the project however in particularly circumstances we will consider connecting to an external certified FPS simulator.) Last Updated: 3 May 2024, 09:39 58. 16. NFRs: Expected performance levels analysis This must also deliver a UI to demonstrate the submission, flows and reporting of simulated payment transactions - What are the expected performance requirements in terms of volume of transactions? 16. A potential future Digital pound system must be able to handle high volume of interoperability payment transactions. The interoperability prototype along with the feasibility report analysis should indicate the credible expected performance metrics of their solution should it be deployed in production. We expect the report to at least include transactions throughput and transaction latency from initiation to completion of the prototype and techniques on optimising and enhancing the performance in order to support several thousand tps in the future. We understand this is a prototype and therefore performance will be limited but the credible route to high performance must be demonstrated. Last Updated: 3 May 2024, 09:38 59. 15. In relation to question 'Were the presenters able to explain the suitable approach to build and deploy the prototype in Bank’s cloud environment along with delivering FPS scheme simulation capability.' Is the Vendor expected to build a simulator for FPS Scheme? Which cloud environment is being proposed for this engagement? Will there be integration with the FPS system? 15. Bank is using Microsoft Azure hosted sandbox environment. We expect the vendor to build or provide an FPS scheme simulation capability and not integrating with the FPS system. Refer to Q9 Last Updated: 3 May 2024, 09:37 60. 14. In relation to question 'Does the proposal explain two or more approaches towards network topology and the method of interaction between the digital pound ecosystem participants for Interoperability transactions? - Do we need to include centralized and decentralized approaches for the proposed solution ?' Do we need to include centralized and decentralized approaches for the proposed solution? Is the Bank interested in exploring blockchain platforms? 14. In this instance network topology and interaction refers to a Hub and Spoke vs point to point. These loosely could be referred to centralised and decentralised. An optimal solution should compare and contrast both options. The Bank's doesn't rule out any particular technologies although please note that the Core Ledger is not in scope for this project and so the technology must be used for providing interoperability Last Updated: 3 May 2024, 09:34 61. 13. Do we need to consider the use of alias lookup to help confirm the payee of commercial bank/digital pound users? 13. Yes, use of aliases will be relevant for payments between digital pound user accounts and commercial bank user accounts. To reiterate confirmation of payee is one of the use cases specified in the Business Problem section that we want demonstrated in this solution Last Updated: 3 May 2024, 09:33 62. 12. Do we have any specific account structure that need to be followed (Ex: Sub accounts, Direct/Indirect account etc) 12. Account structure is not considered important for the purpose of this experiment, only interoperability between commercial bank account and digital pound account. For reference, project Rosalind does support sub-accounts. Last Updated: 3 May 2024, 09:32 63. 11. Do you consider any limit for holding the CBDC units per user? 11. Limits are not considered important for the purpose of this experiment Last Updated: 3 May 2024, 09:31 64. 10. Does the prototype consider an account based CBDC or a token based CBDC for this exercise? 10. As demonstrated in project Rosalind (https://www.bis.org/about/bisih/topics/cbdc/rosalind.htm) the Rosalind API abstracts away the ledger's underlying data structure. The focus of this project is CBDC<->Commercial bank money payments and interoperability will simply send and receive numerical amounts. Last Updated: 3 May 2024, 09:30 65. 9. We assume the scope of work involves creating the FPS scheme simulator. Where will this simulator be hosted? Which network will be used API's for integration between the core system, PSP, FPS and wallet? 9. The proposal should include the simulation approach of FPS scheme along with the message communication between end-user's wallet, Digital Pound intermediary, commercial bank and FPS scheme. Ideally the simulator will be hosted on the Bank's cloud environment to allow use and extension after the project however in particularly circumstances we will consider connecting to an external certified FPS simulator. Last Updated: 3 May 2024, 09:28 66. 8. Do we have a maximum limit in terms of the number of users who will be given access to the Bank's cloud environment for the purpose of this prototype development? 8. We expect a maximum of 4-5 users to meet the requirements of this project and they will work with the Bank's engineering team to configure the cloud environment and pipelines. The supplier's developers will be given contributor access to our source code repository and will then use those pipelines for deployment Last Updated: 3 May 2024, 09:27 67. 7. Do you have any specific security guidelines that has to be adhered to as part of this prototype development? 7. We expect the prototype to follow industry best practices for secure software development. An optimal solution will include a reasonable selection of security controls, along with documentation on secure handling of PII data, secure transmission of payment messages, robust user access procedures etc. Last Updated: 3 May 2024, 09:26 68. 5. Can we propose to bring our I.P solution for this prototype and simulate interaction with interbank payments system and the digital pound API's? If so will we be allowed to install our solution in Bank's environment? 5. No, the deliverables for the engagement must be created using new IP. We would expect the deliverables created for this contract under Specially Written Software/New IPR as defined in the framework terms. Last Updated: 3 May 2024, 09:25 69. 6. Our understanding the Core Ledger is existing as part of earlier Project and we will need to interface with it. Can we please share more details about the Core Ledger, Rosalind API's? Will there be need to enhance these API from Ledger say for security reasons? 6. The ledger will only be accessed via the API. Details on Project Rosalind along with the API endpoints and the functionality can be found here: https://www.bis.org/about/bisih/topics/cbdc/rosalind.htm We expect the API to be extended for the needs of Interoperability payments and will work with the partner to support this. Last Updated: 3 May 2024, 09:25 70. 4.What are the documentation requirements for continued use and deployment after the project? 4.This prototype is our experimental work and we expect to be able to continue to use, test and make continued incremental improvements throughout the Digital Pound design phase even after this project completes. The solution supplied should be fully documented to support this continued work Last Updated: 3 May 2024, 09:02 71. 1. Are there differences between the Rosalind API and the one for this project? 2. Is it a fixed API, or will there be an opportunity to collaborate on potential privacy improvements? 3. Will there be sandboxing accounts provided for the Faster Payments Scheme? 1. Rosalind API focused on CBDC->CBDC payments with temporary fund and defund apis for testing purposes. The goal of this project is to focus on the CBDC<->commercial-bank money payments and therefore we expect new or extended APIs could be developed for this purpose. 2. The scope of the privacy requirements are as per the opportunity spec. We are open to potential extensions if necessary. 3. We expect vendors to propose the simulation approach of Faster Payments Scheme for this prototype. Bank is not directly providing access to any sandbox accounts. Last Updated: 3 May 2024, 08:58