WO2017011596A1 - Systems and methods for facilitating a secure transaction at a non-financial institution system - Google Patents

Systems and methods for facilitating a secure transaction at a non-financial institution system Download PDF

Info

Publication number
WO2017011596A1
WO2017011596A1 PCT/US2016/042163 US2016042163W WO2017011596A1 WO 2017011596 A1 WO2017011596 A1 WO 2017011596A1 US 2016042163 W US2016042163 W US 2016042163W WO 2017011596 A1 WO2017011596 A1 WO 2017011596A1
Authority
WO
WIPO (PCT)
Prior art keywords
sender
recipient
financial institution
identifier
account
Prior art date
Application number
PCT/US2016/042163
Other languages
English (en)
French (fr)
Inventor
III Clinton GILLIAM
Melissa Lowry
Michael Joseph Kennedy
Sergei Lilichenko
Original Assignee
Clearxchange, Llc
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 Clearxchange, Llc filed Critical Clearxchange, Llc
Priority to EP16825143.7A priority Critical patent/EP3323095A4/en
Priority to AU2016294499A priority patent/AU2016294499A1/en
Priority to JP2018521480A priority patent/JP6727299B2/ja
Priority to CN201680052672.4A priority patent/CN108027921B/zh
Priority to CA2992457A priority patent/CA2992457C/en
Priority to KR1020187004378A priority patent/KR102634772B1/ko
Publication of WO2017011596A1 publication Critical patent/WO2017011596A1/en

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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/023—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] the neutral party being a clearing house
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • 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/386—Payment protocols; Details thereof using messaging services or messaging apps
    • 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance

Definitions

  • the technical field relates to systems and methods for transferring funds over an electronic money transfer network, and more particularly to systems and methods for securely transferring funds over an electronic money transfer network to individuals who have access to a physical payment terminal or online payment processes maintained by an entity other than a financial institution.
  • existing systems of transferring money may not make funds available to people who want to send or receive money at a physical payment terminal of a retail store or other non-financial institution that is not a financial institution.
  • Existing systems of transferring money may not make funds available to people who want to send or receive money using online payment processes of non- financial institutions.
  • Debit transfer systems and other systems of transferring money to people at retail establishments and/or retail websites may be cost-prohibitive and/or may not facilitate transfers of money between people.
  • Many existing systems of transferring money to individuals may not make fund available soon after a request to transfer funds has been made (e.g., substantially in "real-time"). As a result, it has often proven difficult to cost-effectively transfer money over electronic money transfer networks to individuals, particularly those individuals who lack access to the payment systems of financial institutions.
  • An example method may include receiving transaction data related to a fund transfer, the transaction data specifying a transfer amount of the fund transfer, a sender public identifier to identify a sender of the fund transfer, a recipient public identifier to identify a recipient of the fund transfer, a financial institution identifier for a sender financial institution, a financial institution identifier for a recipient financial institution, and a tokenized financial instrument of the sender, determining, using the financial institution identifier for the sender financial institution, the sender financial institution, the sender financial institution being a member of a payment network, providing to the sender financial institution the tokenized financial instrument of the sender to enable the sender financial institution to de-tokenize the tokenized financial instrument of the sender and identify an account of the sender financial institution associated with
  • ACH Automatic Clearing House
  • the method further comprises validating that the sender has authorization to use the public identifier to perform the fund transfer.
  • the method may further comprises receiving a tokenized financial instrument of the recipient and a recipient FI identifier associated with the recipient financial institution, determining, using the recipient FI identifier, the recipient financial institution, the recipient financial institution being a member of the payment network, providing to the recipient financial institution the tokenized financial instrument of the recipient to enable the recipient financial institution to de-tokenize the tokenized financial instrument of the recipient and identify an account of the recipient financial institution associated with the recipient, and receiving, from the recipient financial institution, the recipient private identifier generated by the recipient financial institution, the recipient financial institution generating the recipient private identifier upon confirming the account of the recipient financial institution associated with the sender.
  • the method may further comprise receiving the transfer amount of the fund transfer, the sender public identifier to identify the sender of the fund transfer, the recipient public identifier to identify the recipient of the fund transfer, the financial institution identifier for the sender financial institution, the financial institution identifier for the recipient financial institution, and the tokenized financial instrument of the sender from an first online reseller of goods.
  • the first online reseller of goods may tokenize a financial instrument of the sender to create the tokenized financial instrument of the sender.
  • the financial instrument may be issued by the sender financial institution.
  • the method may further comprise receiving a tokenized financial instrument of the recipient from a second online reseller of goods different than the first online reseller of goods.
  • the second online reseller of goods may tokenize a financial instrument of the recipient to create the tokenized financial instrument of the recipient.
  • the recipient financial institution may transfer funds to the account associated with the recipient before the recipient financial institution receives the ACH message.
  • the method may further comprise providing a notification a request to a sender system requesting if the sender will accept the fund transfer from the sender.
  • An example system comprises one or more processors and a memory coupled to the one or more processors.
  • the memory may be configured to instruct the one or more processors to perform a method.
  • the method may comprise receiving transaction data related to a fund transfer, the transaction data specifying a transfer amount of the fund transfer, a sender public identifier to identify a sender of the fund transfer, a recipient public identifier to identify a recipient of the fund transfer, a financial institution identifier for a sender financial institution, a financial institution identifier for a recipient financial institution, and a tokenized financial instrument of the sender, determining, using the financial institution identifier for the sender financial institution, the sender financial institution, the sender financial institution being a member of a payment network, providing to the sender financial institution the tokenized financial instrument of the sender to enable the sender financial institution to de- tokenize the tokenized financial instrument of the sender and identify an account of the sender financial institution associated with the sender, receiving, from the sender financial institution, a sender
  • FIG. 1 depicts a schematic diagram of a funds transfer system in which a sender and a recipient use different banking institutions according to an example implementation.
  • FIG. 2 depicts a schematic diagram of token management logic that may manage tokens for fund transfer requests according to an example implementation.
  • FIG. 3B depicts a process in which a fund transfer request results in the funds being received by a registered or unregistered recipient according to an example
  • FIG. 4 depicts a screen shot of a web page that may be presented to a user to configure user preferences and manage connections with other users.
  • FIG. 5 depicts a screen shot of a web page that may be presented to a user to configure notification settings.
  • FIG. 6 depicts a screen shot of a web page that may be presented to a user to send money to a recipient.
  • FIG. 7 depicts a screen shot of a web page that may be presented to an out-of- network user when an out-of-network user is sent a payment.
  • FIG. 8 depicts a schematic diagram of a funds transfer system in which a sender and a recipient use different banking institutions according to an example implementation.
  • FIG. 9 depicts a flow diagram illustrating an example process for facilitating transfer of funds to an out-of-network recipient according to an example implementation.
  • FIG. 10 depicts a flow diagram illustrating an example process for facilitating transfer of funds from an out-of-network sender to an in-network recipient according to an example implementation.
  • FIG. 11 depicts a flow diagram illustrating an example process for facilitating expedited transfer of funds from an in-network sender to an in-network recipient according to an example implementation.
  • FIG. 12 depicts a diagram of a funds transfer system for securely transferring funds from a sender non-financial institution system to a recipient non-financial institution system, according to some implementations.
  • FIG. 13 depicts a diagram of transfer logic, according to some implementations.
  • FIG. 14 depicts a diagram of registration logic, according to some embodiments.
  • FIG. 15 depicts a diagram of a data flow for securely transferring funds from a sender to a recipient in a funds transfer system, according to some implementations.
  • FIG. 16A depicts a diagram of a flowchart of a method for securely transferring funds from a sender to a recipient in a funds transfer system, according to some
  • FIG. 17 depicts a diagram of a data flow for securely transferring funds from a sender to an unregistered recipient in a funds transfer system, according to some
  • FIG. 18A depicts a diagram of a flowchart of a method for securely transferring funds from a sender to an unregistered recipient in a funds transfer system, according to some implementations .
  • FIG. 18B depicts a diagram of a flowchart of a method for securely transferring funds from a sender to an unregistered recipient in a funds transfer system, according to some implementations .
  • FIG. 19 depicts a diagram of a data flow for registering a participant in a funds transfer system, according to some implementations.
  • FIG. 20 depicts a diagram of a flowchart of a method for registering a participant in a funds transfer system, according to some implementations.
  • FIG. 21 depicts an example of a digital device, according to some embodiments.
  • a funds transfer system 100 that implements a payment network, or a "funds transfer payment network,” is shown.
  • the funds transfer system 100 may be utilized by senders to send funds to recipients and by recipients to receive the funds.
  • the funds transfer system 100 may facilitate the transfer of funds from senders to receivers (e.g., recipients) without either party disclosing any financial account information to each other.
  • the senders and recipients may be individuals or business entities.
  • the sender uses a bank account as the source of funds.
  • the sender may use credit cards, debit cards, business credit cards or check cards as the source of funds.
  • the funds transfer system 100 may be used for both intrabank transfers (i.e., transfers in which the sender and the recipient both have accounts at the same bank and the funds are transferred between the accounts within the same bank) and interbank transfers (i.e., transfers in which the sender and the recipient have accounts at different banks and the funds are transferred between the accounts at different banks).
  • intrabank transfers i.e., transfers in which the sender and the recipient both have accounts at the same bank and the funds are transferred between the accounts within the same bank
  • interbank transfers i.e., transfers in which the sender and the recipient have accounts at different banks and the funds are transferred between the accounts at different banks.
  • the funds transfer system 100 may include, among other systems, a sender computer system 110, a bank computer system 120, a recipient computer system 130, a bank computer system 150, a payment service computer system 160, and an automated clearing house computer system 170.
  • a network 140 may include one or more of the Internet, Cellular network, Wi-Fi, Wi- Max, a proprietary banking network, and so on.
  • the sender performs a funds transfer from an account maintained by the bank computer system 120 and the receiver receives the funds using an account maintained by the bank computer system 150.
  • the computer system 120 is sometimes referred to herein as the sender bank computer system and the computer system 150 is sometimes referred to herein as the receiver bank computer system.
  • the computer system 120 may operate in different capacities in the context of different fund transfer transactions.
  • the examples provided herein are primarily in the context of a sender requesting a funds transfer to a recipient, it will also be appreciated that a recipient may request a funds transfer from a sender.
  • the sender computer system 110 may comprise network interface logic 112, a display device 114, an input device 116, and client application 118.
  • Network interface logic 112 may include, for example, program logic that connects the sender computer system 110 to the network 140.
  • the sender computer system 110 may receive and display screens on the display device 114 including account information, transaction instructions, and so on. In an example implementation, such screens may be used to request a username and password information. Such screens may also be used to prompt the user to provide information regarding the amount of the funds and the identity of the merchant or individual that is to receive the funds.
  • the bank computer system 120 is operated by a bank institution that maintains accounts held by customers, such as demand deposit accounts, credit card accounts, home mortgage loans, student loans, and so on.
  • the bank computer system 120 may, for example, comprise one or more servers each with one or more processors configured to execute instructions stored in memory, send and receive data stored in memory, and perform other operations to implement the operations described herein associated with logic or processes shown in FIGS. 1-7.
  • the information directory 128 may be used when an identifier other than a bank account/routing number is used (e.g. an e-mail address, phone number, Universal Payment Identification Code (UPIC), randomly generated number, and so on) to identify a recipient of a funds transfer.
  • the information directory 128 may be a database that is maintained to allow the financial institution to convert/correlate the recipient's cell phone number (or e-mail address, or other identifier) to a bank account number/routing number of the recipient's bank account. This arrangement allows the sender to uniquely identify the recipient (e.g., with an e- mail address or other identifier), without necessarily having private/personal information regarding the recipient (i.e., the recipient's bank account/routing number).
  • UPIC Universal Payment Identification Code
  • the private identifier is known by the information directory 128, it need not be known by the user with whom it is associated or by other users. However, it may be known by banks and other entities that are members of the funds transfer payment network.
  • the public identifier(s) e.g., phone numbers, e- mail addresses, and so on
  • the private identifier e.g., database UID
  • other information may also be stored in the database entry, such as account information (account numbers, routing numbers, etc.) for accounts held by the user at the bank and user preferences. At least some of this information may be populated automatically, e.g., if the user registers for the funds transfer system 100 during a secure on line banking session on the bank computer system 120.
  • the database entry for each user may also store a registry of other users connected to that user. That is, for each user, a registry may be stored that includes a listing of each other user with whom the user has an established connection. Such connection may be established, for example, the first time that the user sends or receives funds from the other user. A connection may also be established by way of a user interface that permits a user to add connections with other users through a lookup service in the information directory 128 and/or another information directory. An example of such a user interface is discussed below in connection with FIG. 4.
  • the users may include not only users that are registered in the funds transfer payment network, but also other affiliated payment networks, as discussed in greater detail below.
  • additional information may be stored, such as their unique ID and/or other information.
  • the information for the other users may be stored in separate database entries in the information directory 128.
  • a plurality of information directories may exist, each directory maintained by a different institution or entity.
  • users that maintain accounts at the bank associated with bank computer system 120 may register through bank computer system 120
  • users that maintain accounts at the bank associated with bank computer system 150 may register through bank computer system 150, and so on for other users that maintain accounts at other entities.
  • Such entities may also include non-bank entities (e.g., payment processing companies, credit agencies, credit card network providers, and so on), and users may also register through such non-bank entities.
  • additional identifiers may also be used.
  • additional identifiers may be handled with varying levels of security.
  • variations of existing public identifiers may be used to implement special purpose public tokens, public tokens with customized functionality, and so on, as discussed in greater detail below.
  • the token management logic 129 manages tokens.
  • the token management logic 129 may be configured to register tokens, authenticate tokens, generate tokens and so on.
  • the token management logic 129 may also facilitate identification of the recipient when a token is not recognized.
  • the token management logic 129 may also be used to customize attributes of tokens, such that particular accounts are used, particular methods of notification are used, and so on.
  • the token management logic 129 is discussed in greater detail below in connection with FIG. 2.
  • the recipient computer system 130 may be configured in generally the same manner as the other computer systems described herein.
  • the computer system 130 may be a mobile device, such as a cellular phone, smart phone, mobile handheld wireless e-mail device, personal digital assistant, portable gaming device, a desktop computer or other suitable device.
  • the computer system 130 may also comprise one or more servers each with one or more processors configured to execute instructions stored in memory. For example, such an arrangement may be utilized if the recipient is a merchant or other business.
  • the recipient computer system 130 may include point of sale devices (e.g., cash register systems) that are equipped to electronically obtain public token information from customers.
  • the cash register systems may be equipped with a near field communication (NFC) reader device that is capable of reading a public token (e.g., cell phone number) from an NFC equipped cell phone.
  • NFC near field communication
  • the cell phone may include an application that is configured to generate a bar code or other image on a display screen that contains the public token
  • the cash register system may be equipped with a bar code reader configured to read the bar code.
  • the recipient computer system 130 may then request payment from the sender via the funds transfer system 100 using the public token obtained at the point of sale.
  • the recipient bank computer system 150 may be configured in a similar manner as the sender bank computer system 120.
  • the bank computer system 150 comprises network interface logic 152, account processing logic 154, account database 156, and information directory 158 corresponding to the network interface logic 122, account processing logic 124, account database 126 and information directory 128 of the bank computer system 120.
  • the payment service computer system 160 may be associated with a payment service that is configured to facilitate interbank fund transfers, e.g., a payment service provided by a non-bank entity as previously mentioned.
  • the payment service may, for example, be an entity that is formed as a joint venture between banks and/or other entities that send and receive funds using the funds transfer system 100.
  • the payment service may be a third party vendor.
  • the payment service may be a web portal provided for an online community of individuals where such individuals obtain user names/login IDs or otherwise become registered members. The individuals may, for example, use the web portal to interact with each other and/or to interact with a service provided by the online community. Examples of online communities include MSN®, iPhone® users,
  • the payment service may, for example, be an additional service that is offered by the web portal to the members of the online community.
  • the payment service may be provided by one of the banks, i.e., such that the bank performs both the operations described herein as being performed by the bank computer system 120/150 and the operations described herein as being performed by the payment service computer system 160.
  • the banks associated with computer systems 120 and 150 are assumed to be "member banks” That is, the banks associated with computer systems 120 and 150 are assumed to follow established protocols for transferring funds using the funds transfer system 100.
  • the member banks may include at least the banks that are part owners of the joint venture, as well as potentially other banks. While two member banks are shown in FIG. 1, it will be appreciated that there may be additional member banks. Additionally, as previously indicated, non-bank entities may also be members.
  • the payment service may also be used by senders and recipients that have bank accounts at non-member banks, for example, by permitting such users to register directly with the payment service computer system 160. Hence, users do not need to be customers of any particular bank in order to be able to use the funds transfer system 100.
  • the payment service computer system 160 may, for example, comprise one or more servers each with one or more processors configured to execute instructions stored in memory, send and receive data stored in memory, and perform other operations to implement the operations described herein associated with logic or processes shown in FIGS. 1-6.
  • the payment service computer system 160 includes network interface logic 162 and an information directory 168.
  • the payment service computer system 160 may include account processing logic and an account database in the same or similar manner to the account processing logic 124, 155 and the account databases 126, 156.
  • the network interface logic 162 may include user interface program logic configured to generate and present web pages to users accessing the payment service computer system 160 over the network 140.
  • the information directory 168 may be used when an identifier other than a bank account/routing number is used (e.g. an e-mail address, phone number, Universal Payment Identification Code (UPIC), randomly generated number, and so on).
  • the information directory 168 is a database that is maintained to allow the payment service to convert/correlate the recipient's cell phone number (or e-mail address, or other token) to a bank account number/routing number of the recipient's bank account for users that registered through the payment computer service system 160. This arrangement allows the sender to uniquely identify the recipient (e.g., with an e-mail address or other identifier), without necessarily having private/personal information regarding the recipient (i.e., the recipient's bank account/routing number).
  • UPIC Universal Payment Identification Code
  • Users including senders and recipients may register their information with the information directory 168 in advance, e.g., where such users do not bank or have accounts with any of the other member entities.
  • the payment service computer system 160 may be configured such that users that only wish to send funds may do so without registering.
  • the payment service computer service system 160 may be configured to generate web pages that receive credit card information from a sender to complete a transaction each time a sender wishes to send funds, without requiring that the sender ever register with the payment service computer service system 160.
  • the information that is stored in the information directory 168 may vary depending on the implementation, including the extent to which information is also stored in the information directories 128 and 158.
  • information may be stored in both the information directory 128 and the information directory 158.
  • the information directory 128 may store a complete identification of the user's bank accounts and other information collected during registration.
  • the information directory 168 may store a reduced amount of information, such as the registered public token(s), the financial institution with it is associated, and the private token (e.g., unique ID) associated with each token.
  • More detailed bank account number/routing number, or other sensitive information need not be stored at the information directory 168.
  • such information may be stored entirely in the information directories 128, 158 maintained by individual member banks.
  • the extent to which transaction details are tracked and maintained in the account processing logic 124, 154 as compared to the extent to which transaction details are tracked and maintained by the payment service computer system 160 may vary depending on the implementation.
  • the Automatic Clearing House (ACH) system 170 is used to transmit funds to and from bank accounts of the senders and recipients.
  • the ACH Network is a nationwide batch oriented electronic funds transfer system which provides for interbank clearing of electronic payments for participating depository financial institutions.
  • An ACH entry may start with an account holder (known as the Receiver in ACH terminology) authorizing an Originator (e.g., a person or a company) to issue ACH debit or credit to an account.
  • the Originator e.g., a person or a company
  • the Originator must receive authorization from the Receiver.
  • no financial institution may issue an ACH transaction (whether it is debit or credit) towards an account without prior authorization from the Receiver.
  • the Originator then creates an ACH entry to be given to an Originating Depository Financial Institution (ODFI), which may be any financial institution that does ACH origination.
  • ODFI Originating Depository Financial Institution
  • This ACH entry is then sent to an ACH Operator (i.e., central clearing facilities through which financial institutions transmit or receive ACH entries, e.g., the Federal Reserve or the Electronic Payments Network) and is passed on to the Receiving Depository Financial Institution (RDFI), where the Receiver's account is issued either a credit or debit, depending on the ACH transaction.
  • the RDFI may, however, reject the ACH transaction and return it to the ODFI with the appropriate reason, such as that there were insufficient funds in the account or that the account holder indicated that the transaction was unauthorized.
  • An RDFI has a prescribed amount of time in which to perform returns (e.g., two to sixty days from the receipt of the ACH transaction).
  • An ODFI receiving a return of an ACH entry may re-present the ACH entry two more times, or up to three total times, for settlement. Again, the RDFI may reject the transaction, after which the ODFI may no longer represent the transaction via ACH.
  • ACH system is one in use currently, the implementations of the current invention will continue to function similarly even if some methods and steps in the ACH system are modified.
  • the sponsor identification logic 182 may be configured to identify a sponsor of a token. For example, if the sender uses a token to identify a recipient that is unrecognized at the information directory 128 of the sender bank computer system 120 (i.e., because the recipient is not a customer of the sender bank), the sponsor identification logic 182 may be configured to receive the token from the sender bank computer system 120 and access the information directory 168 to provide an identification of the unique ID and financial institution associated with that token.
  • the extent to which the bank computer systems 120, 150 have sponsor identification logic that operates in the same manner as the sponsor identification logic 182 may depend, in part, on the extent to which the information is stored in the information directory 168 as compared to the extent to which information is also stored in the information directories 128 and 158. In various implementations, greater or lesser degrees of reliance may be placed on the information directory 168 to perform user identification functions in a centralized fashion in connection with the transfer of funds between entities. Herein, for sake providing an example, it is assumed that the information directory 168 is used to perform user identification functions in a centralized fashion in connection with the transfer of funds between entities. In such implementations, it may be possible to avoid replicating all the functions of the sponsor identification logic 182 and the bank computer systems 120, 150.
  • the funds transfer payment network is configured to interact with other affiliated payment networks (e.g., PayPal, CashEdge, and so on).
  • other affiliated payment networks e.g., PayPal, CashEdge, and so on.
  • the sponsor identification logic 182 is configured to transmit inquiries to the other affiliated payment networks (e.g., in a predetermined sequence) to determine if the token is recognized at any of the other affiliated payment networks. If the recipient is registered with another payment network, then the funds may be transferred to the recipient by routing the funds through the other payment network.
  • the look up service may operate in the same manner to identify users registered at remote entities.
  • Information may also be stored in the information directory 168 identifying the payment network determined to be associated with that token, thereby facilitating additional funds transfers to that token in the future.
  • funds may be pushed to a recipient that is not registered with the funds transfer payment network but rather that is registered with another payment system. Additionally, such funds may be pushed to the recipient without the sender having to know or be concerned about whether the recipient is registered with the funds transfer payment network.
  • the registration logic 184 is configured to facilitate the process of registering new users. For example, in the preceding discussion, if the token is not recognized at the information directory 168, and is not registered at any other affiliated payment network, then the registration logic may be configured to send the recipient an e-mail or other communication inviting the recipient to register with the payment network. Such an e-mail may include a link to the website provided by the payment service computer system 160.
  • the registration logic 184 may be configured to generate web pages for presentation to the user at the website to facilitate the registration process. If, based on information provided by the user when registering at the website, it is determined that the user is a customer of one of the member entities, then the user may be forwarded to the website of the member entity to complete the registration process.
  • the registration logic 184 may also present web pages to the user in other scenarios (e.g., where the user has arrived at the website as a result of a search engine query, where the user has arrived at the website via another website (e.g., such as an online community website or merchant website), and so on).
  • the registration logic 184 may create new database entries in the information directory 168 responsive to inputs received from the user.
  • the token authentication logic 186 is configured to authenticate tokens. For example, when a user registers a new token, the token authentication logic 186 may be configured to confirm that the user is associated with that token (e.g., that the user who is attempting to register a cell phone number as a token is indeed the owner of that cell phone number). (Herein, the term "own" in the context of telephone numbers refers to the telephone number being assigned to one particular user as opposed to being assigned to other users, and is not being used to refer to ownership as between the user and the phone carrier that provides the telephone number to the user.
  • the authentication logic 186 may perform an authentication operation such as sending the user an e-mail at the new e-mail address.
  • the e-mail may, for example, contain a link that must be accessed by the user in order to successfully complete the registration process.
  • the token authentication logic 186 may be configured to perform authentication operations on previously-registered tokens. For example, a user that registers a cell phone number may ultimately switch cell phone numbers and/or cell phone carriers. The token authentication logic 186 may be configured to process disconnect directories that are published by cell phone carriers and that list cell phone numbers that have been disconnected by that carrier. For example, if a registered cell phone number is listed as having been disconnected, the token authentication logic 186 may send an e-mail to the user at a registered e-mail address to determine whether the cell phone number is no longer a valid token for that user or whether the user has merely changed cell phone carriers but has retained the cell phone number.
  • the token authentication logic 186 may also be configured to send follow up communications to the user trying to use a token to send/receive money from another user if there is uncertainty regarding whether the other user is correct owner of the token.
  • the token authentication logic 186 may be configured to notify the sender that such uncertainty exists, request that the sender provide confirm information that was provided regarding the recipient, provide additional information regarding the recipient, and so on. For example, if a user attempts to send funds using the token jsmith@abc-company.com, an e-mail may be sent to the user if there is uncertainty whether ownership of the token j smith @abc- company.com has changed (e.g., due to a change in employees at ABC Company).
  • the authentication logic 186 may also be configured to access other networks or online
  • the registration logic 182 and the authentication logic 184 cooperate to facilitate the registration of tokens and to ensure that the tokens are associated with their correct owners.
  • the entity that registers a token is responsible for warranting the validity of the registration. For example, if the recipient bank registers a token 415-555-1226, and subsequently accepts a payment to the user that registered the token 415- 555-1226, then the recipient bank is responsible for refunding money to the sender if the user that registered the token 415-555-1226 is not actually the owner of that cell phone number at the time of the funds transfer (e.g., because the previous owner changed cell phone numbers, and the new owner is on a different payment network). Hence, the recipient bank undertakes responsibility for correctly authenticating the user at the time of registration and for routinely processing disconnect directories to ensure that the authentication remains valid.
  • the warranty (and/or limited access to the information directory 168) may be provided as a service to third parties.
  • a token previously provided by the customer e.g., "415-555-1226”
  • the payment service would be responsible for refunding the funds to the correct customer.
  • the fee charged for the service may, for example, be based on the dollar value of liability accepted by the payment service for providing incorrect information.
  • senders may also configure different tokens. For example, a sender may use a first token as their default token (e.g., johnsmith@mail.com), and create additional special purpose tokens where payment is to be made from other accounts (e.g., johnsmith® mail.com/collegesavings to make a tuition payment from a college savings fund).
  • a first token e.g., johnsmith@mail.com
  • additional special purpose tokens where payment is to be made from other accounts
  • the telephone number that may receive a call, text message or voice message, upon the occurrence of a predetermined event is 949-555-7878.
  • the e-mail address that may be used to notify the user that a fund transfer has occurred from or to the user's accounts is pat@mail.com. The user may choose to be notified by e-mail or telephone or both.
  • the account number field 419 may display the type of account and a partial account number of an account that is associated with the token in field 413. Hence, funds sent/received using the token specified in field 413 are withdrawn from/deposited to the account specified in field 419. If an account number is not associated with the e-mail address or the mobile number in field 413, then the account number field 419 may display a message such as "account is not specified.”
  • the notification field 421 may indicate whether the default notification settings specified in field 701 are to be used for notifications or whether other/customized settings are to be used.
  • Actions field 423 may include various links that allow the user to take various actions.
  • links may include, edit, remove, and verify. If the status of a token is verified, then the edit field allows the user to edit attributes of the token as specified in the rules engine 188. For example, the accounts and notification preferences (fields 719 and 721) may be edited in greater detail. If the account number is verified, then the remove link may also be displayed, if the account is unverified or inactive, a verify link that sends an e-mail or a SMS and displays a verification code may be displayed. An edit and remove link may also be displayed for unverified or in active e-mail or telephone numbers. The user may also add new tokens using new connections link 425.
  • separate payment and notification channels may be used for funds transfers.
  • the payment channel occurs through the 415-555-4001 token
  • the notification channel occurs through the 949-555-7878 and pat@mail.com tokens.
  • the user decides to set a custom notification channel for the 415-555-4001 token, the user can do so without disrupting connections that have already been established using the 415-555-4001 token.
  • Disrupting one channel e.g., by changing the token
  • Disrupting one channel does not impact the other channel.
  • the name field 433 may be the name of the recipient as it appears on the account associated with the other user (e.g., as specified by the other user).
  • the nickname field 435 may be a nickname assigned to the other user (e.g., as specified by the user).
  • the e- mail/mobile field 437 may display the public tokens that are being used by the recipient.
  • the status field 437 may display whether a permanent connection has been established for a particular contact.
  • Actions field 441 may be determined based on the status field. For example, if a link has been established, then the actions field 441 may display a link that allows a user to send money to the recipient.
  • the actions field may display a send money link, but the actions field 441 may also display a view details link.
  • the view details link may display another screen to the user where the user may provide further details to establish a connection with a recipient.
  • Other actions that may be displayed are edit and remove. Edit may allow the user to edit each field discussed above and remove may allow a user to remove a recipient and related information from the user's registry.
  • a link 443 may be used to add additional users to the registry, e.g., via a search of information directories 128, 158 and/or 168.
  • the manage connections field 431 may present a message to the user that informs the user when another user is no longer the owner of a token.
  • the message may include a link that allows the user to update the token information.
  • the message presented by the manage connections field 431 may allow the user to update the outdated information.
  • FIG. 5 is a screen shot of a form that allows a user to update default or custom notification settings.
  • the user is provided with a list of e-mail addresses associated with the user's account.
  • the user may use a checkbox to indicate which e-mail address should receive a notification.
  • the user in the screen shot shown in FIG. 5 has chosen e- mail address "psmith@google.com" by placing a check mark 505 in the appropriate field.
  • a user may choose multiple e-mail addresses instead of choosing a single e-mail address.
  • Also shown on the screen shot are telephone numbers associated with the user accounts.
  • the user may use a check mark 509 to select a phone number that receives a notification.
  • the user may choose multiple telephone numbers and multiple e-mail addresses for notification.
  • a link 511 may allow the user to add e-mail addresses or telephone numbers to the account information maintained by the bank.
  • the user may select the link and the user may be automatically taken to a web portal provided by a banking institution. The user may click on save button 513 to save the notification changes implemented by the user.
  • FIG. 6 shows a screen shot of a web page 600 that may be presented to a user when the user selects the send money tab.
  • the web page 600 may include a send money field 601 that the user may fill out to send money to a chosen recipient.
  • the web page 600 may include a display of various payment channels 619 that are available to the user.
  • the web page 600 may also include a field 630 showing details regarding recent transactions that are pending, returned or completed.
  • the user may choose an account from which funds may be sent to the recipient using a drop down menu 605.
  • the drop down menu may be pre-populated with a list of all accounts that are held by the user.
  • the user may enter a dollar amount that the user would like to transfer to the recipient in the amount field 607.
  • the user's name may be presented with an optional field description 609 that may allow the user to ascertain that the payment was for a particular product or service provided by the recipient.
  • Another field may be auto-populated with the user's name as the sender of the funds.
  • a nickname field 611 is also displayed if the recipient knows the user by a name that is different than the user's name as it appears on the user's account.
  • the send money form 601 also displays links that allow the user to add recipients 615, manage recipients 617 and edit the current notification preferences 613.
  • Field 630 shows a few of the most recent transactions that the user has performed. Additional recent transactions may be displayed via selection of a link to view more transfers and/or by selecting the transfer activity tab.
  • Field 630 may display various fields that include information regarding the transactions. For example, such fields may include a date sent field 633, from account field 635, recipient field 637, amount field 639, description field 641, status field 643 and actions field 645.
  • the date sent field 633 lists the date when the user initiated the send request.
  • the from account field 635 may display the type of account (i.e. checking, savings, or money market) and a partial account number.
  • the recipient field 637 may display the full name of the recipient.
  • the amount field 639 displays the dollar amount sent to the recipient.
  • the funds transfer payment network sends a message to the sending bank indicating that the token is unknown.
  • the funds transfer payment network also creates a pending payment, which may include some or all of the following fields: unknown token, sending bank, dollar amount, user name, and recipient name.
  • An in-network user must send an out-of-network user a payment before the out-of-network user can join the funds transfer payment network. This may prevent fraud by ensuring that all users or entities involved in a transaction can be verified. Additionally, because out-of-network users must be invited to the funds transfer payment network by in-network users, fraud and fraudulent transactions are further reduced or eliminated.
  • the funds transfer system 800 stores bank account information for out-of-network users in the out-of-network database 167, but does not store token information for out-of-network users in the out-of-network database 167.
  • the funds transfer payment network associates the recipient with a private identifier as described above.
  • the private identifier may be stored in information directory 168.
  • information directory 168 does not store bank account information.
  • out-of-network database 167 is shown outside of payment service computer system 160 in FIG. 8, in one implementation, the out-of-network database 167 may reside inside payment service computer system 160.
  • the sending bank may send a confirmation to the funds transfer payment network to continue the transaction, as shown in block 908.
  • the funds transfer payment network accesses the separate out-of-network database 167, as shown in block 910.
  • the funds transfer payment network matches the token to the recipient's bank information stored in out-of-network database 167, as shown in block 912.
  • the funds transfer payment network encrypts the receiving bank account information and opaquely sends the recipient's bank account information to the sending back, as shown in block 914.
  • the sending bank decrypts and sends the recipient's bank account information and any other information required to complete the transaction to ACH 170.
  • the funds transfer system 100 also allows communications to non-customers of a financial institution. For example, once a bank is a member of the funds transfer payment network, that bank may be able to send messages to users who are not customers of that bank. Thus, the funds transfer payment network can behave as a communications intermediary. For example, when a new user is prompted to sign up to register with a member entity, that user may be presented a screen that expressly gains approval to send that user messages. In other words, the user must agree in one implementation to receive messages from members as a condition of joining the funds transfer payment network and the funds transfer system 100. Therefore, once a user is signed up, that user can be contacted by other members.
  • the funds transfer system 100 may track the status of payments and provide notifications to a sender and recipient as to the status of payments.
  • information is encrypted by a sender bank and decrypted by a receiver bank so that the payment network does not have access to any of the sender or receiver information.
  • the sender bank may use an encryption algorithm that is known by the receiver bank but is not known by a funds transfer payment network.
  • the sending bank encrypts the account information before any information is given to the payment network.
  • the payment network processes the information, including transferring encrypted sender and receiver information to the receiving bank.
  • the receiving bank knows how to decrypt the encrypted information. In this manner the payment network cannot access any information being communicated by one bank to another bank. The entire transfer of funds is thus opaque to the funds transfer payment network.
  • the funds transfer system 100 relies on the banks' existing fraud systems to manage risks.
  • the payment system does not actually move any money from one entity to another or one bank to another. There is no account owned by the payment service that can even hold money, even for a temporary period of time.
  • the payment system in one implementation only facilitates the transfer of money from one bank to another bank.
  • the funds transfer system 100 or funds transfer payment network may send a payment from an out-of-network user to an in-network user.
  • the funds transfer payment network may create a separate out-of-network database for storing
  • the funds transfer system 100 may present other items besides bills, such as mortgage documents, business documents, subpoenas, or patent filings or applications, for example.
  • the funds transfer system 100 may also be used to securely present documents where the bank verifies the identity of the consumer receiving the documents.
  • the sender can also use the bank to verify receipt of the documents.
  • the biller can track whether the consumer has received the bill. For example, the biller may receive a notification from the funds transfer system 100 that the consumer received the bill.
  • the sender may also be able to confirm that the consumer viewed the bill, e.g., opened or accessed the electronic file on a computer or mobile phone. It should be appreciated that receipt verification or tracking is useful because the biller can confirm, and the consumer cannot deny, that the consumer received the bill.
  • the biller sends a request for money, or a bill or invoice, to the funds transfer payment network.
  • the request or the bill includes a token identifying the recipient of the bill, or the consumer.
  • the biller appends a request ID to the payment ID and sends the bill to the funds transfer payment network.
  • the biller may also be able to add payment instructions to the bill.
  • the funds transfer payment network routes the bill or invoice to the consumer based upon the token.
  • the consumer responds by paying.
  • the funds transfer payment network then notifies the biller of payment.
  • a payment ID is sent to the bank and is then matched to the account. It should be appreciated that the biller or the biller's bank does not need to have the routing and account number of the consumer, thereby increasing security and convenience for the consumer and the biller.
  • the funds transfer payment network provides instructions to the billing bank to debit an account.
  • the funds transfer payment network also provides the consumer's ACH information plus the payment ID, plus the request ID to the biller's bank to debit.
  • an out-of-network user may be able to send payments to a member bank customer even if the member bank customer did not send a payment request to the out-of-network user.
  • registered out-of-network users i.e., users who appear in the out-of-network database 167, can send money to a customer of a member bank.
  • the member bank customers can receive money using that member bank customer's channel of choice. It should be appreciated that the member bank customer does not have to provide perceived confidential information, such as bank account numbers, to out-of-network users from whom they want to receive money.
  • the funds transfer system 100 may be used for debit accounts, electronic funds transfers, credit card transactions, Amazon® payments, payments that are facilitated simply via electronic mail, business to business or merchant payments, expedited payments and scheduled payments, such as for rent, a housekeeper, or a weekly babysitter.
  • the funds transfer payment network verifies account access via trial deposits.
  • the sender gives amounts of transactions and the funds transfer system 100 verifies that the out-of-network sender has access to an account and has authorized the debit transaction.
  • the out-of-network users sending money may be subject to send limits.
  • the send limit amounts may be for per day, per rolling seven-day or per rolling 30-day time periods.
  • the send limits may be enforced for each out-of-network user regardless of the destination of the payments. If an out-of-network user attempts to send a payment exceeding a send limit, the funds transfer system 100 may inform the out-of-network user that the payment exceeds the send limit.
  • the funds transfer payment network can impose transaction fees when an out-of-network user sends money to a customer of a member bank.
  • the decision to accept and execute a money transfer from an out-of-network consumer who wishes to send money may be managed by the member bank, i.e., the bank of the in-network user receiving the money.
  • the member bank i.e., the bank of the in-network user receiving the money.
  • out-of-network users must enroll for the out-of-network service before being able to send money to a member bank customer.
  • an out-of-network user who is registered may be able to both initiate a payment to a registered customer of a member bank and respond to a request for money (e.g., a bill) from a customer of a member bank.
  • the debit transactions from an out-of-network user's bank account may be originated via ACH rails by the member banks.
  • the member bank requires at least one of the following to process a transaction via ACH rails: sender name, transaction amount, transaction fee, recipient profile ID, recipient name as provided by the sender, payment memo, initiation date, bank account number, routing number, and an account type, e.g., checking or savings.
  • the sending bank may use a pull transaction.
  • FIG. 10 is a flow diagram illustrating an example process 1000 for facilitating payment or transfer of funds from an out-of-network sender to an in-network recipient, according to an example implementation of the present invention.
  • process 1000 is described with reference to the flow diagram illustrated in FIG. 10, it will be appreciated that many other methods of performing the acts associated with the process 1000 may be used. For example, the order of many of the blocks may be changed, certain blocks may be combined with other blocks, and many of the blocks described are optional.
  • the funds transfer payment network sends a message to the receiving bank indicating the sender is an out-of-network sender, as shown in block 1008.
  • the receiving bank may send a confirmation to the funds transfer payment network to continue the transaction, as shown in block 1010.
  • the funds transfer payment network accesses the separate out-of-network database 167, as shown in block 1012.
  • the funds transfer payment network matches the sender to the sender's bank information stored in out-of-network database 167, as shown in block 1014.
  • the funds transfer payment network encrypts the sending bank account information and opaquely sends the sending bank's account information to the receiving back, as shown in block 1016.
  • the receiving bank decrypts and sends the sender's account information and any other information required to complete the transaction to ACH 170.
  • a payment may be considered to be real time if funds from a sender to a recipient are deposited in the recipient's account in the amount of time required to send a message from the sender's bank to the recipient's bank.
  • Messages may be sent between the sending bank, the funds transfer payment network and the recipient bank via a messaging service, such as, IBM® WebSphere MQ.
  • Some systems attempt to provide real time payments, however they require leveraging debit card systems, which can be inconvenient.
  • Other systems utilize the ACH system, which may take several days to process and does not provide the speed of the real time or expedited payments presently disclosed.
  • Other systems require that the sender create an account with some alternative payment provider.
  • Yet other systems require having a direct connection to a financial institution's core processing platform.
  • the funds transfer payment network enables real time payments from a sender to a recipient even when the sender and recipient use different banks.
  • the funds transfer payment network can work with any core financial institution's system through a system of APIs, and does not require a direct connection to a financial institution's core processing platform.
  • the funds transfer payment network could alternatively work with non-bank financial institutions such as, for example, brokerage houses or investment companies.
  • the sending and recipient banks are both in-network banks.
  • the sending bank and the receiving bank may be required to agree to offer real time payments to each other before a real time payment can be made.
  • the funds transfer payment network may provide a real time payment service to the sending bank and the recipient bank, in which the banks agree to facilitate real time payments to each other.
  • the funds transfer payment network may additionally or alternatively require that before becoming a member bank, a bank must agree to send and receive real time payments from other member banks.
  • Individual users may also sign up with their respective financial institutions to be able to send and/or receive expedited payments for a service fee.
  • FIG. 11 is a flow diagram illustrating an example process 1100 for facilitating payment or transfer of funds in real time from an in-network sender to an in-network recipient, according to an example implementation of the present invention.
  • the process 1100 is described with reference to the flow diagram illustrated in FIG. 11, it will be appreciated that many other methods of performing the acts associated with the process 1100 may be used. For example, the order of many of the blocks may be changed, certain blocks may be combined with other blocks, and many of the blocks described are optional.
  • data may flow between a sender computer system 110, a funds transfer payment network that uses or implements payment service computer system 160, and recipient computer system 130.
  • a sender may wish to send funds in real time to a recipient, as shown in block 1102.
  • the recipient must be eligible to receive a real time payment, such as, for example, by signing up with a service with the recipient's financial institution.
  • the sending bank may query the funds transfer payment network as to whether the recipient is eligible to receive real time payments.
  • the funds transfer payment network checks whether the recipient is eligible to receive real time payments, as shown in block 1104, and if so, sends a
  • the sending bank then sends an expedited payment message to the funds transfer payment network, as shown in block 1110.
  • the funds transfer payment network in turn sends an expedited payment message to the recipient bank indicating a real time payment, as shown in block 1112.
  • the recipient bank then funds the recipient's account, as shown in block 1114. It should be appreciated that at this stage in the process 1100, the funds have been deposited into the recipient's bank account. It should also be appreciated that at this stage in the process 1100, the recipient bank has funded the recipient's bank account from its own funds, but the sending bank has not yet funded the money to the recipient bank. [00131]
  • the reconciliation or settlement between the sending bank and the recipient bank may occur at some time after the recipient's account has been funded.
  • the settlement or reconciliation between the sending and recipient banks may not occur for several hours or even days after a payment is made to a recipient.
  • the amount of time between the funds being deposited in the recipient's account and the reconciliation between the sending and recipient banks may be referred to as a reconciliation delay. It should be appreciated that the funds transfer payment network substantially avoids the recipient having to wait for the
  • the recipient bank notifies the funds transfer payment network that the recipient's account has been funded, as shown in block 1116.
  • the funds transfer payment network then notifies the sending bank that the recipient's account has been funded, as shown in block 1118.
  • the sending bank may send payment confirmation message to the sender indicating that the recipient's account has been funded.
  • the sending bank then settles the funds with the recipient bank via, for example, an ACH payment, as shown in block 1120.
  • the sending bank may not withdraw funds from the sender's account until after the recipient's account has been funded.
  • the sending bank may however restrict a sender from choosing to send more money than available in the sender's account. This way, the sending back is assured that the sender's account has enough funds to pay back the sending bank.
  • the recipient instead of the receiving bank immediately funding the recipient's account, the recipient must accept the payment before the funds are transferred to the recipient's account. Upon the recipient accepting the payment, the receiving bank transfers the requisite amount to the recipient's account.
  • the funds transfer payment network may require an unregistered recipient to register at an in-network financial institution before being able to receive the funds in an expedited manner.
  • the implementations of the present invention have been described with reference to drawings.
  • the drawings illustrate certain details of specific implementations that implement the systems and methods and programs of the present invention. However, describing the invention with drawings should not be construed as imposing on the invention any limitations that may be present in the drawings.
  • the present invention contemplates methods, systems and program products on any machine-readable media for accomplishing its operations.
  • the implementations of the present invention may be implemented using an existing computer processor, or by a special purpose computer processor incorporated for this or another purpose or by a hardwired system.
  • An exemplary system for implementing the overall system or portions of the invention might include a general purpose computing computers in the form of computers, including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit.
  • the system memory may include read only memory (ROM) and random access memory (RAM).
  • the computer may also include a magnetic hard disk drive for reading from and writing to a magnetic hard disk, a magnetic disk drive for reading from or writing to a removable magnetic disk, and an optical disk drive for reading from or writing to a removable optical disk such as a CD ROM or other optical media.
  • the drives and their associated machine-readable media provide nonvolatile storage of machine-executable instructions, data structures, program modules and other data for the computer.
  • a "financial institution” or FI is an entity that primarily deals with financial transactions such as investments, loans, and/or deposits.
  • Example financial institutions include organizations such as commercial banks, investment banks, insurance companies, brokerages, investment companies, money transmitting entities, trust companies, savings and loans entities, credit unions, shadow banks, or the like.
  • non-financial institution may refer to an entity that does not provide financial services as part of its primary functions.
  • a non-financial institution may comprise a business entity that facilitates sale or exchange of goods and services. Examples of such business entities include service entities and retail entities (e.g., brick- and-mortar retail stores and an online retailers).
  • non-financial institutions comprise social networking entities that provide social networking services to users and/or other individuals. Examples of such social networking entities include Facebook®, Linkedln®, social networks provided by Alphabet®, Inc., and Snapchat®.
  • Non-financial institutions may support online payment system.
  • An "online payment system,” as used herein, may refer to a website or networked application as well as a server system that enables goods/services to be browsed, reviewed, and/or paid for by an individual (e.g., a sender or recipient) using the individual's digital device.
  • the non-financial institution may provide a physical device and/or online service for payment of services rendered or payment of past bills to the non-financial institution.
  • an online retailer e.g., the GAP
  • GAP may provide a payment processing server in communication over a public network such as the Internet.
  • An individual may interact with the payment processing server through a webpage (accessible by a browser on any number of digital devices) or an application such as an application on a smartphone.
  • Financial institutions may act as financial intermediaries between senders and recipients and may facilitate transfer of funds.
  • Financial institutions may be regulated by government(s) and/or other regulatory bodies.
  • a "sender financial institution” may refer to a financial institution that provides financial services to an entity that attempts to transfer funds to another.
  • a sender financial institution may be the sender' s bank.
  • the sender' s bank may include any number of bank accounts associated with the sender.
  • Each account of the sender may include one or more sender account numbers (e.g., an account number that identifies account of the sender).
  • the sender financial institution may provide access to funds (physical currencies, digital currencies, line(s) of credit, etc.) that the sender may use to transfer funds to a recipient.
  • a "recipient financial institution” may refer to a financial institution that provides financial services to an entity that receives funds from another.
  • a recipient financial institution may be the recipient's bank.
  • the recipient's bank may include any number of bank accounts associated with the recipient.
  • Each account of the recipient may include one or more recipient account numbers (e.g., an account number that identifies account of the recipient).
  • the recipient financial institution may provide access to funds (physical currencies, digital currencies, line(s) of credit, etc.) that the recipient may use to receive funds from a sender.
  • FIG. 12 depicts a diagram of a funds transfer system 1200 for securely transferring funds from a sender non-financial institution system to a recipient non-financial institution system, according to some implementations.
  • the funds transfer system 1200 may include a sender system 1202, a recipient system 1204, a first non-FI system 1206, a second non-FI system 1208, a sender FI system 1210, a recipient FI system 1212, a payment service system 1218, an automatic clearing house (ACH) system 1220, a public network 1214 and an ACH network (e.g., private network) 1216.
  • ACH automatic clearing house
  • the sender system 1202 may include one or more digital devices associated with a sender (e.g., a user).
  • the sender may be a person who transfers funds to a third-party recipient using a website of a non-financial institution or a physical payment terminal of the non-financial institution (e.g. using a credit card, debit card, or smart device with a terminal provided by the non-financial institution).
  • the sender may be a person who has access to a networked application or web page that is managed by a retailer (e.g., the first non-FI system 1206).
  • a transfer of funds by the sender may be backed by a sender financial institution, discussed further herein.
  • the sender may maintain a sender account at a sender financial institution that provides access to funds that the sender wishes to transfer to a recipient.
  • the sender system 1202 may have some or all of the components of a digital device, an example of which is shown in FIG. 19 and discussed further herein.
  • the sender system 1202 may be computer (e.g., desktop or laptop computer), a cellular telephone, a smart phone, a mobile handheld wireless e-mail device, a personal digital assistant, a portable gaming device, or other suitable digital device.
  • the sender system 1202 may also include one or more processors configured to execute instructions stored in memory.
  • the sender system 1202 may enable sending funds to the recipient system 1204.
  • the sender system 1202 may include a browser or application configured to interact with online payment processes (e.g., online payment system) supported by the first non-FI system 1206.
  • online payment processes e.g., online payment system
  • FIG. 12 shows the sender system 1202 within the funds transfer system
  • the sender system 1202 may not reside within the funds transfer system 1200 or some or all of the functions of the sender system 1202 may be performed by the first non-FI system 1206.
  • the funds transfer system 1200 may not include the sender system 1202, and/or the first non-FI system 1206 may perform some or all of the functions ascribed to the sender system 1202.
  • the recipient system 1204 may include a digital device associated with a recipient.
  • a recipient may be a person who receives funds proved by the sender (e.g., from the sender system 1202) via online payment processes of a non-financial institution (e.g., first non-FI system 1206). Transfers of funds to the recipient may include transfers to an account held by the recipient at a recipient financial institution. In some implementations, funds are transferred into a recipient account held by the recipient at the recipient financial institution (e.g., recipient FI system 1212) before these funds are made available to the recipient. In various implementations, the recipient FI system 1212 may provide funds to the recipient before a transfer of the funds is made from the sender's account at the sender FI system 1210 (e.g., via the ACH network 1216).
  • the recipient system 1204 may have some or all of the components of a digital device, an example of which is shown in FIG. 19 and discussed further herein.
  • the recipient system 1204 may be computer (e.g., desktop or laptop computer), a cellular telephone, a smart phone, a mobile handheld wireless e-mail device, a personal digital assistant, a portable gaming device, or other suitable digital device.
  • the recipient system 1204 may also include one or more processors configured to execute instructions stored in memory.
  • the recipient system 1204 may include network interface logic 1230, a display device 1232, an input device 1234, and a client application 1236.
  • the network interface logic 1230, the display device 1232, and the input device 1234 may be configured similarly to their counterparts in the sender system 1202.
  • the client application 1236 may include program logic configured to implement one or more of the functions of the recipient system 1204.
  • the client application 1236 may include an application configured to receive and display content or a web browser configured to receive and display web pages from the first non-FI system 1206, the second non-FI system 1208, the sender FI system 1210, the payment service system 1218, the recipient FI system 1212, or any combination.
  • the client application 1236 may include a mobile web browser, a Short Messaging Service (SMS) or other text messaging application, a dedicated application, or other computer program configured to send/receive information over the network 1214.
  • SMS Short Messaging Service
  • the recipient system 1204 may be configured to interact with online payment processes supported by the first non- FI system 1206, the second non-FI system 1208, or both.
  • FIG. 12 shows the recipient system 1204 within the funds transfer system 1200
  • the recipient system 1204 may not reside within the funds transfer system 1200 or some or all of the functions of the recipient system 1204 may be performed by the second non-FI system 1208.
  • the second non-FI system 1208 incorporates a physical payment terminal
  • the funds transfer system 1200 may not include the recipient system 1204, and/or the second non-FI system 1208 may perform some or all of the functions ascribed to the recipient system 1204.
  • the first non-FI system 1206 may include any number of digital devices configured to support the functions of the first non-financial institution.
  • the first non-FI system 1206 may be a server that hosts a website of a retailer.
  • the website may allow users (e.g., sender or receiver) to browse goods and/or services.
  • the website may also allow users to make purchases of the goods and/or services.
  • the first non- FI system 1206 may be a server for interacting with an application (e.g., client application 1228 or client application 1236) on any number of digital devices.
  • the application may allow users to make payments for the goods and/or services.
  • the first non-FI system 1206 may provide services to assist users to direct funds to other users.
  • the first non-FI system 1206 may provide an interface or devcie that allows the sender or recipient to register with the payment service system 1218.
  • the interface may also enable the sender system 1202 to identify the recipient and indicate an amount to transfer to the recipient.
  • the first non-FI system 1206 may provide all or part of the information to the payment service system 1218, the sender FI system 1210, or any other system as further described herein.
  • the first non-FI system 1206 may include one or more servers each with one or more processors configured to execute instructions stored in memory.
  • the servers may be configured to process payment information provided by the client application 1228 on the sender system 1202.
  • the first non-FI system 1206 may have some or all of the components of a digital device, an example of which is shown in FIG. 19 and discussed further herein.
  • the first non-FI system 1206 includes a physical payment terminal that is configured to manage payments for a sender non-financial institution.
  • the physical payment terminal may comprise circuitry, other hardware, and/or software configured to process payment information from the sender (e.g., a credit card at the physical terminal) or from the sender system 1202.
  • the sender e.g., a credit card at the physical terminal
  • the non-FI application 1244 or a financial services provider may tokenize (e.g., encrypt) a number of other identifying information associated with a financial instrument of a sender or recipient (e.g., a credit card or debit card number) to create a token for the sender or recipient.
  • the issuing or backing financial institution for the financial instrument may be capable of de-tokenizing the token to recover the information as disclosed herein.
  • the non-FI institution 1244 may store the tokenized financial instrument of the sender or recipient for future transactions.
  • the non-FI application 1244 may also retrieve or identify a financial identifier that identifies a financial institution associated with the financial instrument (e.g., the financial institution that issued the financial instrument).
  • the second non-FI system 1208 may be similar to the first non-FI system 1206.
  • the second non-FI system 1208 may provide services to assist users to direct funds to other users.
  • the second non-FI system 1208 may provide an interface (e.g., of a physical device) that that allows the sender or recipient to register with the payment service system 1218.
  • the interface may also enable the sender system 1202 to identify the recipient and indicate an amount to transfer to the recipient.
  • the second non-FI system 1208 may provide all or part of the information to the payment service system 1218, the first FI system 1206, or any other system as further described herein.
  • the second non-FI system 1208 may include one or more servers each with one or more processors configured to execute instructions stored in memory.
  • the servers may be configured to process payment information provided by the client application 1236 on the recipient system 1204.
  • the second non-FI system 1208 may be configured to support online payment processes for a recipient non-financial institution. In such
  • the second non-FI system 1208 may include one or more servers each with one or more processors configured to execute instructions stored in memory.
  • the servers may be configured to process payment information provided by the client application 1236 on the recipient system 1204.
  • the second non-FI system 1208 may include network interface logic 1246, a display device 1248, an input device 1250, and a non-FI application 1252.
  • the network interface logic 1246, the display device 1248, and the input device 1250 may be configured similarly to counterparts described herein.
  • the non-FI application 1252 may be configured to manage payments.
  • the recipient non-FI application 1252 may include program logic to process payment information provided to a website or a physical payment terminal supported by the second non-FI system 1208.
  • the recipient non-FI application 1252 comprises program logic to support online payment processes managed by the second non-FI system 1208, as well as logic to tokenize a sender or receiver's financial instrument(s).
  • the sender FI system 1210 may be any digital device operated by or providing services to a financial institution (e.g., a sender financial institution).
  • the sender FI system 1210 may have some or all of the components of a digital device, an example of which is shown in FIG. 19 and discussed further herein.
  • the sender FI system 1210 may hold one or accounts on behalf of a sender.
  • the sender financial institution may maintain accounts held by customers, such as demand deposit accounts, credit card accounts, home mortgage loans, student loans, or the like.
  • the sender FI system 1210 may include one or more servers each with one or more processors configured to execute instructions stored in memory, send and receive data stored in memory, and perform one or more operations.
  • the sender FI system 1210 may include network interface logic 1254, account processing logic 1256, an account database 1258, an information directory 1260, and token management logic 1262.
  • the network interface logic 1254 may include program logic that connects the sender FI system 1210 to the network 1214.
  • the network interface logic 1254 may facilitate secure
  • a "user identifier” or interchangeably, “user token,” as used herein, may refer to information that identifies a participant of a funds transfer for the purpose of transferring funds.
  • User identifiers may include or be associated with public identifiers/public tokens and private identifiers/private tokens.
  • the sender FI system 1210 may include an account database 1258 and an information directory 1260. Once a user is registered with the payment service system 1218 described herein, the sender FI system 1210 may generate a private identifier associated with a user's public identifier. The private identifier of the user may be associated with both the user's public identifier (e.g., the user's email address, phone number, or other contact information) as well as a user's account at the sender FI system 1210.
  • the account database 1258 may include the user's account and the information directory 1260 may associate the public identifier, private identifier, and account information (e.g., account number).
  • the account database 1258 may include any number of accounts for any number of users.
  • the information directory 1260 may include information for any number of private identifiers and public identifiers for any number of users.
  • the payment service system 1218 may include network interface logic 1295, account processing logic 1276, an account database 1278, an information directory 1280, token management logic 1282, fund transfer logic 1284, and registration logic 1286.
  • the network interface logic 1274, the account processing logic 1276, the account database 1278, the information directory 1280, and the token management logic 1282 may be configured similarly to counterparts in the sender FI system 1210.
  • participant processing logic 1276 may determine if a public identifier of a participant is registered by determining if there is an account associated with the public identifier in the account database 1278.
  • a participant may be added to the information directory 1280 upon registering for the funds transfer system 1200 through the sender FI system 1210 or through the first non-FI system 1206. Upon registration, a new entry may be created for the newly registered user in a database that implements the information directory 1280.
  • the information directory 1280 is populated automatically with public identifiers and private identifiers during a secure online banking session that includes the sender FI system 1210.
  • the information directory 1280 stores registries of other participants connected to a specific participant. For instance, for each user, the information directory 1280 may store a registry that includes a listing of each other user with whom the user has an established connection. Such connection may be established, for example, the first time that the user sends or receives funds from the other user. A connection may also be established by way of a user interface that permits a user to add connections with other users through a lookup service in the information directory 1280 and/or another information directory. An example of such a user interface is discussed in connection with FIG. 4 and further herein. The users may include not only users that are registered in the funds transfer payment network, but also other affiliated payment networks, as discussed in greater detail below. For each user in the registry, additional information may be stored, such as their unique ID and/or other information. As another example, the information for the other users may be stored in separate database entries in the information directory 1280.
  • the information directory 1280 may comprise one of a plurality of information directories, each maintained by a different institution or entity. Each information directory may store information about participants relevant to the digital device containing it. Each information directory may allow relevant participants to register with it.
  • the fund transfer logic 1284 may be configured to assist with the transfer of funds between two participants.
  • the fund transfer logic 1284 is further described with regard to FIG. 13.
  • Fund transfers may involve transfers of funds from a sender to a recipient.
  • all participants to a transfer may have registered for fund transfer services provided by the payment service system 1218.
  • at least one participant may be registered only for financial services of a financial institution and/or registered to use the purchase processes (physical purchase terminal, online purchase processes, etc.) of a non-financial institution.
  • registration for fund transfer services provided by the payment service system 1218 may include registering public identifiers for participant accounts and/or receipt of participant redemption tools (e.g., financial instruments), both of which are further discussed herein.
  • participant redemption tools e.g., financial instruments
  • a recipient of a funds transfer may need not take any action to accept a payment (e.g., the recipient may have an "auto-accept" status that allows transfer to the recipient's participant account without further action by the recipient). It is noted in some implementations, the recipient may have to manually accept at least some or all fund transfers.
  • the payment service may, for example, be an additional service that is offered by the web portal to the members of the online community.
  • the payment service may be provided by one of the financial institutions, e.g., such that a financial institution performs both the operations described herein as being performed by the sender FI system 1210, the recipient FI system 1212, the sender non-FI bank system 1214, and the recipient non-FI bank system 1216.
  • the transfer logic 1284 may manage transfers of funds from the sender FI system 1210 to the second non-FI system 1208. Funds obtained at the second non-FI system 1208 may take the form of physical currency, digital currencies, etc. a recipient may obtain from the physical purchase terminal. In implementations where the second non-FI system 1208 supports online payment processes, the transfer logic 1284 may manage transfers of funds from the sender FI system 1210 to the second non-FI system 1208 and/or the recipient system 1204. Funds obtained at the second non-FI system 1208 and/or the recipient system 1204 may take the form of digital currencies, etc.
  • the transfer logic 1284 may facilitate fund transfers to unregistered participants.
  • the transfer logic 1284 may instruct the sender FI system 1210 and the recipient FI system 1212 to extract public identifiers from the transaction data.
  • the transfer logic 1284 may further instruct the sender FI system 1210 and/or the recipient FI system 1212 to look up DDAs after the public identifiers have been extracted.
  • the registration logic 1286 may be configured to manage registration of unregistered participants for fund transfers. The registration logic 1286 is further described with regard to FIG. 14. In some implementations, the registration logic 1286 may issue participant accounts to access those participant accounts.
  • a "participant account,” as used herein, may refer to a registration account managed by the payment service system 1218 to assist in the transfer of funds between financial institutions.
  • a participant account may be linked to and/or backed by funds in financial accounts provided by a financial institution. Participant accounts may be identified by account numbers and/or other account identifiers.
  • a batch transfer system may allow financial institutions to transfer funds to one another as needed and to settle amounts owed to one another at a specified time each day, week, etc. Settlement times may be supported by regulations. As an example, National Automated Clearing House Association (NACHA) rules may require financial institutions that use a batch processing system to settle credits to one another before the end of the next business day after a specific fund transfer.
  • NACHA National Automated Clearing House Association
  • individuals and/or organizations can make a Direct Payment via ACH as either an ACH credit or ACH debit.
  • Direct Payment transactions may be processed as ACH debit transactions, ACH credit transactions, or some combination thereof.
  • a Direct Payment transaction processed as an ACH credit transaction pushes funds into an account. An example of this is when a consumer initiates a payment through his/her bank or credit union to pay a bill.
  • a Direct Payment processed as an ACH debit transaction may pull funds from an account. An example of this is when a consumer establishes a recurring monthly payment for a mortgage or utility bill, and his/her account is debited automatically.
  • FIG. 13 depicts a diagram of fund transfer logic 1284, according to some implementations.
  • the fund transfer logic 1284 may include transaction data management logic 1302, payment validation logic 1304, information directory management logic 1306, payment notification logic 1308, and payment status management logic 1310.
  • One or more of the transaction data management logic 1302, the payment validation logic 1304, the information directory management logic 1306, the payment notification logic 1308, and the payment status management logic 1310 may be implemented using physical computer processor(s) and memory stored in the fund transfer logic 1284.
  • the memory may store computer program instructions to instruct the physical processor(s) to implement one or more of the transaction data management logic 1302, the payment validation logic 1304, the information directory management logic 1306, the payment notification logic 1308, and the payment status management logic 1310.
  • the transaction data management logic 1302 may provide a success message that the sender is registered to the first non-FI system 1206 and/or the sender system 1202. Further, the transaction data management logic 1302 may provide a private identifier of the sender and the amount to be transferred to the sender FI system 1210. The transaction data management logic 1302 may also provide a public identifier of the recipient, a private identifier of the recipient, a recipient FI identifier, a public identifier of the sender and/or any other information to the sender FI system 1210.
  • the transaction data management logic 1302 may receive authorization from the sender FI system 1210 indicating that the sender FI system 1210 has identified the account of the sender and that the sender has sufficient funds for the transaction. At any time, the transaction data management logic 1302 may generate and share a transaction identifier with the sender FI system 1210 and/or the recipient FI system 1212 identifying the transaction to transfer funds from the sender to the recipient.
  • the transaction data management logic 1302 may provide logic and/or instruction to the first non-FI system 1206 to enable the first non-FI system 1206 to provide fund transfer options to users of the system.
  • the transaction data management logic 1302 may provide logic (e.g., code or software) to the first non-FI system 1206 to be placed or embedded within a physical device, web page or code provided by the first non-FI system 1206 to the sender or sender system 1202.
  • the validation logic 1304 implements one or more validation protocols (e.g., validation interfaces) that request confirmation from financial institutions whether or not a sender has authorization to provide the funds requested.
  • the validation logic 1304 may further implement one or more checks to see if public identifiers provided in association with transaction data are valid.
  • the information directory management logic 1306 may be configured to provide instructions to add the transaction data to the information directory 1280. In various implementations, the information directory management logic 1306 may add, delete and/or otherwise modify or manage the information directory 1280.
  • the payment notification logic 1308 may be configured to provide support payment notifications, e.g., notifications to the sender FI system 1210 indicating success or failure of the fund transfer to the recipient and/or sender.
  • the memory may store computer program instructions to instruct the physical processor(s) to implement one or more of the participant account issuing logic 1402, the user identification verification logic 1404, the tokenization logic 1406, the financial institution identification logic 1408, and the account confirmation logic 1410.
  • the participant account issuing logic 1402 may be configured to facilitate issuance of participant accounts. In some implementations, the participant account issuing logic 1402 may create account numbers and/or other account identifiers that participants can use as the basis of participant accounts (e.g., which may assist in the transfer of funds between financial institutions). [00215]
  • the user identification verification logic 1404 may be configured to verify user identifiers when the user identifiers are provided for registering a participant account. In various implementations, the user identification verification logic 1404 is configured to assess whether a participant has the right to register a specific participant account. The user identification verification logic 1404 may further be configured to determine whether or not a user identifier and/or participant account information provided by a participant are associated with accounts at a financial institution or if the financial institution may be identified.
  • Verification of a public identifier may involve one or more verification techniques, such as verifying the public identifier is in appropriate format (e.g., appropriate alphanumeric format), verifying the public identifier has not been previously assigned to another participant, and verifying the public identifier does not include account information.
  • appropriate format e.g., appropriate alphanumeric format
  • the tokenization logic 1406 may be configured to tokenize participant account information.
  • the tokenization logic 1406 may encrypt participant account information or assign proxy numbers to participant account information to keep the participant account information secure from discovery by outside entities, including non- financial institutions.
  • the account confirmation logic 1410 may provide status updates and/or other information to indicate whether or not a participant account has been successfully registered.
  • the account confirmation logic 1410 may instruct the participant system to confirm ownership of the public identifier and send the public identifier and the account information to a non-FI system that corresponds to the participant system.
  • the account confirmation logic 1410 may instruct the sender system 1202 to confirm ownership of the public identifier and send the public identifier and the account information to the first non-FI system 1206.
  • the account confirmation logic 1410 may instruct the recipient system 1204 to confirm ownership of the public identifier and send the public identifier and the account information to the second non-FI system 1208.
  • the account confirmation logic 1410 may instruct the non-FI system that corresponds to the participant system to send the public identifier and the tokenized account data to the payment service system 1218.
  • the public identifier and the tokenized account data is sent directly to the payment service system 1218, while in other implementations, the public identifier and the tokenized account data is sent to the payment service system 1218 through the sender non-FI bank system 1214.
  • the account confirmation logic 1410 may instruct the relevant participant FI system to obtain an identifier of the financial institution associated with the participant using the tokenized account data.
  • the account confirmation logic 1410 may instruct the participant FI system to perform DDA lookups, map DDA numbers to the public identifier, and associate the public identifier with the relevant user account.
  • the account confirmation logic 1410 may provide confirmation of whether or not the participant was successfully registered for fund transfers at non-financial institutions.
  • FIG. 15 depicts a diagram of a data flow 1500 for securely transferring funds from a sender to a recipient in a funds transfer system, according to some implementations.
  • the data flow 1500 depicted in FIG. 15 may be an example, for example, where both the sender and the recipient are already registered with the payment service system 1218.
  • the data flow 1500 includes components of the funds transfer system 1200, shown in FIG. 12, and discussed further herein. More particularly, the data flow 1500 includes operations one or more of the sender system 1202, the recipient system 1204, the first non-FI system 1206, the sender FI system 1210, the recipient FI system 1212, and the payment service system 1218.
  • the elements of the data flow 1500 are by way of example only, and that various implementations may employ a greater number of elements or a lesser number of elements without departing from the scope and substance of the inventive concepts described herein.
  • the sender system 1202 may receive transaction data related to a fund transfer from the sender system 1202.
  • the transaction data may specify an amount of funds to be transferred, a public identifier of a sender (e.g., a participant associated with the sender system 1202), and a public identifier of a recipient (e.g., a participant associated with the second non-FI system 1208).
  • the public identifiers of the sender and the recipient may facilitate routing the fund transfer to the recipient and facilitate reconciliation between sender and recipient financial accounts without requiring account information to be provided outside financial institutions.
  • the sender system 1202 may provide the transaction data to the first non-FI system 1206 over the public network 1214 (or any network).
  • the sender system 1202 may provide the transaction data to a physical purchase terminal or to an application, website, or the like sourced by online purchase processes supported by the first non-FI system 1206.
  • the transaction data may comprise the amount of funds for the transfer, as well as the public identifiers of the sender and the recipient.
  • non-FI system 1206 may include a physical device configured to receive fund transfer information (e.g., sender public identifier, credit or debit card number, amount to be transferred or the like) from the sender without a sender system 1202.
  • fund transfer information e.g., sender public identifier, credit or debit card number, amount to be transferred or the like
  • the first non-FI system 1206 may route the transaction data to the payment service system 1218.
  • the first non-FI system 1206 may recognize that the public identifiers of the sender and recipient are in a format that corresponds to a fund transfer managed by the payment service system 1218.
  • the first non-FI system 1206 may provide the transaction data to the payment service system 1218 over the public network 1214 (or any other network).
  • the payment service system 1218 may validate payment details for the transaction data. As noted herein, validation may involve determining whether the public identifier of the sender is valid, whether the public identifier of the recipient is valid, whether the sender has authorization to provide the funds requested, and/or the like. In some implementations, the payment service system 1218 confirms that the public identifier of the sender is associated with a sender private identifier and an FI system (e.g., sender FI system 1210). Similarly, the payment service system 1218 may confirm that the public identifier of the recipient is associated with a recipient private identifier and an FI system (e.g., recipient FI system 1212). The payment validation logic 1304 may perform operation 1510.
  • the payment service system 1218 may add some or all of the transaction data to the information directory 1280.
  • the payment service system 1218 may log fund transfer information (e.g., time, amount to transfer, recipient public identifier, sender FI identifier, recipient FI identifier, transaction identifier, and/or the like).
  • the payment service system 1218 may store additional information, such as additional sender public identifiers, with a recipient account.
  • the payment service system 1218 may send a notification to the first non-FI system 1206 to that effect.
  • the information directory management logic may perform operation 1512.
  • the information directory management logic 1306 may gather sender private identifier and recipient private identifier from the information directory 1280.
  • the sender private identifier may have been previously generated by the sender FI system 1210 and provided to the payment services system 1218.
  • the recipient private identifier may have been previously generated by the recipient FI system 1212.
  • the sender FI system 1210 may provide instructions to the payment service system 1218 to update any relevant status related to whether or not funds for the fund transfer is approved and/or will be conducted.
  • the payment service system 1218 may generate a transaction identifier that identifies the transaction.
  • the transaction identifier may be shared by the payment service system 1218 with the sender FI system 1210 and the recipient FI system 1204.
  • the payment service system 1218 may provide to the first non-FI system 1206 a first notification of the updated status, including whether or not the funds for the transfer are to be transferred.
  • the sender FI system 1210 may provide the recipient FI system 1212 with a batch transfer to settle fund transfer between the two financial institutions using the ACH network 1216.
  • the request to settle the payment may include or be associated with an ACH message that specifies a transaction identifier (e.g., identifying the transaction and may be linked to the amount to be transferred, an identifier of the sender FI system 1210, and any other information) and/or the amount of the funds transfer.
  • the batch transfer may accompany the sender private identifier, the sender public identifier, the recipient private identifier, the recipient public identifier, the FI identifier of the sender FI system 1210, and/or any other information.
  • the sender private identifier, the sender public identifier, the recipient private identifier, the recipient public identifier, the FI identifier of the sender FI system 1210, and/or any other information may be provided at a later time.
  • the payment status management logic 1310 may perform the operation 1528.
  • the recipient FI system 1212 may provide the payment service system 1218 with an updated status indicating funds were transferred into the recipient account.
  • the payment service system 1218 may provide the first non-FI system 1206 or the sender system 1202 with an updated status indicating funds were transferred into the recipient account.
  • the transaction data may include a recipient public identifier to identify a recipient of the fund transfer.
  • the recipient public identifier may similarly include an email address, a username, a phone number, an alphanumeric string or the like.
  • the recipient public identifier may also uniquely identifies the recipient but keeps financial information of the recipient secure from outside discovery.
  • the transaction data management logic 1302 of the payment service system 1218 may determine that the sender and recipient are registered to respectively use the sender public identifier and the recipient public identifier to perform the fund transfer. In various implementations, the transaction data management logic 1302 may determine that the sender and the recipient are registered with the information directory 1280. The transaction data management logic 1302 may determine, e.g., that public and/or private identifiers of senders and/or recipients have been registered in the information directory 1280.
  • the sender FI system 1210 may identify the sender account by using the sender private identifier to query the information directory 1260. The resulting response may form the basis of retrieving the sender account.
  • the sender private identifier is generated by the sender FI system 1210 during registration and may be used to link the sender with one or more account numbers of accounts of the sender maintained or managed by the sender FI system 1210.
  • the sender private identifier may not be an account number or an encrypted account number.
  • the sender FI system 1210 may evaluate whether the fund transfer is likely to be fraudulent based on the transaction data.
  • the payment validation logic 1304 may determine whether circumstances of the sender's transfer make it appear like the sender is not who the sender claims to be.
  • the sender FI system 1210 may evaluate whether the sender's Internet Protocol (IP) addresses, etc. are valid and/or if the sender has attempted the fund transfer from an authorized system or system the sender has used before, repeated fund transfers in a short time, or the like. If the transfer passes approval, the sender FI system 1210 may provide a notification that it is capable of performing the fund transfer.
  • the payment service system 1218 may receive a notification that the sender FI system 1210 is capable of performing the fund transfer.
  • the payment notification logic 1308 may provide to one or more of the sender system 1202 and the first non-FI system 1206 a status of the fund transfer that indicates the fund transfer will occur.
  • the recipient FI system 1212 may provide to the recipient FI system 1212 transaction data that identifies the transaction identifier, the recipient private identifier, the transfer amount, the identifier of the sender financial institution, and/or the sender private identifier to the recipient financial institution.
  • the private identifiers are provided so that account information need not be transmitted over the public network 1214 (or other network).
  • the sender FI system 1210 may provide funds (including funds for the funds transfer) to the recipient FI system 1212 through the ACH system 1220 and/or the ACH network 1216 as part of a batch fund transfer process.
  • the payment status management logic 1310 may receive a notification of a deposit of the fund transfer into a recipient financial account at the recipient financial institution.
  • the sender system 1202 provides a first financial instrument of a sender or a tokenized financial instrument of a sender (to generate a sender token) to the first non-FI system 1206 and the recipient system 1204 provides second financial instrument of the recipient or a tokenized financial instrument of the recipient (to generate a recipient token) to the first non-FI system 1206 or second non-FI system 1208.
  • non-FI system 1206 may include a physical device configured to receive fund transfer information (e.g., sender public identifier, credit or debit card number, amount to be transferred or the like) from the sender without a sender system 1202.
  • fund transfer information e.g., sender public identifier, credit or debit card number, amount to be transferred or the like
  • the first non-FI system 1206 or the financial service provider associated with the financial instrument may provide the token(s) of the account number(s) to the payment services system 1218.
  • the first non-FI system 1206 or an entity associated with the sender's financial instrument may tokenize the sender's financial instrument and/or the recipient's financial instrument (to generate the sender token and/or the recipient token).
  • the first non-FI system 1206 may also send an FI identifier associated with the sender's financial instrument (e.g., the bank that issued the financial instrument) and the FI identifier associated with the recipient's financial instrument to the payment services system 1218.
  • the payment services system 1218 may identify the sender FI system 1210 with the FI identifier and may provide the sender's token and sender public identifier to the sender FI system 1210.
  • the payment service system 1218 may provide a notification including the sender public identifier, recipient public identifier, sender's token, funds to be transferred, or any other information to the sender FI system 1210 over the public network 1214 (or any network).
  • the payment service system 1218 may also provide a notification including the sender public identifier, recipient public identifier, recipient' s token, funds to be transferred, or any other information to the recipient FI system 1212 over the public network 1214 (or any network).
  • FIG. 18A and FIG. 18B depict diagrams of flowchart of a methods 1800A and
  • the payment notification logic 1308 may send at least some of the transaction data to the sender financial institution to effectuate the fund transfer.
  • the sender public identifier, the recipient public identifier, the transfer amount, recipient FI identifier, and/or the sender' s token may be sent by the payment notification logic 1308 to the sender FI system 1210.
  • the portions of the transaction data may comprise data sufficient to identify the sender of the fund transfer, the recipient of the fund transfer, and the transfer amount of the fund transfer.
  • the sender FI system 1210 may evaluate whether the fund transfer is likely to be fraudulent based on the transaction data.
  • the sender FI system 1210 may provide a notification that it is capable of performing the fund transfer.
  • the payment service system 1218 may receive a notification that the sender FI system 1210 is capable of performing the fund transfer.
  • the recipient FI system 1212 may de-tokenize the recipient's token.
  • the recipient FI system 1212 may identify one or more of the recipient's accounts at the recipient FI system 1212 using the de-tokenized recipient's token (e.g., using the credit card number or debit card number of the recipient). If successful, may recipient FI system 1212 may provide a notification that the recipient's account has been determined to the payment service system 1218 in operation 1826.
  • the payment services system 1218 may provide a transaction identifier for the transfer and a notification to recipient FI system 1212 and/or the sender FI system 1210 indicating that the one or both financial institutions are ready to perform the transfer.
  • FIG. 19 depicts a diagram of a data flow 1900 for registering a participant in a funds transfer system, according to some implementations.
  • the data flow 1900 includes the components of the funds transfer system 1200, shown in FIG. 12, and discussed further herein.
  • the data flow may include the payment service system 1218, and a participant system 1902, a participant non-FI system 1904, and a participant FI system 1906.
  • the participant system 1902 corresponds to the sender system 1202
  • the participant non-FI system 1904 corresponds to the first non-FI system 1206, and the participant FI system corresponds to the sender FI system 1210.
  • the participant system 1902 corresponds to the recipient system 1204, the participant non-FI system 1904 corresponds to the second non-FI system 1208, and the participant FI system 1906 corresponds to the recipient FI system 1212.
  • the data flow 1900 further includes a plurality of operations that correspond to instructions the registration logic 1286 may provide the components of the funds transfer system 1200. It is noted that the elements of the data flow 1900 are by way of example only, and that various implementations may employ a greater number of elements or a lesser number of elements without departing from the scope and substance of the inventive concepts described herein.
  • the participant FI system 1906 may create a participant account.
  • the participant account may be linked to a financial account at a financial institution.
  • the participant account may comprise an account number and/or other account identifier that can be used to identify the account when a participant seeks to register a public identifier for the account.
  • the participant account may be linked to a financial account at a financial institution that comprises financial data, such as debit/credit card information, routing numbers, account numbers, etc.
  • the financial data may comprise identifiers (names, routing numbers, etc.) of financial institutions that provide financial services to the participant system 1902.
  • the participant FI system 1906 may create of a financial instrument (e.g., debit/credit cards may be printed and/or online accounts created for the participant account).
  • the participant FI system 1906 may share the financial instrument with the participant (user of the participant system 1902), the participant system 1902, and/or the payment service system 1218.
  • the participant FI system 1906 may share the financial instrument in conjunction with a financial services provider (e.g., MasterCard).
  • a code may be mailed and/or electronically sent to a participant or the participant system 1902 so that a participant may register user identifier(s) for the participant account.
  • a participant system 1902 may interact with the participant non-FI system 1904.
  • the participant may interact with the participant non-FI system 1904 (e.g., using a credit card and a physical devcie of the participant non-FI).
  • Operations 1914-1920 are described herein from using the participant system 1902 although it will be appreciated that other implementations do not require all or any of the operations.
  • the participant system 1902 may receive a request from the participant to register a participant account using the financial instrument.
  • the participant system 1902 may provide the participant with one or more participant registration screens.
  • the participant system 1902 may receive a public identifier of a participant.
  • the public identifier and the account information may be provided into an input device of the participant system 1902.
  • the public identifier may comprise an alphanumeric or other string that can identify the participant.
  • the participant system 1902 may receive passwords, biometric authentication techniques, other authentication techniques or the like that allow verification of the public identifier.
  • the participant system 1902 may send the public identifier and the participant account information to the participant non-FI system 1904.
  • the participant system 1902 or participant e.g., a user
  • may provide the financial instrument e.g., an account number, routing number or the like related to a financial instrument
  • the participant system 1902 may also send a FI identifier that issued the financial instrument to the participant non-FI system 1904.
  • the participant non-FI system 1904 or a financial services provider associated with the account data may identify tokenized account data representative of participant account information.
  • the tokenized account data may comprise an encrypted version of the participant account information.
  • the tokenized account data may comprise a proxy number that is representative of debit/credit/etc. card numbers in the participant account information.
  • the participant non-FI system 1904 (or the financial services provider) may identify tokenized account data representative of the participant account information.
  • the participant non-FI system 1904 and/or the financial services provider may send the public identifier and the tokenized account data to the payment service system 1218.
  • the participant non-FI system 1904 may optionally send the public identifier and/or the tokenized account data to the participant FI system 1906.
  • the participant non-FI system 1904 may provide the information to the participant FI system 1906, the payment service system 1218, or both.
  • the participant FI system 1906 may optionally send the public identifier and/or the tokenized account data to the payment service system 1218.
  • the information is shared by the participant non-FI system 1904 with the participant FI system 1906 which, in turn, optionally shares all or some of the information with the payment service system 1218.
  • the payment service system 1218 may verify the public identifier is not in use. Verification of the public identifier may include reviewing an information directory to determine whether another user has already registered the public identifier in association with another account. In some implementations, the payment service system 1218 may return a failure message if the public identifier is already in use.
  • the user identification verification logic 1404 may perform operation 1930.
  • the payment service system 1218 may de-tokenize the tokenized account data to extract information to identify a participant financial institution (e.g., the financial institution that manages the participant FI system 1906).
  • a participant financial institution e.g., the financial institution that manages the participant FI system 1906.
  • the payment service system 1218 may send the public identifier and the tokenized account data (e.g., the participant's token) to the participant FI system 1906.
  • the account confirmation logic 1410 may perform the operations 1932 and 1934.
  • the participant FI system 1906 may de-tokenize the tokenized account data.
  • the participant FI system 1906 may decrypt, translate any proxy numbers, etc. to obtain account information for the participant account.
  • the participant FI system 1906 may perform a DDA lookup using, e.g., the account information for the participant's account.
  • the participant FI system 1906 may map the DDA to the user's public identifier.
  • the participant FI system 1906 may generate a private identifier associated with an account number of the participant at the participant's FI system 1906.
  • the participant FI system 1906 may write the account number (e.g., DDA), the public identifier, and the private identifier into an information directory stored in the participant FI system 1906.
  • the participant FI system 1906 may update the public identifier status to reflect the fact that the public identifier can be used for future funds transfers and other transactions involving the participant.
  • the participant FI system 1906 may provide the payment service system 1218 with a confirmation that the public identifier can be used for future fund transfers and other transactions involving the participant.
  • the participant FI system 1906 may also share the private identifier of the participant with the payment service system 1218.
  • the participant non-FI system 1904 may provide configure the participant system 1902 to show a success message indicating that the participant successfully registered.
  • the participant non-FI system 1904 may provide the participant system 1902 with a success message that the public identifier can be used for future funds transfers and other transactions involving the participant.
  • the success message may be shown on the participant system 1902.
  • the user identification verification logic 1404 verifies whether the proposed public identifier is associated with any participants. The user
  • the user identification verification logic 1404 registers the proposed public identifier as the participant public identifier if the proposed public identifier is not associated with any participants.
  • the participant public identifier and any other financial information may be shared with the participant's financial institution. Alternately, the participant may interact with the financial institution (e.g., log onto the participant's account) and the financial institution may confirm the participant' s account. The financial institution may generate a participant private identifier associated with the participant and the participant's account number at the financial institution and private the participant private identifier with the payment services system.
  • the user identification verification logic 1404 may store the proposed public identifier along with the private identifier and associated account information in the information directory 1280.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
PCT/US2016/042163 2015-07-13 2016-07-13 Systems and methods for facilitating a secure transaction at a non-financial institution system WO2017011596A1 (en)

Priority Applications (6)

Application Number Priority Date Filing Date Title
EP16825143.7A EP3323095A4 (en) 2015-07-13 2016-07-13 SYSTEMS AND METHODS FOR FACILITATING SECURE TRANSACTION IN A SYSTEM OF A NON-FINANCIAL INSTITUTION
AU2016294499A AU2016294499A1 (en) 2015-07-13 2016-07-13 Systems and methods for facilitating a secure transaction at a non-financial institution system
JP2018521480A JP6727299B2 (ja) 2015-07-13 2016-07-13 非金融機関システムでのセキュア取引を促進するシステム及び方法
CN201680052672.4A CN108027921B (zh) 2015-07-13 2016-07-13 用于促进在非金融机构系统中安全交易的系统和方法
CA2992457A CA2992457C (en) 2015-07-13 2016-07-13 Systems and methods for facilitating a secure transaction at a non-financial institution system
KR1020187004378A KR102634772B1 (ko) 2015-07-13 2016-07-13 비-금융 기관 시스템에서 안전 거래를 돕기 위한 시스템 및 방법

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201562192008P 2015-07-13 2015-07-13
US62/192,008 2015-07-13

Publications (1)

Publication Number Publication Date
WO2017011596A1 true WO2017011596A1 (en) 2017-01-19

Family

ID=57757580

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2016/042163 WO2017011596A1 (en) 2015-07-13 2016-07-13 Systems and methods for facilitating a secure transaction at a non-financial institution system

Country Status (7)

Country Link
EP (1) EP3323095A4 (zh)
JP (1) JP6727299B2 (zh)
KR (1) KR102634772B1 (zh)
CN (1) CN108027921B (zh)
AU (1) AU2016294499A1 (zh)
CA (1) CA2992457C (zh)
WO (1) WO2017011596A1 (zh)

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10078821B2 (en) 2012-03-07 2018-09-18 Early Warning Services, Llc System and method for securely registering a recipient to a computer-implemented funds transfer payment network
WO2019040156A1 (en) * 2017-08-25 2019-02-28 Google Llc MOBILE DEVICE SECURITY FOR ELECTRONIC PAYMENTS
US10318936B2 (en) 2012-03-07 2019-06-11 Early Warning Services, Llc System and method for transferring funds
US10395247B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc Systems and methods for facilitating a secure transaction at a non-financial institution system
US10395223B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc System and method for transferring funds
US10438175B2 (en) 2015-07-21 2019-10-08 Early Warning Services, Llc Secure real-time payment transactions
US10530841B2 (en) 2017-10-03 2020-01-07 The Toronto-Dominion Bank System and method for transferring value between database records
US10748127B2 (en) 2015-03-23 2020-08-18 Early Warning Services, Llc Payment real-time funds availability
US10769606B2 (en) 2015-03-23 2020-09-08 Early Warning Services, Llc Payment real-time funds availability
US10832246B2 (en) 2015-03-23 2020-11-10 Early Warning Services, Llc Payment real-time funds availability
US10839359B2 (en) 2015-03-23 2020-11-17 Early Warning Services, Llc Payment real-time funds availability
US10846662B2 (en) 2015-03-23 2020-11-24 Early Warning Services, Llc Real-time determination of funds availability for checks and ACH items
US10956888B2 (en) 2015-07-21 2021-03-23 Early Warning Services, Llc Secure real-time transactions
US10963856B2 (en) 2015-07-21 2021-03-30 Early Warning Services, Llc Secure real-time transactions
US10970688B2 (en) 2012-03-07 2021-04-06 Early Warning Services, Llc System and method for transferring funds
US10970695B2 (en) 2015-07-21 2021-04-06 Early Warning Services, Llc Secure real-time transactions
US11037121B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11037113B2 (en) 2018-07-31 2021-06-15 Morgan Stanley Services Group Inc. Network of computing nodes and a method of operating the computing nodes to effectuate real-time bank account-to-bank account money transfer
US11037122B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11062290B2 (en) 2015-07-21 2021-07-13 Early Warning Services, Llc Secure real-time transactions
US11144928B2 (en) 2016-09-19 2021-10-12 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
US11151523B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US11151522B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US11157884B2 (en) 2015-07-21 2021-10-26 Early Warning Services, Llc Secure transactions with offline device
US11386410B2 (en) 2015-07-21 2022-07-12 Early Warning Services, Llc Secure transactions with offline device
US11521249B2 (en) * 2019-03-13 2022-12-06 Stripe, Inc. Auto-reconciliation
US11593800B2 (en) 2012-03-07 2023-02-28 Early Warning Services, Llc System and method for transferring funds

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200013028A1 (en) * 2018-07-09 2020-01-09 American Express Travel Related Services Company, Inc. Peer-to-peer money transfers
RU2716901C1 (ru) * 2018-12-24 2020-03-17 Акционерное общество "Национальная система платежных карт" Способы моментальных денежных переводов и система для реализации способов
KR102273695B1 (ko) * 2019-03-08 2021-07-06 대한민국(기획재정부장관) 입금 식별 코드를 이용한 국고 보조금 이체 방법 및 그 시스템
CN110009351A (zh) * 2019-03-29 2019-07-12 上海盛付通电子支付服务有限公司 用于代发校验的方法与设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080097873A1 (en) * 2006-06-05 2008-04-24 Elliot Cohen System for online travel planning and hotel selection
US20120203695A1 (en) * 2011-02-09 2012-08-09 American Express Travel Related Services Company, Inc. Systems and methods for facilitating secure transactions
US20130238492A1 (en) * 2012-03-07 2013-09-12 Clearxchange, Llc System and method for transferring funds
US20140244515A1 (en) * 2010-12-16 2014-08-28 Democracyontheweb, Llc Systems and methods for facilitating secure access

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4067630B2 (ja) * 1998-03-16 2008-03-26 富士通株式会社 金融処理装置および方法
CN1608267A (zh) * 2001-11-26 2005-04-20 埃帕西菲克公司 用于资金转帐的系统和方法
JP4404518B2 (ja) * 2002-04-17 2010-01-27 日本電気株式会社 送金システム、送金方法および送金プログラム
JP4234412B2 (ja) * 2002-12-12 2009-03-04 ヤフー株式会社 電子商取引に係わる代金の決済サービス方法、決済システム、コンピュータプログラム、プログラム格納媒体
CN101563704B (zh) * 2005-11-03 2012-07-04 支付途径股份有限公司 身份认证的方法和系统
JP5334394B2 (ja) * 2006-09-19 2013-11-06 ヤフー株式会社 決済処理方法、決済処理システム、及び決済処理用プログラム
US7848980B2 (en) * 2006-12-26 2010-12-07 Visa U.S.A. Inc. Mobile payment system and method using alias
US20080249937A1 (en) * 2007-04-06 2008-10-09 Walls Robert K Payment card based remittance system with delivery of anti-money laundering information to receiving financial institution
US20100057614A1 (en) * 2008-08-26 2010-03-04 Qualcomm Incorporated System and method for effecting real-time financial transactions between delayed-settlement financial accounts
US20110145152A1 (en) * 2009-12-15 2011-06-16 Mccown Steven Harvey Systems, apparatus, and methods for identity verification and funds transfer via a payment proxy system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080097873A1 (en) * 2006-06-05 2008-04-24 Elliot Cohen System for online travel planning and hotel selection
US20140244515A1 (en) * 2010-12-16 2014-08-28 Democracyontheweb, Llc Systems and methods for facilitating secure access
US20120203695A1 (en) * 2011-02-09 2012-08-09 American Express Travel Related Services Company, Inc. Systems and methods for facilitating secure transactions
US20130238492A1 (en) * 2012-03-07 2013-09-12 Clearxchange, Llc System and method for transferring funds

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3323095A4 *

Cited By (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11593800B2 (en) 2012-03-07 2023-02-28 Early Warning Services, Llc System and method for transferring funds
US10318936B2 (en) 2012-03-07 2019-06-11 Early Warning Services, Llc System and method for transferring funds
US10078821B2 (en) 2012-03-07 2018-09-18 Early Warning Services, Llc System and method for securely registering a recipient to a computer-implemented funds transfer payment network
US10970688B2 (en) 2012-03-07 2021-04-06 Early Warning Services, Llc System and method for transferring funds
US10395223B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc System and method for transferring funds
US11715075B2 (en) 2012-03-07 2023-08-01 Early Warning Services, Llc System and method for transferring funds
US11605077B2 (en) 2012-03-07 2023-03-14 Early Warning Services, Llc System and method for transferring funds
US11361290B2 (en) 2012-03-07 2022-06-14 Early Warning Services, Llc System and method for securely registering a recipient to a computer-implemented funds transfer payment network
US11321682B2 (en) 2012-03-07 2022-05-03 Early Warning Services, Llc System and method for transferring funds
US11948148B2 (en) 2012-03-07 2024-04-02 Early Warning Services, Llc System and method for facilitating transferring funds
US10395247B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc Systems and methods for facilitating a secure transaction at a non-financial institution system
US11373182B2 (en) 2012-03-07 2022-06-28 Early Warning Services, Llc System and method for transferring funds
US10846662B2 (en) 2015-03-23 2020-11-24 Early Warning Services, Llc Real-time determination of funds availability for checks and ACH items
US10878387B2 (en) 2015-03-23 2020-12-29 Early Warning Services, Llc Real-time determination of funds availability for checks and ACH items
US10839359B2 (en) 2015-03-23 2020-11-17 Early Warning Services, Llc Payment real-time funds availability
US10748127B2 (en) 2015-03-23 2020-08-18 Early Warning Services, Llc Payment real-time funds availability
US10832246B2 (en) 2015-03-23 2020-11-10 Early Warning Services, Llc Payment real-time funds availability
US10769606B2 (en) 2015-03-23 2020-09-08 Early Warning Services, Llc Payment real-time funds availability
US11037121B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US10970695B2 (en) 2015-07-21 2021-04-06 Early Warning Services, Llc Secure real-time transactions
US11037122B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11062290B2 (en) 2015-07-21 2021-07-13 Early Warning Services, Llc Secure real-time transactions
US11922387B2 (en) 2015-07-21 2024-03-05 Early Warning Services, Llc Secure real-time transactions
US10438175B2 (en) 2015-07-21 2019-10-08 Early Warning Services, Llc Secure real-time payment transactions
US11151523B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US10762477B2 (en) 2015-07-21 2020-09-01 Early Warning Services, Llc Secure real-time processing of payment transactions
US11386410B2 (en) 2015-07-21 2022-07-12 Early Warning Services, Llc Secure transactions with offline device
US11151522B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US11157884B2 (en) 2015-07-21 2021-10-26 Early Warning Services, Llc Secure transactions with offline device
US10956888B2 (en) 2015-07-21 2021-03-23 Early Warning Services, Llc Secure real-time transactions
US10963856B2 (en) 2015-07-21 2021-03-30 Early Warning Services, Llc Secure real-time transactions
US11151566B2 (en) 2016-09-19 2021-10-19 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
US11151567B2 (en) 2016-09-19 2021-10-19 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
US11144928B2 (en) 2016-09-19 2021-10-12 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
WO2019040156A1 (en) * 2017-08-25 2019-02-28 Google Llc MOBILE DEVICE SECURITY FOR ELECTRONIC PAYMENTS
US10530841B2 (en) 2017-10-03 2020-01-07 The Toronto-Dominion Bank System and method for transferring value between database records
US11122113B2 (en) 2017-10-03 2021-09-14 The Toronto-Dominion Bank System and method for transferring value between database records
US11037113B2 (en) 2018-07-31 2021-06-15 Morgan Stanley Services Group Inc. Network of computing nodes and a method of operating the computing nodes to effectuate real-time bank account-to-bank account money transfer
US11521249B2 (en) * 2019-03-13 2022-12-06 Stripe, Inc. Auto-reconciliation

Also Published As

Publication number Publication date
EP3323095A4 (en) 2019-04-10
KR20180075473A (ko) 2018-07-04
CA2992457A1 (en) 2017-01-19
AU2016294499A1 (en) 2018-02-15
KR102634772B1 (ko) 2024-02-06
CN108027921A (zh) 2018-05-11
JP6727299B2 (ja) 2020-07-22
EP3323095A1 (en) 2018-05-23
CA2992457C (en) 2021-12-21
CN108027921B (zh) 2022-02-18
JP2018525758A (ja) 2018-09-06

Similar Documents

Publication Publication Date Title
US11373182B2 (en) System and method for transferring funds
CA2992457C (en) Systems and methods for facilitating a secure transaction at a non-financial institution system
US11715075B2 (en) System and method for transferring funds
US10318936B2 (en) System and method for transferring funds
US11361290B2 (en) System and method for securely registering a recipient to a computer-implemented funds transfer payment network
US11810087B1 (en) System and method for transferring funds
US11972402B1 (en) Real-time interbank transactions systems and methods
JP2020520013A (ja) 資金振替を促進するためのシステムおよび方法
US20120116963A1 (en) Invoicing and electronic billing system and method
US10970688B2 (en) System and method for transferring funds
US20240078547A1 (en) System and method for facilitating transferring funds

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: 16825143

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2992457

Country of ref document: CA

Ref document number: 2018521480

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 11201800290R

Country of ref document: SG

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20187004378

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2016825143

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2016294499

Country of ref document: AU

Date of ref document: 20160713

Kind code of ref document: A