JP2018525758A - System and method for promoting secure transactions in non-financial institution systems - Google Patents

Abstract

A system and method for secure remittance over a private network.
The method receives transaction data relating to a remittance, including a tokenized financial product, provides the tokenized financial product to a sender financial institution, and the sender financial institution provides the tokenized financial product. Enabling de-tokenization and identifying the sender's account, receiving the sender's secret identifier generated by the sender's financial institution, providing the sender's amount of money for the transfer Enabling the sender financial institution to send money, providing the transaction identifier and the receiver's secret identifier to the recipient financial institution, and the recipient financial institution paying from the sender financial institution to the recipient financial institution Receiving an ACH message from the sender financial institution via the ACH network and allowing the funds to be transferred via the ACH network.
[Selection] Figure 1

Description

  TECHNICAL FIELD The technical field relates to systems and methods for transferring money via an electronic money transfer network, and more particularly, having access to a physical payment terminal or online payment process maintained by an entity other than a financial institution via the electronic money transfer network. The present invention relates to a system and method for securely transferring money to an individual.

  Many existing systems that transfer money via an electronic money transfer network, such as an automatic clearinghouse (ACH) network, have limitations. For example, with normal wire transfer, both the sender and payee typically need to be physically present at the financial institution or have direct access to the financial institution's account (eg, online access) . The requirement that senders and payees have an account with a financial institution is that the non-bank user demographics of the population and / or access to / from some people, such as those who do not have easy access to the financial institution Remittance can be difficult. Furthermore, conventional wire transfers, including remittances or currency exchanges between financial institutions, are highly regulated and generally require additional fees. These fees can form the basis of transaction costs that can make money transfer between individuals inefficient, impractical, or otherwise difficult.

  Many existing systems that transfer money to individuals do not support the remittance scenarios that usually occur. As an example, existing remittance systems may not fund people who want to send or receive money at physical payment terminals at retail stores or other non-financial institutions that are not financial institutions. Existing remittance systems may not fund people who wish to send or receive money using a non-financial institution's online payment process. Debit transfer systems and other systems that transfer money to people at retailer facilities and / or retailer websites can be prohibitive in cost and / or may not facilitate transfers between people. Many existing personal remittance systems may not provide funds immediately (eg, approximately “real time”) after a request for funds is made. As a result, it has proven difficult in many cases to transfer money efficiently via an electronic money transfer network to individuals, particularly individuals who do not have access to financial institution payment systems.

  The systems, methods, and computer-readable media discussed herein are secure to individuals with access to a second (eg, public) network via an electronic money transfer network, such as an automatic clearinghouse (ACH) network. Related to sending money. An example method is to receive transaction data related to a remittance, where the transaction data includes a remittance amount, a sender public identifier that identifies the sender of the remittance, and a recipient public identifier that identifies the recipient of the remittance Specify the sender's financial institution identifier, the recipient financial institution's financial institution identifier, and the sender's tokenized financial instrument, receive and send the sender's financial institution using the financial institution identifier The sender financial institution is a member of the payment network, and the sender financial institution provides the sender's tokenized financial product to the sender financial institution Allows the sender to de-tokenize the sender's tokenized financial instrument and identify the account of the sender financial institution associated with the sender, and from the sender financial institution to the sender financial institution Receiving the sender's secret identifier thus generated, the sender's financial institution generating the sender's secret identifier when confirming the account of the sender's financial institution associated with the sender The sender's secret identifier is associated with the sender's public identifier, and the sender's financial institution provides the sender's remittance amount, the recipient's public identifier, and the receiver's financial institution identifier. Enables the identification of the availability of money in the account associated with the sender that satisfies the remittance amount, generates a transaction identifier associated with the transfer, a transaction identifier and a recipient secret identifier To the beneficiary financial institution to enable the beneficiary financial institution to identify the account associated with the beneficiary so that the beneficiary financial institution can receive the ACH message over the ACH network. The ACH message indicates a payment from the sender financial institution to the payee financial institution, and the ACH message is generated by the sender financial institution and the sender Contains a transaction identifier that identifies the transfer to and from the payee, and the ACH message allows the payee financial institution to get money from the ACH batch transfer and deposit money into the account associated with the payee And enabling.

  In some embodiments, the method may further include verifying that the sender has permission to perform the transfer using the public identifier. The method includes receiving a payee FI identifier associated with the payee tokenized financial instrument and the payee financial institution, and using the payee FI identifier to identify the payee financial institution. The beneficiary financial institution is a member of the payment network, identifies and provides the beneficiary tokenized financial instrument to the beneficiary financial institution, and the payee financial institution tokenizes the beneficiary tokenized financial instrument Unlocking and enabling the identification of the payee financial institution account associated with the payee and receiving from the payee financial institution a payee secret identifier generated by the payee financial institution The payee financial institution may further include generating and receiving a payee secret identifier when the payee financial institution associated with the sender is verified.

  This method consists of the transfer amount, the sender's public identifier that identifies the sender of the transfer, the recipient's public identifier that identifies the recipient of the transfer, the financial institution identifier of the sender financial institution, and the financial institution identifier of the recipient financial institution And receiving the sender's tokenized financial instrument from the first online product reseller. The first online product reseller may tokenize the sender's financial instrument to create the sender's tokenized financial instrument. Financial instruments can be issued by a sender financial institution.

  In some embodiments, the method may further include receiving the recipient's tokenized financial instrument from a second online product reseller different from the first online product reseller. The second online product reseller may tokenize the payee's financial product to create the payee's tokenized financial product. The payee financial institution may transfer money to the account associated with the payee before the payee financial institution receives the ACH message. The method may further include providing a notification request to the sender system requesting whether the sender is to accept the money from the sender.

  The example system includes one or more processors and memory coupled to the one or more processors. The memory may be configured to instruct one or more processors to perform the method. The method is to receive transaction data associated with a remittance, wherein the transaction data includes a remittance amount for the remittance, a sender public identifier that identifies the sender of the remittance, a recipient public identifier that identifies the recipient of the remittance, Use the sender's financial institution identifier, the recipient financial institution's financial institution identifier, and the sender's tokenized financial instrument to specify and receive the sender's financial institution's financial institution identifier. Identifying the financial institution, the sender financial institution being a member of the payment network, and providing the sender financial institution the tokenized financial product of the sender to the sender financial institution Allowing the sender's tokenized financial instrument to be de-tokenized and identifying the account of the sender's financial institution associated with the sender, and from the sender's financial institution to the sender's financial institution The sender's secret identifier generated by the sender, the sender's financial institution generates and receives the sender's secret identifier if the sender's account associated with the sender is confirmed. And associating the sender's secret identifier with the sender's public identifier, and providing the sender's financial institution with the amount of money to be sent, the recipient's public identifier, and the recipient's financial institution identifier. Enabling the identification of the availability of money in the account associated with the sender, satisfying the transfer amount, generating a transaction identifier associated with the transfer, transaction identifier and recipient secret An identifier is provided to the payee financial institution to enable the payee financial institution to identify the account associated with the payee so that the payee financial institution can connect to the ACH message via the ACH network. The ACH message indicates a payment from the sender financial institution to the payee financial institution, and the ACH message is generated by the sender financial institution and is received by the sender and the receiver. Includes a transaction identifier that identifies the transfer to and from the person, and the ACH message allows the payee financial institution to get money from the ACH batch transfer and deposit money into the account associated with the payee And enabling.

  The non-transitory computer readable media system may include executable instructions that are executable by the processor to perform the methods. The method is to receive transaction data associated with a remittance, wherein the transaction data includes a remittance amount for the remittance, a sender public identifier that identifies the sender of the remittance, a recipient public identifier that identifies the recipient of the remittance, Use the sender's financial institution identifier, the recipient financial institution's financial institution identifier, and the sender's tokenized financial instrument to specify and receive the sender's financial institution's financial institution identifier. Identifying the financial institution, the sender financial institution being a member of the payment network, and providing the sender financial institution the tokenized financial product of the sender to the sender financial institution Allowing the sender's tokenized financial instrument to be de-tokenized and identifying the account of the sender's financial institution associated with the sender, and from the sender's financial institution to the sender's financial institution The sender's secret identifier generated by the sender, the sender's financial institution generates and receives the sender's secret identifier if the sender's account associated with the sender is confirmed. And associating the sender's secret identifier with the sender's public identifier, and providing the sender's financial institution with the amount of money to be sent, the recipient's public identifier, and the recipient's financial institution identifier. Enabling the identification of the availability of money in the account associated with the sender, satisfying the transfer amount, generating a transaction identifier associated with the transfer, transaction identifier and recipient secret An identifier is provided to the payee financial institution to enable the payee financial institution to identify the account associated with the payee so that the payee financial institution can connect to the ACH message via the ACH network. The ACH message indicates a payment from the sender financial institution to the payee financial institution, and the ACH message is generated by the sender financial institution and is received by the sender and the receiver. Includes a transaction identifier that identifies the transfer to and from the person, and the ACH message allows the payee financial institution to get money from the ACH batch transfer and deposit money into the account associated with the payee And enabling.

  These and other advantages will be apparent to those of ordinary skill in the art from reading the following description and a study of several examples of the drawings.

FIG. 2 shows a schematic diagram of a remittance system using banking institutions with different senders and recipients, according to an example embodiment. FIG. 4 shows a schematic diagram of token management logic that may manage tokens for fund transfer requests according to an example embodiment. FIG. 6 illustrates a process by which a remittance request leads to funding by a registered or non-registered recipient according to an example embodiment. FIG. 6 illustrates a process by which a remittance request leads to receipt by a registered or non-registered recipient, according to an example embodiment. Figure 5 shows an example screen of a web page that can be presented to a user to configure user preferences and manage ties with other users. Fig. 5 shows an example screen of a web page that can be presented to the user to configure notification settings. Fig. 5 shows an example screen of a web page that can be presented to a user for transmission to a recipient. FIG. 6 shows an example of a screen of a web page that can be presented to a user outside the network when the user outside the network sends a payment. FIG. 2 shows a schematic diagram of a remittance system using banking organizations with different senders and recipients, according to an example embodiment. 6 illustrates a flow diagram illustrating an example process for facilitating transmissions to off-network recipients, according to an example embodiment. 6 illustrates a flow diagram illustrating an example process for facilitating a remittance from an off-network sender to an in-network recipient, according to an example embodiment. 6 illustrates a flow diagram illustrating an example process for facilitating rapid transfers from an intra-network sender to an off-network recipient, according to an example embodiment. FIG. 3 illustrates a diagram of a remittance system that securely transfers money from a non-financial institution system sender to a non-financial institution system recipient, according to some embodiments. FIG. 6 shows a diagram of transfer logic according to some embodiments. FIG. 4 shows a diagram of registration logic according to some embodiments. FIG. 4 illustrates a data flow diagram for securely transferring money from a sender to a recipient in a money transfer system, according to some embodiments. FIG. 4 shows a flowchart diagram of a method for securely transferring money from a sender to a recipient in a money transfer system, according to some embodiments. FIG. 4 shows a flowchart diagram of a method for securely transferring money from a sender to a recipient in a money transfer system, according to some embodiments. FIG. 4 illustrates a data flow diagram for securely transferring money from a sender to an unregistered recipient in a money transfer system, according to some embodiments. FIG. 4 illustrates a flowchart diagram of a method for securely transferring money from a sender to an unregistered recipient in a money transfer system, according to some embodiments. FIG. 4 illustrates a flowchart diagram of a method for securely transferring money from a sender to an unregistered recipient in a money transfer system, according to some embodiments. FIG. 4 illustrates a data flow diagram for registering a participant in a remittance system, according to some embodiments. FIG. 4 shows a flowchart diagram of a method of registering a participant in a remittance system, according to some embodiments. 2 illustrates an example of a digital device according to some embodiments.

  Referring to FIG. 1, a remittance system 100 that implements a payment network or “remittance payment network” is shown. The remittance system 100 can be used by a sender to send funds to a recipient and for the recipient to receive funds. The remittance system 100 may facilitate remittance from a sender to a recipient (eg, a recipient) without any parties disclosing any financial account information with each other. Senders and payees can be individuals or business entities. In the example embodiment, the sender uses a bank account as a funding source. In other embodiments, the sender can use a credit card, debit card, business credit card, or check card as a source of funds. The remittance system 100 provides intra-bank transfers (ie transfers where both the sender and recipient have accounts in the same bank and funds are transferred between accounts within the same bank) and inter-bank transfers (ie senders). And transfers where the payee has an account in a different bank and the funds are transferred between different bank accounts).

  The remittance system 100 may include a remittance computer system 110, a bank computer system 120, a payee computer system 130, a bank computer system 150, a payment service computer system 160, and an automatic clearinghouse computer system 170, among others. Each of the systems described above may communicate through a network 140, which may include one or more of the Internet, a cellular network, Wi-Fi, Wi-Max, a proprietary bank network, etc. Throughout FIG. 1 and the rest of the description, to provide an example, a sender performs a transfer from an account maintained by the bank computer system 120 and a recipient receives an account maintained by the bank computer system 150. Suppose you use and receive funds. Accordingly, the computer system 120 is sometimes referred to herein as a sender bank computer and the computer system 150 is referred to herein as a payee bank computer system. Of course, it is clear that any given bank computer system can operate at different capacities for various remittance transactions. Furthermore, although the examples provided herein relate primarily to a sender requesting a remittance to a recipient, it is understood that the recipient may request a remittance from the sender.

  The remittance computer system 110 may be operated by an individual user (eg, business owner or employee, consumer, etc.) through the online bank area of the website provided by the remittance bank computer system 120 or by the payment service 160. Can be used to interact with bank functions provided through the provided website. The sender computer system 110 may include, for example, a user computer (eg, a desktop or laptop computer), a mobile phone, a smartphone, a mobile handheld wireless email device, a personal information terminal, a portable gaming device, or other suitable device. The sender computer system 110 may also include one or more servers each having one or more processors configured to execute instructions stored in memory. For example, such a configuration may be used when the sender is a merchant or other business.

  Sender computer system 110 may include network interface logic 112, display device 114, input device 116, and client application 118. The network interface logic 112 may include, for example, program logic that connects the sender computer system 110 to the network 140. As described in more detail below, for example, the sender computer system 110 may receive a screen containing account information, transaction instructions, etc. and display it on the display device 114. In example embodiments, such a screen may be used to request username and password information. Such a screen may also be used to prompt the user to provide information regarding the amount of funds and the identity of the merchant or individual to receive the funds. Such information may include, for example, name, address, telephone number, email address, or recipient selection from an electronic directory, and / or other information. Such screens can also include screens that display information about past transactions. Such a screen is presented to the user via the display device 114. Input device 116 may be used to allow a user to initiate account access and facilitate receipt of remittance request information from the user.

  Client application 118 may include program logic (ie, stored executable instructions) configured to perform at least some of the functions described herein. As will be appreciated, the level of functionality resident in the sender computer system 110 compared to other components of the money transfer system 100 can vary depending on the embodiment. The client application 118 simply receives a web page from the bank computer system 120 and a web browser configured to display the received web page (eg, Internet Explorer®, Mozilla Firefox®, Chrome). (Registered trademark), Safari (registered trademark), and the like. The client application may also include a mobile web browser, a text message (SMS) interface, a dedicated application, or other program suitable for sending and receiving information over the network 140.

  The bank computer system 120 is operated by a banking organization that maintains accounts held by customers such as savings accounts, credit card accounts, home mortgages, student loans and the like. The bank computer system 120 may, for example, execute instructions stored in memory, send and receive data stored in memory, perform other operations, and relate to the logic or process illustrated in FIGS. May include one or more servers each having one or more processors configured to perform the operations described herein.

  Bank computer system 120 may include network interface logic 122, account processing logic 124, account database 126, and information directory 128. The network interface logic 122 may include, for example, program logic that connects the bank computer system 120 to the network 140. Network interface logic 122 may facilitate secure communication between the bank and the sender and / or payee. The network interface logic 122 may also facilitate communication with other entities such as other banks, payment systems. The network interface logic 122 may include user interface program logic configured to generate web pages and present the web pages to a user accessing the bank computer system 120 via the network 140.

  Account processing logic 124 performs account processing to perform transactions related to the account holder's account, such as checking and debiting accounts, checking and debiting, checking and debiting residential mortgages. To process. Thus, whenever funds are transferred into or out of an account holder's (e.g., money sender or recipient) account processing logic 124 reflects the appropriate debit or credit in the account database 126. The account database 126 then stores account information (e.g., information about transactions, account holders, etc.) for accounts maintained by banks on behalf of customers. Account processing logic 124 may also process a remittance request to transfer money from a sender using the sender computer system 110 to a recipient using the recipient computer system 130.

  The information directory 128 is used when an identifier other than a bank account / bank branch code is used to identify the recipient of the remittance (eg, email address, telephone number, common payment identification code (UPIC), random number, etc.). obtain. The information directory 128 is maintained to allow the financial institution to convert / correlate the recipient's mobile phone number (or email address or other identifier) to the bank account number / bank branch code of the recipient's bank account. Database. This configuration allows the sender to uniquely identify the recipient (eg, email address) without necessarily having to have private / personal information about the recipient (ie, the recipient's bank account / bank branch code). Or other identifiers).

  A user may register information in the information directory 128 prior to any financial transaction. Users can be added to the information directory 128 once they register with the money transfer system 100 through the bank computer system 120. Once registered, a new entry for the newly registered user may be created in the database implementing the information directory 128. The user interacts with the user (e.g., just as people selectively and freely share phone numbers and email addresses with such other individuals to communicate with other individuals). One or more identifiers (eg, phone numbers, email addresses, etc.) that can be shared with other individuals may be provided. Herein, such identifiers are referred to as “public identifiers” or “public tokens”. (The terms “identifier” and “token” are used interchangeably herein to refer to a code that identifies a user (eg, email address, telephone number, user-generated or system-generated string, etc.). ) The information directory 128 may be maintained securely and may generate or otherwise be associated with an identifier used to identify the user in the information directory 128. Herein, such an identifier is referred to as a “secret identifier”. The secret identifier can be, for example, a unique ID of the user's database entry in the information directory 128. The secret identifier is known by the information directory 128, but need not be known by the user or other user with which the secret identifier is associated. However, the secret identifier may be known by banks and other entities that are members of the remittance payment network. Account information (account number, bank branch code, etc.) regarding accounts and user preferences held by the bank in addition to public identifiers (eg, telephone numbers, email addresses, etc.), secret identifiers (eg, database UID), etc. Other information can also be stored in the database entry. At least some of this information may be filled in automatically, for example, when the user registers with the remittance system 100 during a secure online banking session with the bank computer system 120.

  In addition, each user's database entry may store the registry of other users associated with that user. That is, for each user, a registry containing a list of each other user with whom the user has an established connection may be stored. Such a connection may be established, for example, the first time a user sends funds or receives funds from other users. The association can also be established by a user interface that allows the user to add associations 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. Users may include not only users registered with a remittance payment network, but also other related payment networks as discussed in more detail below. For each user in the registry, additional information such as the user's unique ID and / or other information may be added. As another example, information about other users may be stored in a separate database entry in information directory 128.

  In various embodiments, there may be multiple information directories, each directory being maintained by a different institution or entity. For example, a user holding an account at a bank associated with the bank computer system 120 may register through the bank computer system 120, and a user holding an account at the bank associated with the bank computer system 150 through the bank computer system 150. The same applies to other users who can register and hold accounts in other entities. Such entities can also include non-bank entities (eg, payment processing companies, credit agencies, credit card network providers, etc.) and users can register through such non-bank entities.

  In addition to the public and secret identifiers already described herein, additional identifiers can also be used. For example, such additional identifiers can be handled at various security levels. As another example, as discussed in more detail below, special public tokens, public tokens with customized functionality, etc. may be implemented using variations of existing public identifiers.

  The token management logic 129 manages tokens. For example, the token management logic 129 may be configured to register tokens, authenticate tokens, generate tokens, and the like. Token management logic 129 may also facilitate recipient identification if the token is not recognized. The token management logic 129 can also be used to customize the attributes of the token so that a specific account is used, a specific notification method is used, and so on. Token management logic 129 is discussed in further detail below in connection with FIG.

  Recipient computer system 130 may be configured generally the same as other computer systems described herein. For example, if the beneficiary is an individual, the computer system 130 is a mobile device such as a mobile phone, smartphone, mobile handheld wireless email device, personal information terminal, portable gaming device, desktop computer, or other suitable device. obtain. Computer system 130 may also include one or more servers each having one or more processors configured to execute instructions stored in memory. For example, such a configuration may be utilized when the recipient is a merchant or other business.

  In one embodiment (eg, the payee is a conventional merchant), the payee computer system 130 includes a point-of-sale device (eg, cash register) equipped to electronically obtain public token information from the customer. System). For example, a cash register system may include an NFC reader device that can read a public token (eg, a mobile phone number) from a near field communication (NFC) equipped mobile phone. As another example, a mobile phone may be configured to generate a barcode or other image including a public token on the display screen, and the cash register system may include a barcode reader configured to read the barcode. . The payee computer system 130 may then request payment from the sender via the money transfer system 100 using a public token obtained at the point of sale.

  The payee bank computer system 150 may be configured similarly to the sender bank computer system 120. Accordingly, bank computer system 150 includes network interface logic 152, account processing logic 154, account database 156, and information corresponding to network interface logic 122, account processing logic 124, account database 126, and information directory 128 of bank computer system 120. Directory 158 is included.

  Payment service computer system 160 may be associated with a payment service configured to facilitate inter-bank remittance, for example, a payment service provided by a non-bank entity as described above. The payment service may be, for example, an entity formed as a joint venture between banks and / or other entities that send and receive funds using the remittance system 100. As another example, the payment service may be a third party vendor. As another example, a payment service may be a web portal provided to such an individual's online community where an individual obtains a username / login ID or otherwise becomes a registered member. Individuals may interact with each other using, for example, a web portal and / or with services provided by an online community. Examples of the online community include MSN (registered trademark), iPhone (registered trademark) user, Facebook (registered trademark), and LinkedIn (registered trademark). The payment service can be, for example, an additional service provided to members of the online community from a web portal. As another example, the payment service is performed by one of the banks, ie, the operations described herein as being performed by the bank computer system 120/150 and the payment service computer system 160. May be provided to perform both of the operations described herein.

  Herein, it is assumed that the banks associated with computer systems 120 and 150 are “member banks”. That is, it is assumed that the banks associated with the computer systems 120 and 150 follow an established protocol for transferring money using the money transfer system 100. For example, for payment services created as a joint venture, member banks may include at least banks that are joint owners of the joint venture and potentially other banks. Although two member banks are shown in FIG. 1, it is understood that there may be additional member banks. Further, as indicated above, non-bank entities can be members. Payment services may also be used by senders and payees who have bank accounts at non-member banks, for example by allowing such users to register directly with payment service computer system 160. Thus, the user does not have to be a customer of any particular bank because the remittance system 100 can be used.

  The payment service computer system 100 executes, for example, instructions stored in the memory, sends and receives data stored in the memory, performs other operations, and associates with the logic or process shown in FIGS. One or more servers each having one or more processors configured to perform the operations described herein. Payment service computer system 160 includes network interface logic 162 and information directory 168. Although not specifically shown, it is understood that payment service computer system 160 may include account processing logic and account database in the same or similar manner as account processing logic 124, 155 and account database 126, 156. Network interface logic 162 may include user interface program logic configured to generate web pages and present them to users accessing payment service computer system 160 over network 140.

  The information directory 168 may be used when identifiers other than bank account / bank branch codes are used (eg, email address, telephone number, common payment identification code (UPIC), random number, etc.). As described above in connection with information directories 128 and 158, information directory 168 is used by the payment service that registers the recipient's mobile phone number (or email address or other token) through the payment computer service system 160. A database maintained to allow conversion to the bank account number / bank branch code of the recipient's bank account. This configuration allows the sender to uniquely identify the recipient (eg, email address) without necessarily having to have private / personal information about the recipient (ie, the recipient's bank account / bank branch code). Or other identifiers).

  Users, including senders and payees, may, for example, pre-register user information in the information directory 168 if such users do not bank with any other member entity or do not have an account with any other member entity. Can register. Further, the payment service computer system 160 may be configured so that a user who wants only remittance can do so without registering. For example, the payment service computer system 160 may display a web page that receives credit card information from the sender and completes the transaction without the sender having to register with the payment service computer service system 160 each time the sender wishes to send money. May be configured to generate.

  As will be appreciated, the information stored in the information directory 168 can vary depending on the embodiment, including the degree to which the information is also stored in the information directories 128 and 158. For example, in one embodiment, when a user registers with bank computer system 120 (or bank computer system 150 or another member entity's computer system), the information may be stored in both information directory 128 and information directory 158. The information directory 128 may store complete identification information of the user's bank account and other information collected during registration. Conversely, the information directory 168 may store smaller amounts of information such as registered public tokens, associated financial institutions, and secret tokens (eg, unique IDs) associated with each token. More detailed bank account numbers / bank branch codes or other sensitive information need not be stored in the information directory 168. In another embodiment, instead of using the payment service computer system 160 to maintain the information directory 168, such information is generally stored in information directories 128, 158 maintained by individual member banks. Can do. As will also be appreciated, the degree to which transaction details are tracked and maintained in account processing logic 124, 154 is compared to the degree to which transaction details are tracked and maintained by payment service computer system 160. Can vary.

  An automatic clearinghouse (ACH) system 170 is used to exchange funds with sender and recipient bank accounts. As is known, the ACH network is a nationwide batch processing oriented electronic money transfer system that is provided for interbank settlement of electronic payments of participating deposit savings financial institutions. An ACH entry can begin with an account holder (known as a recipient in ACH terminology) authenticating an originator (eg, an individual or company) to issue an ACH debit or credit to the account. . In response to an ACH transaction, the originator must receive authentication from the receiver. According to ACH rules and regulations, a financial institution will not issue an ACH transaction to an account (regardless of deposit or credit) without pre-authentication from the receiver. When the authentication is received, the originator creates an ACH entry that is given to the originating trustee (ODFI), which can be any financial institution that performs ACH origination. This ACH entry is then sent to the ACH operator (ie, the central settlement facility where the financial institution sends or receives the ACH entry) and passed to the receiving trust financial institution (RDFI), where the receiver's account is the ACH Issued either by credit or deposit depending on the transaction. However, the RDFI may reject the ACH transaction and return the ACH transaction to ODFI with appropriate reasons, such as the account holder indicating that funds in the account were insufficient or the transaction was not approved. The RDFI has a defined amount of time to execute a return (eg, 2-60 days from receipt of an ACH transaction). The ODFI that receives the return of the ACH entry may re-present the ACH entry for settlement more than once or a total of three times. Again, RDFI may reject the transaction, after which ODFI no longer represents the transaction via ACH. The above description of the ACH system is currently in use, and embodiments of the present invention continue to work in the same way even if some methods and steps in the ACH system are changed.

  Referring to FIG. 2, FIG. 2 shows the token management logic 169 in more detail. As shown in FIG. 2, token management logic 169 includes sponsor identification or sponsor search logic 182, registration logic 184, token authentication logic 186, rules engine 188, and token generation logic 190. Although token management logic 169 is shown, it is understood that token management logic 129 and 159 may be configured in the same or similar manner.

  Sponsor identification logic 182 may be configured to identify the sponsor of the token. For example, if the sender uses a token to identify a recipient that is not recognized in the information directory 128 of the sender bank computer system 120 (ie, because the recipient is not a customer of the sender bank), 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 a unique ID and financial institution identification information associated with the token.

  As will be appreciated, 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 is such that the information is also stored in the information directories 128 and 158. As well as the degree to which that information is stored in the information directory 168. In various embodiments, the information directory 168 may be relied upon to a greater or lesser extent in order to perform centralized user identification functions in connection with transfers between entities. Herein, to provide an example, it is assumed that the information directory 168 is used to centralize and perform user identification functions in connection with transfers between entities. In such embodiments, it may be possible to avoid duplicating all the functions of sponsor identification logic 182 and bank computer systems 120, 150.

  In one embodiment, the remittance payment network is configured to interact with other related payment networks (eg, PayPal®, CashEdge, etc.). In such a configuration, if the token provided by the sender bank computer system 120 is not recognized in the information directory 168, the sponsor identification logic 182 sends a query to other relevant payment networks (eg, in a predetermined sequence). ), Configured to identify whether the token is recognized by any of the other related payment networks. If the payee is registered with another payment network, it can be transferred to the payee by routing funds through the other payment network. In embodiments where a user lookup service is provided by the information directory 168, the lookup service may operate in the same way to identify users registered with the remote entity. Information identifying the payment network identified as being associated with the token can also be stored in the information directory 168, thereby assisting further transfers to the token in the future. Thus, such a configuration may push funds to a recipient who is not registered with the remittance payment network but rather is registered with another payment system. Further, such funds may be pushed to the recipient without the sender needing to know or consider whether the recipient is registered with the remittance payment network.

  Registration logic 184 is configured to facilitate the process of registering new users. For example, in the discussion above, if the token is recognized in the information directory 168 and is not registered with any other associated payment network, the registration logic may send an email or other message to guide the recipient to register with the payment network. May be configured to send the communication to the recipient. Such email may include a link to a website provided by payment service computer system 160. Registration logic 184 may be configured to generate a web page that is presented to the user at the website to facilitate the registration process. When registering on a website, if the user is identified as one customer of a member entity based on information provided by the user, the user may visit the member entity's website to complete the registration process. Can be transferred. As will be appreciated, the registration logic 184 may be useful for other scenarios (eg, if a user visits that website as a result of a search engine query, the user may enter another website (eg, an online community website or merchant website). The web page can also be presented to the user, for example, when the web site is visited via). Registration logic 184 may create a new database entry in information directory 168 representing the input received from the user.

  The token authentication logic 186 is configured to authenticate the token. For example, when a user registers a new token, the token authentication logic 186 indicates that the user is associated with the token (eg, the user attempting to register a mobile phone number as a token actually owns the mobile phone number). Can be configured to confirm that the person is a person. (In this specification, the term “owned” with respect to a telephone number refers to a telephone number being assigned to one particular user as opposed to being assigned to another user, And the telephone carrier that provides the user with the phone number, which is not used to refer to ownership. This term is used with respect to email addresses as well). As another example, if the user attempts to register a new email address, the authentication logic 186 may perform an authentication operation such as sending a new email to the user with the new email address. The email may include, for example, specific links that the user must access to successfully complete the registration process.

  Further, token authentication logic 186 may be configured to perform an authentication operation on previously registered tokens. For example, a user who registers a mobile phone number may eventually switch between mobile phone numbers and / or mobile phone carriers. The token authentication logic 186 may be configured to process a cancellation directory that lists the mobile phone numbers published by the mobile phone carrier and canceled by that carrier. For example, if a registered mobile phone number is listed as canceled, the token authentication logic 186 sends an email to the user's registered email address, and the mobile phone number is no longer in the user's registered email address. It may be determined whether it is not a valid token or whether the user has just changed the mobile phone carrier but maintains a mobile phone number.

  The token authentication logic 186 is uncertain as to whether or not another user is the correct owner of the token to a user who uses the token to send money to / receive money from another user. If so, it can also be configured to send a follow-up communication. For example, the token authentication logic 186 notifies the sender that such uncertainty exists, requests the sender to provide confirmation information provided for the recipient, and provides additional information about the recipient. And so on. For example, if the user is token jsmith @ abc-company. com to transfer money using the token jsmith @ abc-company. If there is uncertainty about whether the ownership of the com has changed (eg, due to a change in ABC employees), an email may be sent to the user. Authentication logic 186 may also be configured to access other networks or online communities (eg, Facebook ™, LinkedIn ™, etc.) to obtain additional information that can be used to authenticate the token. it can. The token authentication logic 186 may also be configured to track a changing public token according to the date and time of use and the date and time when a particular recipient has stopped using a particular public token.

  Thus, registration logic 184 and authentication logic 186 work together to facilitate registration of the token and ensure that the token is associated with the correct owner. In one embodiment, the entity that registers the token is responsible for ensuring the validity of the registration. For example, if the payee bank registers token 415-555-1226 and subsequently accepts payment to the user who registered token 415-555-1226, the user who registered token 415-555-1226 is actually When the transfer is not the owner of the mobile phone number (for example, because the previous owner changed the mobile phone number and the new owner is in a different payment network), the receiving bank returns money to the sender. Take responsibility for funding. Accordingly, the receiving bank is responsible for correctly authenticating the user at registration and processing the cancellation directory on a daily basis to ensure that the authentication remains valid.

  In one embodiment, the guarantee (and / or limited access to the information directory 168) may be provided as a service to a third party. For example, an online reseller who is refinancing money to a customer may wish to confirm that the token previously provided by the customer (eg, “415-555-1226”) remains accurate. If the funds are refunded to the customer at the “415-555-1226” token, but the customer no longer owns the token, the payment service is responsible for refunding the funds to the correct customer. The fee charged for the service may be based, for example, on the dollar value of the responsibility that the payment service accepts for providing inaccurate information. As another example, a fee per token is imposed to identify a user based on the token and / or to identify a token (eg, email address, mobile phone number, etc.) based on the user's identification information. Services can be provided.

  The rules engine 188 may be configured to allow a user to configure different attributes for different tokens. Attributes can be specified by rules configured based on user-specified preferences. In various embodiments, the rules engine 188 may provide the user with default settings that are used until the user chooses to customize the rule. For example, the rules engine 188 may be used to configure a method that is directed to various accounts held by a user at a bank (eg, transferring at least a portion of funds or transferring money to a particular type of account), etc. . As another example, the funds may be divided into multiple accounts according to rules specified by the user, for example, the funds may be at least one of a retirement account, a savings account, a PayPal® account, or a certificate of deposit. Can also be transferred to one. As another example, some of the funds received may be transferred to a different user registered with the payment network. As another example, the rules engine 188 may be used to configure a method in which a notification is sent to a recipient notifying the recipient that a remittance request was made by the sender. For example, according to one embodiment, the rules are configured to specify the channel (email, text message, voicemail, etc.) on which the notification is sent, the email account and / or phone number etc. on which the notification is sent. Can do. As another example, if the transfer amount is greater than the threshold, the user may receive an automated telephone call instead of an electronic message, or may receive an email / phone call instead of no message. As another example, if the remittance request originates from a specific sender, the user can specify a notification mode (eg, email, voicemail, or text message). As another example, the rules engine 188 may be used to determine the payment channel (eg, ACH transfer, credit card network, PayPal® network, printed and mailed check, etc.) used to send money to the recipient. Can be configured. As another example, the rules engine 188 may be used to configure the speed at which money is transferred to the payee (eg, immediate, same day, next day, next day payment, etc.). As another example, the rules engine 188 may be used to configure trading limits (eg, charging a particular token with an amount greater than $ 500 during a predetermined time period such as one day, one week, one month, etc. To ensure that you can't).

  The token generation logic 190 may be configured to generate an additional public token for the user. The token generation logic 190 may cooperate with the rules engine 188 to create different tokens configured with different attributes. For example, a company may want to use different individual tokens depending on who in the company is responsible for a particular transaction. For example, a beneficiary who owns several apartments may wish to create a different token for each apartment. For example, the additional token may be based on a user-provided alphanumeric string, may be generated by the system based on a pseudo-random alphanumeric string, or may be generated otherwise. For example, if a landlord payee already uses an email address as a public token (eg, landing@mail.com), the additional public token is a variant of the public token already used by the payee ( For example, landlord@mail.com/building1, landlord@mail.com/building2, landlord@mail.com/building3, etc. Such tokens can then be configured with different attributes using rules engine 188. For example, if each different building has a different building manager, when an apartment tenant pays rent, an email may be sent to the email address of each building manager in that particular apartment.

  As another example, a landlord payee may provide each tenant with a different public token that the tenant uses to pay rent. Again, for example, the additional token can be a variant of a public token already used by the recipient (e.g., land@mail.com/unit 101, land@mail.com/unit2, land@mail.com/ unit3 etc.). The bank computer system 150 may then receive funds from each tenant and all funds may be sent to one or more accounts belonging to the landlord. Account processing logic 154 generates a report showing the funds received in connection with each token (for example, which tenant paid in a given month and which tenant still paid in a given month) To indicate whether or not). The token can also be programmed with additional information, such as an expected monthly payment. The account processing logic 154 is then configured to compare the actual amount received with the expected monthly payment to ensure that the tenant has paid completely and track the entire tenant's account status Can do.

  As another example, the recipient can configure a disposable token. For example, a recipient may have an event in an organization where other users are expected to contribute financially to the event. In that case, the recipient may construct a token (e.g., johnsmith@mail.com/moms-birthday-party) that may be provided to other users. Account processing logic 154 may then generate a report showing funds received from each of the other users associated with the token.

  As another example, a sender can configure different tokens. For example, if the sender uses the first token as the default token (eg, John Smith@mail.com) and the payment is to be made from another account, an additional dedicated token (eg, lesson from college expense funds) Johnsmith@mail.com/collegesavings) for making payments.

  As another example, as described above, the information directories 128, 158, 168 may provide a lookup service that a user can use to establish connections with other users. In such embodiments, the user may be able to configure aspects of the token that are displayed to other users. For example, if an individual is doing business under a different name (eg, Joseph Smith DBA “Joe's Lawn Mowing Service”), even if the name of the account is actually an individual name, It may be desirable to allow a user to configure a token for display to other users. In this way, business customers can more easily establish business ties.

  Referring to FIGS. 3A and 3B, FIGS. 3A and 3B illustrate a process by which funds can be received by registered or unregistered recipients according to example embodiments. In FIGS. 3A and 3B, a remittance message is received from the sender at the sender bank computer system 120 and propagated to the payee bank computer system, where the funds are deposited into the payee's account. In particular, in step 301 of FIG. 3A, the sender bank computer system 120 receives a request for money transfer from the sender to identify the recipient using the token. In step 311, the bank computer system 120 searches the information directory 128 to determine whether the token is associated with a user registered with the sender bank (ie, is a transfer within the same bank). . If the token is associated with a user who has registered with the sender bank, at step 313 the payee's account information is obtained from the information directory 128. Subsequently, in step 315, it is sent to the payee's account. As discussed in more detail below in connection with FIGS. 4-6, a remittance may be made to a payee's financial account based on the sender's and payee's preferences.

  In step 311, if the payee is not registered with the sender bank, the process proceeds to step 321. In step 321, the bank computer system 120 sends an inquiry to the payment service computer system 160 to identify whether the token is associated with a user registered with another member entity of the remittance payment network. For example, if the sender is the first to send money to this particular recipient, the bank computer system 120 may transfer the recipient's public token provided by the sender. In this scenario, sponsor identification logic 182 may perform a search of information directory 168 to determine whether the token is associated with a user who has registered with another member entity. If the public token is in the directory, the payment service computer system 160 may return a unique ID associated with the public token along with the identity of the financial institution or other member entity associated with the sender bank computer system 120. . The sender bank computer system 120 may then create another registry entry for the sender and store the recipient's public token and unique ID as part of the registry entry. The sender bank computer system 120 may also prompt the sender to provide other information about the recipient (eg, a nickname or other name that the sender wants to identify the recipient).

  As another example, if the sender has previously transferred money to this recipient, the bank computer system 120 may transfer the recipient's unique ID to the payment service computer system 160. In this scenario, sponsor identification logic 182 may find a recipient in information directory 168 using the unique ID as an index into the database implementing information directory 168. Assuming that the unique ID is still valid and still in the information directory 168, the payment service computer system 160 may return a financial institution or other member entity associated with the sender bank computer system 120. As another example, if the sender has previously transferred money to this recipient, the bank computer system 120 identifies the associated member entity based on the unique ID itself (eg, the unique ID is Embedded with information identifying the financial institution). In step 323, the sender's registry is updated to include the recipient's entry, including the recipient's unique identifier. In step 325, the money is transferred to a member entity (eg, the payee bank in the example of FIG. 1) and credited with the payee's unique ID. Based on the unique ID, the information directory 158 may be accessed by the payee bank computer system 150 to identify the payee's account number. The funds can then be deposited into the recipient's bank account.

  In step 321, if the payee is not a user registered with another member entity of the remittance payment system, the process proceeds to step 331 shown in FIG. 3B. In step 331, sponsor identification logic 182 of payment service computer system 160 sends a query to another payment network (eg, PayPal®, Star, Blink, Interlink, Plus, etc.) and the token is another payment. Specify whether it is associated with a user registered in the network. For example, sponsor identification logic 182 may send an inquiry to a first payment network to inquire whether the recipient is registered with that payment network. If not registered, sponsor identification logic 182 may continue to send additional queries to other related payment networks until the payment network in which the payee has registered the account is identified. In step 333, if the payee is registered with another payment network, information identifying the payment network identified as being associated with the token may also be stored in the information directory 168, so that its future It may facilitate additional transfers to the token. Next, in step 335, the funds may be transferred to the payee by routing funds through the other payment network. Thus, in such a configuration, funds may be pushed to a recipient who is not registered with the remittance payment network without having to know or consider whether the recipient is registered with the remittance payment network.

  After the other payment network search is completed, if the other payment network with which the payee is registered is identified, the payee is assumed not to be a registered user of any payment network. Accordingly, in step 341, an invitation to join the payment network is sent to the recipient. For example, if the token used by the sender is an email address, an email is sent to the recipient notifying the recipient that the other user is about to send money and inviting the recipient to join the payment network. Is done. A link in the email may be directed to a website provided by the bank computer system 120, for example, with the recipient. As another example, if the token used by the sender is a mobile phone number, a text message may be sent to the recipient that includes a URL that invites the recipient to join the payment network. As will be appreciated, in other situations, such as when the recipient is not a registered user of a remittance payment network, such referral letter to the recipient even when the user is a registered user of another payment network. Can be sent.

  In step 343, the payee may be prompted to provide account information. In step 351, it may be determined whether the user is a customer of the member entity based on the account information. For example, the bank branch code of the checking account can be used to identify whether the user is a customer of a member entity. If the payee is a customer of the member entity, at step 353, the payee may transfer to the member entity (eg, payee bank in the example of FIG. 1) for registration. In the information directory 158 of the payee bank computer system 150 and the information directory 168 of the payment service computer system 160, a unique ID is associated with the payee. In step 355, the sender's registry is updated to include the recipient, including the recipient's unique identifier. In step 357, the money is transferred to the payee.

  If the payee is not a member entity customer, then in step 363 the payee is registered by the payment service computer system 160. In step 365, the sender's registry is updated to include the recipient's entry, including the recipient's unique identifier. In step 367, the money is transferred to the payee. As will be appreciated, if the payee has a customized remittance preference, the remittance may be processed by the rules engine 188 according to the payee preference. Examples of token customization that reflects such preferences have already been described above in connection with the rules engine 188 and token generation logic 190.

  FIG. 4 is a screen example of a web page 400 that can be provided to the user when the user selects a preference tab. Web page 400 may be used to configure preferences in connection with token management logic 129, 159, or 169 (depending on where the user registers with the payment network). The web page 400 includes a plurality of fields including a default notification setting field 401, a connection management field 411, and a recipient management field 431. A default notification setting field 401 presents information regarding the current default notification setting of the remittance event to the user. As shown in the screen example of FIG. 4, the notification setting field 401 includes a telephone number (field 403) to which an automatic telephone notification or a text message notification is to be transmitted and an e-mail address (field 405) to which an e-mail notification is to be transmitted. Can include specified settings. The user may also be allowed to specify the name of the account (field 407) to be seen by the other user when the other user receives the remittance notice. The information specified in field 407 may also be used in other situations, such as when other users are searching for a connection through a service search in information directories 128, 158, 168. The user may configure the rules engine 188 to notify the user about the transaction based on user preferences received from the user before the transaction occurs. If the user fails to configure customized notification settings, the default notification settings may be used. In various embodiments, the user may select different / custom notification settings for each token that the user registers.

  In the example shown in FIG. 4, the telephone numbers that can receive a call, text message, or voice message when a predetermined event occurs are 949-555-7878. In addition, an email address that can be used to notify the user that a transfer has been made to or from the user's account is pat @ mail. com. The user may select notification via email, phone, or both.

  The token field 413 may display a specific token that the user has registered or is in the process of registering. The status field 415 may indicate whether the token is verified / unverified or active / inactive. The money receipt field 417 is derived in part from the information in the status field and indicates whether a particular token is currently available for sending / receiving funds. For example, in the case of an inactive phone number (ie, 650-555-5555), the user may send / receive funds using this token in associations established before the token becomes inactive. However, the user cannot establish a new connection with another user based on this token. For example, this may be a mobile number that the user previously owned. Since unique IDs serve as the basis for remittances after the associations are established, previously established associations are still valid (because those associations are based on unique IDs rather than mobile numbers) It is not allowed to establish a new connection (since another user may be using the token at that time).

  Account number field 419 may display the account type and the partial account number of the account associated with the token in field 413. Accordingly, funds sent / received using the token specified in field 413 are withdrawn / deposited into the account specified in field 419. If the account number is not related to the email address or mobile number in field 413, account number field 419 may display a message such as "Account not specified". Notification field 421 may indicate whether the default notification setting specified in field 701 should be used for notification or other / customized settings should be used.

  The action field 423 may include various links that allow the user to take various actions. For example, a link can include editing, deleting, and verifying. If the token status has been verified, the edit field allows the user to edit the token attributes as specified in the rules engine 188. For example, account and notification preferences (fields 719 and 721) may be edited in more detail. If the account number is verified, a delete link can also be displayed. If the account is unverified or inactive, an email or SMS may be sent and a verification link displaying the verification code may be displayed. Edit and delete links can also be displayed in unverified or active emails or phone numbers. The user can also add a new token using the new tied link 425.

  As is apparent from fields 401 and 411, separate payment and notification channels may be used for the transfer. For example, in the case of 415-555-4001 tokens, the payment channel is through 415-555-4001 tokens, but the notification channel is 949-555-7878 and pat @ mail. com tokens. Further, if the user decides to set up a custom notification channel for the 415-555-4001 token, the user can do so without interfering with the binding already established using the 415-555-4001 token. . Blocking one channel (eg, due to a token change) does not affect other channels.

  The association management field 431 allows the user to perform various functions related to managing the association of the user with other users. Field 431 shows the binding registry established by the user. Within field 431, various information about each other user, such as name (field 433), nickname (field 435), e-mail / mobile (field 437), status (field 439), and action (field 441). As well as a link that allows the user to add a new recipient 443. Although not specifically shown, it is understood that each user's unique ID can also be displayed in the registry shown in field 431. As described above, the unique ID does not need to be known by the user and is maintained more safely.

  Name field 433 may be the name of a recipient (eg, specified by the other user) displayed in an account associated with the other user. Nickname field 435 may be a nickname assigned to the other user (eg, specified by the user). The email / mobile field 437 may display the public token that the recipient is using. Status field 437 may indicate whether a permanent connection has been established for a particular communication. The action field 441 may be determined based on the status field. For example, if a link is established, the action field 441 may display a link that allows the user to send money to the payee. If the link is not established, the action field may display a send money link, but the action field 441 may also display a detail display link. The detail display link may display another screen to the user, which may provide further details for the user to establish a connection with the recipient. Other actions that can be displayed are edit and delete. Editing may allow the user to edit each of the fields described above, and deletion may allow the user to delete the recipient and associated information from the user's registry. Link 443 may be used to add additional users to the registry, for example, through a search of information directories 128, 158, and / or 168.

  In an example embodiment, the binding management field 431 may present a message to the user notifying the user that another user is no longer the owner of the token. The message may include a link that allows the user to update the token information. In other embodiments, if other users' information has changed, the message presented by the association management field 431 may allow the user to update the old information.

  FIG. 5 is an example form screen that allows the user to update default or custom notification settings. In FIG. 5, a list of email addresses associated with the user's account is provided to the user. The user may use a checkbox to indicate which email address should receive the notification. For example, the user in the screen example shown in FIG. 5 has selected the e-mail address “psmith@google.com” by placing a check mark 505 in an appropriate field. In other embodiments, instead of selecting one email address, the user may select multiple email addresses. The example screen also shows a telephone number associated with the user account. A user may use checkmark 509 to select a phone number to receive notifications. In other embodiments, the user may select multiple phone numbers and multiple email addresses for notification. Link 511 may allow the user to add an email address or phone number to the account information maintained by the bank. In one embodiment, the user may select a link and automatically display to the user a web portal provided by the banking institution. The user can click save button 513 to save the notification changes implemented by the user.

  FIG. 6 shows a screen example of a web page 600 that can be presented to the user when the user selects the remittance tab. Web page 600 may include a remittance field 601 that a user can fill out to transfer money to a selected recipient. Web page 600 may include an indication of various payment channels 619 available to the user. The web page 600 may also include a field 630 that shows details regarding recent transactions that are pending, returned or completed.

  The remittance form 601 may prompt the user to select a recipient from a pull-down menu 603. The list of recipients presented using menu 603 may be filled using the list of recipients included in field 431 discussed in FIG. The list in the recipient menu 603 may include the name of the user who has remittance or received funds in the past or the name of the user added in another way. In one embodiment, the recipients may be identified by a nickname assigned to each recipient. Because the nickname can be directly correlated to a unique ID in the token management logic 129, account information can be derived from the nickname via the unique ID. Therefore, as described above, the connection between the two users is not hindered if the mobile phone number or email address becomes obsolete. After selecting the payee, the user can select an account that can be transferred to the payee using the drop-down menu 605. The drop-down menu can be pre-filled with a list of all accounts held by the user. The user may enter in the amount field 607 the dollar price that the user wishes to transfer to the payee. The user's name may be presented with an optional field description 609 that allows the user to confirm that the payment is for a specific product or service provided by the recipient. Can be confirmed. Another field may automatically fill in the user's name as a sender. The nickname field 611 is also displayed when the recipient knows the user by a name different from the user's name found in the user's account. The remittance form 601 also displays a link 615 that allows the user to add a recipient, a link 617 that allows the recipient to be managed, and a link 613 that allows the current notification preferences to be edited.

  The payment channel form 619 presented to the user may allow the user to select various payment channels such as credit card, ACH, or PayPal®. A receive available funds field 623 may also be displayed with each payment channel. For example, the credit card method may fund the recipient within two days of the transmission request process. However, the user may be charged a fee as indicated by field 625, eg, $ 5.00. In another example, the user may select an ACH in field 621, but funds may be provided to the recipient within 4 days without a fee. Other payment channels such as PayPal®, Star, Blink, Interlink, and Plus may be presented to the user.

  Field 630 shows a small number of the latest transactions executed by the user. Additional recent transactions may be displayed through the selection of a link that displays more transfers and / or by selecting the Transfer Activity tab. Field 630 may display various fields that contain information about the transaction. For example, such fields may include a remittance date field 633, a remittance source field 635, a payee field 637, an amount field 639, a description field 641, a status field 643, and an action field 645. The remittance date field 633 lists the date when the user started the remittance request. The source account field 635 may display the account type (ie, current, regular, or financial market) and partial account number. Recipient field 637 may display the full name of the recipient. Amount field 639 displays the dollar price sent to the payee. The description field 641 displays the description entered by the user while processing the request. Status field 643 may inform the user whether the transfer is pending, returned, not processed, or completed. The action field 645 may display a link that allows the user to view further details regarding the current status of the transfer.

Payments Outside the Network In an alternative embodiment to FIGS. 3A and 3B, the sender is a registered user of any member of any payment network-whether it is a remittance payment network or other existing payment network. It may be possible to transfer money to a non-recipient. A user at a participating bank (ie, the sending bank) is desired to send money to the desired recipient's token (eg, mobile phone number or email address) and recipient, for example, through the sending bank's online interface. Enter the dollar price. The dollar price and token are then sent to the remittance payment network for verification services. The remittance payment network cannot find a token match in the payment network directory because the payee is outside the remittance payment network or is not part of any known payment network, or both . In response, the remittance payment network sends a message to the remittance bank indicating that the token is unknown. The remittance payment network also generates pending payments, which may include some or all of the following fields: unknown token, remittance bank, dollar price, user name, and payee name.

  The remittance bank then sends the message to the recipient using the token. For example, the remittance bank may send a message to the recipient that the sender wishes to send money to the recipient. Alternatively, the remittance payment network sends a message to the recipient. If the payee is not a registered user of any member of any payment network, the payee may be directed to a link to a remittance payment network website to register and begin the process of receiving pending payments. If the token entered by the sender is the recipient's email address, the recipient receives the link at the email address. If the token entered by the sender is the recipient's mobile phone number, the recipient receives the link at the mobile phone number.

  FIG. 7 shows a screen example of a web page 700 as an example that can be presented to a recipient when an invitation with a link is allowed. As shown in FIG. 7, the payee is prompted to enter a token at the location where the payee was notified of the pending payment. The user enters a token into a field in web page 700. The remittance payment network checks the entered token against the pending payment. In one embodiment, the payee can proceed only if the entered token matches an unknown token of the pending payment.

  In one embodiment, a recipient who is not registered with any member of the remittance payment network can join the remittance payment network and receive funds only if the registered remittance invites the unregistered recipient. it can. To enable a recipient to participate in a remittance payment network, the recipient's information and account ownership may need to be verified and collected. Thus, it should be understood that in order for an unregistered off-network recipient to participate in a remittance payment network, the remittance payment network may need to verify that the payment is pending. As used herein, “out of network” refers to a user of a financial institution that is not a member of a remittance payment network. Alternatively, “out of network” may refer to a financial institution that is not a member of a remittance payment network. In order for an off-network user to participate in a remittance payment network, the in-network user must send funds to the off-network user. This may avoid fraud by ensuring that all users or entities involved in the transaction can be verified. In addition, fraud and fraudulent transactions are further reduced or eliminated because off-network users must be invited to the remittance payment network by in-network users.

  Once the payee registers with the remittance payment network, the remittance payment network may send the payee's bank account information to the sending bank to complete the initiation transaction. The transaction can be completed, for example, via ACH. As is known in the art, ACH transactions can be “pull” or “push” transactions. If a user in the network sends money to a user outside the network, the remittance bank may use a push transaction.

  When the payee becomes a registered user of the remittance payment network, the remittance payment network and remittance system 100 may maintain information about the payee in an off-network database. FIG. 8 shows an exemplary remittance system 800. The remittance system 800 is similar to the remittance system 100, but the payment service computer system includes an off-network database 167. Off-network database 167 may store information collected during financial transactions involving off-network users. For example, the remittance payment network may perform a remittance to an off-network user and store bank information about the off-network payee in an off-network database 167. In one embodiment, remittance system 800 may store off-network user token and bank account information in off-network database 167.

  In an alternative embodiment, remittance system 800 stores off-network user bank account information in off-network database 167 but does not store off-network user token information in off-network database 167. Instead, the remittance payment network associates a secret identifier with the recipient, as described above. The secret identifier may be stored in the information directory 168. Alternatively, the secret identifier may be stored in the information directory 128 or the information directory 158. Accordingly, the user token information is stored in a directory separate from the off-network database 167, for example, the information directory 168, and the user bank account information is stored in the off-network database 167. It should be understood that this alternative embodiment increases user security by not storing the user's token and the user's bank information in the same database. It should also be understood that the public information is not stored with the user's bank information, thereby reducing the risk of fraud or theft. Thus, the remittance payment network can securely process off-network payee payments and transactions by using the secret identifier to match the payee's token with the payee's bank information.

  In one embodiment, the information directory 168 does not store bank account information. Although the off-network database 167 is shown external to the payment service computer system 160 in FIG. 8, in one embodiment, the off-network database 167 may reside within the payment service computer system 160.

  In future transactions involving payees, the remittance payment network uses an off-network database 167 to facilitate remittance of funds from members. FIG. 9 is a flow diagram illustrating an example process 900 for facilitating payments or transfers to off-network recipients in accordance with an example embodiment of the present invention. Although the process 900 will be described with reference to the flowchart shown in FIG. 9, it will be appreciated that many other ways of performing the operations associated with the process 900 can be used. For example, the order of many of the blocks can be changed, certain blocks can be combined with other blocks, and many of the described blocks are optional.

  In order to pay off-network recipients whose information is already stored in off-network database 167, the data is sent or paid using remittance computer system 110, payment service computer system 160 including off-network database 167. It can flow between the network and the recipient computer system 130. The sender may desire to use the token to send money to the recipient, as shown in block 902. The remittance bank sends the token and dollar price to the remittance payment network. The remittance payment network notes that the token is for an off-network recipient, as shown at block 904, and sends a message indicating that the recipient is an off-network recipient, as shown at block 906. Send to remittance bank. As shown in block 908, the remittance bank may send a confirmation to the remittance payment network to continue the transaction. Upon receipt of the confirmation, the remittance dominating network accesses a separate off-network database 167 as shown in block 910. The remittance system network checks the token against the recipient's bank information stored in the off-network database 167, as shown at block 912. The remittance payment network encrypts the recipient bank account information and transmits the recipient's bank account information opaquely to the remittance bank, as shown at block 914. The remittance bank decrypts the payee's bank account information and sends the payee's bank account information and any other information necessary to complete the transaction to ACH 170.

  The remittance system 100 also enables communication to non-customers of financial institutions. For example, when a bank becomes a member of a remittance payment network, the bank may be able to send messages to users who are not customers of the bank. Therefore, the remittance payment network can act as a communication mediator. For example, if a new user is prompted to sign up and register with a member entity, the user may be presented with a screen that explicitly gives the user approval to send a message. In other words, the user must, in one embodiment, agree to receive messages from members as a condition of participating in the remittance payment network and remittance system 100. Thus, when a user signs up, the user can be contacted by other members.

  In one embodiment, a financial institution that is a member of a remittance payment network can send money to a non-customer, receive funds from a non-customer, and request funds on behalf of a customer. Accordingly, it should be understood that a financial institution that is a member of a remittance payment network can help its customers do business with other entities that are not customers of that financial institution.

  In one embodiment, the remittance system 100 may track payment status and provide notifications about payment status to the sender and recipient.

  In one embodiment, the information is encrypted by the sending bank and decrypted by the receiving bank, so that the payment network does not have access to either the sender information or the recipient information. For example, the remittance bank may use an encryption algorithm known by the receiving bank but not known to the remittance payment network. In this case, the remittance bank encrypts the account information before any information is given to the payment network. The payment network processes the information, including transferring the encrypted sender information and recipient information to the receiving bank. The receiving bank knows how to decrypt the encrypted information. In this way, the payment network cannot access any information communicated from one bank to another. Therefore, the remittance is totally opaque from the remittance payment network.

  In one embodiment, remittance system 100 relies on a bank's existing fraud system to manage risk. In one embodiment, the payment system does not actually transfer any money from one entity to another or from one bank to another. There is no account owned by a payment service that can hold money even for a temporary period. In one embodiment, the payment system only facilitates transfers from one bank to another.

  In one embodiment, the remittance system 100 or remittance payment network may send payments from users outside the network to users within the network. The remittance payment network may create a separate off-network database that stores information about the off-network sender, or may utilize an existing database.

  In one embodiment, a member bank user may be able to present a bill or invoice using the remittance system 100. Invoices may be presented to consumers of products or services offered by member bank users. A consumer can be an in-network user or an off-network user. Invoice presentation includes electronic files, such as Adobe PDF® documents, Microsoft Word® documents, text files, image files, or any other suitable document that displays the invoice to the consumer. obtain. An electronic file, such as an Adobe PDF® document, may include a due date provided by the claimant. In one embodiment, remittance system 100 may present other items besides a bill, such as, for example, a mortgage document, a business document, a subpoena, or a patent application document or application.

  The remittance system 100 can also be used to securely present a document when the bank identifies the identity of the consumer receiving the document. The sender can also use the bank to verify receipt of the document. In one embodiment, the biller can track whether the consumer has received a bill. For example, the biller may receive a notification from the remittance system 100 that the consumer has received the bill. The remittance may also be able to confirm that the consumer has viewed the bill, for example, opened or accessed the electronic file on a computer or mobile phone. It should be understood that verification or tracking of receipt is useful because the consumer can confirm that the consumer has received the invoice and the consumer cannot deny that it has been received.

  In the case of in-network bill presentation, the claimant sends a money request, bill, or invoice to the remittance payment network. The request or bill includes a token that identifies the bill recipient or consumer. The claimant attaches the request ID to the payment ID and sends the bill to the remittance payment network. The claimant may also be able to add payment instructions to the bill. The remittance payment network routes bills or invoices to consumers based on the tokens. In response, the consumer pays. The remittance payment network then notifies the claimant of the payment. The payment ID is sent to the bank and then verified against the account. It should be understood that the claimant or the claimant's bank need not have the consumer's bank branch code and account number, thereby increasing the security and convenience of the consumer and the claimant.

  For off-network consumers, instead of sending the payment ID along with the request ID, the remittance payment network provides instructions to the billing bank to debit the account. The remittance payment network also provides the biller's bank with the payment ID and request ID plus the consumer's ACH information for debiting.

  In one embodiment, the off-network user may be able to send the payment to the member bank customer even if the member bank customer does not send a payment request to the off-network user. Thus, registered off-network users, ie users found in off-network database 167, can send money to member bank customers. A member bank customer can receive money using the channel selected by the member bank customer. It should be understood that member bank customers do not need to provide sensitive information, such as bank account numbers, to users outside the network who wish to receive money. Remittance system 100 can be used for debit transactions, electronic money transfers, credit card transactions, Amazon® payments, payments facilitated simply via email, business-to-business or business-merchant payments, early payments, and rents, housework, Or it can be used for regular payments such as weekly babysitters. In one embodiment, the remittance payment network verifies account access via a trial deposit. The remittance gives the transaction amount, and the remittance system 100 verifies that the off-network remittance can access the account and authorize the deposit transaction.

  In one embodiment, an off-network user who sends money may receive a money transfer limit. The remittance limit may be every day, every repeated 7 day time period, or every repeated 30 day time period. Remittance limits can be enforced for each off-network user regardless of payee. If the off-network user attempts to send a payment that exceeds the remittance limit, the remittance system 100 may notify the off-network user that the payment exceeds the remittance limit. In one embodiment, the remittance payment network may charge a transaction fee when an off-network user sends money to a member bank customer.

  The decision to accept and execute remittances from non-network consumers who wish to remit can be managed by the member bank, ie the bank of the user in the network receiving the money. As described above with respect to off-network database 167, off-network users must register for off-network services before they can transfer money to member bank customers. Thus, a registered off-network user may be able to both initiate payments to member bank registered customers and respond to monetary requests (eg, invoices) from member bank customers. Want to be understood.

  Debit transactions from bank accounts of users outside the network can occur via ACH rails by member banks. In one embodiment, a member bank requires at least one of the following to process a transaction via the ACH rail: sender name, transaction amount, transaction fee, recipient profile ID, remittance Name, payment remarks, start date, bank account number, bank branch code, and account type, such as current or normal, as provided by the subscriber. If a user outside the network sends money to a user inside the network, the sending bank may use a pull transaction.

  For security purposes, in one embodiment, an off-network user may not be allowed to initiate a payment request and may not be allowed to send payments to other off-network users. It should be understood that these features prevent fraud and encourage financial institutions to participate in remittance payment networks.

  FIG. 10 is a flow diagram illustrating an example process 1000 for facilitating payments or transfers from an off-network sender to an in-network recipient, according to an example embodiment of the present invention. Although the process 1000 will be described with reference to the flowchart shown in FIG. 10, it will be appreciated that many other ways of performing the operations associated with the process 1000 can be used. For example, the order of many of the blocks can be changed, certain blocks can be combined with other blocks, and many of the described blocks are optional.

  To transfer money from an off-network sender whose information has already been stored in an off-network database 167 to an on-network recipient, the data uses or implements a sender computer system 110, a payment service computer system 160 that includes an off-network database 167. Between the remittance payment network and the payee computer system 130. The sender may desire to use the token to send money to the recipient, as shown in block 1002. The remittance bank sends the token and dollar price to the remittance payment network. As indicated at block 1004, the remittance payment network notes that the request is from an off-network remittor. As indicated at block 1006, the remittance payment network may verify the account access using the trial deposit. As indicated at block 1008, the remittance payment network sends a message to the receiving bank indicating that the remittance is an off-network remittance. The receiving bank may send a confirmation to the remittance payment network to continue the transaction, as shown in block 1010. Upon receipt of the confirmation, the remittance payment network accesses a separate off-network database 167 as indicated at block 1012. As indicated at block 1014, the remittance payment network verifies the remittance with the remitter's bank information stored in the off-network database 167. As indicated at block 1016, the remittance payment network encrypts the remittance bank account information and opaquely transmits the remittance bank account information to the receiving bank. The receiving bank decrypts the sender's bank account information and sends the sender's bank account information and any other information necessary to complete the transaction to the ACH 170.

Early Payment In one embodiment, the sender may be able to make “real time” or early payment of funds to the recipient. It should be understood that a payment may be considered “real time” if the funds paid are provided to the recipient much earlier than the payment is normally provided. For example, a payment may be considered near real-time if the funds are deposited into the payee's account within minutes. In one embodiment, payment is made in real time when funds from the sender to the recipient are credited to the recipient's account in the amount of time required to send a message from the sender's bank to the recipient's bank. Can be considered. The message may be transmitted between the remittance bank, the remittance payment network and the receiving bank via a management service such as IBM®, WebSphere MQ.

  Some systems attempt to provide real-time payments, but require the use of a debit card system, which can be inconvenient. Other systems utilize the ACH system, which can take several days to process and does not provide the real-time or early payment speed disclosed herein. Other systems require the sender to create an account with several alternative payment providers. Still other systems require having direct access to the financial institution's core processing platform.

  Still other systems allow for rapid payment from the sender's credit card. The remittance payment network allows real-time remittances from the sender's financial institution, such as the sender's primary financial institution, to the recipient. It should be understood that remittances from the sender's primary financial institution may allow the sender to centralize financial transactions and manage money more easily and conveniently. The sender can use any number of financial institutions, each financial institution is a member of a remittance payment network, and the sender uses a different token (eg, email address, phone) at each financial institution. As long as you can send / receive money from any of those institutions.

  In other systems, rapid payment is possible if the sending bank is the same as the receiving bank. The remittance payment network allows real-time payments from the sender to the recipient, even if the sender and recipient use different banks. The remittance payment network can work with any core financial institution's system through the API system and does not require a direct connection to the financial institution's core processing platform. The remittance payment network can alternatively work with non-bank financial institutions such as securities companies or investment companies.

  In one embodiment, both the sending and receiving banks are intra-network banks. In order to make real-time payments, the sending and receiving banks may need to agree on providing each other's real-time payments. For example, a remittance payment network may provide a real-time payment service to a sending bank and a receiving bank, where both banks agree to facilitate real-time payments to each other. A remittance payment network may additionally or alternatively have the requirement that a bank must agree to send and receive payments from other member banks before becoming a member bank. Individual users can also sign up with each financial institution in order to be able to send and / or receive early payments for service fees.

  FIG. 11 is a flow diagram illustrating an example process 1100 that facilitates real-time payment or transfer of funds from an intra-network sender to an intra-network recipient according to an example embodiment of the present invention. Although the process 1100 will be described with reference to the flowchart shown in FIG. 11, it is understood that many other ways of performing the operations associated with the process 1100 can be used. For example, the order of many of the blocks can be changed, certain blocks can be combined with other blocks, and many of the described blocks are optional.

  Data may flow between the remittance payment network and payee computer system 130 using or implementing the remittance computer system 110, payment service computer system 160, in order to pay funds in real time from the intra-network sender to the intra-network payee. . As indicated at block 1102, the sender may wish to send money to the recipient in real time. In one embodiment, the payee must be eligible to receive real-time payments, such as by signing up for service with the payee's financial institution. The remittance bank can query the remittance payment network as to whether the recipient is eligible to receive real-time payments. The remittance payment network checks whether the recipient is eligible to receive real-time payments, as shown in block 1104, and if so, sends a confirmation message to the remittant as shown in block 1106. Send to financial institutions. Upon receiving confirmation that the payee is eligible, the remittance bank removes the funds from the sender account, as shown in block 1108. Accordingly, at this stage of the process 1100, funds have been removed from the sender's bank account.

  Next, as shown in block 1110, the remittance bank sends an early payment message to the remittance payment network. Accordingly, as indicated at block 1112, the remittance payment network sends an early payment message indicating real-time payment to the payee bank. Next, as shown in block 1114, the payee bank funds the payee's account. It should be appreciated that at this stage of the process 1100, funds have been deposited into the recipient's bank account. It should also be understood that at this stage of the process 1100, the payee bank is funding the payee's bank account from its own funds, but the remittance bank still does not supply money to the payee bank. .

  Mediation or settlement between the sending bank and the payee bank may occur at some point after funding the payee's account. The settlement or reconciliation between the sending bank and the payee bank may not take place hours or days after the payment is made to the payee. The amount of time between depositing into the payee's account and reconciliation between the sending bank and the payee bank may be referred to as reconciliation delay. It should be understood that the remittance payment network substantially avoids waiting for an arbitration delay before the recipient receives the funds. In some cases, the remittance payment network may provide a maximum number of hours before money is provided to the recipient, eg, 2 hours. It should be understood that money will be available to the payee in the amount of time required to send the electronic message to the payee bank substantially.

  Referring again to FIG. 11, after funding the payee's account, the payee bank notifies the remittance payment network that the payee's account has been funded, as shown at block 1116. The remittance payment network then notifies the remittance bank that funds have been funded to the payee's account, as shown at block 1118. The sending bank may send a payment confirmation message to the sender indicating that the recipient's account has been funded. The sending bank then settles the funds with the payee bank via ACH payment, as shown in block 1120.

  In one embodiment, in order to make payments faster, the sending bank is not withdrawn from the sender's account until after the recipient's account has been funded. However, the remittance bank may restrict the sender from selecting more than the money available in the sender's account. In this way, the remittance bank ensures that the sender's account has sufficient funds to pay the remittance bank.

  In one embodiment, instead of the recipient bank immediately funding the payee's account, the payee must accept payment before the funds are transferred to the payee's account. When the payee accepts the payment, the receiving bank transfers the required amount to the payee's account.

  In one embodiment, the remittance payment network may require an unregistered payee to register with a financial institution in the network to receive funds early.

  Embodiments of the present invention have been described with reference to the drawings. The drawings illustrate certain details of particular embodiments that implement the systems, methods, and programs of the present invention. However, describing the invention with the drawings should not be construed as imposing any limitations on the present invention that may be presented in the drawings. The present invention contemplates methods, systems, and program products on any machine-readable medium that accomplishes its operations. Embodiments of the present invention may be implemented using existing computer processors, or by dedicated computer processors incorporated for this or other purposes, or by hardwired systems.

  As noted above, embodiments within the scope of the present invention include a program product that includes a machine-readable medium that includes or has stored machine-executable instructions or data structures. Such machine-readable media can be any available media that can be accessed by a general purpose or special purpose computer or other machine in a processor. By way of example, such machine-readable media can be RAM, ROM, EPROM, EEPROM, CD-ROM, or other optical disk storage, magnetic disk storage, or other magnetic storage, or machine-executable instructions or data structures. Any other non-transitory media that can be used to store the desired program code in the form of, and can be accessed by a general purpose or special purpose computer, or other machine having a processor. . Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions.

  Embodiments of the present invention may generally be implemented, for example, in the form of program modules executed by a machine in a networked environment and implemented by a program product including machine executable instructions such as program code. Explained about the steps. Generally, a program includes routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Machine-executable instructions represent associated data structures, and program modules represent examples of program code that perform the steps of the methods disclosed herein. A particular sequence of such executable instructions or associated data structures represents an example of a corresponding operation that performs the functions described in such steps.

  As described above, embodiments of the present invention may be implemented in a networked environment using logical connections to one or more remote computers having processors. Such a network computing environment may encompass many types of computers, including personal computers, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronic devices, network PCs, minicomputers, mainframe computers, etc. Those skilled in the art understand that. Implementations of the invention may also be practiced in distributed computing environments where tasks are linked through a communications network (by a hard wire drink, a wireless link, or a combination of hard wire drinks and wireless links). It is executed by a local processing device and a remote processing device. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

  An exemplary system for implementing all or part of the system of the present invention is a general purpose computing computer in the form of a computer that includes a processing unit, system memory, and a system bus that couples various system components including the system memory to the processing unit. Can be included. The system memory may include read only memory (ROM) and random access memory (RAM). The computer can also include a magnetic hard disk drive that reads from and writes to a magnetic hard disk, a magnetic disk drive that reads from and writes to a removable magnetic disk, and an optical disk drive that reads from and writes to a removable optical disk such as a CD ROM or other optical media. . The drives and associated machine-readable media provide non-volatile storage of computer machine-executable instructions, data structures, program modules, and other data. It should also be noted that the term “terminal” is intended herein to encompass computer input devices and output devices. Input devices include a keyboard, keypad, mouse, joystick, or other input device that performs similar functions, as described herein. Output devices include computer monitors, printers, facsimile machines, or other output devices that perform similar functions as described herein.

  It should be noted that although the figures herein may show method steps in a particular order and configuration, it will be understood that the order of these steps may differ from the order shown. For example, two or more steps may be performed simultaneously or partially simultaneously. Also, some method steps performed as discrete steps may be combined, steps performed as combined steps may be separated into discrete steps, a particular process sequence may be reversed or otherwise changed, The nature and number of discrete processes can be varied or modified. The order or sequence of any elements or devices may be varied or replaced according to alternative embodiments. Accordingly, all such modifications are intended to be included within the scope of this invention as defined in the appended claims. Such variations depend on the software and software system selected and the designer's choice. It is understood that all such variations are within the scope of the present invention. Similarly, the software and web embodiments of the present invention can be accomplished using standard programming techniques using rule-based logic and other logic to perform various database search, correlation, comparison, and identification steps. Can be achieved. The foregoing descriptions of embodiments of the present invention have been presented for purposes of illustration and description. It is not intended to be exhaustive, ie, to limit the invention to the precise forms disclosed, and modifications and variations are possible in light of the above teachings, or variations and modifications may be made to the invention. Can be obtained from implementation. The embodiments illustrate the principles of the invention and its practical application so that one skilled in the art can make use of the invention in various embodiments with various modifications that are suitable for the particular intended use. Selected and explained to explain. Other substitutions, modifications, changes, and abbreviations may be made to the design, operating conditions, and configuration of the embodiments without departing from the scope of the invention as expressed in the appended claims. .

Secure remittances through non-financial institutions In various embodiments, senders and / or payees have access to online payment processes or physical payment terminals maintained by non-financial institutions (eg, service providers). May not have. As used herein, a “remitter” can include an entity (individual, company, corporation, etc.) that provides an order to transfer an amount of funds from a sender's financial institution to a recipient. “Recipient” of funds, as used herein, can refer to the intended recipient of funds from a sender (eg, a recipient of funds in a recipient account of the recipient's financial institution). Receive funds). “Remittance Participant” as used herein may refer to either a sender or a recipient of funds.

  A “financial institution” or FI is an entity that primarily deals with financial transactions such as investments, loans, and / or deposits. Examples of financial institutions include commercial banks, investment banks, insurance companies, securities companies, investment companies, remittance entities, trust companies, savings and loan entities, credit unions, shadow banks, and the like.

  “Non-financial institution” or “non-FI” as used herein may refer to an entity that does not provide financial services as part of its primary function. Non-financial institutions may include business entities that facilitate the sale or exchange of products and services. Examples of such business entities include service entities and retail entities (eg, conventional retail stores and online retail stores). In some embodiments, the non-financial institution includes a social networking entity that provides social networking services to users and / or other individuals. Examples of such social networking entities include Facebook (registered trademark), LinkedIn (registered trademark), Alphabet (registered trademark), Inc. And the social network provided by Snapchat (registered trademark).

  Non-financial institutions may support online payment systems. An “online payment system”, as used herein, allows an individual (eg, a sender or recipient) to view, review, and / or pay for a product / service using a personal digital device. May refer to a website or network application and server system. For example, a non-financial institution may provide a non-financial institution with a physical device and / or online service for payment of services provided or payment of past bills. In another example, an online retailer (eg, GAP) may provide a payment processing server that communicates over a public network such as the Internet. An individual may interact with the payment processing server through an application, such as a web page (accessible by a browser on any number of digital devices) or a smartphone application.

  In various embodiments, a non-financial institution may include a physical payment terminal that accepts funds from an individual for payment of products and / or services. A physical payment terminal at a non-financial institution may also allow a user to obtain funds (eg, physical currency, digital currency, etc.).

  A financial institution can act as an intermediary between the sender and recipient and can facilitate the transfer. A financial institution may be regulated by the government and / or other regulatory agencies. A “sender financial institution” may refer to a financial institution that provides financial services to an entity attempting to transfer money to another entity. For example, the 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 can include one or more sender account numbers (eg, an account number that identifies the sender account). The sender financial institution may provide access to funds (physical currency, digital currency, credit lines, etc.) that the sender can use to send money to the recipient.

  A “recipient financial institution” may refer to a financial institution that provides financial services to an entity that receives funds from another entity. For example, the payee financial institution may be the payee's bank. The payee's bank may include any number of bank accounts associated with the payee. Each payee account may include one or more payee account numbers (eg, an account number identifying the payee account). The payee financial institution may provide access to funds (physical currency, digital currency, credit lines, etc.) that the payee can use to receive funds from the sender.

  FIG. 12 illustrates a diagram of a remittance system 1200 that securely transfers money from a sender non-financial institution system to a recipient non-financial institution system, according to some embodiments. Remittance system 1200 includes sender system 1202, recipient system 1204, first non-FI system 1206, second non-FI system 1208, sender FI system 1210, recipient FI system 1212, payment service system 1218, automatic clearing A ring house (ACH) system 1220, a public network 1214, and an ACH network (eg, a private network) 1216 may be included.

  The sender system 1202 may include one or more digital devices associated with the sender (eg, user). By way of example, a sender uses a non-financial institution's website or a non-financial institution's physical payment terminal (eg, using a smart device with a credit card, debit card, or terminal provided by a non-financial institution And can be a person who sends money to a third party payee. As an example, the sender can be a person who can access a network application or web page managed by a retailer (eg, the first FI system 1206). The remittance by the sender can be sponsored by the sender financial institution further discussed herein. As an example, a sender may maintain a sender account at a sender financial institution that provides access to funds that the sender wants to send to the recipient.

  The sender system 1202 may have some or all of the components of a digital device, examples of which are shown in FIG. 12 and discussed further herein. For example, the sender system 1202 can be a computer (eg, a desktop or laptop computer), a mobile phone, a smartphone, a mobile handheld wireless email device, a personal information terminal, a portable gaming device, or other suitable digital device. Sender system 1202 may also include one or more processors configured to execute instructions stored in memory.

  Sender system 1202 may include network interface logic 1222, display device 1224, input device 1226, and client application 1228. The network interface logic 1222 may include program logic that enables a connection between the sender system 1202 and the public network 1214 (or any network). Display device 1224 may include a display configured to display content, such as information from an online payment system graphical user interface (GUI) or payment server system 1218 and / or information from sender FI system 1210. Input device 1226 may be used to allow a sender to initiate account access and facilitate receipt of money request information from a user.

  In some embodiments, the sender system 1202 may allow a transfer to the payee system 1204. For example, the sender system 1202 may include a browser or application configured to interact with an online payment process (eg, online payment system) supported by the first non-FI system 1206.

  Client application 1228 may include program logic configured to perform one or more of the functions of the sender system 1202. In some embodiments, the client application 1228 may include or be an application configured to receive and display content (eg, on the display device 1224) or from the sender FI system 1210 to the web. It may include or be a web browser configured to receive and display the page. For example, client application 1228 includes 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 via network 1214. obtain.

  Although FIG. 12 illustrates a sender system 1202 within a remittance system 1200, in some embodiments, the sender system 1202 may not be present within the remittance system 1200, or some of the functions of the sender system 1202. Note that or all may be performed by the first non-FI system 1206. For example, in some embodiments where the first non-FI system 1206 incorporates a physical payment terminal, the remittance system 1200 may not include the sender system 1202 and / or the first non-FI system 1206 may be , Some or all of the functions attributed to the sender system 1202 may be performed.

  Recipient system 1204 may include a digital device associated with the recipient. For example, the payee may be a person who receives funds (eg, from the sender system 1202) provided by the sender via an online payment process of a non-financial institution (eg, the first non-FI system 1206). The transfer to the payee may include a transfer to an account held by the payee at the payee financial institution. In some embodiments, funds are transferred to a payee account held by the payee at the payee financial institution (eg, payee FI system 1212) before the funds are provided to the payee. In various embodiments, the payee FI system 1212 may fund the payee before the transfer is made from the sender account of the sender FI system 1210 (eg, via the ACH network 1216).

  Recipient system 1204 may have some or all of the components of a digital device, examples of which are shown in FIG. 19 and discussed further herein. Like the sender system 1202, the recipient system 1204 can be a computer (eg, desktop or laptop computer), cell phone, smartphone, mobile handheld wireless email device, personal information terminal, portable gaming device, or other suitable digital. It can be a device. Recipient system 1204 can also include one or more processors configured to execute instructions stored in memory.

  Recipient system 1204 may include network interface logic 1230, display device 1232, input device 1234, and client application 1236. Network interface logic 1230, display device 1232, and input device 1234 may be configured similarly to the counterparty of sender system 1202. Client application 1236 may include program logic configured to perform one or more of the functions of recipient system 1204. In various embodiments, the client application 1236 is an application or first non-FI system 1206, a second non-FI system 1208, a sender FI system 1210, a payment service system configured to receive and display content. 1218, recipient FI system 1212, or any combination may include a web browser configured to receive and display web pages. 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 via network 1214.

  In various embodiments, the payee system 1204 may request a notification requesting permission to receive funds from the sender, a notification request requesting approval of the transaction, a notification indicating the status of the transfer, and / or a transfer from the sender. A notification of success may be received. The payee system 1204 may be configured to interact with an online payment process supported by the first non-FI system 1206, the second non-FI system 1208, or both.

  Although FIG. 12 shows a payee system 1204 within a remittance system 1200, in some embodiments, the payee system 1204 may not be present in the remittance system 1200, or some of the functions of the payee system 1204. Note that or all may be performed by the second non-FI system 1208. For example, in some embodiments where the second non-FI system 1208 incorporates a physical payment terminal, the remittance system 1200 may not include the payee system 1204 and / or the second non-FI system 1208 may be Some or all of the functions attributed to the recipient system 1204 may be performed.

  The first non-FI system 1206 may include any number of digital devices configured to support the functions of the first non-financial institution. For example, the first non-FI system 1206 may be a server that hosts a retailer website. On a website, a user (eg, a sender or recipient) may be able to view products and / or services. At the website, the user may also be able to purchase products and / or services. In some embodiments, the first non-FI system 1206 may be a server that interacts with an application (eg, client application 1228 or client application 1236) on any number of digital devices. Depending on the application, the user may be able to pay for products and / or services.

  In various embodiments, the first non-FI system 1206 may provide a service that assists users in directing funds to other users. For example, the first non-FI system 1206 may provide an interface or device that allows a sender or recipient to register with the payment service system 1218. The interface may also allow the sender system 1202 to identify the recipient and indicate the amount to be paid 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. In such an embodiment, the first non-FI system 1206 may include one or more servers each having one or more processors configured to execute instructions stored in memory. The server 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, examples of which are shown in FIG. 19 and discussed further herein. In some embodiments, the first non-FI system 1206 includes a physical payment terminal configured to manage payments of a sender non-financial institution. In these embodiments, the physical payment terminal is configured to process payment information from the sender (eg, a credit card at the physical terminal) or payment information from the sender system 1202, other Hardware and / or software may be included.

  First non-FI system 1206 may include network logic 1238, optional display device 1240, input device 1242, and non-FI application 1244. Network interface logic 1238, display device 1240, and input device 1242 may be configured similarly to the counterparts described herein.

  Non-FI application 1244 may be configured to manage payments of sender non-financial institutions. For example, non-FI application 1244 may provide a physical device, web page, or information to an application (eg, including client application 1228). With non-FI application 1244, in some embodiments, a user can pay for a previously purchased product / service, browse for a product / service, purchase a product / service, and / or request money to others. Could be offered. In some embodiments, the sender non-FI application 1244 may include program logic that processes payment information provided to a physical payment terminal as directed by the first non-FI system 1206. The sender non-FI application 1244 may include program logic that supports an online payment process managed by the first non-FI system 1206.

  In some embodiments, the non-FI application 1244 or financial service provider (eg, MasterCard network) may provide some other identifying information (eg, credit card number or The debit card number) may be tokenized (eg, encrypted) to create a sender or recipient token. A financial instrument issuer or sponsoring financial institution may be able to de-tokenize the token as described herein. The non-FI agency 1244 may store the sender or payee's tokenized financial instrument for future transactions. Non-FI application 1244 may also obtain or identify a financial identifier that identifies a financial institution associated with a financial product (eg, a financial institution that issued the financial product).

  The second non-FI system 1208 may be similar to the first non-FI system 1206. For example, both systems may be owned by the same entity or related entities (both systems provide services to the same entity). Alternatively, each system may be operated, owned or controlled by a different entity.

  Like the first non-FI system 1206, the second non-FI system 1208 may include any number of digital devices configured to support the functions of the second non-financial institution. For example, the second non-FI system 1208 may provide a physical interface for receiving a sender or payee's public identifier and / or account number and transferring money to any number of individuals. In another example, the second non-FI system 1208 may be a server that hosts a retailer website. At a website, a user (eg, a sender or recipient) may be able to view past purchases and / or future school inputs for products and / or services. At the website, the user may also be able to purchase products and / or services. In some embodiments, the second non-FI system 1208 may be a server that interacts with an application (eg, client application 1228 or client application 1236) on any number of digital devices. Depending on the application, the user may be able to pay for products and / or services.

  In various embodiments, the second non-FI system 1208 may provide a service that assists the user in directing funds to other users. For example, the second non-FI system 1208 may provide an interface or device that allows a sender or recipient to register with the payment service system 1218. The interface may also allow the sender system 1202 to identify the recipient and indicate the amount to be paid 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. In such embodiments, the second non-FI system 1208 may include one or more servers each having one or more processors configured to execute instructions stored in memory. The server may be configured to process payment information provided by the client application 1236 on the payee system 1204.

  The second non-FI system 1208 may have some or all of the components of the digital device, examples of which are shown in FIG. 12 and discussed further herein. In some embodiments, the second non-FI system 1208 includes a server and / or physical payment terminal that is configured to manage payments of the payee non-financial institution. The physical payment terminal may include circuitry, other hardware, and / or software configured to process payment information at payment hardware on the payee system 1204.

  In some embodiments, the second non-FI system 1208 may be configured to support the payee non-financial institution's online payment process. In such embodiments, the second non-FI system 1208 may include one or more servers each having one or more processors configured to execute instructions stored in memory. The server may be configured to process payment information provided by the client application 1236 on the payee system 1204.

  Second non-FI system 1208 may include network interface logic 1246, display device 1248, input device 1250, and non-FI application 1252. Network interface logic 1246, display device 1248, and input device 1250 may be configured similarly to the counterparts described herein. Non-FI application 1252 may be configured to manage payments. The payee non-FI application 1252 may include program logic that processes payment information provided to a website or physical payment terminal supported by the second non-FI system 1208. In some embodiments, the payee non-FI application 1252 includes program logic that supports an online payment process managed by the second FI system 1208 and logic that tokenizes the sender or payee's financial instrument. Including.

  Sender FI system 1210 may be any digital device that is operated by a financial institution (eg, a sender financial institution) or that provides services to a financial institution (eg, a sender financial institution). The sender FI system 1210 may have some or all of the components of a digital device, examples of which are shown in FIG. 19 and discussed further herein. The sender FI system 1210 may have one or more accounts on behalf of the sender. The sender financial institution may maintain accounts held by customers such as demand deposit accounts, credit card accounts, home mortgages, student loans and the like. Sender FI system 1210 has one or more processors each configured to execute instructions stored in memory, send and receive data stored in memory, and perform one or more operations. One or more servers may be included. Sender FI system 1210 may include network interface logic 1254, account processing logic 1256, account database 1258, 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. Network interface logic 1254 may facilitate secure communication between the sender FI system 1210 and the other elements of FIG.

  Account processing logic 1256 can be used for account holder accounts such as crediting and debiting current accounts and ordinary accounts, crediting and debiting residential mortgages and home collateral, crediting and debiting student loan accounts, etc. It may be configured to process related transactions. In some embodiments, the account processing logic 1256 may reflect the appropriate debit and credit entries in the account database 1258 when transferred into and out of the account holder's account (eg, the participant's account). Account processing logic 1256 may also process a remittance request to transfer money from the sender to the recipient. Money can be transferred using the techniques described herein.

  Account database 1258 may be configured to store account information (e.g., information about transactions, account holders, etc.) for accounts maintained by banks on behalf of customers.

  The information directory 1260 may be configured to store a table that correlates user identifiers to account information used to make a remittance. The information directory 1260 may be used when a user identifier that does not specify account information is used to make a remittance. In some embodiments, the information directory 1260 may associate the sender's secret identifier with the sender's account in the account database 1258. Information directory 1260 is further described herein.

  “Account information”, as used herein, may refer to information used to transfer money to or from a money transfer participant. The account information may include, for example, an account number for transferring money, a bank branch code, a credit card number, a digital currency code, and the like.

  A “user identifier” or synonymous “user token”, as used herein, may refer to information that identifies a participant of a remittance for the purpose of remittance. The user identifier may include or be associated with a public identifier / public token and a secret identifier / secret token.

  A “public identifier” or synonymous “public token” may refer to information that identifies a participant of a remittance but does not identify account information associated with the participant. In some embodiments, public identifiers may be configured to be shared with each other by participants. As an example, a participant may desire to transfer money to the participant or share a public identifier with other participants who wish to receive funds from the participant. A public identifier can be other information that can be used to identify a participant (eg, a sender or recipient) such as, for example, an email address or telephone number.

  “Secret identifier” or synonymous “secret token” as used herein may refer to information that identifies a user (eg, a user who has an account in the FI system) and / or is associated with a participant Account information (e.g., account number). The secret identifier may be generated by the sender FI system 1210 and used by the sender FI system 1210 to identify account information such as account number, bank branch number, credit card information, and the like. In some embodiments, the secret identifier does not include a bank account number, bank branch code, credit card number, or the like.

  The secret identifier may be known by one or more financial institutions and entities that are members of a payment network that transfers money to participants. In one example, the sender FI system 1210 may generate a secret identifier associated with the sender. However, the secret identifier may not indicate any secret information to any other entity. The sender FI system 1210 may share the sender's secret identifier with the payment service system 1218. The sender's secret identifier may not be provided to the sender system 1202, the sender, the recipient system 1204, the recipient, the first non-FI system 1206, or the second non-FI system 1208. Neither the payment service system 1218 nor the payee FI system 1212 can identify any account number or other secret information from the sender's secret identifier.

  FI systems (eg, sender FI system 1210 and payee FI system 1212) may be other than FI systems (eg, with each other), automatic clearinghouse system 1220, and / or payment service system 1218 discussed herein. Do not share a secret identifier with any entity. Similarly, payment service system 1218 does not share a secret identifier received from the FI system with any entity other than the FI system. As described herein, participants in remittances between non-financial institutions may use the techniques described herein to transfer money to each other using public identifiers that participants provide to each other. In this configuration, in some embodiments, the sender need not necessarily have secret / personal information about the payee (ie, the payee's bank account / bank branch code) and the payee (eg, email address or Other identifiers) can be uniquely identified. In addition to the public and secret identifiers already described herein, additional identifiers can be used. For example, such additional identifiers can be handled with various levels of security. As another example, as discussed in more detail below, special public tokens, public tokens with customized functionality, etc. may be implemented using variations of existing public identifiers.

  The sender FI system 1210 may include an account database 1258 and an information directory 1260. When a user registers with the payment service system 1218 described herein, the sender FI system 1210 may generate a secret identifier associated with the user's public identifier. The user's secret identifier may be associated with both the user's public identifier (eg, the user's email address, telephone number, or other contact information) and the user's account in the sender FI system 1210. The account database 1258 may include user accounts, and the information directory 1260 may associate public identifiers, secret identifiers, and account information (eg, account numbers). Account database 1258 may include any number of accounts for any number of users. Information directory 1260 may contain information about any number of secret identifiers and public identifiers for any number of users.

  The token management logic 1262 may be configured to manage tokens (eg, public identifiers and / or secret identifiers). In various embodiments, token management logic 1262 may be configured to register tokens, authenticate tokens, generate tokens, and the like. Token management logic 1262 may also help identify the recipient if the token is not recognized. The token management logic 1262 may also be used to customize the attributes of the token such that a specific account is used, a specific notification method is used, and so on. The token management logic 1262 may have some or all of the attributes of the token management logic 129 shown in FIG. 2 and discussed in connection with FIG.

  In some embodiments, the token management logic 1262 is configured to recognize, identify, authenticate, and detokenize financial instrument tokens (eg, tokenized by the first non-FI system 1206). Can do. Once detokenized, token management logic 1262 may restore financial information such as account numbers or bank branch numbers associated with financial instruments as discussed herein.

  The payee FI system 1212 may include a digital device operated by a financial institution that provides financial services to the payee system 1204. Recipient FI system 1212 may have some or all of the components of a digital device, examples of which are shown in FIG. 19 and discussed further herein. The payee financial institution may maintain accounts held by customers such as demand deposit accounts, credit card accounts, home mortgages, student loans and the like. Recipient FI system 1212 has one or more processors each configured to execute instructions stored in memory, send and receive data stored in memory, and perform one or more operations. One or more servers may be included. Recipient FI system 1212 may include network interface logic 1264, account processing logic 1266, account database 1268, information directory 1270, and token management logic 1272. Network interface logic 1264, account processing logic 1266, account database 1268, information directory 1270, and token management logic 1272 may be configured similarly to the counterparty of the sender FI system 1210.

  The payment service system 1218 sends the recipient FI from the sender account of the sender FI system 1210 via the first non-FI system 1206 (eg, as directed by the sender system 1202). It may include a digital device configured to enable or facilitate a payment service that enables secure transfer (to a payee account of system 1212). Payment service system 1218 may have some or all of the components of a digital device, examples of which are shown in FIG. 19 and discussed further herein. Payment service system 1218 has one or more processors each configured to execute instructions stored in memory, send and receive data stored in memory, and perform one or more operations. One or more servers may be included.

  In some embodiments, payment service system 1218 may transfer money between one or more of sender FI system 1210, payee FI system 1212, sender non-FI bank system 1214, and payee non-FI bank system 1216. To help.

  Payment service system 1218 may provide payment services to participants who have accounts at member banks. More specifically, in some embodiments, financial institutions associated with the sender FI system 1210 and the recipient FI system 1212 may include member banks. A “member bank” as used herein may refer to a financial institution that is a member of the payment service system 1218 and follows a protocol established by a government agency, regulatory agency, etc. to transmit to each other. In various embodiments, payment service system 1218 provides payment services to participants who have accounts at financial institutions that are not member banks.

  Payment service system 1218 may include network interface logic 1274, account processing logic 1276, account database 1278, information directory 1280, token management logic 1282, remittance logic 1284, and registration logic 1286. Network interface logic 1274, account processing logic 1276, account database 1278, information directory 1280, and token management logic 1282 may be configured similarly to the counterparty of the sender FI system 1210.

  In various embodiments, participants in the remittance may share information with the information directory 1280 using the network 1214. Network interface logic 1274 may be configured to receive information over network 1214. Account processing logic 1276 may identify whether the participant's public identifier is registered by identifying whether there is an account associated with the public identifier in account database 1278. Participants may add to the information directory 1280 when they register with the remittance system 1200 through the remittance FI system 1210 or the first non-FI system 1206. Once registered, a new entry for the newly registered user may be created in the database that implements the information directory 1280. In some embodiments, the information directory 1280 is automatically filled with public and secret identifiers during a secure online banking session that includes the sender FI system 1210.

  In some embodiments, the information directory 1280 stores a registry of other participants associated with a particular participant. For example, for each user, the information directory 1280 may store a registry that includes a list of each other user with whom the user has established a connection. Such a connection can be established, for example, the first time a user exchanges funds with another user. The association can also be established by a user interface that allows a user to add associations with other users through the information directory 1280 and / or another information directory nine lookup service. Examples of such user interfaces are further discussed herein in connection with FIG. Users may include not only users registered with remittance payment networks, but also users registered with other related payment networks, as described in more detail below. For each user in the registry, additional information such as the user's unique ID and / or other information may be stored. As another example, other user information may be stored in a separate database entry in information directory 1280.

  In various embodiments, the information directory 1280 may include one of a plurality of information directories, each information directory being maintained by a different institution or entity. Each information directory may store information about the participants associated with the digital device that includes each information directory. Each information directory may allow associated participants to register with the information directory.

  The remittance logic 1284 may be configured to support remittance between two participants. The remittance logic 1284 is further described with respect to FIG. The remittance can include a remittance from the sender to the recipient. In various embodiments, all participants in the transfer may be registered for a remittance service provided by payment service system 1218. However, in some embodiments, at least one participant may register only with a financial institution's financial services and / or use a non-financial institution's purchasing process (physical purchasing terminal, online purchasing process, etc.) You may have registered with As described herein, registration with a remittance service provided by payment service system 1218 includes registration of a participant account public identifier and / or receipt of a participant redemption tool (eg, financial instrument). Both of these are discussed further herein. In various embodiments, the recipient of the remittance may not have to take any action to accept the payment (eg, the recipient may enter the payee's specific account without further action by the recipient). May have an “automatic accept” status that allows money transfer). Note that in some embodiments, the payee may need to manually accept at least some transfers or all transfers.

  In some embodiments, payment service system 1218 may provide a web portal that is provided to a personal online community, where such individual obtains the user's name / login ID, or Become a registered member. Individuals may interact with each other using, for example, a web portal and / or with services provided by an online community. Examples of the online community include MSN (registered trademark), iPhone (registered trademark) user, Facebook (registered trademark), and LinkedIn (registered trademark). The payment service can be, for example, an additional service provided by a web portal to members of the online community. As another example, the payment service may be implemented by a financial institution as being performed by a sender FI system 1210, a recipient FI system 1212, a sender non-FI bank system 1214, and a recipient non-FI bank system 1216, for example. It may be provided by one of the financial institutions to perform both operations described in the specification.

  In embodiments where the second non-FI system 1208 corresponds to a physical purchase terminal, the remittance logic 1284 may manage remittances from the sender FI system 1210 to the second non-FI system 1208. Funds obtained with the second non-FI system 1208 may take the form of physical currency, digital currency, etc., and the recipient may obtain from a physical purchase terminal. In embodiments where the second non-FI system 1208 supports an online payment process, the remittance logic 1284 may manage remittances from the sender FI system 1210 to the second non-FI system 1208 and / or payee system 1204. . Funds obtained at the second non-FI system 1208 and / or the payee system 1204 are managed by the payee FI system 1212 and / or accessed by the second non-FI system 1208 and / or the payee system 1204. It can take the form of a digital currency that can be deposited into an online account. In some embodiments, remittance logic 1284 may facilitate remittance to unregistered participants. In some embodiments, the remittance logic 1284 may instruct the sender FI system 1210 and the recipient FI system 1212 to extract a public identifier from the transaction data. The remittance logic 1284 may further direct the remittance FI system 1210 and / or the payee FI system 1212 to obtain the DDA after the public identifier is extracted.

  Registration logic 1286 may be configured to manage registration of unregistered participants for remittances. Registration logic 1286 is further described with respect to FIG. In some embodiments, registration logic 1286 may issue participant accounts to access these participant accounts. A “participant account” as used herein may refer to a registered account managed by the payment service system 1218 to assist in the transfer of money between financial institutions. Participant accounts may be linked and / or sponsored by funds in financial accounts provided by financial institutions. Participant accounts may be identified by account number and / or other account identifier.

  Registration logic 1286 may create tokenized account data for those participant accounts when participants attempt to register user identifiers for those participant accounts. “Tokenized account data” as used herein may include a representation of account information that secures the account information from external discovery. In some embodiments, tokenized account data may include an encrypted proxy number or account information. The tokenized account data may further include a financial institution name / identifier, etc. associated with the account information. In various embodiments, registration logic 1286 may allow a user to register a user identifier for a participant account.

  Automated Clearinghouse (ACH) system 1220 may include one or more digital devices used to exchange funds with the sender and payee's bank accounts. An automatic clearinghouse (ACH) system 1220 may be used to exchange funds with the sender and recipient bank accounts. In some embodiments, the ACH system 1220 may facilitate secure transfer of funds and / or information between the sender FI computer system 1210 and the recipient FI computer system 1212. ACH system 1220 may include a computer system configured similarly to ACH system 170 shown in FIG.

  In some embodiments, ACH system 1220 may enable a batch processing system. A “batch processing system” as used herein may include a system that allows a financial institution to accumulate transactions over a specified time period. In some embodiments, financial institutions that transfer funds with each other through a batch processing system may be in a specified time period (hourly, daily, weekly, etc.) or until a specified event occurs. Transactions can be accumulated. After a specified period of time or a specified event, financial institutions may use a private network (eg, ACH network 1216) and / or ACH system 1220 to settle payments to each other. In some embodiments, a batch remittance system may allow financial institutions to remit money to each other as needed, and settle the amounts paid to each other at specified times, such as daily, weekly, etc. Settlement times can be supported by regulation. As an example, the National Automatic Payment Association (NACHA) rules may require a financial institution to use a batch processing system to settle credit to each other after a specific remittance and before the end of the next business day.

  In various embodiments, the ACH network 1220 may allow the sender FI system 1210 and the recipient FI system 1212 to send money electronically. Instead of using paper to convey the necessary transaction information, such as when using a check, transactions over the ACH network 1220 can be transmitted electronically over a private network, resulting in faster and more secure processing time and Enable cost savings. The ACH network 1220 may handle different types of transactions, including but not limited to account transfer transactions and direct payment transactions. Account transfer transactions may include salary deposits, employee expense refunds, government benefits, taxes and other refunds, and pension and interest payments. Direct transfer transactions may include ACH credit payments from businesses or governments to consumers. Direct payment transactions may include paying using funds. In some embodiments, individuals and / or organizations can make direct payments via the ACH as either ACH credits or ACH debits. Direct payment transactions may be processed as ACH debit transactions, ACH credit transactions, or some combination thereof. Direct payment transactions that are processed as ACH credit transactions push funds into the account. An example of this is when a consumer initiates a payment to pay an invoice through a consumer bank or credit union. Direct payments that are processed as ACH debit transactions can pull funds out of the account. An example of this is when a consumer establishes a monthly recurring payment for a mortgage or utility bill and is automatically debited from the consumer's account.

  Although FIG. 12 describes a sender system 1202 and a payee system 1204, it will be understood that the sender system 1202 and the payee system 1204 are optional. For example, the sender can interact directly with a first non-FI system 1206 that can include, for example, a physical device configured to receive a credit card number or debit card number from the sender. The physical device may further receive the sender's public identifier. In some embodiments, the physical device or another portion of the sender system 1202 may further receive the amount to be paid to the payee and the payee public identifier. In this example, the physical device, sender system 1202, or financial service provider (eg, MasterCard or Visa) tokenized the credit card number and / or debit card number and / or sponsored or issued the financial instrument. An identifier of the financial institution may be provided. The non-FI system 1206 and / or financial service provider may provide the sender's public identifier, financial institution identifier (eg, identifying the sender FI system 1210), remittance amount, and / or recipient identifier to the payment service system 1218 and / Or may be provided to the sender FI system 1210.

  FIG. 13 illustrates the logic of remittance logic 1284 according to some embodiments. The remittance logic 1284 may include transaction data management logic 1302, payment verification logic 1304, information directory management logic 1306, payment notification logic 1308, and payment status management logic 1310. One or more of transaction data management logic 1302, payment verification logic 1304, information directory management logic 1306, payment notification logic 1308, and payment status management logic 1310 can store memory stored in the physical computer processor and remittance logic 1284. Can be implemented using. The memory is a computer program that instructs a physical processor to implement one or more of transaction data management logic 1302, payment verification logic 1304, information directory management logic 1306, payment notification logic 1308, and payment status management logic 1310. Instructions can be stored.

  Transaction data management logic 1302 includes transaction data and payment service system 1218 with a particular system (eg, sender system 1202, recipient system 1204, first non-FI system 1206, and second non-FI system 1208). The transaction data may be managed, including the transaction data. “Transaction Data”, as used herein, is a request to perform a transfer from one participant to another (eg, from a sender to a recipient received from the first non-FI system 1206). , The sender's public identifier, the recipient's public identifier, the transaction identifier identifying the transaction to be sent, the sender's secret identifier, the recipient's secret identifier, the financial institution (FI) identifier associated with the sender, the recipient It may refer to data related to the transaction, including an associated FI identifier, or any combination. In some embodiments, the transaction data includes a remittance amount.

  Transaction data management logic 1302 may, in some embodiments, receive transaction data indicating that the sender is trying to provide funds to the recipient (eg, sender system 1202, first non-FI system 1206). From the sender FI system 1210 and / or financial service provider). The transaction data may include, in this example, the sender's public identifier, the recipient's public identifier, the sender FI system identifier, and the amount to be transferred. Transaction data management logic 1302 identifies whether the sender is registered by comparing the sender's public identifier with a list of registered users (eg, information in account database 1278, information directory 1280, etc.). obtain. If registered, transaction data management logic 1302 may provide a success message that the sender is registered with first non-FI system 1206 and / or sender system 1202. In addition, transaction data management logic 1302 may provide the sender's secret identifier and amount to the sender FI system 1210. The transaction data management logic 1302 may also provide the sender FI system 1210 with the recipient's public identifier, the recipient's secret identifier, the recipient FI identifier, the sender's public identifier, and / or any other information. .

  Transaction data management logic 1302 may receive from the sender FI system 1210 authentication that indicates that the sender FI system 1210 identifies the sender's account and that the sender has sufficient funds for the transaction. At any time, transaction data management logic 1302 may generate a transaction identifier that identifies the transaction to be transferred from the sender to the recipient and share it with the sender FI system 1210 and / or the recipient FI system 1212.

  In some embodiments, the transaction data management logic 1302 provides the first non-FI system 1206 with logic and / or instructions that allow the first non-FI system 1206 to provide remittance options to the user of the system. obtain. For example, the transaction data management logic 1302 may be logic (e.g., code or software) that is placed or incorporated into a physical device, web page, or code provided by the first non-FI system 1206 to the sender or sender system 1202. ) May provide a first non-FI system 1206. The logic allows the sender to view the remittance options, allows the sender to enter or select the recipient's public identifier, allows the sender to enter or select the sender's own public identifier, and And may be able to receive the sender's debit card number or credit card number and / or any other information.

  Validation logic 1304 may be configured to validate payment details associated with the transaction data. The verification specifies whether or not the sender's public identifier is registered, whether or not the recipient's public identifier is registered, or a financial institution (or member financial institution known to the FI identifier). ) May be included. The FI identifier is obtained as part of the tokenization of the sender's debit card number or credit card number, or in any number of ways (eg, based on information provided by the sender's debit card or credit card or sender) It is understood that the

  In various embodiments, the validation logic 1304 includes one or more validation protocols (eg, validation interfaces) that require confirmation from the financial institution whether the sender has the authorization to provide the requested funds. carry out. Validation logic 1304 may further perform one or more checks to see if the public identifier provided in association with the transaction data is valid.

  Information directory management logic 1306 may be configured to provide instructions for adding transaction data to information directory 1280. In various embodiments, the information directory management logic 1306 may add, delete, and / or otherwise change or manage the information directory 1280.

  Payment notification logic 1308 may be configured to provide and support payment senders, for example, notifications indicating success or failure of the transfer of money to the recipient and / or the sender to the sender FI system 1210.

  Payment status management logic 1310 may be configured to manage status updates that indicate whether a remittance is possible or whether there is an error. In some embodiments, payment status management logic 1310 may request additional information to assist in the remittance process.

  FIG. 14 shows a diagram of registration logic 1286 according to some embodiments. It will be appreciated that in some embodiments, the registration logic 1286 may register the sender and / or recipient once. Registration logic 1286 may include participant account issuance logic 1402, user identification verification logic 1404, tokenization logic 1406, financial institution identification logic 1408, and account verification logic 1410. One or more of the participant account issue logic 1402, user identification verification logic 1404, tokenization logic 1406, financial institution identification logic 1408, and account verification logic 1410 can store memory stored in the physical computer processor and registration logic 1286. Can be implemented using. The memory is a computer program that instructs the physical processor to implement one or more of participant account issue logic 1402, user identification verification logic 1404, tokenization logic 1406, financial institution identification logic 1408, and account verification logic 1410. Instructions can be stored.

  Participant account issue logic 1402 may be configured to facilitate issuance of participant accounts. In some embodiments, participant account issuance logic 1402 may support an account number and / or other account identifier that the participant can use as a basis for the participant account (eg, transfer between financial institutions). ) Can be created.

  User identity verification logic 1404 may be configured to verify the user identifier when the user identifier is provided for registration of the participant account. In various embodiments, the user identity verification logic 1404 is configured to evaluate whether a participant has the right to register a particular participant account. User identification verification logic 1404 is configured to identify whether the user identifier and / or participant account information provided by the participant is associated with the financial institution's account or whether the financial institution can be identified. Further configuration is possible.

  Public identifier verification includes verification that the public identifier is in an appropriate format (eg, an appropriate alphanumeric format), verification that the public identifier has not been previously assigned to another participant, and that the public identifier is account information. One or more verification techniques, such as verification that they are not included.

  Tokenization logic 1406 may be configured to tokenize participant account information. In various embodiments, tokenization logic 1406 may encrypt participant account information or assign proxy numbers to participant account information so that participant account information is not discovered by external entities including non-financial institutions. .

  Financial institution identification logic 1408 may be configured to identify a financial institution associated with the participant account information. Financial institution identification logic 1408 may identify a participant financial institution that provides financial services to the participant system. In some embodiments, financial institution identification logic 1408 may identify an appropriate participant financial institution using a financial institution's username / identifier, etc., included in the tokenized account data. As an example, in embodiments where the participant system corresponds to the sender system 1202, the financial institution identification logic 1408 may identify the sender FI system 1210. In embodiments where the participant system corresponds to the payee system 1204, the financial institution identification logic 1408 may identify the payee FI system 1212.

  Account verification logic 1410 may provide status updates and / or other information to indicate whether the participant account registration was successful. Account verification logic 1410 may verify ownership of the public identifier and instruct the participant system to send the public identifier and account information to the non-FI system corresponding to the participant shim. As an example, the account verification logic 1410 may verify ownership of the public identifier and instruct the sender system 1202 to send the public identifier and account information to the first non-FI system 1206. As another example, account verification logic 1410 may instruct recipient system 1204 to verify ownership of the public identifier and send the public identifier and account information to second non-FI system 1208.

  Account verification logic 1410 may instruct the non-FI system corresponding to the participant system to send the public identifier and tokenized account data to payment service system 1218. In some embodiments, the public identifier and tokenized account data are sent directly to the payment service system 1218, while in other embodiments, the public identifier and tokenized account data are passed through the sender non-FI bank system 1214. Sent to payment service system 1218. Account verification logic 1410 may instruct the associated participant FI system to use the tokenized account data to obtain the identifier of the financial institution associated with the participant. Account verification logic 1410 may instruct the participant FI system to perform a DDA lookup, map the DDA number to a public identifier, and associate the public identifier with the associated user account. In various embodiments, account verification logic 1410 may provide confirmation of whether a participant has successfully registered a remittance with a non-financial institution.

  FIG. 15 illustrates a diagram of a data flow 1500 for securely transferring money from a sender to a recipient in a money transfer system, according to some embodiments. The data flow 1500 shown in FIG. 15 may be an example in which both the sender and recipient are already registered with the payment service system 1218, for example. The data flow 1500 is shown in FIG. 12 and includes the components of the remittance system 1200 that will be discussed further herein. More specifically, the data flow 1500 may include 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. Includes multiple actions. The elements of data flow 1500 are merely examples, and various embodiments may utilize more or fewer elements without departing from the scope and spirit of the inventive concepts described herein. Note that you get.

  In operation 1502, the sender system 1202 may receive transaction data associated with the transfer from the sender system 1202. Transaction data specifies the remittance amount, the public identifier of the sender (eg, the participant associated with the sender system 1202), and the public identifier of the recipient (eg, the participant associated with the second non-FI system 1208). Can do. As further described herein, the sender and payee public identifiers facilitate the routing of transfers to the payee, without the need to provide account information outside the financial institution, and the sender financial account and Mediation with payee financial accounts may be facilitated.

  In operation 1504, the sender system 1202 may provide transaction data to the first non-FI system 1206 via the public network 1214 (or any network). In various embodiments, the sender system 1202 may provide transaction data to a physical purchase terminal or an application sourced by an online purchase process supported by the first non-FI system 1206, a website, or the like. Transaction data may include the amount of money transferred and the public identifiers of the sender and recipient.

  It will be appreciated that operations 1502 and 1504 may be optional. For example, as discussed herein, the non-FI system 1206 may send remittance information (eg, a sender's public identifier, credit or debit card number, source account, etc.) without a sender system 1202 from the sender. A physical device configured to receive may be included.

  In operation 1506, 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 sender and payee identifiers are in a format corresponding to the money transfer managed by the payment service system 1218. At operation 1508, the first non-FI system 1206 may provide transaction data to the payment service system 1218 via the public network 1214 (or any other network).

  In operation 1510, payment service system 1218 may verify payment details of the transaction data. As described herein, the verification provides whether the sender's public identifier is valid, whether the recipient's public identifier is valid, and whether the sender provides the requested funds. It may include specifying whether or not to have permission. In some embodiments, the payment service system 1218 verifies that the sender's public identifier is associated with the sender's secret identifier and the FI system (eg, the sender FI system 1210). Similarly, payment service system 1218 may verify that the recipient's public identifier is associated with the recipient secret identifier and the FI system (eg, recipient FI system 1212). Payment verification logic 1304 may perform operation 1510.

  In operation 1512, payment service system 1218 may add some or all of the transaction data to information directory 1280. For example, payment service system 1218 may log remittance information (e.g., time of day, amount of remittance, recipient secret identifier, sender FI identifier, recipient FI identifier, and / or transaction identifier, etc.). In some embodiments, payment service system 1218 may store additional information, such as additional sender public identifiers, along with the payee account. In various embodiments, if a remittance request has been successfully added to the information directory 1280, the payment service system 1218 may send a notification to that effect to the first non-FI system 1206. Information directory management logic may perform operation 1512.

  In operation 1514, the information directory management logic 1306 may collect the sender secret identifier and the recipient secret identifier from the information directory 1280. As discussed herein, the sender's secret identifier may have been previously generated by the sender's FI system 1210 and provided to the payment service system 1218. Similarly, the recipient secret identifier may have been previously generated by the recipient FI system 1212.

  In operation 1516, payment service system 1218 may provide payment notification to sender FI system 1210 via public network 1214 (or any network). The payment notification may notify the sender FI system 1210 that the remittance request has been successfully added to the information directory 1280. The payment notification may include at least some of the transaction data, including a remittance request amount, a sender's secret identifier, and a recipient's secret identifier. The payment notice may include instructions or information to the sender FI system 1210 that assists in sending money to the recipient FI system 1212. Payment notification logic 1308 may perform operation 1516.

  At operation 1518, the sender FI system 1210 may obtain one or more accounts (eg, DDA) associated with the sender's secret identifier. In various embodiments, the sender FI system 1210 may obtain a DDA in the information directory 1260 using the sender's secret identifier. The sender FI system 1210 may identify any number of accounts and / or other information associated with the sender system 1206.

  In operation 1520, the sender FI system 1210 may determine whether the sender account has sufficient funds to perform the transfer. In operation 1522, the sender FI system 1210 may determine whether the sender account has sufficient funds, whether the transaction data is likely fraud / suspect, or any other that may be based on regulatory compliance. Internal checks such as checks can be performed.

  In operation 1524, the sender FI system 1210 provides instructions to the payment service system 1218 to update any relevant status related to whether the funds for the transfer are approved and / or implemented. obtain. From time to time, payment service system 1218 may generate a transaction identifier that identifies the transaction. The transaction identifier may be shared with the sender FI system 1210 and the recipient FI system 1204 by the payment service system 1218. Payment service system 1218 may provide first notification of updated status to first non-FI system 1206, including whether or not funds for remittance should be transferred.

  In operation 1526, payment service system 1218 may provide second notification of updated status to sender system 1202 (or first non-FI system 1206), including whether or not the transfer is made. In various embodiments, payment status management logic 1310 may perform operations 1524 and 1526.

  In operation 1528, the sender FI system 1210 may use the ACH network 1216 to provide the recipient FI system 1212 with a batch transfer that settles the transfer between the two financial institutions. In various embodiments, a request to settle a payment may include a transaction identifier (eg, identifying the transaction and may be linked to a remittance amount, a sender FI system 1210 identifier, and any other information) and / or remittance amount. May include or be associated with an ACH message. In some embodiments, the batch transfer is accompanied by a sender secret identifier, sender public identifier, recipient secret identifier, recipient public identifier, FI identifier of the sender FI system 1210, and / or any other information. Can do. Alternatively, the sender secret identifier, the sender public identifier, the recipient secret identifier, the recipient public identifier, the FI identifier of the sender FI system 1210, and / or any other information may be provided later. In some embodiments, payment status management logic 1310 may perform operation 1528.

  In operation 1530, the payee FI system 1212 may identify the transaction identifier and obtain information related to the transfer, including, for example, the payee and the transfer amount. For example, the payee FI system 1212 may use the transaction identifier to identify the payee and obtain one or more accounts (eg, DDA) associated with the payee.

  In operation 1532, payee FI system 1212 may deposit the amount of money to be transferred to the payee's payee account. For example, funds may be deposited into the recipient's DDA by the recipient FI system 1212 from the amount received in the ACH transfer.

  At operation 1534, the payee FI system 1212 may provide an updated status to the second non-FI system 1208 and / or payee system 1204 indicating that the funds have been transferred to the payee account.

  At operation 1536, the payee FI system 1212 may provide an updated status to the payment service system 1218 indicating that the money has been transferred to the payee account. In operation 1538, payment service system 1218 may provide an updated status to first non-FI system 1206 or sender system 1202 indicating that the money has been transferred to the payee account.

  16A and 16B show flowchart diagrams of methods 1600A and 1600B for securely transferring money from a sender to a recipient in a money transfer system, according to some embodiments. The flowchart of methods 1600A and 1600B may include operations similar to those of FIG. Methods 1600A and 1600B may be performed by one or more of the systems and system components shown in FIGS. Note that the methods 1600A and 1600B may include more or fewer operations than those explicitly indicated.

  In operation 1602, transaction data management logic 1302 may receive transaction data from the first non-FI system 1206 via the public network 1214. The transaction data may specify a remittance amount between the sender and the recipient (eg, between the sender system 1202 and the second non-FI system 1208 or the recipient system 1204). In some embodiments, the transaction data may include a sender public identifier that identifies the sender of the transfer. The sender's public identifier uniquely identifies the sender, but does not include the sender's financial information to protect against external discovery, such as an email address, user name, phone number, alphanumeric string, etc. May contain information that can be used to contact The transaction data may include a payee public identifier that identifies the payee. The recipient public identifier may also include an email address, user name, phone number, alphanumeric string, and the like. The payee public identifier may also uniquely identify the payee, but protects the payee's financial information from external discovery.

  In operation 1604, transaction data management logic 1302 of payment service system 1218 identifies that the sender and recipient are registered to perform the transfer using the sender public identifier and the recipient public identifier, respectively. obtain. In various embodiments, the transaction data management logic 1302 may identify that the sender and recipient are registered in the information directory 1280. The transaction data management logic 1302 may specify that, for example, the sender and / or recipient's public and / or secret identifier is registered in the information directory 1280.

  In operation 1606, transaction data management logic 1302 may use the sender's public identifier to collect the sender's financial institution identifier and sender's secret identifier having the sender financial account. In operation 1608, transaction data management logic 1302 may collect the identifier of the payee financial institution having the payee financial account and the payee secret identifier using the payee public identifier. The transaction data management logic 1302 uses the name, identifier, etc. embedded in the transaction data to identify the sender financial institution and the recipient financial institution to obtain the sender financial institution and / or the recipient financial institution. obtain.

  In operation 1610, the payment notification logic 1308 may send the transaction data and at least some of the acquired information to the sender financial institution to perform the transfer. In various embodiments, the sender secret identifier, the recipient public identifier, the recipient FI system 1212, and the amount transferred may be sent to the sender FI system 1210 by the payment notification logic 1308. The portion of the transaction data may include data sufficient to identify the sender of the remittance, the recipient of the remittance, and the amount of remittance.

  In operation 1612, the sender FI system 1210 may obtain a sender account using the sender secret identifier. In some embodiments, the sender FI system 1210 may identify the sender account by querying the information directory 1260 using the sender secret identifier. The resulting response can be the basis for obtaining a sender account. As discussed herein, during registration, the sender's secret identifier is generated by the sender's FI system 1210 during registration, and the sender's account is maintained or managed by the sender's FI system 1210. Can be used to link one or more account numbers. The sender's secret identifier may not be an account number or an encrypted account number. For example, the sender secret identifier is not provided to the sender system 1202, recipient system 1204, or first non-FI system 1206, but the sender secret identifier is not reverse engineerable (eg, from the sender's secret identifier). You can't get an account number). The sender's secret identifier is not the only identifier that the sender FI system 1210 can use due to its association with other account information. In operation 1614, the sender FI system 1210 may evaluate whether the sender financial account has sufficient funds to perform the transfer. In some embodiments, the sender FI system 1210 ensures that the sender has account access, sufficient funds, and other information necessary to perform the transfer using the public identifier. Or, multiple instructions may be sent to the sender FI system 1210.

  In operation 1616, the sender FI system 1210 may evaluate whether the transfer is likely a fraud based on the transaction data. In some embodiments, the payment validation logic 1304 may identify from the sender's remittance status that the sender appears to be not the person the sender claims. The sender FI system 1210 determines whether the sender's Internet Protocol (IP) address, etc. is valid and / or whether the sender is authorized or whether the sender is attempting to send money from a system previously used. It can be evaluated whether or not remittance was repeated in a short time. If the transfer is approved, the sender FI system 1210 may provide a notification that the transfer can be performed. In operation 1618, payment service system 1218 may receive a notification that sender FI system 1210 can perform the transfer.

  In some embodiments, the payment service system 1218 may generate a transaction identifier associated with the transfer and provide the transaction identifier to the sender FI system 1210 and the payee FI system 1212. The transaction identifier may be used between the sender FI system 1210 and the recipient FI system 1212 in ACH batch transfers.

  In operation 1620, payment notification logic 1308 may provide a remittance status to the sender system 1202 and / or the first non-FI system 1206 indicating that a remittance is taking place.

  In operation 1622, the sender FI system 1210 or payment service system 1218 identifies to the recipient FI system 1212 the transaction identifier, the recipient secret identifier, the transaction amount, the sender financial institution identifier, and / or the sender secret identifier. Transaction data may be provided to the payee financial institution. In various embodiments, the secret identifier is provided so that account information need not be transmitted over the public network 1214 (or other network).

  In operation 1624, the sender FI system 1210 may provide funds (including funds for money transfer) to the recipient FI system 1212 as part of the batch transfer process through the ACH system 1220 and / or the ACH network 1216. At operation 1628, payment status management logic 1310 may receive a notification of the transfer of funds to the payee financial account of the payee financial institution.

  FIG. 17 illustrates a diagram of a data flow 1700 for securely transferring money from a sender to a recipient in a transfer system, according to some embodiments. The data flow 1700 may be a data flow when a participant such as a remittance has not registered in the payment service system 1208 in the past, for example. The data flow 1700 includes the components of the remittance system 1200 shown in FIG. 12 and discussed further herein. More specifically, data flow 1700 includes one of sender system 1202, first non-FI system 1206, second non-FI system 1208, sender FI system 1210, payment service system 1218, and payee FI system 1212. One or more actions. It should be noted that the elements of data flow 1700 are merely examples, and that various embodiments may have more or fewer elements without departing from the scope and spirit of the inventive concepts described herein. Can also be used.

  In operation 1702, the sender system 1202 may receive transaction data associated with the transfer. Transaction data can specify the amount of money to be sent. The transaction data may specify the sender's public identifier (eg, a participant associated with the sender system 1202) and the recipient's public identifier. As described further herein, as further described herein, the sender and payee public identifiers can be used to send money to the payee without having to provide account information outside the financial institution. Facilitating routing and facilitating reconciliation between the sender financial account and the payee financial account. It will be appreciated that the payee system 1204 can also receive transaction data related to the transfer.

  In operation 1704, the sender system 1202 (and the recipient system 1204) may provide transaction data to the first non-FI system 1206 via the public network 1214. In various embodiments, the sender system 1202 may be provided to a physical purchase terminal or an application sourced by a payment process supported by the first non-FI system 1206, a website, or the like. Similarly, the payee system 1204 may also provide transaction details to the second non-FI system 1208 or the first non-FI system 1206. In some embodiments, the first non-FI system 1206 and the second non-FI system 1208 are owned by the same entity. In some embodiments, the sender system 1202 provides the sender's first financial instrument or sender's tokenized financial instrument (to generate the sender's token) to the first FI system 1206; The payee system 1204 provides the payee's second financial product or payee's tokenized financial product (to generate the payee token) to the first non-FI system 1206 or the second non-FI system 1208. To do.

  It will be appreciated that operations 1702 and 1704 may be optional. For example, as discussed herein, the non-FI system 1206 may send remittance information (eg, a sender's public identifier, credit or debit card number, source account, etc.) without a sender system 1202 from the sender. A physical device configured to receive may be included.

  It will be appreciated that the first and second non-FI systems may not be necessary. For example, the sender system 1202 and the receiver system 1204 each provide transaction information (eg, funds transferred, tokenized financial products for creating tokens from the receiver and sender, and public identifiers of the sender and receiver). It can be a smartphone configured to share. Transaction information may be provided to payment service system 1218.

  In operation 1706, the first non-FI system 1206 may route the transaction data to the payment service system 1218. In operation 1708, the first non-FI system 1206 may provide transaction data to the payment service system 1218 via the public network 1214 (or any network). The transaction data may include a sender public identifier, a recipient public identifier, a transfer amount, a recipient token, and a sender token. In some embodiments, the first non-FI system 1206 may receive an account number associated with any number of financial instruments. The first non-FI system 1206 may tokenize the account number of the financial product or provide the account number to a financial service provider associated with the financial product to tokenize the account number. Subsequently, the first non-FI system 1206 or financial service provider associated with the financial instrument provides the payment service system 1218 with an account number token.

  In operation 1710, payment service system 1218 may determine whether the sender is registered with payment service system 1218 using the sender's public identifier. If the sender is already registered, the sender does not need to re-register. If the sender is not recognized, payment service system 1218 may request additional information from the sender, sender system 1202, or first non-FI system 1206 to identify the sender.

  Similarly, payment service system 1218 may determine whether the recipient has registered with payment service system 1218 using the recipient's public identifier. If the recipient is already registered, the recipient need not re-register. If the payee is not recognized, the payment service system 1218 receives additional information from the payee, payee system 1204, first non-FI system 1206, or second non-FI system 1208 to identify the sender. Can be requested.

  In some embodiments, 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 (the sender token and / or Or to generate a recipient token). The first non-FI system 1206 also transmits to the payment service system 1218 the FI identifier associated with the sender's financial instrument (eg, the bank that issued the financial instrument) and the FI identifier associated with the recipient's financial instrument. You can also If the payment service system 1218 specifies a sender's registration (eg, at the time of the sender's registration request), the payment service system 1218 uses the FI identifier to identify the sender's FI system 1210 and the sender's token and money transfer. The public identifier may be provided to the sender FI system 1210.

  At operation 1712, payment service system 1218 may add transaction data to information directory 1280 to temporarily log the transaction. The non-FI system 1210 may, for example, include a sender's public identifier, funds to send, a recipient's public identifier, a financial identifier associated with the financial instrument, a tokenized account number for the financial instrument (eg, a sender's token and / or recipient) It is understood that information related to the transfer can be logged or stored, including any token) or any combination.

  In operation 1714, the payment service system 1218 sends to the sender FI system 1210 via the public network 1214 (or any network) the sender's public identifier, the recipient's public identifier, the sender's token, the money to send, or any Notifications including other information may be provided. The payment service system 1218 sends the payer public identifier, payee public identifier, payee token, money to transfer, or any other information to the payee FI system 1212 via the public network 1214 (or any network). Notifications including can also be provided.

  In operation 1716, the sender FI system 1210 may de-tokenize the sender's token to identify a financial instrument number (eg, credit or debit card number). At operation 1718, the sender FI system 1210 may obtain one or more de-tokenization numbers to identify the sender and any number of accounts (eg, DDA) associated with the sender. In various embodiments, the sender FI system 1210 may further verify the account using the sender's public identifier. The sender FI system 1210 may, for example, identify an account and / or other information associated with the sender system 1206. If the sender and the sender account of the sender FI system 1210 are identified, at operation 1720, the sender FI system 1210 may generate a sender secret identifier and share the secret identification with the payment service system 1218; Payment service system 1218 may then store the information in an information directory.

  At operation 1722, the sender FI system 1210 may determine whether the sender account has sufficient funds to perform the transfer. The sender FI system 1210 may also perform internal checks, such as checks related to whether the transaction data is likely to be fraud / suspicious. In operation 1724, the sender FI system 1210 may provide an instruction to the payment service system 1218 to update the status of the transaction.

  In operation 1726, payment service system 1218 may provide first notification of updated status to first non-FI system 1206, including whether or not funds for remittance can be transferred. In operation 1728, payment service system 1218 provides second notification of updated status to first non-FI system 1206 or sender system 1202, including whether or not funds for transfer can be transferred. obtain. In various embodiments, payment status management logic 1310 may perform operations 1726 and 1728.

  From time to time, payment service system 1218 may generate a transaction identifier associated with the transaction. In one example, payment service system 1218 may generate a transaction identifier when a sender secret identifier is received from sender FI system 1210 and a recipient secret identifier is received from recipient FI system 1212. Payment service system 1218 may provide transaction identifiers and any other information to payee FI system 1212 and sender FI system 1210.

  In operation 1730, the recipient FI system 1212 may detokenize the recipient token. At operation 1734, the recipient FI system 1212 may obtain one or more DDAs associated with the recipient's public identifier. The payee FI system 1212 may obtain the DDA associated with the sender system 1202 in the information directory 1270 using the payee's public identifier.

  In operation 1734, the sender FI system 1210 may provide batch payments to the recipient FI system 1212 to settle the payment of the transfer via the ACH network 1216. In various embodiments, a request to settle a payment may include both transfers over the ACH network 1216 and may involve a transaction identifier and a transfer amount.

  At operation 1736, the payee FI system 1212 may identify the funds from the ACH batch process using the transaction identifier and deposit the funds to be transferred into the payee's payee account. Funds may be deposited into the recipient's DDA by the recipient FI system 1212. At operation 1738, the payee FI system 1212 may update the status of the payee account to indicate that funds have been transferred to the payee account. In operation 1740, the payee FI system 1212 may provide an updated status to the payee non-FI system 1208 and / or payee system 1204 indicating that the funds have been transferred to the payee account.

  At operation 1742, the payee FI system 1212 may provide the payment service system 1218 with an updated status indicating that funds have been transferred to the payee account. At operation 1744, payment service system 1218 may provide an updated status indicating that funds have been transferred to the payee account to first non-FI system 1206. In operation 1746, the first non-FI system 1206 may provide an updated status to the sender system 1202 indicating that the funds have been transferred to the payee account. In operation 1748, the sender FI system 1210 and the recipient FI system 1212 may settle the amount to be sent via the ACH system 1220 and / or the ACH network 1216. Act 1748 may be performed as part of a batch transfer process between two organizations.

  In some embodiments, the payee FI system 1212 may place the funds in the payee's account before the funds are received from the sender FI system 1210 through the ACH network. Next, when a batch payment is received, it can be refunded to the recipient FI system 1212.

  18A and 18B show flowchart diagrams of methods 1800A and 1800B for securely transferring money from a sender to a recipient in a money transfer system, according to some embodiments. The flowchart of 1800A or 1800B may be similar to the flow discussed in FIG. Methods 1800A and 1800B may be performed by one or more of the systems or system components shown in FIGS. Note that the methods 1800A and 1800B may include more or fewer operations than are explicitly shown.

  In operation 1802, transaction data management logic 1302 of payment service system 1218 may receive transaction data from first non-FI system 1206 via public network 1214. Transaction data includes the amount of money sent between the sender and the recipient (eg, between the sender system 1202 and the second non-FI system 1208 or the recipient system 1204), and the sender who identifies the sender of the transfer. The public identifier, the recipient public identifier that identifies the recipient of the transfer, the sender token of the sender's tokenized financial instrument, the recipient token of the recipient's tokenized financial instrument, and the sender associated with the sender's financial instrument The FI identifier (eg, the issuing bank of the sender's financial instrument) and / or the recipient's FI identifier associated with the recipient's financial instrument may be specified. It will be appreciated that transaction data can be received from any number of sources. For example, the transaction data management logic 1302 receives some of the transaction data from the first non-FI system 1206, and from any number of entities, the sender token of the sender's tokenized financial instrument, the recipient's tokenized financial instrument. Multiple recipient tokens, or both.

  In operation 1804, transaction data management logic 1302 may identify that the sender and recipient are not registered to perform the transfer using the sender public identifier and recipient public identifier, respectively. In various embodiments, the transaction data management logic 1302 may identify that the sender and payee are registering through a non-financial institution. In various embodiments, the sender, recipient, or both are not registered.

  In operation 1806, transaction data management logic 1302 may identify the sender FI system 1210 or the recipient FI system 1212 using the financial institution identifier from the transaction data received in operation 1804.

  In operation 1808, the payment notification logic 1308 may send at least some of the transaction data to the sender financial institution to transfer the money. In various embodiments, the sender public identifier, recipient public identifier, amount transferred, recipient FI identifier, and / or sender token may be sent by the payment notification logic 1308 to the sender FI system 1210. The portion of the transaction data may include data sufficient to identify the sender of the remittance, the recipient of the remittance, and the amount of remittance.

  In operation 1810, payment notification logic 1308 may send at least some of the transaction data to the payee financial institution to transfer money. In various embodiments, the payee public identifier, the sender public identifier, the transfer amount, the sender FI identifier, and / or the payee token may be sent to the payee FI system 1212 by the payment notification logic 1308. The portion of the transaction data may include data sufficient to identify the sender of the remittance, the recipient of the remittance, and the amount of remittance.

  In operation 1812, the sender FI system 1210 may de-tokenize the sender secret identifier. In operation 1814, the sender FI system 1210 obtains the sender account using information from the de-tokenized sender secret identifier (eg, using the sender's credit card number or debit card number). Can do.

  At operation 1816, the sender FI system 1210 may evaluate whether the sender financial account has sufficient funds to perform the transfer. In some embodiments, the sender FI system 1210 may ensure that the sender has account access, sufficient funds, and other information necessary to perform the transfer using the public identifier.

  At act 1818, the sender FI system 1210 may evaluate whether the transfer is likely a fraud based on the transaction data. The sender FI system 1210 may provide notification that the transfer can be performed. In operation 1820, payment service system 1218 may receive a notification that sender FI system 1210 can perform the transfer.

  At act 1822, the recipient FI system 1212 may de-tokenize the recipient's token. In act 1824, the recipient FI system 1212 uses the de-tokenized recipient token (eg, using the recipient's credit card number or debit card number) to receive the recipient FI system 1212. One or more of the person's accounts may be identified. If successful, the payee FI system 1212 may provide a notification to the payment service system 1218 that the payee's account has been identified at operation 1826. The payment service system 1218 may provide the recipient FI system 1212 and / or the sender FI system 1210 with a transaction identifier for the remittance and notification that one or both financial institutions are ready to send the remittance.

  At operation 1828, the sender FI system 1210 may provide funds for the transfer to the recipient FI system 1212 as part of a batch transfer process that includes an indication of a transaction identifier through the ACH system 1220 and / or the ACH network 1216. At act 1830, payment status management logic 1310 may receive a notification of the receipt of the transfer to the payee financial account of the payee financial institution.

  FIG. 19 shows a diagram of a data flow 1900 for registering participants in a remittance system, according to some embodiments. The data flow 1900 is shown in FIG. 12 and includes the components of the remittance system 1200 discussed further herein. Data flows may include payment service system 1218 and participant system 1902, participant non-FI system 1904, and participant FI system 1906. In some embodiments, participant system 1902 corresponds to sender system 1202, participant non-FI system 1904 corresponds to first non-FI system 1206, and participant FI system corresponds to sender FI system 1210. To do. In various embodiments, participant system 1902 corresponds to recipient system 1204, participant non-FI system 1904 corresponds to second non-FI system 1208, and participant FI system 1906 corresponds to recipient FI system 1212. To do. Data flow 1900 further includes a plurality of operations corresponding to instructions that registration logic 1286 may provide to components of remittance system 1200. It should be noted that the elements of data flow 1900 are merely examples, and various embodiments may include more or fewer elements without departing from the scope and spirit of the inventive concepts described herein. It can also be used.

  In operation 1908, participant FI system 1906 may create a participant account. The participant account may be linked to the financial institution's financial account. In various embodiments, a participant account may include an account number and / or other account identifier that can be used to identify the account when the participant attempts to register the account's public identifier. The participant account may be linked to a financial institution's financial account including financial data such as debit / credit card information, bank branch code, account number and the like. The financial data may include an identifier (name, bank branch code, etc.) of a financial institution that provides financial services to the participant system 1902. At operation 1910, participant FI system 1906 may create a financial instrument (eg, print a debit / credit card and / or create an online account for the participant account).

  In operation 1912, participant FI system 1906 may share the financial product with the participant (user of participant system 1902), participant system 1902, and / or payment service system 1218. Participant FI system 1906 may share financial products with a financial service provider (eg, MasterCard). In some embodiments, the code may be mailed and / or sent electronically to the participant or participant system 1902 so that the participant can register a user identifier for the participant account.

  In some embodiments, participant system 1902 may interact with participant non-FI system 1904. In other embodiments, a participant may interact with a participant non-FI system 1904 (eg, using a credit card and a participant non-FI physical device). Although operations 1914-1920 are described herein from the use of participant system 1902, it is understood that other embodiments do not require all or any of the operations.

  At operation 1914, participant system 1902 may receive a request from the participant to register a participant account using the financial instrument. At operation 1916, participant system 1902 may provide the participant with one or more participant registration screens. At operation 1918, participant system 1902 may receive the participant's public identifier. In some embodiments, the public identifier and account information may be provided to the input device of participant system 1902. The public identifier may include alphanumeric characters or other strings that can identify the participant. Participant system 1902 may receive passwords, biometric techniques, other authentication techniques, etc. that allow verification of public identifiers.

  At operation 1920, participant system 1902 may send a public identifier or participant account information to participant non-FI system 1904. In some embodiments, a participant system 1902 or a participant (eg, a user) may provide a financial product (eg, an account number associated with the financial product, a bank branch code, etc.) to the participant non-FI system 1904. Or tokenize the financial product to generate a token for the financial product and provide the token to a specific non-FI system 1904 or financial service provider. The participant system 1902 can also send the FI identifier that issued the financial product to the participant non-FI system 1904.

  At operation 1922, the participant non-FI system 1904 or a financial service provider associated with the account data may identify tokenized account data representing participant account information. Tokenized account data may include encrypted participant account information. In some embodiments, the tokenized account data may include a proxy number that represents a card number such as debit / credit in the participant account information. In operation 1926, the participant non-FI system 1904 (or financial service provider) may identify tokenized account data representing participant account information.

  In operation 1924, the participant non-FI system 1904 and / or financial service provider may send a public identifier or tokenized account data to the payment service system 1218. In operation 1926, participant non-FI system 1904 may optionally send a public identifier and / or tokenized account data to participant FI system 1906. In some embodiments, participant non-FI system 1904 may provide information to participant FI system 1906, payment service system 1218, or both.

  In operation 1928, participant FI system 1906 may optionally send a public identifier and / or tokenized account data to payment service system 1218. In one example, the information is shared with the participant FI system 1906 by the participant non-FI system 1904, and thus the participant FI system 1906 optionally shares all or some of the information with the payment service system 1218. .

  In operation 1930, payment service system 1218 may verify that the public identifier is not being used. Validation of the public identifier may include reviewing the information directory to identify whether another user has already registered that public identifier in connection with another account. In some embodiments, payment service system 1218 may return a failure message if the public identifier is already in use. User identity verification logic 1404 may perform operation 1930.

  In operation 1932, payment service system 1218 may identify the participant financial institution using tokenized account data or financial institution identifiers from participant system 1902 and / or participant non-FI system 1904. In some embodiments, payment service system 1218 may evaluate the tokenized account for a name, identifier, etc. corresponding to the financial institution. In various embodiments, payment service system 1218 may de-tokenize tokenized account data to extract information and identify participant financial institutions (eg, financial institutions that manage participant FI system 1906). .

  At operation 1934, the payment service system 1218 may send the public identifier and tokenized account data (eg, the participant's token) to the participant FI system 1906. Account verification logic 1410 may perform operations 1932 and 1934.

  In operation 1936, participant FI system 1906 may detokenize the tokenized account data. Participant FI system 1906 may decrypt and translate any proxy number or the like to obtain account information for the participant account. In operation 1938, participant FI system 1906 may perform a DDA lookup using account information of the participant's account, for example. At operation 1940, participant FI system 1906 may map the DDA to the user's public identifier. Participant FI system 1906 may generate a secret identifier associated with the participant's account number in participant's FI system 1906. In some embodiments, participant FI system 1906 may write an account number (eg, DDA), public identifier, and secret identifier to an information directory stored in participant FI system 1906. At operation 1942, participant FI system 1906 may update the public identifier status to reflect that the public identifier is available for future transfers and other transactions involving the participant.

  In operation 1944, participant FI system 1906 may provide payment service system 1218 with confirmation that the public identifier is available for future transfers or other transactions involving the participant. Participant FI system 1906 may also share the participant's secret identifier with payment service system 1218.

  In operation 1946, the information directory management logic 1306 may associate the participant secret identifier with the participant public identifier. At operation 1948, payment service system 1218 may provide participant non-FI system 1904 a success message that the public identifier is available for future transfers and other transactions involving the participant. Account verification logic 1410 may perform operation 1948.

  At operation 1950, participant non-FI system 1904 may provide and configure participant system 1902 to indicate a success message indicating that the participant registration was successful. At operation 1952, participant non-FI system 1904 may provide participant system 1902 with a success message that the public identifier is available for future transfers or other transactions involving the participant. In operation 1954, a success message may be displayed on participant system 1902.

  FIG. 20 shows a flowchart diagram of a method 2000 for registering participants in a remittance system, according to some embodiments. The method 2000 may be performed by one or more of the methods shown in FIGS. Note that the method 2000 may include more or fewer operations than are explicitly shown.

  In operation 2002, participant account issue logic 1402 creates a participant financial account. Participant account issue logic 1402 may create a sender financial account corresponding to a particular sender or a recipient account corresponding to a particular recipient. Participant account issue logic 1402 may link a participant account to a financial account maintained / sponsored by a financial institution. In some embodiments, participant accounts may be linked to collateral, cash, etc. Participant account issue logic 1402 may store information about participant accounts in information directory 1280.

  In operation 2004, user identity verification logic 1404 receives the proposed public identifier from the participant. Proposed public identifiers may or may not include email addresses, alphanumeric user names, common payment identification codes (UPICs), telephone numbers, user-generated or system-generated numbers or strings, etc. . The proposed public identifier may provide a basis for identifying participants and / or participant systems.

  In operation 2006, user identification verification logic 1404 verifies whether any participant is associated with the proposed public identifier. User identification verification logic 1404 determines whether the proposed public identifier includes an email address, alphanumeric user name, common payment identification code (UPIC), telephone number, user generated or system generated number or string, etc. Can be verified. User identification verification logic 1404 may verify whether the proposed public identifier corresponds to a public identifier used to identify another participant.

  In operation 2008, if the proposed public identifier is not associated with any participant, user identification verification logic 1404 registers the proposed public identifier with the participant public identifier. As discussed herein, the participant public identifier and any other financial information (eg, token, financial instrument number, etc.) may be shared with the participant's financial institution. Alternatively, the participant may interact with the financial institution (eg, log the participant's account), and the financial institution may verify the participant's account. The financial institution may generate a participant secret identifier associated with the participant and the account number of the participant at the financial institution and provide the participant secret identifier to the payment service system.

  User identity verification logic 1404 may store the proposed public identifier in information directory 1280 along with the secret identification and associated account information.

  FIG. 21 illustrates an example of a digital device 2100 according to some embodiments. Digital device 2100 includes a processor 2105, a memory system 2110, a storage system 2115, a communication network interface 2120, an input / output (I / O) interface 2125, a display interface 2130, and a bus 2135. Bus 2135 may be communicatively coupled to processor 2015, memory system 2110, storage system 2115, communication network interface 2120, I / O interface 2125, and display interface 2130.

  In some embodiments, the processor 2105 includes circuitry or any processor capable of processing executable instructions. Memory system 2110 includes any memory configured to store data. Some examples of the memory system 2110 are storage devices such as RAM or ROM. Memory system 2110 may include a RAM cache. In various embodiments, the data is stored in the memory system 2110. Data in the memory system 2110 can be cleared or eventually transferred to the storage system 2115.

  Storage system 2115 includes any storage device configured to obtain and store data. Some examples of storage system 2115 are flash drives, hard drives, optical drives, and / or magnetic tape. In some embodiments, the digital device 2100 includes a memory system 2110 in the form of RAM and a storage system 2115 in the form of flash data. Both memory system 2110 and storage system 2115 include computer readable media that may store instructions or programs executable by a computer processor including processor 2105.

  A communication network interface (com network interface) 2120 may be coupled to the data network. The communication network interface 2120 may support communication via, for example, an Ethernet connection, a serial connection, a parallel connection, or an ATA connection. The communication network interface 2120 may also support wireless communication (eg, 802.1 a / b / g / n, WiMAX, LTE, 3G, 2G). Those skilled in the art will appreciate that the communication network interface 2120 can support many wired and wireless standards.

  An optional input / output (I / O) interface 2125 is any device that receives input from a user and outputs data. Display interface 2130 is any device that can be configured to output graphics and data to a display. In one example, display interface 2130 is a graphics adapter.

  Those skilled in the art will appreciate that the hardware elements of the digital device 2100 are not limited to those shown in FIG. Digital device 2100 may include more or fewer hardware elements than shown. In addition, hardware elements may share functionality and still be within the various embodiments described herein. In one example, encoding and / or decoding may be performed by a processor 2105 and / or a coprocessor located at the GPU.

  The functions or components described above may consist of instructions stored on a storage medium such as a computer readable medium. The instructions can be obtained and executed by a processor. Some examples of instructions are software, program code, and firmware. Some examples of storage media are memory devices, tapes, disks, integrated circuits, and servers. The instructions, when executed by the processor, are operable to instruct the processor to operate according to some embodiments. Those skilled in the art are familiar with instructions, processors, and storage media.

  For purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the description. However, it will be apparent to those skilled in the art that embodiments of the present disclosure may be practiced without these specific details. In some instances, modules, structures, processes, features, and devices are shown in block diagram form in order to avoid obscuring the description. In some cases, a functional block diagram or flowchart is shown to represent data or logic flow. Block diagram or flow diagram components (eg, modules, blocks, structures, devices, features, etc.) may be variously combined, separated, deleted, reordered in ways other than those explicitly described and shown herein. And can be substituted.

  As used herein, "one embodiment", "embodiments", "some embodiments", "various embodiments", "specific embodiments", "other embodiments", "series of embodiments" Etc. means that a particular feature, design, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearances of the phrases “in one embodiment” or “in an embodiment” in various places in the specification are not necessarily all referring to the same embodiment, and are mutually exclusive to other embodiments. It is not a separate or alternative embodiment. Furthermore, various features are described with or without an explicit reference to “embodiments”, etc., and various features can be combined in various ways and included in some embodiments, while others Various embodiments can be omitted. Similarly, various features are described which may be preferred or necessary in some embodiments but not in other embodiments.

  The language used herein has been selected primarily for readability and teaching purposes, and has not been selected to describe or limit the spirit of the invention. Accordingly, it is intended that the scope not be limited by this detailed description, but rather be limited by any claim that results from an application based on this specification. Accordingly, the disclosure of the embodiments is intended to be illustrative rather than limiting of the scope, which is set forth in the following claims.

Claims (20)

Receiving transaction data associated with a remittance, the transaction data comprising: a remittance amount for the remittance, a sender public identifier identifying the sender of the remittance, and a recipient public identifier identifying the recipient of the remittance Receiving, specifying a financial institution identifier of the sender financial institution, a financial institution identifier of the payee financial institution, and the tokenized financial product of the sender
Identifying the sender financial institution using the financial institution identifier of the sender financial institution, wherein the sender financial institution is a member of a payment network;
Providing said sender's tokenized financial instrument to said sender's financial institution, said sender's financial institution de-tokenizing said sender's tokenized financial instrument, and associated with said sender Making it possible to identify the account of the sender financial institution,
Receiving from the sender financial institution the sender's secret identifier generated by the sender financial institution, wherein the sender financial institution is the account of the sender financial institution associated with the sender. Generating and receiving the sender secret identifier when
Associating the sender's secret identifier with the sender's public identifier;
Providing the remittance financial institution to the remittance amount of the remittance, the payee public identifier, and the payee financial institution identifier so that the remittance financial institution satisfies the remittance amount of the remittance Enabling the identification of the availability of money in the account associated with
Generating a transaction identifier associated with the remittance;
Providing the transaction identifier and a payee secret identifier to the payee financial institution to enable the payee financial institution to identify an account associated with the payee so that the payee financial institution can Enabling an ACH message to be received over a network, wherein the ACH message indicates a payment from the sender financial institution to the payee financial institution, and the ACH message is the sender financial The transaction identifier generated by an institution and identifying the transfer between a sender and a recipient, the ACH message is received by the recipient financial institution from the ACH batch transfer and the receipt Enabling and allowing money to be deposited into said account associated with a person.   The method of claim 1, further comprising verifying that the remittance has permission to perform the remittance using the public identifier. Receiving the recipient's tokenized financial instrument and a recipient FI identifier associated with the recipient financial institution;
Identifying the payee financial institution using the payee FI identifier, wherein the payee financial institution is a member of the payment network;
Providing the beneficiary financial institution with the tokenized financial product of the payee, the payee financial institution de-tokenizing the tokenized financial product of the payee and associated with the payee Making it possible to identify the account of the payee financial institution,
Receiving, from the payee financial institution, the payee secret identifier generated by the payee financial institution, wherein the payee financial institution is associated with the payee financial institution associated with the sender. The method of claim 1, further comprising: generating and receiving the payee secret identifier when an account is verified.   The remittance amount of the remittance, the sender's public identifier identifying the sender of the remittance, the recipient public identifier identifying the recipient of the remittance, the financial institution identifier of the sender financial institution, the receipt The method of claim 1, further comprising receiving the financial institution identifier of a human financial institution and the tokenized financial instrument of the sender from a first online product reseller.   The method of claim 4, wherein the first online product reseller tokenizes the sender's financial instrument to create the tokenized financial instrument of the sender.   The method of claim 5, wherein the financial instrument is issued by the sender financial institution.   5. The method of claim 4, further comprising receiving the recipient's tokenized financial instrument from a second online product reseller that is different from the first online product reseller.   The method of claim 7, wherein the second online product reseller tokenizes the payee's financial instrument to create the tokenized financial instrument of the payee.   The method of claim 1, wherein the payee financial institution transfers money to the account associated with the payee before the payee financial institution receives the ACH message.   The method of claim 1, further comprising providing a notification request to the sender system requesting whether or not the sender is to accept the transfer from the sender. One or more processors;
A memory coupled to the one or more processors, the memory configured to instruct the one or more processors to perform a method, the method comprising:
Receiving transaction data associated with a remittance, the transaction data comprising: a remittance amount for the remittance, a sender public identifier identifying the sender of the remittance, and a recipient public identifier identifying the recipient of the remittance Receiving, specifying a financial institution identifier of the sender financial institution, a financial institution identifier of the payee financial institution, and the tokenized financial product of the sender
Identifying the sender financial institution using the financial institution identifier of the sender financial institution, wherein the sender financial institution is a member of a payment network;
Providing said sender's tokenized financial instrument to said sender's financial institution, said sender's financial institution de-tokenizing said sender's tokenized financial instrument, and associated with said sender Making it possible to identify the account of the sender financial institution,
Receiving from the sender financial institution the sender's secret identifier generated by the sender financial institution, wherein the sender financial institution is the account of the sender financial institution associated with the sender. Generating and receiving the sender secret identifier when
Associating the sender's secret identifier with the sender's public identifier;
Providing the remittance financial institution to the remittance amount of the remittance, the payee public identifier, and the payee financial institution identifier so that the remittance financial institution satisfies the remittance amount of the remittance Enabling the identification of the availability of money in the account associated with
Generating a transaction identifier associated with the remittance;
Providing the transaction identifier and a payee secret identifier to the payee financial institution to enable the payee financial institution to identify an account associated with the payee so that the payee financial institution can Enabling an ACH message to be received over a network, wherein the ACH message indicates a payment from the sender financial institution to the payee financial institution, and the ACH message is the sender financial The transaction identifier generated by an institution and identifying the transfer between a sender and a recipient, the ACH message is received by the recipient financial institution from the ACH batch transfer and the receipt Enabling and enabling depositing money into the account associated with a person.   The system of claim 11, wherein the method further comprises verifying that the remittance has permission to perform the remittance using the public identifier. The method
Receiving the recipient's tokenized financial instrument and a recipient FI identifier associated with the recipient financial institution;
Identifying the payee financial institution using the payee FI identifier, wherein the payee financial institution is a member of the payment network;
Providing the beneficiary financial institution with the tokenized financial product of the payee, the payee financial institution de-tokenizing the tokenized financial product of the payee and associated with the payee Making it possible to identify the account of the payee financial institution,
Receiving, from the payee financial institution, the payee secret identifier generated by the payee financial institution, wherein the payee financial institution is associated with the payee financial institution associated with the sender. 12. The system of claim 11, further comprising: generating and receiving the payee secret identifier when an account is verified.   The method includes the remittance amount of the remittance, the remittance public identifier identifying the remitter of the remittance, the payee public identifier identifying the payee of the remittance, and the financial institution of the remittance financial institution. The system of claim 1, further comprising receiving an identifier, the financial institution identifier of the payee financial institution, and the tokenized financial instrument of the remittance from a first online product reseller.   15. The system of claim 14, wherein the first online product reseller tokenizes the sender's financial instrument to create the tokenized financial instrument of the sender.   The system of claim 15, wherein the financial instrument is issued by the sender financial institution.   15. The system of claim 14, wherein the method further comprises receiving the recipient's tokenized financial instrument from a second online product reseller different from the first online product reseller.   The system of claim 17, wherein the second online product reseller tokenizes the payee's financial instrument to create the tokenized financial product of the payee.   The system of claim 1, wherein the payee financial institution transfers money to the account associated with the payee before the payee financial institution receives the ACH message. A non-transitory computer readable media system comprising executable instructions, wherein the executable instructions are executable by a processor to perform the method, the method comprising:
Receiving transaction data associated with a remittance, the transaction data comprising: a remittance amount for the remittance, a sender public identifier identifying the sender of the remittance, and a recipient public identifier identifying the recipient of the remittance Receiving, specifying a financial institution identifier of the sender financial institution, a financial institution identifier of the payee financial institution, and the tokenized financial product of the sender
Identifying the sender financial institution using the financial institution identifier of the sender financial institution, wherein the sender financial institution is a member of a payment network;
Providing said sender's tokenized financial instrument to said sender's financial institution, said sender's financial institution de-tokenizing said sender's tokenized financial instrument, and associated with said sender Making it possible to identify the account of the sender financial institution,
Receiving from the sender financial institution the sender's secret identifier generated by the sender financial institution, wherein the sender financial institution is the account of the sender financial institution associated with the sender. Generating and receiving the sender secret identifier when
Associating the sender's secret identifier with the sender's public identifier;
Providing the remittance financial institution to the remittance amount of the remittance, the payee public identifier, and the payee financial institution identifier so that the remittance financial institution satisfies the remittance amount of the remittance Enabling the identification of the availability of money in the account associated with
Generating a transaction identifier associated with the remittance;
Providing the transaction identifier and a payee secret identifier to the payee financial institution to enable the payee financial institution to identify an account associated with the payee so that the payee financial institution can Enabling an ACH message to be received over a network, wherein the ACH message indicates a payment from the sender financial institution to the payee financial institution, and the ACH message is the sender financial The transaction identifier generated by an institution and identifying the transfer between a sender and a recipient, the ACH message is received by the recipient financial institution from the ACH batch transfer and the receipt A non-transitory computer readable media system comprising: enabling money to be deposited into said account associated with a person .

Images