WO2025078815A1

WO2025078815A1 - Digital automatic teller machine and method

Info

Publication number: WO2025078815A1
Application number: PCT/GB2024/052593
Authority: WO
Inventors: Michael Terance RYAN
Original assignee: Cool Partnership Ltd
Current assignee: Cool Partnership Ltd
Priority date: 2023-10-13
Filing date: 2024-10-09
Publication date: 2025-04-17
Anticipated expiration: 2026-04-13
Also published as: GB202315755D0; GB2634570A

Abstract

Described herein is a dispensing machine for dispensing a digital form of cash. The dispensing machine comprises a card reader configured to read account information that is stored on an EMV chip or magnetic strip of a user's bank card; a cassette for holding a plurality of digital payment cards for dispensing to a user; a user interface; a communications interface; and a processor. The processor is configured to: obtain account information from the user's bank card via the card reader; receive a request via the user interface for the issuance of a digital payment card with a desired sum of money ascribed to the digital payment card; operate the communications interface to communicate with a bank to determine whether the user's account has sufficient funds to transfer the desired sum of money to the digital payment card; upon receiving confirmation from the bank that the user's account does have sufficient funds to transfer the desired sum of money to the digital payment card, communicate with the digital payment card to ascribe the funds to the digital payment card; and once the funds have been ascribed to the digital payment card, dispense the digital payment card to the user.

Description

Digital automatic teller machine and method

Field of the invention

The present disclosure relates to an automatic teller machine and method, in particular a digital automatic teller machine and method.

Background

Economies across the world are now moving quickly towards the inevitable use of digital cash and the replacement of physical or paper fiat cash. For larger payments (for example above a contactless payment option) there are a plethora of solutions already in place and more options are coming into place.

However, almost all sovereign Treasuries, National Banks, and governments, acknowledge and accept that there remains and probably will remain for the foreseeable future, a need for physical cash, as it is used today. Without a true digital replacement for Fiat cash, a central bank digital currency (CBDC) cannot fully function for all people either efficiently or socially.

Physical fiat cash still does not have a comprehensive or desirable digital replacement. The few CBDCs in operation and the majority of sovereign state economies who are still reviewing the CBDC options, do not have a true solution that replaces all the characteristics and qualities of paper (or polymer) cash, such as the traditional £20 note, dollar bill or euro. etc. Without a true solution the transition to digital currency cannot fully work and many people will suffer.

Research confirms overwhelming percentages of movement from physical cash usage to digital via debit and credit cards and phone apps across the world. It also shows that a significant percentage of debit card users would prefer the management control and anonymity etc of cash if they could also use that in a digital form.

Summary of the invention

Aspects of the invention are as set out in the independent claims and optional features are set out in the dependent claims. Aspects of the invention may be provided in conjunction with each other and features of one aspect may be applied to other aspects.

In a first aspect there is provided a dispensing machine for dispensing a digital form of cash. The dispensing machine comprises a card reader configured to read account information that is stored on an EMV® chip or magnetic strip of a user’s bank card; a cassette for holding a plurality of digital payment cards for dispensing to a user; a user interface; a communications interface; and a processor. The processor is configured to: obtain account information from the user’s bank card via the card reader; receive a request via the user interface for the issuance of a digital payment card with a desired sum of money ascribed to the digital payment card; operate the communications interface to communicate with a bank to determine whether the user’s account has sufficient funds to transfer the desired sum of money to a corresponding digital cash bank account for the digital payment card; upon receiving confirmation from the bank that the user’s account does have sufficient funds to transfer the desired sum of money to a digital cash bank account for the digital payment card, communicate with the digital payment cards digital cash bank account to ascribe the funds to the digital payment card; dispense the digital payment card to the user.

It will be appreciated that no cash is actually held on the digital payment card itself - instead the cash is held in a corresponding digital cash bank account, for example a central bank (CB) digital cash account.

In some examples, the processor is configured to operate the communications interface to communicate with a digital cash holding bank to hold the ascribed funds for that individual payment card and once the funds have been ascribed to the digital payment card, ascribe a unique one-time-only (OTO) bank account number with an identifier, such as a permanent ID, of that digital payment card. The unique OTO bank account number may be ascribed by a central bank (CB) or digital currency authority (DCA) operating bank. It will be appreciated that the communication with the permanent ID of the digital payment card to the central bank (CB) or digital currency authority (DCA) operating bank that is to ascribe the OTO DCA number is an optional stage of communication for the DCA operator to choose. The payment card preferably has the correct DCA number. That is ensured by including the payment card’s permanent unique ID in the DCA OTO account number.

It will be understood that the bank may be the user’s bank, i.e. , the user’s issuing bank. The communication with the bank may be via the user’s card processing network.

Communicating with the digital payment card to ascribe the funds to the digital payment card may comprise communicating with the payment card to update a balance value displayed on a display of the digital payment card.

Communicating with the payment card to ascribe funds to the digital payment card may comprise communicating with an EMV chip on the digital payment card to bind the payment card to a one-time-only bank account created by a central bank or the digital cash account operating bank.

The dispensing machine may further comprise a receptacle for receiving used digital payment cards.

The card reader may comprise a contactless card reader.

The card reader may comprise a chip and pin card reader.

The digital payment card may be automatically dispensed when the funds have been ascribed to the digital payment card.

The user interface may comprise at least one of a display and a user input. The user input may for example be a touchscreen or buttons.

The dispensing machine may further comprise a near field communications interface for communicating with the digital payment card.

Upon receiving confirmation from the user’s bank that the user’s account does have sufficient funds to transfer the desired sum of money to the DCA holding bank or institution, which will ascribe a OTO bank account number to the digital payment card, the dispensing machine may be configured to send details of the next available digital payment card to a remote bank, before communicating with the digital payment card to ascribe the funds to the digital payment card. The remote bank may be a central bank.

Communicating with the digital payment card to ascribe the funds to the digital payment card may comprise receiving a one-time-only bank account number from the remote bank and ascribing the one-time-only bank account number to the digital payment card.

The OTO bank account number may be included so as to conform with anti-money laundering (AML) requirements preventing transfers from one existing anonymous payment instrument to another, or adding to an existing anonymous payment instrument such as an existing digital payment card. If there is no AML requirement then the digital payment card can hold a permanent DCA bank number, that number could be issued to the DCA operator when funds are supplied for that bank account.

In another aspect there is provided a system for dispensing a digital form of cash, the system comprising: a near field communications interface for communicating with a digital payment card; a communications interface for communicating with a user’s bank; a user interface; and a processor. The processor is configured to: receive a request via the user interface for the issuance of a digital payment card with a desired sum of money ascribed to the digital payment card; operate the communications interface to communicate with the user’s bank to determine whether the user’s account has sufficient funds to transfer the desired sum of money to the digital payment card; upon receiving confirmation from the user’s bank that the user’s account does have sufficient funds to transfer the desired sum of money to the digital payment card, communicate with the digital payment card to ascribe the funds to the digital payment card.

Communicating with the payment card to ascribe funds to the digital payment card may comprise communicating with an EMV® compliant chip on the digital payment card to bind the payment card to a one-time-only bank account created by a central bank.

In another aspect there is provided a method of dispensing a digital form of cash, the method comprising: obtaining credentials from an EMV® compliant bank card; sending the credentials from the EMV® compliant bank card to the user’s card processing network; receiving a validation message from the user’s card processing network; receiving a request to withdraw funds from the user, the request including an indication of the value of the funds requested; sending the request including the value of funds requested to the user’s card processing network; receiving a validation message from the user’s card processing network; receiving an indication of a one-time-only bank account to be paired to a digital payment card, along with an indication of the value of funds to be displayed on a display of the digital payment card; and issuing the digital payment card to the user.

Receiving a validation message from the user’s card processing network may comprise receiving a validation message from the user’s issuing bank via the user’s card processing network.

Sending the request including the value of funds requested to the user’s card processing network may comprise sending the request including the value of funds and a unique identifier of the digital payment card to the user’s card processing network.

The method may further comprise forwarding the request from the user’s card processing network to a central bank, and wherein the central bank creates a unique one-time-only bank account to be paired to the unique identifier of the digital payment card.

The method may further comprise obtaining credentials from an existing digital payment card, the credentials comprising at least an ID associated with the digital payment card, and a balance value of the digital payment card; sending the credentials from the existing digital payment card to the user’s card processing network; and receiving a validation of the existing digital payment card from the user’s card processing network. In another aspect there is provided a method of dispensing a digital form of cash, the method comprising: obtaining credentials of a user’s EMV® compliant bank card from a dispensing machine; checking the credentials of the user’s EMV® compliant bank card and sending a validation message to the dispensing machine in response to the check indicating that the credentials are correct; receiving a request to withdraw funds from the user, the request including an indication of the value of the funds requested, and forwarding this request to the user’s issuing bank; receiving a validation message from the user’s issuing bank (for example, confirming that the user has sufficient funds for the withdrawal) and forwarding the validation message on to the dispensing machine; receiving an indication of a one-time-only bank account to be paired to a digital payment card, along with an indication of the value of funds to be displayed on a display of the digital payment card and forwarding to the dispensing machine.

Checking the credentials of the user’s EMV® compliant bank card may check the legitimacy of the card for use, as well as the availability of funds to complete the transaction.

The request to withdraw funds from the user may include an indication of the value of the funds requested and a unique identifier of the digital payment card; and forwarding the request may comprise forwarding the request including the value of funds and the unique identifier of the digital payment card to the user’s issuing bank.

The method may further comprise forwarding the request to withdraw funds to a central bank (CB) or DCA holding bank, and wherein the central bank creates a unique one- time-only bank account to be paired to the unique identifier of the digital payment card. Forwarding the request to withdraw funds to a central bank may be via the user’s issuing bank.

The method may further comprise obtaining credentials of an existing digital payment card from the dispensing machine, the credentials comprising at least an ID associated with the digital payment card, and a balance value of the digital payment card; sending the credentials of the existing digital payment card to the user’s issuing bank; sending a request to validate the withdrawal of funds to the user’s issuing bank; and receiving a validation of the existing digital payment card from the user’s card processing network and forwarding to the dispensing machine

In another aspect there is provided a method of checking the balance value of a digital payment card, the method comprising: obtaining credentials from an EMV® compliant bank card; sending the credentials from the EMV® compliant bank card to the user’s card processing network; receiving a validation message from the user’s card processing network; receiving a request to check the balance of a digital payment card from the user, the request including credentials of the digital payment card; sending the request including the digital payment card’s credentials to the user’s card processing network; receiving a validation message from the user’s card processing network; sending the request from the user’s card processing network to a central bank or DCA holding bank; receiving a balance value from the central bank or DCA holding bank; and displaying the balance value to the user.

Receiving a request to check the balance of a digital payment card from the user may comprise obtaining credentials of the digital payment card. For example, the digital payment card may be scanned or interrogated by a contactless, such as an NFC, interface.

In another aspect there is provided a computer readable non-transitory storage medium comprising a program for a computer configured to cause a processor to perform the method(s) described above.

Drawings

Embodiments of the disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:

Fig. 1 shows a functional schematic diagram of how a conventional automatic teller machine works in the United Kingdom;

Fig. 2 shows a diagram of an example conventional automatic teller machine (ATM).

Fig. 3 is a functional schematic diagram of an example digital payment card or “dNote” which in this example is a payment card. Fig. 4 shows an example dispensing machine.

Fig. 5 is a sequence diagram illustrating an example process for withdrawing cash onto a digital payment card via a digital automatic teller machine.

Fig. 6 is a sequence diagram illustrating an example process for checking the balance on an existing digital payment card, such as a dNote.

Fig. 7 is a sequence diagram illustrating an example process for returning an existing dNote with a balance still remaining on it, and exchanging it for a new dNote with a new and current balance.

Specific description

Embodiments of the disclosure relate to a dispensing machine or dATM (digital ATM) that enables a withdrawer to withdraw cash at a specific licensed dATM in digital form from their personal bank account. The dATM issues a combined “traditional and digital payment instrument” or digital payment card, optionally with a card value display (CVD), herein referred to as a digital banknote or “dNote” for short. The digital banknote or dNote holds a digital cash bank (or institution) account number together with the payment instrument’s unique and permanent ID number, for the digital cash bank store of that amount being withdrawn via that dATM in that transaction. A user may be able to withdraw cash in this digital form using the digital bank note or dNote using the withdrawer’s personal bank account credit card or debit card or an alternative bank account with a ATM account card, which may be placed into and present at that dATM unit, or via an NFC reader within that dATM unit.

The dATM then sends the inserted or NFC read, personal bank debit/credit/ATM cards encrypted unique ID details to the cards issuing financial institution/bank, for validation of authenticity via the dATM units associated processing partners. The card issuing institution validates or not the withdrawers card and returns a valuation or not message via the same processing rout to that licenced dATM.

Then, if validated, the dATM sends that same request for validation including both the requested withdrawal amount and the unique ID of the next dNote (payment instrument) to be issued by that dATM. To the payment Card institution (such as Visa). The payment card institution issue back to the dATM a validation or not of adequate funds to cover the transaction.

Upon receipt of a positive validation for adequate funds, the dATM sends a message to the processor (or if no processor, then the issuing bank) to instigate a transfer of the amount requested to a digital currency authority (DCA) bank/central bank (CB) or institution via the processing entity together with the next (payment instruments) say dNote’s unique ID number.

The DCA institution then allocates a OTO (one time only) bank account number for the stored amount of digital cash at the DCA to the payment instruments personal unique ID number and sends that DCA bank number to the dATM for transferring to the next payment instrument and with that ID number, together with an instruction for the CVD to illuminate with the amount of digital cash held in the DCA.

The dATM then issues the Payment instrument or dNote for the withdrawer to take and use as they want. The processing institution and the issuing bank later resolve the settlement of the transaction and fees, depending on their individual arrangement.

Fig. 1 is a functional schematic diagram of a process 100 of how a conventional ATM machine works.

Fig. 2 shows a diagram of an example conventional automatic teller machine (ATM) 200.

The major parts of an ATM include:

Mainboard (not shown)- This part controls the processing of the ATM. This houses the CPU, memory, and provides connection to all the other ATM parts.

Card Reader 265- This part reads account information that is stored on an EMV® chip or magnetic strip. Most card readers and cards today are EMV-enabled. The EMV® acronym stands for Europay®, MasterCard®, Visa®. It is the global standard for chipbased debit and credit card transactions. The EMV® chip creates a unique transaction code for that particular transaction.

Display screen (LCD) 250 - This part provides instructions on how to use the ATM.

Keypad 255- This part allows the customer to input information regarding the transaction that they would like to execute. The information provided by the customer may include the personal identification number (PIN), the type of transaction, and the amount of the transaction.

Cassette (not shown) - This part holds the ATM cash.

Cash dispenser 260- This part moves cash from the cassette to the tray.

Printer (not shown) - This part prints a receipt for the customer.

Power Supply (not shown) - This part connects the rest of the ATM to external power.

I/O Board (not shown) - This part controls the communication with the processor through the internet or phone line.

Modem (not shown) - This part executes the communication to the internet.

As shown in Fig. 1, the process 100 begins when a user inserts their personal card into the card reader 265 of the ATM 115. After inserting their card, the mainboard will request that the user enters their pin using the display 250. After entering their pin using the keypad 255, the mainboard requests the type of transaction to occur using the display 250. After the PIN and transaction is entered, the mainboard sends a unique EMV® transaction code, PIN, and transaction to the processor through the I/O board and modem. The processor uses this information to route the transaction to an ATM network or host 101 that is associated with the card. The networks associated with the card are usually printed on the back of the card. The ATM network 101 then sends this information to the card issuer (i.e., the user’s bank) 103 to determine whether the transaction is approved. If the user is requesting cash, the host 101 causes an electronic funds transfer 117 to take place from the customer's bank account 105 to the host processor's account 113. Once the funds are transferred to the host processor's bank account 113, the processor sends an approval code to the ATM 115 authorizing the machine to dispense the. The processor then performs an automated clearing house (ACH) process 103 to transfer the cardholder's funds into the merchant's bank account 111 , usually the next bank business day. In this way, the merchant 109 is reimbursed for all funds dispensed by the ATM 115. This approval or denial is sent back to the ATM 115 through the ATM network 101 and ATM processor. Each further transaction is processed in the same manner.

When a withdrawal is selected the transaction is processed and, if approved, the user’s bank debits their account 105 for the amount. This transaction is sent back through the ATM networks 101 and processor to the ATM 115. The mainboard then initiates the dispensing of the cash 113.

As noted above, embodiments of the disclosure relate to a dATM (digital ATM) that enables the withdrawer to withdraw cash at that specific licensed dATM in digital form from their personal bank account. The digital form may be in the form of a digital payment card, herein referred to as a “dNote”, as described in more detail with reference to Fig. 3 below.

Fig. 3 is a functional schematic diagram of an example digital payment card or “dNote” which in this example is a payment card. In this example the payment card has a form factor that is the same as a regular credit or debit card (i.e., 85.60 by 53.98 millimetres with rounded comers with a radius of 2.88-3.48 millimetres conforming to the ISO/IEC 7810 ID-1 standard). However, it will be understood that the functionality displayed in Fig. 3 may have a different form factor, for example it may be integrated into a wearable device such as a bracelet or necklace. In this example the payment card is EMV® (Europay®, MasterCard®, and Visa®) compliant. The payment card may comply with ISO/IEC 7816 and/or ISO/IEC 14443. The payment card comprises an EMV® contact interface 319 and a contactless antenna 317, both coupled in parallel to a secure element (SE) 305. Each digital payment card or dNote has its own individual and unique permanent ID number. The permanent ID number may be, for example, a unique serial number. The permanent ID may be part of the firmware of the payment card or dNote. For example, the permanent ID may be stored on or in the EMV® interface 319, the MCU 300 and/or SE 305, each of which will be discussed in more detail below.

The SE 305 is a microprocessor chip which can store sensitive data and run secure apps such as payment. It acts as a vault, protecting what’s inside the SE (applications and data) from malware attacks that are typical in the host (i.e., the device operating system). Applications may use the SE 305 to digitally sign data with a key stored in this secure element. This key helps the secure element unlock encrypted data so it can be read. The SE 305 securely stores card/cardholder data and manages the reading of encrypted data. During a payment transaction it uses industry standard technology to help authorize a transaction. The SE 305 when used in other payment cards other than a payment card could for example be embedded in a phone or subscriber identification module (SIM) card. The SE 305 can be implemented in payment cards in one of several ways: as a removable device - for example, in a universal integrated circuit card (UICC) (also known as a SIM card) or in a Micro SD card; as an embedded SE (eSE); and/or as a cloud service. The SE 305 may provide the following features at the hardware level:

• Detection of hacking and modification attempts;

• Creation of a Root of T rust (RoT) platform for encryption systems;

• Provision of secure memory for storing private encryption keys, bank card details, and other information;

• Cryptographically secure generation of random numbers;

• Generation of keys — for example, pairs of private and public keys for asymmetric encryption.

The SE 305 may comprise a Java Card Operating System (OS), and a payment applet.

In the example shown the SE 305 is coupled to the contact interface 319 via an ISO multiplexer (MUX) 303. The ISO multiplexer 303 is also coupled to a microcontroller (MCU) 300. The ISO MUX 303 is configured to provide access to the SE 305 for the MCU 300. The ISO MUX 303 multiplexes the contact lines between the contact interface 319 and MCU 300 and may be configured to arbitrate between the SE 305 and the MCU 300.

The MCU 300 is configured to communication with the SE 305 via a communication protocol according to at least one of ISO-7816 and EMV® standards. The MCU 300 may comprise or be coupled to a memory, which may be a secure memory. The MCU 300 may be a low energy 32-bit controller.

The MCU 300 is coupled to a display which may be referred to as a card value display (CVD), and in this example is a bi-stable display 315. Although other displays may be used, preferably the display is a low power display such as ePaper or elnk. A bi-stable display is advantageous as it does not require power to maintain the display, power is only used to change the display. In this example the bi-stable display 315 is an alphanumeric display and comprises a bi-stable controller configured to communicate with and receive instruction from the MCU 300 to display a value. The MCU 300 is configured to receive information from a merchant payment terminal via the SE 305 relating to at least one of (i) the value of the transaction, and (ii) a balance value held in an account linked to the payment card/SE 305.

The payment card in this example also comprises a power harvesting module in the form of an energy harvesting system (EHS) 310 configured to harvest energy from an interaction of the payment card with a payment/merchant terminal. For example, the EHS 310 is configured to harvest and accumulate energy from a contact or contactless transaction with a merchant terminal. The EHS 310 may be available from, e.g., Freevolt™ and may be a radio frequency energy harvesting system. In this example the EHS 310 is coupled to both the EMV® contact interface 319 and the contactless antenna 317. The EHS 310 is also coupled to an energy storage 320 which may be in the form of a battery or capacitor and is configured to store energy captured by the EHS 310.

The EHS 310 is coupled to the MCU 300 and the bi-stable display 315 and is configured to provide power to the MCU 300 and the bi-stable display 315.

The SE 305 is configured to communicate with a merchant terminal to perform a transaction. The payment card is configured to use power obtained from the transaction via the energy harvesting system 310 to power the MCU 300 and the display 315. The MCU 300 may comprise a memory, and is configured to store a balance value, and to obtain information relating to the transaction from the SE 305. The MCU 300 memory may be secure, being electronically sealed and protected. The MCU 300 is configured to obtain and display an updated balance value on the display 315 based on the obtained information relating to the transaction obtained from the SE 305. The MCU 300 is configured to communicate with the SE 305 to obtain information relating to the transaction.

The MCU 300 may be configured to communication with the SE 305 by running a virtual or “spoof” transaction. The MCU 300 may be configured to connect with the SE 305 and behave like a merchant terminal, communicating with the SE 305 using the same standards (such as ISO-7816 and EMV®). The communication between the MCU 300 and the SE 305 may comprise a series of command-response messages. These may comprise commands such as “do you have a last transaction value”, “tell me the value of the previous transaction” or “tell me the value of the balance held in the account linked to this SE”. In some examples this may require adaption of the service layer of the SE 305 to provide this functionality.

In some examples, the SE 305 is configured to store information relating to a balance value held in an account linked to the payment card. In such examples the MCU 300 may be configured to communicate with the SE 305 to obtain a balance value held in the account linked to the payment card. However, this may only work then the merchant terminal is online at the time of the transaction, and/or when the payment card is in communication with (for example in range of the contactless interface 317 or coupled via the contact interface 319) the merchant terminal.

Additionally, or alternatively, the SE 305 is configured to store the value of the transaction (for example, the SE 305 is configured to store the value of the transaction when communicating with the merchant terminal via at least one of the contactless interface 317 and the contact interface 319). In such examples, the MCU 300 may be configured to store a balance value, communicate with the SE 305 to obtain the value of the transaction from the information relating to the transaction, and update the balance value based on the difference between the stored balance value and the value of the transaction.

In some examples, the MCU 300 is configured to determine that a transaction has taken place, and trigger communication with the SE 305 in response to a transaction having taken place to obtain at least one of (i) the value of the transaction, and (ii) a balance value held in an account linked to the payment card. Waiting until after the transaction has taken place advantageously means that the SE 305 is only communicating with one entity (merchant terminal, MCU 300) at a time. Because the MCU 300 communicates with the SE 305, this means that it is only the SE 305 that communicates with the “outer world” thereby ensuring that the payment card remains secure. The MCU 300 may be configured to determine that a transaction has taken place for example by receiving an indication from the EHS 310 that it has received energy (e.g., from the transaction), for example above a selected threshold level of energy. In some examples, the MCU 300 may be configured to switch between two modes of operation in response to a transaction having taken place; for example, a first “sleep” mode when a transaction has not taken place for more than a selected threshold period of time, and a second “awake” mode of operation in response to a transaction having taken place. In some examples the MCU 300 may be configured to return to the first “sleep” mode of operation in response to the MCU 300 having updated the balance value on the display 315, and/or in response to a selected threshold period of time having elapsed.

In some examples the MCU 300 is configured to communicate with a remote device via the wireless communications interface 317 and/or an additional wireless communications interface (such as an NFC interface) to obtain a balance value held in an account linked to the payment card. The remote device may, for example, by a mobile device such as a smartphone or tablet device.

The MCU 300 is configured to update the balance value displayed by the MCU 300 on display 315 (and held by the MCU 300 memory) in the event that there is a difference in the balance value stored by the MCU 300 and held in the account. In some examples, the remote device may be configured to provoke an alert if the balance value stored on the MCU 300 and the balance value held in the account differ.

In some examples the digital payment card or dNote may be personalised to the biometric data of the user. For example, the digital payment card or dNote may have a biometric sensor - for example a fingerprint scanner. In other examples, the dNote or digital payment card may comprise biometric information corresponding to the user, which can be verified by a dispensing machine (such as the dATM described below) and/or by other means such as a payment terminal when the user wishes to use their digital payment card (in a similar vein to how chip and pin cards are currently used - but instead a user’s fingerprint may be used).

As noted above, embodiments of the disclosure relate to a dispensing machine or digital ATM (dATM) that enables a withdrawer to withdraw cash at a specific licensed dATM in digital form from their personal bank account.

It will be understood that there may be two forms of dATM: (i) a merchant’s ATM (Type A), and (ii) an app-based ATM (type B), as will be described in more detail below.

1. Merchant's dATM (Type A): This type of dATM is equipped with an issuance capability for new dNotes. It includes an attached issuance box, which can be a mobile device such as an iPad, or a purpose-made unit - for example with mechanical buttons. Type A ATMs cater to various users, including those without a mobile device such as an iPhone but with a bank card, merchants providing dNotes as part of a service, individuals without a dNote, and those checking their dNote balance. It also serves employers and institutions like banks or post offices. This type of ATM is described in more detail below with reference to Fig. 4.

2. App-based ATM (Type B): Type B dATMs are designed for users with other mobile devices running an app, and using virtual dNotes on a payment app. These ATMs do not issue new dNotes but focus on loading existing payment cards (for example that may be empty with no DCA ID reference prior to loading) and also checking the balance of dNotes. They are accessible to users with mobile devices who wish to reload their existing dNotes or verify their balance.

The electrical and mechanical design of the dATM system encompasses several critical elements, including physical components, card readers, and secure mechanisms. Key considerations include:

1. Anti-Theft Measures: The ATMs should preferably incorporate anti-theft measures.

2. Card Reader: The card reader's integration may be built into a mobile device, connected externally, or utilize NFC technology.

3. Withdrawal Process: The process for digital cash withdrawal, including how debit card information is read and processed for secure withdrawals.

4. Mechanical Design: Consideration of the physical design, including the user interface with touch-button functionality, and the design of receiving and issuance boxes. App and dATM Ecosystem:

• Users will be able to manage their dNotes, check balances, and initiate re-loading directly from the app or via dATMs.

• Information and updates, such as new dNote issuance or balance adjustments, will seamlessly synchronize between the app and dATMs.

• The ecosystem will adhere to the highest security standards, ensuring that users' transactions and data remain protected whether they are using the app or dATMs.

Practical Functionality:

The practical functionality of the dispensing machine or dATM may include the following functionalities:

1. AML Compliance: The system should preferably comply with Anti-Money Laundering (AML) requirements and legal regulations. This may include limitations on topping up dNotes and handling residual balances.

2. Balance Management: Rules regarding dNote balance allocation, including a requirement for a zero balance before issuing a new dNote.

3. Split Payments: Consideration of functionalities for splitting payments or handling residual balances, which may require additional processing time.

4. Issuer Authentication: Mechanisms to authenticate cardholders and process withdrawals securely.

5. Return Messages: Establishing a secure communication flow between a central bank or DCA operating bank, the dATM, and the corresponding dNote to ensure correct allocation and balance display.

An example dispensing machine or dATM 400 is shown in Fig. 4. The dATM 400 may have many features of the conventional ATM described above with reference to Fig. 2. In particular, the dATM 400 comprises a display screen 401 for displaying a user interface to the user, for example to display balance values and/or for a user to interact with to issue a new dNote to be loaded with funds. For example, the display screen 401 may display a message 403 indicating whether the transaction has been successful or not. The dATM 400 also comprises a payment card reader which may be in the form of a slot 404 for receiving a credit/debit card, and/or a wireless communications interface such as an NFC reader 402, for receiving information from a credit/debit card and/or digital payment card or dNote, and/or for sending information to a digital payment card or dNote. The dATM 400 also comprises a new digital payment card or dNote dispensing slot 405 and optionally a return card slot 406 for returning old or used digital payment cards or dNotes. It will be understood that the dATM 400 may comprise a cassette for holding new digital payment cards or dNotes to be used and/or a cassette for holding old/used returned dNotes. Also shown in Fig. 4 is an optional speaker 407 for providing audible feedback to a user. Although not shown, it will be appreciated that the dATM 400 will comprise a processor for processing transactions, and a communications interface such as a modem for communicating with a banking authority such as a central bank.

In some examples the dATM 400 may comprise a third slot (not shown) for receiving a biometric dNote as described above. This third slot may enable the dNote to be recharged. This is because the biometric dNote or “bio dNote” cannot be swallowed for reuse by another user later. It is personal. Therefore, a third slot may be used, designed so as not to swallow the bio dNote leaving an element proud for retrieval after the drawdown is indicated complete.

It will also be understood that the functionality of the dATM 400 shown in Fig. 4 may at least be partially provided by an iPad® or other similar tablet or handheld computing device coupled to a dispensing unit. The dispensing unit may comprise the slots for receiving/dispensing digital payment cards or dNotes, and/or a cassette (where present) for holding them The iPad® or other similar tablet or handheld device may comprise an interface, such as NFC interface, for communicating with and receiving credentials from a user’s bank card (such as their debit card), and/or communicating with a new digital payment card or dNote to be dispensed (for example, to link it to a new OTO bank account as will be discussed in more detail below).

Methods for withdrawing digital cash via the dATM 400 of Fig. 4 are described in more detail below with reference to Figs. 5 and 7. The process for withdrawing digital cash is a very similar process as when withdrawing physical cash from a conventional ATM as described above with reference to Fig. 1 , up to the point of issuance of the (traditional cash or) digital payment card or dNote. That is:

A. The user indicates their chosen personal bank account for the withdrawal as normal today.

B. The ATM informs the processing company of the proposed transaction.

C. The processing company connects the issuing bank (via the owner’s banks card processor (e.g., Mastercard® or Visa®), for confirmation that the card is authentic and if the transaction is funded and can go ahead. If approved, then in the traditional physical cash case, the physical cash is issued and later the processing company transfers the agreed funds (digitally) from the issuing bank to the receiving bank, in this case the receiving bank is the central bank, in digital deposit form. However, in the digital cash or dNote drawdown process, the dATM 400 is preferably registered to the operator and protected from cyber-attack. Then after approval of the user’s bank card the central bank authority must be informed immediately of the proposed transfer of funds, and an identifier or permanent ID of the dNote waiting to be issued that time. The central bank authority will allocate and issue a new one-time-only (OTO) central bank digital cash account (CBDCA) number to that next available dNote at that dATM 400. As part of the process of allocating a dNote the dATM 400 may send information identifying the specific dNote (e.g., the permanent ID and the OTO bank account number combined to form a “full dNote ID number”) to the central bank for matching against the newly-create OTO central bank digital cash account. The central bank uses the full dNote ID number together with the OTO number for recognition and use later.

D. The dATM then issues (with a Traditional money ATM cash to the value of the requested and approved amount or) for a digital cash withdrawal to a dNote or digital payment card. The dNote receives the new balance value from the CBDCA. This may illuminate a card value display (CVD) on the dNote with that value before issue.

It will be understood that in some examples, for fraud reasons and compliance with antimoney laundering requirements, a dNote with a residual balance cannot be topped up with more funds. Instead, the dNote must have a balance value of zero. At zero, the OTO bank account will automatically cease to exist and the digital payment card effectively becomes a new payment instrument when issued with a DCA CB to comply with AML.

The process for withdrawing cash onto a dNote via a dATM is now described in more detail with reference to Fig. 5 As shown in Fig. 1 , the process begins when a user submits 501 their debit card to the dATM. The debit card may be an EMV® bank card. The dATM then sends 503 the debit card data (e.g., credentials obtained from the bank card) to the user’s card processing network, which performs a check on the debit card data. If this check passes, then the user’s card processing network sends 505 a signal to the dATM validating the debit card. The user is then presented with the option of choosing their desired function and in this instance may press 507 “withdraw” on the dATM and enters 509 a withdrawal required amount. The dATM receives this information and sends 511 the withdrawal amount data to the user’s card processing network. The user’s card processing network sends 513 a request to the user’s issuing bank asking it to validate enough cash to issue. In response, assuming there are enough funds, the user’s issuing bank sends 515 a confirmation of the validated amount to the user’s card processing network, which in turn forwards this to the dATM. The dATM then obtains a permanent ID of a dNote to be issued (which may be the next available dNote in the cassette, if a cassette is present) to the user, and sends 517 this along with the validated amount, via the user’s card processing network, to the central bank (CB) or the digital cash account (DCA). In response, the CB/DCA creates a one- time-only (OTO) bank account number that is linked to the dNote permanent ID, and sends 521 the OTO bank account number and the amount to be displayed on the optional dNote display (CVD) to the dATM. In response, the dATM issues 523 a new dNote to the user, with the new dNote being linked to the OTO bank account created by the CB/DCA via its permanent ID.

While in the example above the OTO bank account number is sent to the dNote, in some examples the OTO bank account number need not be sent to the dNote if the CB/DCA has a database that matches the permanent ID of each dNote to its corresponding OTO bank account. Additionally, or alternatively, while in the example above the permanent ID of the dNote is sent to the CB/DCA, in some examples a permanent ID is not required if the OTO bank account number is sent to the dNote, as the OTO bank account number may be used to match the dNote to the relevant funds held on account. It will be understood that the OTO bank account may be a single use or temporary bank account created solely and uniquely for each digital payment card. In other words, the OTO bank account is created at the point a new digital payment card such as a dNote is to be issued, and is closed either when the balance is zero, or when the digital payment card such as a dNote is returned. The reason for this action is compliance with AML rules.

The process for checking the balance on an existing digital payment card or dNote is now described with reference to Fig. 6 The reason a balance on an existing digital payment card or dNote might need to be checked is because a fraudster may have passed the digital payment card or dNote on to the user as a form of payment possibly offline. The ability to check that the CVD is correct is a security measure for the receiver of a dNote, in a similar way to how a bank or merchant may use counterfeit note readers

The process begins by the user submitting 601 (i.e., tapping or entering their dNote against or into the dATM) their debit card (i.e., their debit card for their conventional banking account) to the dATM. The dATM in turn sends 603 the debit card data to the user’s card processing network. The user’s card processing network validates 605 (or not) the user’s debit card and sends this to the dATM. The user is then presented with the option of choosing their desired function and in this instance may press “balance” 607, and is prompted to insert or tap 609 their existing dNote against or into the dATM. The dATM then sends 611 dNote data (such as permanent ID and/or OTO account number) to the user’s card processing network which validates (or not) 613 the user’s dNote data. This validation step may comprise performing a lookup to check if the permanent ID and/or OTO account number match (this may be performed by the user’s card processing network and/or the CB/DCA), although it will be understood that in some examples the sending 611 and validation 613 steps may be omitted. If the dNote data is validated, the user’s card processing network sends information to the CB/DCA or their operators requesting the current balance value. This information may include the dNote data. In response the CB/DCA sends 617 the balance to the user’s card processing network, which in turn confirms 619 the balance to the dATM, which in turn displays 621 the balance to the user/dNote holder. In some examples there may be an optional charge that is incurred and charged 623 to the user’s debit card account for the balance check.

Fig. 7 shows the process for returning an existing dNote with a balance still remaining on it, and exchanging it for a new dNote with a new and current balance. The process begins with the user submitting 7101 their debit card at the dATM (for example by inserting their debit card into the dATM). The dATM sends 703 the debit card data to the user’s card processing network. The user’s card processing network then validates (or not) 705 the user’s debit card. The user is then presented with the option of choosing their desired function and in this instance may press 707 “withdraw”. The user may then be presented with the option by the dATM, or be prompted by the dATM, to submit or insert 709 an existing dNote for surrender. The dATM may then send 711 the existing dNote card data to the user’s card processing network which may then validate the dNote card and send 713 existing dNote residual balance payment to the user’s issuing bank as well as sending a validation 715 to the dATM, although it will be understood that the sending 711 , 713 and/or validating 715 steps may be omitted. The user may then be presented by the dATM with the option of selecting the withdrawal amount and the user may enter 717 the withdrawal amount required on a new dNote. The dATM then sends 719 the withdrawal amount to the user’s card processing network which may in turn send a request 721 to the user’s issuing bank asking it to validate that there is enough cash to issue. The user’s issuing bank may then confirm the validated amount by sending 723 this to the dATM as well as sending 725, in parallel, the amount requested to the CB/DCA. In response, the CB/DCA creates a corresponding one-time-only (OTO) bank account and sends this and the amount to the dATM. In response the dATM issues 729 the user with a new dNote linked to the OTO for the amount requested in the withdrawal request.

As noted above, in some examples there will be a “Type B” dATM. The “Type B” dATM may be app-based. Type B dATMs may be designed for users with other mobile devices running an app, and using virtual dNotes on a payment app. These ATMs do not issue new dNotes but focus on reloading existing ones and checking the balance of dNotes. They are accessible to users with mobile devices who wish to reload their dNotes or verify their balance. This may be enabled through an app running on a mobile device. The app may be configured to read a dNote ID adjacent to the mobile device via near-field communication (NFC). The app may be configured to send the dNote ID to the corresponding CB/DCA. A user may then initiate a transfer, via their own personal banking app, to transfer £X digital cash to that dNote adjacent to the iPhone, and/or to a “virtual dNote” in the mobile device’s wallet. The CBDCA may then assign a new one-time-only (OTO) bank account number to be allocated to the dNote ID, at the same time issuing confirmation of that amount of cash to be displayed on the dNote’s optional CVD.

Users may be able to re load either a physical dNote or a “virtual” dNote (i.e. , acting as a payment card on a user’s mobile device) using the app as follows. For example, users may initiate the drawdown and receive process via their personal banking app on their mobile device. This process involves transferring funds to either a corresponding mobile device account for a virtual dNote, or a corresponding mobile device account for an adjacent dNote - for example, an NFC-connected adjacent dNote (referred to as a physical dNote). Payment transactions may be executed within the app (i.e., the user’s personal banking app), either through bank transfers from other accounts or card payments. If these transactions are successfully cleared, the balance is augmented, along with the allocation of a new one-time-only (OTO) bank account, as previously outlined. A return message from the CB/DCA to the mobile device app conveys the OTO number and the balance. This message is then received by the physical dNote, still attached via NFC. When the Current Value Display (CVD) is illuminated (in the app), signifying completion, users can check their virtual dNote balance within the payment app, indicated as "Virtual dNote balance: £x."

In summary, a mobile device user may, via their personal banking app, instruct a transfer to an adjacent physical dNote (or a virtual dNote in the mobile device’s wallet). Payment may be taken from the user’s personal bank account and transferred to the CBDCA. The CBDCA allocates a new OTO account number to the adjacent physical dNote ID in its database. The mobile device in turn sends the signal of its transfer value to the adjacent dNote. It will be understood that an operator may apply any processing arrangement however, the ultimate concept is that a digital cash dATM enables the withdrawal of digital cash, which is issued in the form of a digital payment instrument (dNote) with an optional CVD i.e. , the dNote (with a newly allocated OTO DCA access number or key) be held in a DCA (digital cash account) and not issued in physical polymer cash as todays ATM’s do.

It will be appreciated from the discussion above that the embodiments shown in the Figures are merely exemplary, and include features which may be generalised, removed or replaced as described herein and as set out in the claims. In the context of the present disclosure other examples and variations of the apparatus and methods described herein will be apparent to a person of skill in the art.

Claims

CLAIMS:

1. A dispensing machine for dispensing a digital form of cash, the dispensing machine comprising: a card reader configured to read account information that is stored on an EMV chip or magnetic strip of a user’s bank card; a cassette for holding a plurality of digital payment cards for dispensing to a user; a user interface; a communications interface; and a processor, wherein the processor is configured to: obtain account information from the user’s bank card via the card reader; receive a request via the user interface for the issuance of a digital payment card with a desired sum of money ascribed to the digital payment card; operate the communications interface to communicate with a bank to determine whether the user’s account has sufficient funds to transfer the desired sum of money to a corresponding digital cash bank account for the digital payment card; upon receiving confirmation from the bank that the user’s account does have sufficient funds to transfer the desired sum of money to a digital cash bank account for the digital payment card, communicate with the digital cash bank account to ascribe the funds to the digital payment card; and once the funds have been ascribed to the digital payment card, dispense the digital payment card to the user.

2. The dispensing machine of claim 1 , wherein communicating with the digital payment card to ascribe the funds to the digital payment card comprises communicating with the payment card to update a balance value displayed on a display of the digital payment card.

3. The dispensing machine of claim 1 or 2, wherein communicating with the payment card to ascribe funds to the digital payment card may comprise communicating with an EMV chip on the digital payment card to bind the payment card to a one-time-only bank account created by a central bank.

4. The dispensing machine of any of the previous claims, further comprising a receptacle for receiving used digital payment cards.

5. The dispensing machine of any of the previous claims, wherein the card reader comprises a contactless card reader.

6. The dispensing machine of any of claims 1 to 4, wherein the card reader comprises a chip and pin card reader.

7. The dispensing machine of any of the previous claims wherein the digital payment card is automatically dispensed when the funds have been ascribed to the digital payment card.

8. The dispensing machine of any of the previous claims wherein the user interface comprises at least one of a display and a user input.

9. The dispensing machine of any of the previous claims, further comprising a near field communications interface for communicating with the digital payment card.

10. The dispensing machine of any of the previous claims, wherein upon receiving confirmation from the user’s bank that the user’s account does have sufficient funds to transfer the desired sum of money to the digital payment card, the dispensing machine is configured to send details of the next available digital payment card to a remote bank, before communicating with the digital payment card to ascribe the funds to the digital payment card.

11. The dispensing machine of claim 10 wherein communicating with the digital payment card to ascribe the funds to the digital payment card comprises receiving a one- time-only bank account number from the remote bank and ascribing the one-time-only bank account number to the digital payment card.

12. A system for dispensing a digital form of cash, the system comprising: a near field communications interface for communicating with a digital payment card; a communications interface for communicating with a user’s bank; a user interface; and a processor, wherein the processor is configured to: receive a request via the user interface for the issuance of a digital payment card with a desired sum of money ascribed to the digital payment card; operate the communications interface to communicate with the user’s bank to determine whether the user’s account has sufficient funds to transfer the desired sum of money to the digital payment card; upon receiving confirmation from the user’s bank that the user’s account does have sufficient funds to transfer the desired sum of money to the digital payment card, communicate with the digital payment card to ascribe the funds to the digital payment card.

13. The dispensing machine of claim 12, wherein communicating with the digital payment card to ascribe the funds to the digital payment card comprises communicating with the payment card to update a balance value displayed on a display of the digital payment card.

14. The dispensing machine of claim 12 or 13, wherein communicating with the payment card to ascribe funds to the digital payment card comprises communicating with an EMV® compliant chip on the digital payment card to bind the payment card to a one- time-only bank account created by a central bank.

15. A method of dispensing a digital form of cash, the method comprising: obtaining credentials from an EMV® compliant bank card; sending the credentials from the EMV® compliant bank card to the user’s card processing network; receiving a validation message from the user’s card processing network; receiving a request to withdraw funds from the user, the request including an indication of the value of the funds requested; sending the request including the value of funds requested to the user’s card processing network; receiving a validation message from the user’s card processing network; receiving an indication of a one-time-only bank account to be paired to a digital payment card, along with an indication of the value of funds to be displayed on a display of the digital payment card; issuing the digital payment card to the user.

16. The method of dispensing of claim 15, wherein sending the request including the value of funds requested to the user’s card processing network comprises sending the request including the value of funds and a unique identifier of the digital payment card to the user’s card processing network.

17. The method of dispensing of claim 16, further comprising forwarding the request from the user’s card processing network to a central bank, and wherein the central bank creates a unique one-time-only bank account to be paired to the unique identifier of the digital payment card.

18. The method of dispensing of any of claims 15 to 17 further comprising: obtaining credentials from an existing digital payment card, the credentials comprising at least an ID associated with the digital payment card, and a balance value of the digital payment card; sending the credentials from the existing digital payment card to the user’s card processing network; and receiving a validation of the existing digital payment card from the user’s card processing network.

19. A method of dispensing a digital form of cash, the method comprising: obtaining credentials of a user’s EMV® compliant bank card from a dispensing machine; checking the credentials of the user’s EMV® compliant bank card and sending a validation message to the dispensing machine in response to the check indicating that the credentials are correct; receiving a request to withdraw funds from the user, the request including an indication of the value of the funds requested, and forwarding this request to the user’s issuing bank; receiving a validation message from the user’s issuing bank and forwarding the validation message on to the dispensing machine; receiving an indication of a one-time-only bank account to be paired to a digital payment card, along with an indication of the value of funds to be displayed on a display of the digital payment card and forwarding to the dispensing machine.

20. The method of dispensing of claim 19, wherein: the request to withdraw funds from the user includes an indication of the value of the funds requested and a unique identifier of the digital payment card; and forwarding the request comprises forwarding the request including the value of funds and the unique identifier of the digital payment card to the user’s issuing bank.

21. The method of dispensing of claim 20, further comprising forwarding the request to withdraw funds to a central bank, and wherein the central bank creates a unique one- time-only bank account to be paired to the unique identifier of the digital payment card.

22. The method of any of claims 19 to 21 , further comprising: obtaining credentials of an existing digital payment card from the dispensing machine, the credentials comprising at least an ID associated with the digital payment card, and a balance value of the digital payment card; sending the credentials of the existing digital payment card to the user’s issuing bank; sending a request to validate the withdrawal of funds to the user’s issuing bank; and receiving a validation of the existing digital payment card from the user’s card processing network and forwarding to the dispensing machine

23. A method of checking the balance value of a digital payment card, the method comprising: obtaining credentials from an EMV® compliant bank card; sending the credentials from the EMV® compliant bank card to the user’s card processing network; receiving a validation message from the user’s card processing network; receiving a request to check the balance of a digital payment card from the user, the request including credentials of the digital payment card; sending the request including the digital payment card’s credentials to the user’s card processing network; receiving a validation message from the user’s card processing network; sending the request from the user’s card processing network to a central bank; receiving a balance value from the central bank; and displaying the balance value to the user.

24. The method of claim 23, wherein receiving a request to check the balance of a digital payment card from the user comprises obtaining credentials of the digital payment card.

25. A computer readable non-transitory storage medium comprising a program for a computer configured to cause a processor to perform the method of any of claims 15 to 24.