WO2021105753A1 - Procédé et système de transfert de devise électronique - Google Patents

Procédé et système de transfert de devise électronique Download PDF

Info

Publication number
WO2021105753A1
WO2021105753A1 PCT/IB2019/060224 IB2019060224W WO2021105753A1 WO 2021105753 A1 WO2021105753 A1 WO 2021105753A1 IB 2019060224 W IB2019060224 W IB 2019060224W WO 2021105753 A1 WO2021105753 A1 WO 2021105753A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
user
financial institution
recipient user
recipient
Prior art date
Application number
PCT/IB2019/060224
Other languages
English (en)
Inventor
Donato VADRUCCIO
Original Assignee
Paydo S.P.A.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Paydo S.P.A. filed Critical Paydo S.P.A.
Priority to PCT/IB2019/060224 priority Critical patent/WO2021105753A1/fr
Publication of WO2021105753A1 publication Critical patent/WO2021105753A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes

Definitions

  • the present invention relates to the technical field of computer systems and of communications between computer systems. More in particular, the present invention relates to the technical field of computer systems and of communications between computer systems adapted to transfer money and titles in electronic form between users.
  • the present invention relates to the fields of computer and communication systems. More in particular, a system and methods are provided to facilitate the exchange of electronic money between users by means of computer devices.
  • banker’s checks or bank checks is still very frequent despite the many drawbacks related thereto, some of the main ones of which are: the check, either a bank check or a cashier’s check, is, to date, issued only in paper form and has remained on paper despite the innovations introduced in the banking sector in recent years; it must be produced by the issuing bank and physically delivered to the customer; the customer, in turn, must physically carry the check with him or her in order to be able to issue it to someone.
  • the bank check can be issued post-dated although this is not allowed by law; the cashier’s check is used mainly for notarial transactions because the bank wire is not concurrent with respect to the stipulation of the contract to which it refers.
  • the management of the entire check issuing/paying process is particularly burdensome and risky for the banking system itself.
  • wire transfers generally referred to as bank transfers in Europe
  • bank transfers have the advantage of having no amount limits, allowing international transactions and transactions to anyone with a current account, but have major disadvantages; they are revocable until shortly before being cleared by bank (which may even occur a few days after having ordered the payment), they do not provide an instantaneous outcome (1 -2 working days elapse after they have been cleared by the bank for the recipient to be certain of the transaction) and require the exchange of bank details between recipient and payer. Therefore, a bankwire is not a suitable instrument for transactions in which payment must be certain at the same time as the exchange of an asset (e.g. as is the case of the sale of a used car or a notarial instrument).
  • Instant bank transfers provide an instantaneous outcome once they have been ordered but have amount limits (e.g. €15,000 for SEPA SCT Instant, € 100,000 since July 2020), require the exchange of bank details and both banks involved in the transaction must be members of the banking circuit within which the transfer takes place. Therefore, an instant bank transfer is not suitable for payments over a given threshold and has an inconvenient user experience mainly because of the necessary exchange of bank details and because the recipient is not notified of the performed transaction but must verify it by accessing their account.
  • amount limits e.g. €15,000 for SEPA SCT Instant, € 100,000 since July 2020
  • the ever-increasing number of P2P electronic money transfers allow users to exchange money easily and instantly, but they have two major drawbacks; the first is linked to the amount limit which is kept very low (generally between € 200 and € 300), due to the fact that the amount transferred is credited to the recipient before it is debited to the payer and there is always the risk - assumed by the bank - that the account is not sufficient due to concurrent transactions; the second drawback is related to the need for these transfers to be referred to a closed circuit, both the payer and the recipient must have accounts with the banks which subscribe to the service or must download third-party applications and register for new services in order to complete the transaction.
  • Credit or debit cards whether physical or virtual (such as Google Pay, Apple Pay, Samsung Pay, etc.) are always subject to monthly spending limits (generally between € 1 ,300 and € 1 ,500) which make them unusable for high amount payments, also need a POS device to be able to collect a payment effectively reducing the beneficiaries to business users.
  • monthly spending limits generally between € 1 ,300 and € 1 ,500
  • the first is the possibility to set payment at a future date which is irrevocable. To date, only the bank transfer - or bank wire - allows users to set a payment at a future date but this can be canceled until shortly before the transfer is actually effected, making it, in fact, a useful tool only for the payer as it does not offer any kind of guarantee or certainty to the recipient.
  • the second is that the electronic payment system can be used immediately without needing the users to be provided with dedicated software programs or mobile apps in advance, without the need for the recipient to register to currency transfer services or hold a bank account with the same financial institution where the payer user has an account, and without the need for the payer user to know the recipient user’s bank details.
  • Another feature missing from the electronic payment systems currently available is the possibility to associate customization of the payment itself with the collection step of the payment.
  • the aforesaid customization e.g. through images or videos, may be related to the object of the payment itself, to the paying company or to a particular chosen event.
  • Today’s electronic payment tools allow only a limited object to be associated with the payment but they do not allow the payment to be characterized by the addition of content which can personalize it. This feature could be useful for companies which reimburse their customers (e.g. by sending cash backs as part of marketing campaigns) or for sending gifts related to special occasions and should be available without needing to know the recipient’s bank details.
  • an object of the present invention to introduce a new method and system for transferring electronic money between users which is immune from the aforesaid drawbacks and which is safe and easy to use, thereby contributing to facilitating the progressive replacement of the cash, checks and electronic money payment methods currently in use.
  • Fig. 1 shows a block chart of a preferred implementation of the distributed electronic payment system according to the present description
  • Fig. 2 shows a first diagrammatic flow chart of a preferred embodiment of the method according to the present description, in which the interactions between the described system and the users of the described system are highlighted; and Fig. 3 shows a second diagrammatic flow chart of a preferred embodiment of the method according to the present description, in which the interactions between the described system and the users of the described system are highlighted.
  • the method and system to support the electronic payment described below is structured in a sequence of steps which provide an initial collection of the information related to the payment; the successive sending of the payment by the payer user; the receipt by the recipient user of the payment made by the payer user; the acceptance by the recipient user of the payment received and finally the transfer of the amount which is the object of the transfer from the payer user to the recipient user.
  • the initial payment information can be collected through different channels which must have access to the payer’s current account from which the payment will withdraw the sums to be transferred.
  • the aforesaid channels may be traditional banking channels (home banking, mobile banking, credit or debit cards, either virtualized or not, etc.) or other channels such as fintech platforms which, by taking advantage of the new European open banking regulations dictated by the PSD2 (Payment Service Directive), have access to the current account.
  • the information to be collected through one of the aforesaid channels relates to the following data:
  • the recipient s name and surname
  • the identifier may be a telephone number, an email address, an account number, the tax code or any code which uniquely identifies the recipient within the distributed payment system according to the invention;
  • the payment date which may be the same as or later than the date of creation of the payment itself;
  • a description of the payment which may consist of a free text or a text chosen from a predetermined list;
  • the payment method which may require the immediate blocking of funds to be transferred or not.
  • the data collected through one of the above channels are sent to the system which is the subject of this description.
  • the system may request the blocking of the amounts relating to the payment on the payer’s current account, or this blocking may be done by the recipient at the time of acceptance or on the payment date, if future.
  • the system sends the payment notification - which is irrevocable - to the recipient through the digital channel related to the unique identifier of the recipient.
  • the payment will be sent via an email message; if the identifier is the phone number, the payment will be sent via an SMS text message or via instant messages (Whatsapp, Telegram, in-app notification, etc.); if the identifier is a code which identifies a device of another nature (e.g. a POS), the message will travel on the network to which that device is connected. The recipient will then receive a message containing the details of the payment and instructions to cash it on a device consistent with the transmission channel used (PC, smartphone, POS, etc.).
  • the transmission channel used PC, smartphone, POS, etc.
  • the payment may be received by the recipient in different ways. If the channel receiving the payment can connect directly to the system according to the present invention, the payment can be accepted directly from the channel interface (e.g. through POS, through the bank channel etc.). If the channel cannot connect directly to the system (e.g. as in the case of emails or SMS text messages), the message will contain a link to a web page or an application for portable devices, made available by the system according to the invention, which will allow access to the payment received.
  • the channel interface e.g. through POS, through the bank channel etc.
  • the message will contain a link to a web page or an application for portable devices, made available by the system according to the invention, which will allow access to the payment received.
  • the recipient will have a period of a given number of days configurable by the system which is the object of the invention to be able to accept payment from the set payment date. During such a period of time, the payer may neither cancel nor change the payment. After such a period of time, the payment will be canceled and it will no longer be possible for the recipient to collect it.
  • the payment may be accepted by the recipient in different ways. If the recipient’s unique identifier is already linked to the coordinates of the recipient’s current account within the system according to the invention, then the recipient will only have to accept or refuse the payment. If, on the other hand, the recipient’s unique identifier is not linked to the recipient’s bank details, the recipient must enter these before accepting the payment. The recipient will not have to download any new apps or register for any new services in order to collect the payment received.
  • the recipient may, at any time, associate his or her bank details with his or her unique identifier within the system which is the subject of the invention. In this manner, for subsequent received payments, the bank details will be automatically suggested by the system according to the present description. The entered bank details can still be changed at any time.
  • the portal where it is possible to accept the payment, can be customized both in terms of graphics and content to associate the payment with the event related to the payment itself.
  • the system may display the logo of the campaign and the text which reminds the association of the payment made with the campaign.
  • the money transfer relating to the transfer is made as follows:
  • the system communicates with the payer’s current account, checks availability and, if the account is sufficient, blocks the funds (if not already done so during the step of creating of the payment if the payer chose guaranteed payment) and queues the payment on the chosen system in irreversible manner, so as to protect the recipient.
  • the system will settle the payment according to the methods and timing typical of the underlying payment system (e.g.: one working day in the case of an SCT transfer (SEPA Credit Transfer), within 20 seconds in the case of SCT Instant).
  • All the steps of the payment and the changes to the status of the payment itself are notified in real-time to both the payer and to the recipient through the most appropriate channels with respect to the channel chosen by the payer and used for payment.
  • the last notification sent to the recipient is the one confirming the availability of the sums and the irreversible start of the credit made.
  • the payment transaction can be associated with an unlock code to increase security.
  • a code may be generated by the system which is the object of the present description and communicated by the payer to the recipient on a channel other than the one used for the transmission of the payment, or it may be a code already in the possession of the recipient (customer number, tax code, etc.) and previously shared with the user payer. Such a code, if set by the payer, must be entered by the recipient in order to unlock the payment.
  • the code can also be provided to an independent third party to act as an escrow agent by unlocking the transaction at the appropriate time.
  • the payment at a future date is irrevocable, therefore, after the payment has been sent by the payer to the recipient, the payer is no longer entitled to cancel or modify it. This applies both to payments with immediate payment dates and to payments with future dates. It is the system according to the present invention which guarantees irrevocability, regardless of the chosen payment regulation system (e.g., SEPA SCT, SEPA SCTinst, Wire Transfer), of which the system according to the present description becomes a value-added service. Indeed, the chosen payment regulation system does not see the payment request until it must be effected because the system which is the object of the present invention keeps the payment and communicates it to the regulation system only when the money transfer must be actually effected.
  • the chosen payment regulation system e.g., SEPA SCT, SEPA SCTinst, Wire Transfer
  • the system according to the present invention also allows scheduling irrevocable and recurring future payments at regular intervals within a given time interval and allows providing an instantaneous outcome of the transaction, both to the payer and to the recipient, even when the chosen payment system does not provide such a possibility. This is made possible by the fact that the sums are blocked on the payer’s account when the payment is accepted (either on the payment date if it is accepted earlier, or at the creation of the payment if the guaranteed method is chosen). Even if the payment is settled at a later time (e.g. as with weekend bank transfers), the amount has already been blocked and thus removed from the payer’s availability.
  • the system also allows customizing the recipient’s user experience.
  • the customization can be done in two ways, i.e. by choosing from a predefined, preset list or by implementing it ad hoc.
  • the customization by choosing one of the available pre-prepared models provides a fixed structure of the payment acceptance page and the possibility of modifying some of its contents.
  • the customization may be chosen by the payer directly from the channel with which the payer accesses the system functionality.
  • the customization may also be defined by the payer on payment collection page structure level. In this case, the structure is defined and implemented by means of an ad hoc project aimed at modifying the collection section accessed by the payer, modifying its graphics and contents also by means of multimedia elements, such as images or videos.
  • the present description illustrates an electronic payment service from current account to current account free of the limitations of current systems.
  • the method and the system according to the present description can, therefore, be used by any user in possession of a bank account and are adapted to settle payments from current account to current account.
  • the recipient user of the electronic payment made through the system according to the present description is put in a position to collect payment without having to register to any new service or download new applications (e.g. as is the case of all P2P payment services). This feature is also useful for the payer user who will not have to worry about whether the recipient is a subscriber to some particular service but will only have the service according to the invention integrated in one of the channels which has access to his or her current account.
  • the distributed electronic payment system 103 is configured to communicate, by means of an interconnection network 8, e.g. the Internet, with a payer user 100 provided with a communication device 9, with a recipient user 101 provided with a communication device 10, and with a financial institution 102 which has access to the current account of the payer user 100.
  • the financial institution 102 may be a bank, an electronic money institution, a payment institution, a fintech and, in general, any organization which has access to the current account of the payer user 100.
  • the distributed electronic payment system 103 according to the present description will be integrated into the channels of the financial institution 102 so as to make it available to the payer users 100 who hold a current account with said financial institution 102.
  • the payer user accesses his or her current account through the channels provided by the financial institution 102 connected to the current account.
  • These channels may be home banking, mobile banking, corporate banking, or even apps for smartphones or smartwatches, or any other channel on which the financial institution 102 has integrated its services and made them available to users.
  • the communication device 9 of the payer user 100 may be a personal computer, a smartwatch, a smartphone or any other device configured to reach the aforementioned channels provided by the financial institution 102 with access to the current account of the payer user 100.
  • the recipient user 101 will be put in a position to collect the payment sent by the payer user 100 by means of a second communication device 10 configured to communicate, by means of said interconnection network 8, with the distributed electronic payment system 103 according to the present description.
  • the communication device 10 of the recipient user 101 may be a personal computer, a smartwatch, a smartphone and also a POS payment terminal, a cash register, etc.
  • a preferred implementation of the system 103 comprises a remote server 3 configured to communicate with at least one server 102a of at least one bank or financial institution 102.
  • Said remote server 3 is connected to a first database 1 containing the general transaction information which must be shared between the financial institutions which manage the current accounts of payer and recipient and is configured to manage payment transactions centrally and to communicate and exchange data with recipient users 101 by means of said interconnection network 8.
  • the remote server 3 may be associated with cryptographic communication protocols or security layers 6 which allow secure communication over said interconnection network 8, e.g. a TCP/IP type network, such as the Internet, providing authentication, data integrity and encryption.
  • said remote server 3 is further connected to a second database 2 containing confidential information for the financial institution, i.e. information which must not be shared between financial institutions which manage the current accounts of payer and recipient users.
  • said remote server 3 comprises a first server 4 and a second server 5.
  • the remote server 4 is connected to a first database 1 containing the general transaction information which must be shared between the financial institutions which manage the current accounts of payer and recipient and is configured to manage payment transactions centrally and to communicate and exchange data with the recipient users 101 by means of said interconnection network 8.
  • the second server 5 is connected to the second database 2 containing confidential information for the financial institution, i.e. information which must not be shared between financial institutions which manage the current accounts of payer and recipient users.
  • the second server 5 may preferably be associated with cryptographic communication protocols or security layers 6 which allow secure communication over said interconnection network 8, e.g. a TCP/IP type network, such as the Internet, providing authentication, data integrity and encryption.
  • Said security layers 6 may be built using state-of-the-art techniques and comprise, for example, at least one firewall and one network balancer associated with said firewall.
  • the electronic currency according to the present invention is transferred in three steps: generating and sending the payment request by the payer user 100 of a sum drawn from his or her bank account, receiving and accepting the payment by the recipient user 101 , transferring money by the bank of the payer user 100. (Generating and sending the request).
  • the payment method provides a payer user 100 to access, from his or her personal computer, tablet, smartwatch or smartphone, the Internet Banking (IB) or Mobile Banking (MB) application of his or her bank and choose a section relating to the new method of payment according to the present invention.
  • the payer user 100 accesses 201 , through his or her communication device 9, the server 102a on which the channel of the financial institution 102 which has access to the current account from which the payer 100 wants to send money is hosted.
  • This access is performed according to the usual procedures of the concerned financial institution, using the requirements and user experience (UX) typical of the chosen channel (e.g., the IB or MB application used can now ask the payer user 100, at this point, for the OTP or PWD required for the ordering operations and a confirmation to make the transfer).
  • UX requirements and user experience
  • the payer user 100 enters 202 the information relating to a promise of payment (e.g. the recipient user’s details 101 , the amount to be transferred, the date of the transfer, a possible security PIN, the description and payment method, which may be standard, instant, repeated, or otherwise, etc.) which are sent to the financial institution 102.
  • a promise of payment e.g. the recipient user’s details 101 , the amount to be transferred, the date of the transfer, a possible security PIN, the description and payment method, which may be standard, instant, repeated, or otherwise, etc.
  • the server 102a of the financial institution 102 sends 203 the aforesaid payment information to the server 3 (or the second server 5) of the system 103.
  • the server 3 (or the second server 5) of the system 103 creates 204 payment (e.g. by creating an identifier within the system by entering the payment record with all the information in said database 2) and sends 205 a payment notification prepared to the recipient user 101 , through a channel consistent with the unique ID of the recipient used by the payer user 100 (e.g. email in the case of email address, SMS or instant message in the case of phone number, etc.).
  • Said notification preferably comprises the information needed to proceed with the collection of the payment (a web link in the case of email or SMS, or the possibility of accepting directly the payment for cash or POS devices of the recipient user 101 ).
  • the server 3 or the second server 5 of the system 103 sends 206 the respective request to financial institution 102, which will block 207 the money for the transaction, as requested.
  • the notification to the recipient user 101 is sent only after confirmation of the blocking of funds by the bank. (Reception and acceptance of payment).
  • the recipient user 101 receives 208 the payment notification. If the notification contains the link, the recipient user 101 must follow the link which will direct him to a web page for the collection contained on said a first server 3 of the system 103 according to the present invention. If, on the other hand, the recipient receives the notification on a channel which is directly integrated in the system in accordance with the present description, he or she may continue the collection operations directly from that channel (e.g., in the case of POS, the payment can be accepted by the device by pressing a button on the user interface of the POS). Again, in this case, the interaction takes place with said first server 3 but the user interface to perform the collection is hosted elsewhere.
  • the recipient user 101 can confirm 209 his or her bank details if they have already been saved (e.g., the IBAN code for the transfer credit) or can enter new ones. If required by the payment method chosen by the payer, the recipient must also enter 210 an unlock code for the transaction (e.g., the PIN set during the creation of the payment which can be associated with the transaction and which can be represented by the tax code, the customer code, the contract code or any other code associated with the transaction). At this point, the recipient user 101 may either accept or refuse the payment 211 . The refused payment will cease to be available. (Making the payment).
  • an unlock code for the transaction e.g., the PIN set during the creation of the payment which can be associated with the transaction and which can be represented by the tax code, the customer code, the contract code or any other code associated with the transaction.
  • the recipient user 101 may either accept or refuse the payment 211 . The refused payment will cease to be available. (Making the payment).
  • the system 103 collects the data entered from the recipient user 101 to complete the requested payment. If the date when the payment is accepted by the recipient user 101 is the same as or later than the date set by the payer user for payment, the request to send the money to the financial institution 102 hosting the current account of the payer user 100 is sent 212; otherwise, if the date on which the requested payment is accepted is earlier than the payment date, the system 103 keeps 213 the requested payment pending until the payment date indicated by the payer user 100. Finally, on the payment date, the request to send the money is sent 212 to the financial institution 102 hosting the current account of the payer user 100.
  • the financial institution 102 checks 214 the balance of the current account of the payer user 100 from which to charge and, if it is sufficient, blocks 215 the funds necessary for the transfer (if it did not already do so) and irreversibly queues 216 to the payment by sending 217 notification to the system 103. If the current account is not sufficient, the financial institution 102 sends 217 a notification of a negative outcome of the transaction to the system 103.
  • the system 103 sends 218 a notification to the payer user 100 and to the recipient user 101 notifying them that the irreversible payment is in progress.
  • the system 103 will instead notify 218 the failed payment to the payer user 100 and the recipient user 101 .
  • the payment notification - which is irrevocable - is sent to the recipient through the digital channel related to the unique identifier of the recipient him or herself.
  • the payment will be sent via an email message; if the identifier is the phone number, the payment will be sent via an SMS text message or via instant messages (Whatsapp, Telegram, in-app notification, etc.); if the identifier is a code which identifies a device of another nature (e.g. a POS), the message will travel on the network to which that device is connected. The recipient will then receive a message containing the details of the payment and instructions to cash it on a device consistent with the transmission channel used (PC, smartphone, POS, etc.).
  • the transmission channel used PC, smartphone, POS, etc.
  • the financial institution 102 transfers 219 the money to the recipient user’s current account 101 using the chosen payment control system.
  • the payment shall be made for a defined period of time from the payment date specified by the payer. If the recipient user 101 does not accept or refuses the payment by that date, the payment will expire and it will no longer be possible to complete it.
  • an embodiment or “a preferred embodiment” means that a particular structure or feature or a characteristic element described in relation to an embodiment is comprised in at least one embodiment of the described object. Therefore, the presence of the expression “in an embodiment” or “in a preferred embodiment” or “in the embodiment” or “in the preferred embodiment” in various points of the description does not necessarily refer to the same embodiment. Furthermore, the characteristic elements, structures of particular features may be combined in any manner suited to one more or embodiments.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Cash Registers Or Receiving Machines (AREA)

Abstract

Le système et le procédé décrits permettent de transférer des titres sous forme électronique entre un utilisateur payeur et un utilisateur destinataire, pourvus chacun un dispositif de communication conçu pour échanger des données sur un réseau d'interconnexion de données, tel qu'Internet. Le transfert de titres sous forme électronique est effectué suite à l'échange de messages avant le transfert des titres, messages qui sont dûments approuvés par les utilisateurs impliqués avant le transfert. En outre, le transfert est irrévocable et ne nécessite pas que l'utilisateur destinataire télécharge des programmes logiciels ou des applications mobiles, effectue des inscriptions à des services de transfert de devise ou ait un compte courant avec la même institution financière où l'utilisateur payeur est titulaire d'un compte courant.
PCT/IB2019/060224 2019-11-27 2019-11-27 Procédé et système de transfert de devise électronique WO2021105753A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/IB2019/060224 WO2021105753A1 (fr) 2019-11-27 2019-11-27 Procédé et système de transfert de devise électronique

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IB2019/060224 WO2021105753A1 (fr) 2019-11-27 2019-11-27 Procédé et système de transfert de devise électronique

Publications (1)

Publication Number Publication Date
WO2021105753A1 true WO2021105753A1 (fr) 2021-06-03

Family

ID=69143618

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2019/060224 WO2021105753A1 (fr) 2019-11-27 2019-11-27 Procédé et système de transfert de devise électronique

Country Status (1)

Country Link
WO (1) WO2021105753A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130060708A1 (en) * 2011-09-06 2013-03-07 Rawllin International Inc. User verification for electronic money transfers
US20140279446A1 (en) * 2013-03-15 2014-09-18 Square, Inc. Transferring money using email
US20190295052A1 (en) * 2012-03-07 2019-09-26 Early Warning Services, Llc System and method for transferring funds

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130060708A1 (en) * 2011-09-06 2013-03-07 Rawllin International Inc. User verification for electronic money transfers
US20190295052A1 (en) * 2012-03-07 2019-09-26 Early Warning Services, Llc System and method for transferring funds
US20140279446A1 (en) * 2013-03-15 2014-09-18 Square, Inc. Transferring money using email

Similar Documents

Publication Publication Date Title
US10937031B2 (en) System and method for local data conversion
CN110612546B (zh) 用于数字资产账户管理的方法和装置
JP6294398B2 (ja) エイリアスを使用したモバイル・ペイメントのシステム及び方法
US7757945B2 (en) Method for electronic payment
CN109313762B (zh) 用于表征预存资金支付的数据集的安全生成和处理的系统、方法和设备
US20160132884A1 (en) Real-time payments through financial institution
US20130006848A1 (en) Method of virtual transaction using mobile electronic devices or fixed electronic devices or a combination of both, for global commercial or noncommercial purposes
US20090319425A1 (en) Mobile Person-to-Person Payment System
US20080162348A1 (en) Electronic-Purse Transaction Method and System
US20110320347A1 (en) Mobile Networked Payment System
US20140046788A1 (en) Payment method and system
US20080270246A1 (en) Global electronic payment system
US20200051060A1 (en) Automated digital method and system of providing or sharing access
KR20010110740A (ko) 개인간, 개인과 사업체간, 사업체와 개인간 그리고사업체간 금융 거래 시스템
CN101454794A (zh) 移动的个人之间支付系统
WO2009152184A1 (fr) Système de paiement pour mobiles
MX2008012503A (es) Sistema movil de pago de persona a persona.
CN101990770A (zh) 移动电话支付业务系统中的虚拟支付账户数据
US20120330825A1 (en) Processing a purchase transaction based on different payment methods
KR20130043682A (ko) 송금 및/또는 결제를 위한 방법 및 시스템, 장치-판독가능한 매체
CN112204597A (zh) 区块链支付系统
JP2017505960A (ja) 送金システム及び方法
WO2021105753A1 (fr) Procédé et système de transfert de devise électronique
WO2004019151A2 (fr) Procede et systeme pour transferer de l'argent par un reseau de telecommunication
KR20020078319A (ko) 인스턴트 메신저를 이용한 전자지갑 서비스 제공 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19832726

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19832726

Country of ref document: EP

Kind code of ref document: A1