《英格兰银行：2024销售点（POS）概念验证：数字英镑实验报告（英文版）（22页）.pdf》由会员分享，可在线阅读，更多相关《英格兰银行：2024销售点（POS）概念验证：数字英镑实验报告（英文版）（22页）.pdf（22页珍藏版）》请在三个皮匠报告上搜索。

1、Digital pound experiment reportMay 2024Point-of-sale proof of conceptBank of England Contents Summary 2 Background 3 Project overview 6 Results 19 Reflection and next steps 20 Bank of England Page 1SummaryAs part of the design phase for a digital pound,the Bank of England(the Bank)is conductingexper

2、iments and proofs of concept(PoC)in collaboration with private-sector innovators and arange of stakeholders.These aim to assess the technical feasibility and technology andpolicy implications of potential digital pound design features.No decision has been taken onwhether or not to build a digital po

3、und.The purpose of this experiment was to assess the technical feasibility of using existing point-of-sale(POS)hardware,as currently used in the UK,to initiate digital pound payments.Thisinvolved a PoC that used EMV1 standards to send payment instructions from smart cards toPOS devices,and then to a

4、n application programming interface(the BoE API).While the Bank did not build a digital pound infrastructure,and no real money payments weremade,the experiment demonstrated the following from a technology perspective:The experiment also concluded that it is technically feasible to implement offline

5、paymentsfunctionality at points of sale using existing POS terminals.But this functionality might requirethat an offline payments application be deployed to those terminals in order to store offlinebalances.Therefore,while existing POS terminals may not need to be modified to makeonline digital poun

6、d payments,they might need to be modified for offline payments.There are several other factors,such as operational,legal and commercial considerations,that will impact design choices around digital pound payments at points of sale.Those factorswere not tested in this experiment.Existing POS terminal

7、s in the UK could,in principle,be used to initiate digital poundpayments.Those terminals do not appear to require modification in order to make digital poundpayments.Bank of England Page 2BackgroundIn February 2023,the Bank published a Technology Working Paper,which accompaniedthe Bank and HM Treasu

8、rys joint Consultation Paper on the digital pound.The Bank andHM Treasury confirmed in January 2024 that further preparatory work was justified toenable us to respond to developments in the payments landscape and to reduce materiallythe lead time if there is a future decision to introduce a digital

9、pound.The Bank and HMTreasury have therefore moved from the research and exploration phase of work on a digitalpound to the design phase,which will result in a decision around the middle of the decade onwhether to build a digital pound.Figure 1:Roadmap for the digital pound projectBank of England Pa

10、ge 3The objectives of the design phase are to:As part of the design phase,the Bank is conducting experiments and PoC in collaborationwith private-sector innovators and a range of stakeholders.These experiments and PoC donot indicate a decision to build a digital pound or a final digital pound design

11、.They aim toassess the technical feasibility and technology and policy implications of a digital pound,inorder to help the Bank and HM Treasury explore the design of a digital pound,and provideevidence to support a decision on whether to build one.By partnering on experiments andPoC,the Bank and HM

12、Treasury seek to catalyse private innovation in digital currencytechnologies,encourage innovative digital money business models and support knowledgesharing across the UK fintech sector.The point-of-sale feasibility studyAs discussed in the Technology Working Paper,in order for a digital pound to me

13、et its policygoals,it would need to be useful for everyday payments,including being able to makepayments in store.Today,in-store card payments are enabled through the sending ofpayment instructions from the merchants POS terminal to the payers card issuer.This isfacilitated by the merchants acquirer

14、 and the payment scheme associated with the payerscard.If a digital pound were to utilise existing POS terminals,this would reduce,or potentially eveneliminate the need for merchants to invest in new hardware.Existing POS terminals havewide adoption in the UK,and merchants often maintain the same te

15、rminals for several yearswithout changing them.Those terminals are also familiar to merchants,their staff,andconsumers,delivering a consistent user experience.cut lead-times on digital pound development and equip ourselves with the knowledge andcapabilities to move into a build phase,if required;det

16、ermine the technology feasibility and investment needed to build a digital pound;articulate,in detail,what the technology and operational architecture for a digital poundwould look like;assess and evaluate the benefits and costs of a digital pound architecture;deepen the Banks knowledge of central b

17、ank digital currency(CBDC)technology andsupport stakeholder understanding of our technology approach;support the development of the broader UK digital currency technology industry throughcollaboration,knowledge-sharing,experimentation and proofs of concept;andprovide the basis for a future decision

18、on whether to introduce a digital pound and move toa build phase.Bank of England Page 4The Banks POS feasibility work took place in two stages.First,the Bank commissioned afeasibility study to explore how digital pound payments could be made using existing POSinfrastructure in the UK.The study concl

19、uded that it would be feasible,from a technologyperspective,to use existing POS hardware to make digital pound payments,and highlighteddifferent payment flows that could be used to deliver this.This report covers the second stageof the Banks POS feasibility work,a PoC which aimed to validate the fin

20、dings from thefeasibility study.Bank of England Page 5Project overviewConsult Hyperion2 developed this PoC to help us test digital pound payment initiation usingexisting POS hardware.We(the Bank and Consult Hyperion)used the following componentsto simulate in-store digital pound payments:In addition

21、 to the components listed above,we developed an application that could enableoffline payments on the POS devices.POS devices,namely traditional POS terminals,mobile POS terminals,and a softwarePOS application on an Android mobile phone;EMV-compliant contactless kernels;3Smart cards4 with EMV applica

22、tions5 and different verification methods,namelyConsumer Device Cardholder Verification Method(CDCVM)6 and Online PIN;A proxy server developed by Consult Hyperion,referred to as the BoE API;andA web application dashboard showing balances,transactions and error logs.Figure 2:Mobile,traditional and so

23、ftware POS devicesBank of England Page 6ImplementationPayment flowsThis PoC explored three different payment flows:For each payment flow,we considered sale and refund transactions,and transaction queries.PASSTHRUPASSTHRU where a request for payment is sent to the BoE API via the merchantsPayment Int

24、erface Provider(PIP);DIRECT where a request for payment is sent directly to the BoE API,bypassing themerchants PIP;andPEER where a payment is made between two devices without network connection,supporting offline payments.This flow assumes that balance is stored remotely on the core ledger provided

25、by theBank.The merchants POS device requests payment.The payer taps their device on the merchants POS device.The payer either authenticates to their device using CDCVM or enters their PIN on themerchants POS device.A request for payment with payer authentication data is sent from the merchants POS t

26、othe merchants PIP.The merchants PIP sends this request(authentication data is encrypted)to the BoE API,which routes it to the payers PIP.The payers PIP authenticates the payer using the authentication data in the request.Upon successful authentication,the payers PIP sends the payment instruction to

27、 the coreledger to transfer digital pounds from the payer to the merchant.Digital pounds are transferred from the payers wallet to the merchants wallet and thetransaction data is viewable on the web application.7Bank of England Page 7Figure 3A:Sale transaction at POS using the PASSTHRU payment flowB

28、ank of England Page 8Figure 3B:Sale transaction at POS using the PASSTHRU payment flowBank of England Page 9DIRECTThis flow assumes that balance is stored remotely on the core ledger provided by theBank.The merchants POS device requests payment.The payer taps their device on the merchants POS device

29、.The payer either authenticates to their device using CDCVM or enters their PIN on themerchants POS device.An encrypted request for payment,along with payer authentication data,is sent from themerchants POS directly to the BoE API.The BoE API routes this request to the payers PIP.The payers PIP auth

30、enticates the payer using the authentication data in the request.Upon successful authentication,the payers PIP sends the payment instruction to the coreledger to transfer digital pounds from the payer to the merchant.Digital pounds are transferred from the payers wallet to the merchants wallet and t

31、hetransaction data is viewable on the web application.8Bank of England Page 10Figure 4A:Sale transaction at POS using the DIRECT payment flowBank of England Page 11Figure 4B:Sale transaction at POS using the DIRECT payment flowPEERThis flow assumes that balance is stored on the users device.Therefor

32、e,paymentscan be made offline,with immediate confirmation and settlement.This flow also introduces the concept of a controller and a server of the transaction.The controller is the application that initiates the transfer.It can be in a merchant POS device or a consumers device.The server is the appl

33、ication that receives the transfer request.9 The controller or server can be either the payer or the payee.Bank of England Page 12The controller initiates the transaction.The server device is tapped onto the controller device.Upon the controllers request,each device verifies that the other is valid

34、to conduct atransaction and the payer carries out authentication using CDCVM.If authentication is successful,a payment request is sent from the controller to the server.If this payment request is accepted,digital pounds are transferred directly from the payersdevice to the payees device,with the pay

35、ers balance debited before the payees balanceis credited.If the devices were online,the transfer details would immediately be notified to the coreledger and made viewable on the web application.If the devices were offline,the transaction details would be stored on the devices until theyreconnect to

36、the network.Bank of England Page 13Figure 5:PEER sale transaction using the PEER flow,with payees device as thecontrollerBank of England Page 14The EMV applications on the smart cards were not appropriate for storing offline balances,asthey were primarily designed as risk management counters.10 Ther

37、efore,we developed anew application that could store offline balances on the smart cards.This new applicationwas not based on EMV standards so we also needed to deploy a new kernel to the terminalsthat could interact with it.Figure 6:PEER sale transaction using the PEER flow,with payers device as th

38、econtrollerBank of England Page 15AuthenticationWe enabled two verification mechanisms for user authentication,CDCVM and Online PIN.CDCVM was enabled via a fingerprint sensor on the smart cards.11 Although not widelyadopted,fingerprint-enabled smart cards have been around for many years and are avai

39、labletoday for POS payments.To set up the card,the payer enrolled their fingerprint to the card.When used forauthentication,the fingerprint on the sensor was checked against the enrolled fingerprint.Thefingerprint data was stored on the users card and was never transferred to the Bank or theusers PI

40、P.Online PIN verification was implemented through the exchange of cryptographic keysbetween the merchants POS terminal,the payers PIP,the merchants PIP,and the BoE API.This process ensured that,similar to card payments and automated teller machine(ATM)transactions in the UK,the users PIN was transfe

41、rred securely.The BoE API held a sharedkey with the merchants PIP(merchant PIP working key)and with the payers PIP(payer PIPworking key).No personal data was transferred to the Bank.Where Online PIN verificationwas selected:PIN values were captured on the POS terminals as encrypted PIN blocks.If the

42、 PASSTHRU flow was used,the PIN block was immediately sent to the merchantPIP for PIN translation.12If the DIRECT flow was used,the PIN block was sent to the BoE API,which passed itback to the merchant PIP for PIN translation.The merchant PIP translated the PIN block from the terminal working key to

43、 the merchantPIP working key,before sending it to the BoE API.The BoE API translated the merchant PIP working key to the payer PIP working key,before sending it to the payers PIP.The payers PIP checked that the PIN matched the payers reference PIN,beforeapproving authentication.13Bank of England Pag

44、e 16Figure 7:Online PIN verification in the PASSTHRU payment flowBank of England Page 17Figure 8:Online PIN verification in the DIRECT payment flowBank of England Page 18ResultsPayment flowsWe successfully implemented the PASSTHRU and DIRECT payment flows using thetraditional,mobile and software POS

45、 terminals.The DIRECT flow required all POS terminals to be connected to the BoE API,which placedsignificant key management load14 on the BoE API.Also,since payment instructions weresent directly to the BoE API,they were sent with a SHA256 hash of the primary accountnumber(PAN),rather than the PAN.1

46、5 This ensured that the PAN was not visible to the BoEAPI.This flow did not use the Association for Payment Clearing Services(APACS)70standard which is commonly used in the UK today.16 PAN is a mandatory field in the APACS70 file definition.Therefore,the APACS 70 standard was not appropriate for thi

47、simplementation of the DIRECT flow.While we successfully implemented the PEER flow using the traditional POS terminal and thesoftware POS application.We were unable to implement it using mobile POS terminalsbecause of restricted access to terminals software development kit.Despite this limitation,we

48、 were able to demonstrate offline payments using this payment flow,as payments could beexecuted without an immediate connection to the BoE API.Unlike the DIRECT and PASSTHRU payment flows,the PEER flow required that the POSterminals software be modified or updated.AuthenticationWe successfully imple

49、mented both CDCVM and Online PIN verification,enabling the payersPIP to authorise the payer.CDCVM verification was possible for all payment flows,in bothonline and offline(PEER)transactions.Online PIN verification was implemented in both the PASSTHRU and DIRECT flows.However,the DIRECT flow introduc

50、ed complexities since it required the BoE API to send theencrypted PIN block to the merchants PIP before routing the payment instruction to thepayers PIP.Also,since Online PIN verification required online approval,this verificationmechanism did not work for offline(PEER)transactions.Bank of England

51、Page 19Reflection and next stepsThis PoC demonstrated the technical feasibility of using existing POS hardware to initiatedigital pound payments.It was useful in developing the Banks understanding of therequirements for initiating digital pound payments at POS,both online and offline.This PoC made s

52、everal assumptions about design choices for a digital pound,including whatPOS hardware to use,whether there would be cards and what type,where balance is storedand the applicable PIN translation mechanism.At this time,no such design choices havebeen made.There are a range of considerations,other tha

53、n technical feasibility,that willimpact design choices for in-store digital pound payments.Bank of England Page 201.EMV(Europay,Mastercard and Visa)is a set of technical specifications which enable card-based payments to beconsistently accepted across different payment schemes.2.Consult Hyperion was

54、 awarded a contract for point of sale consultancy services.3.EMV kernels are the software applications that implement the EMV functionality,enabling payment processing.4.These smart cards were fingerprint-enabled,allowing us to test strong customer authentication without requiring users toauthentica

55、te to a smartphone.The users fingerprint remained on their card and was not shared with other parties.SeePayment Services Regulations 2017 for information on strong customer authentication requirements.5.We developed applications based on EMV standards that could interact with the EMV kernels on the

56、 POS devices.6.CDCVM enables users to be authenticated on their own devices rather than on the merchants POS device.Thismechanism supports contactless payments.7.The transaction data is viewable by the payers PIP and the payees PIP,but not by the Bank.8.The transaction data is viewable by the payers

57、 PIP and the payees PIP,but not by the Bank.9.The use of a controller allows transactions to be resumed in the event of an error.The funds may be locked if thetransaction does not resume,but they would be unlocked when both devices return online.10.They are designed to record how many transactions a

58、re completed offline and the transaction amounts approved offline.11.Smart cards rather than smartphones were used in order to test providing strong customer authentication to users whodo not have,or choose not to use,a smartphone.12.From a technical perspective,another option would be to enable mer

59、chant PIP to translate PINs directly to the payerPIP working key.13.Hardware Security Modules(HSMs)were not used in this PoC.HSMs are hardware security devices that storecryptographic keys and protect the keys from tampering or unauthorised access.They could be used in a productionCBDC system to pro

60、tect PINs from compromise.14.This refers to the volume of keys that the BoE API was required to store.15.PAN refers to the long number on a debit or credit card.16.APACS 70 is a messaging standard used in the UK payments industry for passing payment instructions between themerchants POS terminal and the merchants acquirer.Bank of England Page 21