KR102634772B1 - Systems and methods for assisting secure transactions in non-financial institutional systems - Google Patents

Abstract

The systems and methods discussed herein relate to securely transferring funds over private networks. To receive transaction data related to fund transfers that include tokenized financial instruments, to enable the sender financial institution to de-tokenize the tokenized financial instruments and to identify the sender's account; Provide tools to the sender's financial institution, receive the sender's private identifier generated by the sender's financial institution, provide the sender's financial institution with the transfer amount of the funds transfer to enable the sender's financial institution to transfer the funds, and provide the sender's financial institution with the transfer amount of the fund transfer to enable the sender's financial institution to transfer the funds. Provides a transaction identifier and a recipient private identifier to the recipient financial institution to enable the institution to receive ACH messages from the sender financial institution over the ACH network, and the ACH messages are sent to the sender to effect a transfer of funds over the ACH network. Represents a payment from a financial institution to a recipient financial institution.

Description

Systems and methods for assisting secure transactions in non-financial institutional systems

This technical field relates to systems and methods for transferring funds through electronic money transfer networks, and more particularly to accessing physical payment terminals or online payment processes maintained by entities other than financial institutions through electronic money transfer networks. It relates to systems and methods for safely transferring funds to individuals.

Many existing systems for transferring money over electronic money transfer networks, such as the Automatic Clearing House (ACH) network, have limitations. For example, a conventional wire transfer typically requires both the sender of the money and the recipient of the money to be physically present at the financial institution or have direct access (e.g., online access) to an account at the financial institution. Requiring the sender and recipient to have an account at a financial institution(s) will benefit some segments of the population, such as the underbanked and/or those who do not have access to financial institutions. This can make it difficult to transfer money. Additionally, conventional wire transfers, which involve transferring money or exchanging currencies between financial institutions, are highly regulated and typically require additional fees. These fees can form the basis of transaction costs that make the transfer of money between individuals inefficient, impractical, or otherwise difficult.

Many existing systems for transferring money to individuals do not accommodate otherwise possible money transfer scenarios. By way of example, existing systems for transferring money may prevent a person wishing to send and receive funds from accessing funds at a physical payment terminal at a retail store or other non-financial institution. Existing systems for transferring money may use non-financial institutions' online payment processes to prevent those wishing to send or receive money from accessing funds. Debit transfer systems and other systems for transferring money to people at a retail store and/or a retail website may be expensive and/or may not assist in transferring money between people. Many existing systems for transferring money to individuals may not make funds available soon (e.g., in substantially “real time”) after a request to transfer funds is made. As a result, it has often proven difficult to cost-effectively transfer money to individuals via electronic money transfer networks, especially to individuals who do not have access to a financial institution's payment system.

Systems, methods, and computer-readable media discussed herein may securely transfer funds to an individual connected to a second (e.g., public) network via an electronic money transfer network, such as an Automated Clearing House (ACH) network. It is related to An exemplary method includes receiving transaction data related to a funds transfer, wherein the transaction data includes: a transfer amount of the funds transfer, a sender public identifier to identify the sender of the funds transfer, a recipient public identifier to identify the recipient of the funds transfer, and the sender. Specifying a financial institution identifier for the financial institution, a financial institution identifier for the recipient financial institution, and the sender's tokenized financial instrument, determining the sender financial institution using the financial institution identifier for the sender financial institution. As such, the sender financial institution may, as a member of the payment network, step in order to enable the sender financial institution to de-tokenize the sender's tokenized financial instruments and to identify the sender financial institution's account associated with the sender. providing the remitter's tokenized financial instrument to the remitter financial institution, receiving, from the remitter financial institution, the remitter's private identifier generated by the remitter financial institution, wherein the remitter financial institution generating a sender private identifier when verifying an account with a sender financial institution associated with the sender, associating the sender private identifier with a sender public identifier, and determining the availability of money in an account associated with the sender to satisfy the transfer amount of the funds transfer. providing the sender financial institution with a transfer amount of the funds transfer, a recipient public identifier, and a recipient financial institution identifier, generating a transaction identifier associated with the funds transfer, and allowing the recipient financial institution to determine Providing a transaction identifier and a recipient private identifier to the recipient financial institution to identify the account associated with the recipient and enable the recipient financial institution to receive ACH messages over the ACH network, wherein the ACH messages are sent from the sender financial institution. represents a payment to a recipient financial institution, the ACH message is generated by the sender financial institution and includes a transaction identifier to identify the transfer of funds between the sender and recipient, and the ACH message is an ACH message that is generated by the recipient financial institution from an ACH batch transfer. In some embodiments, the method may include authorizing a sender to use a public identifier to effect a transfer of funds. It further includes the step of confirming whether you have it. The method includes receiving a recipient's tokenized financial instrument and a recipient FI identifier associated with the recipient financial institution, using the recipient FI identifier to determine a recipient financial institution, wherein the recipient financial institution is a member of a payment network. , providing the recipient's tokenized financial instrument to the recipient financial institution so that the recipient financial institution can de-tokenize the recipient's tokenized financial instrument and identify an account at the recipient financial institution associated with the recipient; and receiving, from the recipient financial institution, a recipient private identifier generated by the recipient financial institution, wherein the recipient financial institution generates the recipient private identifier when verifying an account at the recipient financial institution associated with the sender. there is.

The method includes the transfer amount of the funds transfer, the sender public identifier to identify the sender of the funds transfer, the recipient public identifier to identify the recipient of the funds transfer, the financial institution identifier for the sender financial institution, and the financial institution identifier for the recipient financial institution; and receiving the sender's tokenized financial instrument from the first online reseller of the product. The first online reseller of the product may tokenize the sender's financial instrument to create the sender's tokenized financial instrument. Financial instruments may be issued by the remitter's financial institution.

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

An 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 includes receiving transaction data related to a funds transfer, wherein the transaction data includes: a transfer amount of the funds transfer, a sender public identifier to identify the sender of the funds transfer, a recipient public identifier to identify the recipient of the funds transfer, and the sender financial institution. specifying a financial institution identifier for, a financial institution identifier for the recipient financial institution, and a tokenized financial instrument of the sender, determining the sender financial institution using the financial institution identifier for the sender financial institution, The remitter financial institution, which is a member of the payment network, is responsible for enabling the remitter financial institution to de-tokenize the remitter's tokenized financial instruments and to identify the remitter's financial institution's account associated with the remitter. providing a tokenized financial instrument of the remitter financial institution, receiving, from the remitter financial institution, the remitter's private identifier generated by the remitter financial institution, wherein the remitter financial institution identifies a remitter financial institution associated with the remitter; generating a sender private identifier when verifying the sender's account; associating the sender private identifier with a sender public identifier; and determining, at the sender's financial institution, the availability of money in the account associated with the sender to satisfy the transfer amount of the funds transfer. providing the transfer amount of the funds transfer, a recipient public identifier, and a recipient financial institution identifier to the sender financial institution, generating a transaction identifier associated with the funds transfer, and allowing the recipient financial institution to open an account associated with the recipient. Providing a transaction identifier and a recipient private identifier to the recipient financial institution to identify the recipient financial institution and enable the recipient financial institution to receive ACH messages over the ACH network, wherein the ACH messages are used to transmit payments from the sender financial institution to the recipient financial institution. , the ACH message is generated by the sender financial institution and includes a transaction identifier to identify the transfer of funds between the sender and the recipient, and the ACH message allows the recipient financial institution to retrieve the money from the ACH batch transfer and It may include a step of allowing the deposit to be deposited into an account associated with the recipient.

A nontransitive computer-readable medium system can include executable instructions, and the executable instructions can be executed by a processor to carry out the method. The method includes receiving transaction data related to a funds transfer, wherein the transaction data includes a transfer amount of the funds transfer, a sender public identifier to identify the sender of the funds transfer, a recipient public identifier to identify the recipient of the funds transfer, and a sender financial institution. specifying a financial institution identifier for the sender financial institution, a financial institution identifier for the recipient financial institution, and a tokenized financial instrument of the sender, determining the sender financial institution using the financial institution identifier for the sender financial institution, wherein the sender The financial institution is a member of the payment network, in order to enable the sender financial institution to de-tokenize the sender's tokenized financial instruments and to identify the account at the sender financial institution associated with the sender. providing a tokenized financial instrument to the remitter financial institution, receiving, from the remitter financial institution, a private identifier of the remitter generated by the remitter financial institution, wherein the remitter financial institution is Creating a sender private identifier when verifying the account; Associating the sender private identifier with a sender public identifier; Allowing the sender financial institution to determine the availability of money in the account associated with the sender to satisfy the transfer amount of the funds transfer. Provide the transfer amount of the funds transfer, the recipient public identifier, and the recipient financial institution identifier to the sender financial institution, create a transaction identifier associated with the funds transfer, and cause the recipient financial institution to identify the account associated with the recipient. Providing a transaction identifier and a recipient private identifier to the recipient financial institution to enable the recipient financial institution to receive an ACH message over the ACH network, wherein the ACH message transmits a payment from the sender financial institution to the recipient financial institution. represents, the ACH message is generated by the sender financial institution and includes a transaction identifier to identify the transfer of funds between the sender and recipient, and the ACH message enables the recipient financial institution to obtain money from the ACH batch transfer and Allowing a deposit to be deposited into an account associated with the recipient.

These and other advantages will become apparent to those skilled in the art upon reading the following description and studying several examples of the drawings.

1 shows a schematic diagram of a funds transfer system where the sender and recipient use different banking institutions, according to an example implementation.
Figure 2 shows a schematic diagram of token management logic capable of managing tokens for fund transfer requests, according to an example implementation.
3A illustrates a process whereby a funds transfer request results in funds being received by a registered or unregistered recipient, according to an example implementation.
FIG. 3B illustrates a process whereby a funds transfer request results in funds being received by a registered or unregistered recipient, according to an example implementation.
4 shows a screenshot of a web page that may be provided to a user to configure user preferences and manage connections with other users.
Figure 5 shows a screen shot of a web page that can be provided to a user to configure notification settings.
Figure 6 shows a screenshot of a web page that can be provided to a user to transfer money to a recipient.
7 shows a screenshot of a web page that may be presented to an out-of-network user when the out-of-network user transfers a payment.
8 shows a schematic diagram of a funds transfer system where the sender and recipient use different banking institutions, according to an example implementation.
9 depicts a flow diagram illustrating an example process to assist in transferring funds to an out-of-network recipient, in accordance with an example implementation.
FIG. 10 shows a flow diagram illustrating an example process to assist in transferring funds from an out-of-network sender to an in-network recipient, according to an example implementation.
11 shows a flow diagram illustrating an example process to facilitate an expedited transfer of funds from an in-network sender to an in-network recipient, according to an example implementation.
FIG. 12 illustrates a diagram of a funds transfer system for securely transferring funds from a sender non-financial institution system to a recipient non-financial institution system, according to some implementations.
Figure 13 shows a diagram of transfer logic, according to some implementations.
Figure 14 shows a diagram of registration logic, according to some implementations.
Figure 15 depicts a diagram of data flow for securely transferring funds from a sender to a recipient within a funds transfer system, according to some implementations.
FIG. 16A depicts a flowchart diagram of a method for securely transferring funds from a sender to a recipient within a funds transfer system, according to some implementations.
FIG. 16B depicts a flowchart diagram of a method for securely transferring funds from a sender to a recipient within a funds transfer system, according to some implementations.
FIG. 17 illustrates a diagram of data flow for securely transferring funds from a sender to an unregistered recipient within a funds transfer system, according to some implementations.
FIG. 18A depicts a flowchart diagram of a method for securely transferring funds from a sender to an unregistered recipient within a funds transfer system, according to some implementations.
FIG. 18B depicts a flowchart diagram of a method for securely transferring funds from a sender to an unregistered recipient within a funds transfer system, according to some implementations.
Figure 19 shows a diagram of data flow for registering a participant within a funds transfer system, according to some implementations.
Figure 20 shows a diagram of a flow chart of a method for registering a participant within a funds transfer system, according to some implementations.
21 shows an example of a digital device, according to some implementations.

Referring to Figure 1, a funds transfer system 100 is shown that implements a payment network or “funds transfer payment network”. The funds transfer system 100 may be used by a sender to transfer funds to a recipient and by a recipient to receive funds. Fund transfer system 100 may assist in transferring funds from a sender to a recipient (e.g., recipient) without both parties revealing any financial account information to each other. The sender and recipient may be individuals or business entities. In an example implementation, the sender uses a bank account as the source of funds. In other implementations, the sender may use a credit card, debit card, business credit card, or check card as the source of funds. Fund transfer system 100 can support intra-bank transfers (i.e., transfers in which both the sender and recipient have accounts at the same bank and funds are transferred between accounts within the same bank) and inter-bank transfers (i.e., transfers in which the sender and recipient have different accounts). It can be used both for holding accounts at banks and for funds being transferred between accounts at different banks.

Fund transfer system 100 includes, among other systems, a sender computer system 110, a bank computer system 120, a recipient computer system 130, a bank computer system 150, a payment services computer system 160, and An automatic clearinghouse computer system 170 may be included. Each of the foregoing systems may communicate over a network 140, which may include one or more of the Internet, a cellular network, Wi-Fi, Wi-Max, a dedicated banking network, etc. 1 and throughout the remainder of the description, to provide an example, a sender may effect a transfer of funds from an account maintained by bank computer system 120, and a recipient may transfer funds from an account maintained by bank computer system 150. It is assumed that funds are received using . Accordingly, computer system 120 is sometimes referred to herein as a sender bank computer system, and computer system 150 is sometimes referred to herein as a recipient bank computer system. Of course, it will be appreciated that any given bank computer system may operate with different capabilities in the context of different fund transfer transactions. Additionally, although the examples provided herein are primarily situations of a sender requesting to transfer funds to a recipient, it will also be understood that a recipient may request a transfer of funds from the sender.

The remitter computer system 110 may interact with banking functions provided through the online banking area of a website provided by the remitter bank computer system 120 or through a website provided by the payment service 160 to create transactions. To function, it may be utilized by individual users (e.g., business owners or employees, consumers, and others). The sender computer system 110 may be, for example, a user's computer (e.g., a desktop or laptop computer), a cellular phone, a smartphone, a mobile handheld wireless e-mail device, a personal digital assistant, a portable gaming device, or other Appropriate devices may be included. The remitter computer system 110 may also include one or more servers, each having one or more processes configured to execute instructions stored in memory. For example, such an arrangement may be used where the sender is a merchant or other business entity.

Sender computer system 110 may include network interface logic 112, display device 114, input device 116, and client application 118. Network interface logic 112 may include program logic that connects remittance sender computer system 110 to network 140, for example. As described in more detail below, for example, remitter computer system 110 may receive and display screens on display device 114 containing account information, transaction instructions, and the like. In an example implementation, such a screen may be used to request username and password information. Such screens may also be used to prompt the user to provide information related to 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, e-mail address, selection of recipient from an electronic directory, and/or other information. Such screens may also include screens that display information related to past transactions. Such a screen is presented to the user via display device 114. Input device 116 may be used to allow the user to initiate account access and to assist in receiving funds transfer request information from the user.

Client application 118 may include program logic (i.e., stored executable instructions) configured to implement at least some of the functionality described herein. As can be appreciated, the level of functionality residing in sender computer system 110 relative to other components of funds transfer system 100 may vary depending on the implementation. Client application 118 simply receives a web page from banking computer system 120 and displays the received web page in a web browser (e.g., Internet Explorer®, Mozilla Firefox®, Chrome®, Safari®, and other ) can be. Client applications may also include mobile web browsers, text messaging (SMS) interfaces, dedicated applications, or other programs suitable for sending and receiving information over network 140.

Bank computer system 120 is operated by banking institutions that maintain accounts held by customers, such as demand deposit accounts, credit card accounts, home mortgage loans, student loans, and others. Bank computer system 120 may, for example, execute instructions stored within memory, transmit and receive data stored within memory, and perform operations described herein associated with the logic or processes shown in Figures 1-7. Implementation may include one or more servers each having one or more processors configured to perform different operations.

Bank computer system 120 may include network interface logic 122, account processing logic 124, account database 126, and information directory 128. Network interface logic 122 may include program logic that connects bank computer system 120 to network 140, for example. Network interface logic 122 may assist in secure communication between the bank and the sender and/or recipient. Network interface logic 122 may also assist in communicating with other entities, such as other banks, clearing systems, and others. Network interface logic 122 may include user interface program logic configured to generate web pages and provide web pages to users who access bank computer system 120 via network 140.

Account processing logic 124 processes the account holder's accounts (such as account credits and debits for checking and savings accounts, credits and debits for home mortgage and home equity accounts, credits and debits for student loan accounts, and others). Account processing is performed to process transactions in relation to transactions. Accordingly, whenever funds are transferred into or out of the account of an account holder (e.g., sender or recipient of funds), account processing logic 124 stores account information for the account maintained by the bank on behalf of the bank's customers (e.g., sender or recipient of funds). It reflects the appropriate debits and credits in the account database 126, which stores transactions (e.g., transactions, information about account holders, and others). Account processing logic 124 may also process a funds transfer request to transfer funds from a sender using sender computer system 110 to a recipient using recipient computer system 130.

Identifiers other than bank account/routing numbers (e.g., e-mail addresses, phone numbers, Universal Payment Identification Code (UPIC), randomly generated numbers, and others) may be used to identify the recipient of a fund transfer. When doing so, the information directory 128 may be used. Information directory 128 is a database maintained to enable a financial institution to translate/associate a recipient's cell phone number (or e-mail address, or other identifier) to the bank account number/routing number of the recipient's bank account. It can be. This arrangement allows the sender to identify the recipient (e.g., using an e-mail address or other identifier) without the need to have private/personal information about the recipient (i.e., the recipient's bank account/routing number). to enable identification.

Users may register their information using the information directory 128 prior to any financial transaction. A user may be added to the information directory 128 when registering with the funds transfer system 100 through the bank computer system 120. Upon registration, a new entry may be created for the newly registered user within a database implementing information directory 128. Users may share with other individuals with whom such users interact (for example, in the same way that people selectively or freely share telephone numbers and e-mail addresses with other individuals in order to communicate with such individuals). You may provide one or more identifiers (e.g., phone number, e-mail address, and others). 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 (e.g., e-mail address, phone number, user-generated or system-generated string, etc.) (possibly used) Information directory 128 may also create or otherwise associate identifiers, which are maintained securely and used to identify users within information directory 128. Herein, such identifiers are referred to as “private identifiers.” The private identifier may be, for example, a unique ID of a database entry for the user within information directory 128. Although the private identifier is known to the information directory 128, it need not be known to the user associated with such private identifier or to other users. However, this may be known to banks and other entities that are members of the funds transfer payment network. In addition to public identifier(s) (e.g., phone number, e-mail address, and others) and private identifiers (e.g., database UID), account information (account number, Other information, such as routing numbers, etc.) and user preferences, may also be stored within the database entry. For example, if a user registers for funds transfer system 100 during secure online banking on bank computer system 120, at least some of this information may be automatically recorded.

Additionally, the database entry for each user may also store a registry of other users connected to that user. In other words, for each user, a registry may be stored containing a list of each other user with whom the user has established connections. Such a connection may be established, for example, when a user first sends or receives money to or from another user. Connections may also be established by a user interface that allows users to add connections to other users through lookup services within the information directory 128 and/or other information directories. An example of such a user interface is described below with respect to FIG. 4 . As described in more detail below, users may include registered users within a funds transfer payment network, as well as other affiliated payment networks. For each user within the registry, additional information may be stored, such as their unique ID and/or other information. As another example, information about different users may be stored in separate database entries within information directory 128.

In various implementations, there may be multiple information directories, each directory maintained by a different organization or entity. For example, a user maintaining an account at a bank associated with bank computer system 120 may register through bank computer system 120, and a user maintaining an account at a bank associated with bank computer system 150 may register through bank computer system 120. Registration can be done through the bank's computer system 150, as can other users maintaining accounts with other entities. Such entities may also include non-bank entities (e.g., payment processing companies, credit agencies, credit card network providers, and others), and users may also register through such non-bank entities.

In addition to the public and private identifiers already described herein, additional identifiers may also be used. For example, such additional identifiers may be treated with variable security levels. As another example, as described in more detail below, modifications to existing public identifiers may be used to implement special purpose public tokens, public tokens with custom functionality, and others.

Token management logic 129 manages tokens. For example, token management logic 129 may be configured to register tokens, accept tokens, generate tokens, and so on. Token management logic 129 may also assist with identification of the recipient when the token is not recognized. Token management logic 129 may also be used to customize the properties of the token, such that a particular account is used, a particular notification method is used, or others. Token management logic 129 is described in more detail below with respect to FIG. 2 .

Recipient computer system 130 may be configured generally in the same manner as other computer systems described herein. For example, if the recipient of funds is an individual, computer system 130 may be a cellular phone, smartphone, mobile handheld wireless e-mail device, personal digital assistant, portable gaming device, desktop computer, or other suitable device. . Computer system 130 may also include one or more servers, each having one or more processes configured to execute instructions stored in memory. For example, such an arrangement may be used where the recipient is a merchant or other business.

In one implementation (e.g., if the recipient is a brick-and-mortar merchant), recipient computer system 130 may be a point of sale device configured to electronically obtain public token information from a customer. device) (e.g., a cash register system). For example, a cash register system may be equipped with a near field communication (NFC) reader device capable of reading public tokens (e.g., cell phone numbers) from near field communication (NFC) equipped cell phones. As another example, a cell phone can include an application configured to generate a barcode or other image containing a public token on a display screen, and a cash register system can have a barcode reader configured to read the barcode. Recipient computer system 130 may then request payment from the sender through funds transfer system 100 using the public token obtained at the point of sale.

Recipient bank computer system 150 may be configured in a similar manner as sender bank computer system 120. Accordingly, bank computer system 150 includes network interface logic (122), account processing logic 124, account database 126, and information directory 128, corresponding to network interface logic 122, account processing logic 124, account database 126, and information directory 128 of bank computer system 120. 152), account processing logic 154, account database 156, and information directory 158.

Payment services computer system 160 may be associated with payment services configured to assist in the transfer of funds between banks, such as payment services provided by non-bank entities such as those described above. The payment service may be an entity formed, for example, as a joint venture between banks and/or other entities that send and receive funds using the funds transfer system 100. As another example, the payment service may be a third party vendor. As another example, the payment service may be a web portal provided for an online community of individuals, wherein such individuals acquire usernames/login IDs or otherwise become registered members. Individuals may use a web portal, for example, to interact with each other and/or to interact with services provided by the online community. Examples of online communities include MSN®, iPhone® Users, Facebook®, Linkedln®, and others. A payment service may be an additional service provided to members of an online community, for example, by a web portal. As another example, payment services may be provided by one of the banks, i.e., the bank may then perform the operations described herein as implemented by the bank computer system 120/150 and the payment service computer system ( All of the operations described herein as performed by 160) are performed.

Herein, the banks associated with computer systems 120 and 150 are assumed to be “member banks.” That is, the banks associated with computer systems 120 and 150 are assumed to follow established protocols for transferring funds using funds transfer system 100. For example, in the context of a payment service created as a joint venture, the member banks may include the bank that is at least a partial owner of the joint venture, as well as potentially other banks. Although two member banks are shown in Figure 1, it will be appreciated that there may be additional member banks. Additionally, as discussed above, non-bank entities may also be members. The payment service may also be utilized by senders and recipients who have bank accounts at non-member banks, for example, by allowing such users to register directly using the payment services computer system 160. Accordingly, a user does not need to be a customer of any particular bank to be able to use the funds transfer system 100.

Payment services computer system 160 may, for example, execute instructions stored within memory, transmit and receive data stored within memory, and perform operations described herein associated with the logic or processes shown in FIGS. 1-6. It may include one or more servers, each having one or more processors, configured to perform different operations. Payment services computer system 160 includes network interface logic 162 and information directory 168. Although not specifically shown, payment services computer system 160 may include account processing logic and account databases, in the same or similar manner as account processing logic 124, 155 and account databases 126, 156. You will understand that it exists. Network interface logic 162 may include user interface program logic configured to generate web pages and provide web pages to users who access payment services computer system 160 via network 140.

When identifiers other than bank account/routing numbers (e.g., e-mail addresses, phone numbers, Universal Payment Identification Code (UPIC), randomly generated numbers, and others) are used, the information directory 168 It can be used. As described above with respect to information directories 128 and 158, information directory 168 provides that, for users who register through payment computer service system 160, payment services may be provided to the recipient's cell phone number (or e-mail address). , or other tokens) to the bank account number/routing number of the recipient's bank account. This arrangement allows the sender to identify the recipient (e.g., using an e-mail address or other identifier) without the need to have private/personal information about the recipient (i.e., the recipient's bank account/routing number). to enable identification.

Users, including senders and recipients, may register their information in advance using the information directory 168, for example, if such users are not banked or do not have an account with any other member entity. . Additionally, payment services computer system 160 may be configured to allow users who only wish to transfer funds to do so without registration. For example, to create a web page that receives credit card information from the sender to complete the transaction each time the sender wishes to transfer funds without the sender having to register in any way with the payment services computer service system 160. , a payment service computer service system 160 may be configured.

As can be appreciated, the information stored in information directory 168 may vary depending on the implementation, including the extent to which information is also stored within information directories 128 and 158. For example, in one implementation, when a user registers at bank computer system 120 (or at bank computer system 150, or at another member entity's computer system), information is stored in information directory 128 and information directory 128. It can be stored in both directories 158. Information directory 128 may store complete identification of the user's bank account and other information collected during registration. Conversely, information directory 168 may store a reduced amount of information, such as registered public token(s), their associated financial institutions, and private tokens (e.g., unique IDs) associated with each token. You can. No more specific bank account numbers/routing numbers, or other sensitive information need be stored in information directory 168. In another implementation, instead of using the payment services computer system 160 to maintain the information directory 168, such information may be stored entirely within the information directories 128, 158 maintained by the individual member banks. As can also be appreciated, the extent to which transaction details are tracked and maintained in account processing logic 124, 154, relative to the extent to which transaction details are tracked and maintained by payment services computer system 160, may vary depending on the implementation. It may vary depending on the example.

The Automated Clearing House (ACH) system 170 is used to transfer funds to and from the bank accounts of senders and recipients. As known, the ACH Network is a nationwide, batch-oriented electronic funds transfer system that provides interbank clearing of electronic payments for participating depository financial institutions. An ACH entry may begin with an account holder (known as a recipient in ACH terminology) authorizing an Originator (e.g., a person or company) to issue an ACH debit or credit to the account. Depending on the ACH transaction, the originator must receive authorization from the recipient. Under ACH's rules and regulations, non-financial institutions cannot issue ACH transactions (whether debit or credit) to an account without prior approval from the recipient. Once approval is received, the originator creates an ACH entry for provision to an Originating Depository Financial Institution (ODFI), which can be any financial institution that creates an ACH. These ACH entries are then transmitted to the ACH operator (i.e., a central clearing facility through which financial institutions transmit and receive ACH entries, such as the Federal Reserve or an electronic payment network), which processes the ACH transactions accordingly. , the recipient's account is forwarded to a Receiving Depository Financial Institution (RDFI), which issues a credit or debit. However, RDFI may reject an ACH transaction and return it to ODFI with appropriate reason, such as insufficient funds in the account or the account holder indicating that the transaction was not authorized. RDFIs have a predefined amount of time (e.g., 2 to 6 days from receipt of an ACH transaction) to effect returns. The ODFI receiving the return of the ACH entry may re-provide the ACH entry more than two times for settlement purposes, or up to a total of three times. Again, the RDFI may reject the transaction, after which the ODFI may no longer offer transactions through ACH. The foregoing description of the ACH system is one that is currently available, and current implementations of the invention will continue to function similarly even if some methods and steps within the ACH system are changed.

Referring to Figure 2, Figure 2 illustrates token management logic 169 in more detail. As shown in Figure 2, token management logic 169 includes sponsor identification or sponsor discovery logic 182, registration logic 184, token approval logic 186, rules engine 188, and token creation logic 190. ) includes. Although token management logic 169 is shown, it will be appreciated 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 a sender uses a token to identify a recipient who is not recognized in the information directory 128 of the sender's bank computer system 120 (e.g., because the recipient is not a customer of the sender's bank) , sponsor identification logic 182 may be configured to receive a token from the sender bank computer system 120 and access information directory 168 to provide a unique ID and identification of the financial institution associated with that token.

As can be appreciated, the extent to which bank computer systems 120, 150 have sponsor identification logic that operates in the same manner as sponsor identification logic 182 is, in part, also stored within information directories 128 and 158. Compared to the scope of information, it may vary depending on the scope of information stored in the information directory 168. In various implementations, a high or low degree of reliability may be placed in the information directory 168 to enforce user identification functions in a centralized manner in connection with the transfer of funds between entities. Herein, to provide an example, it is assumed that information directory 168 is utilized to implement user identification functions in a centralized manner in connection with fund transfers between entities. In such an implementation, duplication of sponsor identification logic 182 and all functionality of bank computer systems 120, 150 may be prevented.

In one implementation, the funds transfer payment network is configured to interact with other affiliated payment networks (e.g., PayPal, CashEdge, and others). In such an arrangement, if the token presented by the sender bank computer system 120 is not recognized within the information directory 168, the sponsor identification logic 182 may determine whether the token is recognized by any other affiliated payment network. configured to transmit an inquiry to another affiliated payment network (e.g., in a predetermined sequence). If the recipient is registered with another payment network, funds can be transferred to the recipient by routing the funds through the other payment network. In implementations where a user search service is provided by information directory 168, the search service may operate in the same manner to identify users registered by remote entities. Information may also be stored within the information directory 168 identifying the payment network determined to be associated with the token in question, thereby assisting in transferring additional funds to that token in the future. Accordingly, in such an arrangement, funds may be deposited to a recipient who is not registered with the funds transfer payment network but is registered with another payment system. Additionally, such funds may be deposited to the recipient without the sender needing to know or be concerned as to whether the recipient is registered with the funds transfer payment network.

Registration logic 184 is configured to assist in the process of registering new users. For example, in the preceding discussion, if a token is not recognized in the information directory 168 and has not been registered on any other affiliated payment network, the registration logic may include sending an e-mail or other invitation to the recipient to register with the payment network. It may be configured to transmit a communication to a recipient. Such e-mail may include a link to a website provided by payment services computer system 160. Registration logic 184 may be configured to generate web pages for presentation to users on a website to assist with the registration process. If, based on information provided by the user when registering on the website, it is determined that the user is a customer of one of the member entities, the user may be directed to the member entity's website to complete the registration process. As can be appreciated, registration logic 184 may also be used to determine if a user (e.g., an online community website or merchant website and (such as when the website is reached through another website, and in other cases) web pages can be provided to the user in different scenarios. Registration logic 184 may create new database entries within information directory 168 in response to input received from a user.

Token approval logic 186 is configured to approve tokens. For example, when a user registers a new token, the token approval logic 186 determines that the user is associated with that token (e.g., a user wishing to register a cell phone number as a token must register that cell phone number). It can be configured to confirm that the owner is the de facto owner. (Here, the term "owned" in the context of a phone number refers to a phone number assigned to one particular user, as opposed to assigned to another user, and to the user and the telephone carrier that provided the number to the user. (The term is similarly used in the context of e-mail addresses.) As another example, when a user wishes to register a new e-mail address, the approval logic 186 Approval operations such as sending an e-mail to the user with a new e-mail address can be performed. The e-mail may, for example, contain a link that must be accessed by the user to successfully complete the registration process.

Additionally, token approval logic 186 may be configured to perform approval operations on previously-registered tokens. For example, a user who registered a cell phone number may ultimately switch the cell phone number and/or cell phone carrier. Token approval logic 186 may be configured to process a release directory issued by a cell phone carrier and listing cell phone numbers released by that carrier. For example, if a registered cell phone number is listed as revoked, token approval logic 186 may determine whether the cell phone number is no longer a valid token for that user, or if the user has simply lost their cell phone carrier. To determine whether or not you have changed but maintained your cell phone number, an e-mail may be sent to the user to the registered e-mail address.

Token acceptance logic 186 also sends follow-up communications to users who wish to use the token to send/receive money from other users, in cases where there is uncertainty as to whether that other user is the correct owner of the token. It can be configured to do so. For example, the token acceptance logic 186 may be configured to notify the sender that such uncertainty exists, to request that the sender provide confirmation regarding information that has been provided regarding the recipient, to provide additional information related to the recipient, etc. , and so on. For example, if a user wants to transfer funds using the token jsmith@abc-company.com, the owner of the token jsmith@abc-company.com (e.g. due to a change in employment at ABC Company) If there is uncertainty as to whether something has changed, an e-mail may be sent to the user. Authorization logic 186 may also be configured to connect to other networks or online communities (e.g., Facebook, Linkedln, etc.) to obtain additional information that can be used to authorize tokens. Token acceptance logic 186 may also be configured to track public token changes by date and time of use and the date and time a particular recipient ceases using the particular public token.

Accordingly, to facilitate registration of tokens and to ensure that the token is associated with its correct owner, registration logic 182 and authorization logic 184 cooperate. In one implementation, the entity registering a token is responsible for ensuring the validity of the registration. For example, if the recipient bank registered token 415-555-1226 and subsequently accepted payment for a user who registered token 415-555-1226 (e.g., if the previous owner changed their cell phone number), If the user who registered the token 415-555-1226 is not the actual owner of the cell phone number at the time of the funds transfer (due to the new owner being on a different payment network), the recipient bank is responsible for refunding the money to the sender. there is. Accordingly, the recipient bank is responsible for correctly authorizing the user upon registration and for routinely processing the release directory to ensure that the authorization remains valid.

In one implementation, the guarantee (and/or limited access to the information directory 168) may be provided to third parties as a service. For example, an online retailer refunding money to a customer may want to verify that a token previously provided by the customer (e.g., "415-555-1226") is maintained accurately. If funds are refunded to a customer of the "415-555-1226" token, but that customer no longer owns that token, the payment service will be responsible for refunding the funds to the correct customer. The fee charged for a service may be based, for example, on the dollar value of the liability the paying service accepts for providing inaccurate information. As another example, a per-token fee may be charged for identifying a user based on a token and/or for identifying a token based on the user's identification (e.g., e-mail address, cell phone number, etc.). services can be provided.

The rules engine 188 is configured to allow users to configure different attributes for different tokens. Such attributes may be specified by rules that are configured based on preferences specified by the user. In various implementations, the rules engine 188 may provide the user with default settings that are used until the user decides to customize the rules. For example, rules engine 188 may be used to direct funds from a bank to various accounts held by a user (e.g., to convey at least a portion of the funds or to transfer funds to a particular type of account). Methods, etc. can be configured. As another example, funds may be split between multiple accounts according to rules specified by the user, for example, funds may also be transferred into at least one of a retirement account, a savings account, a PayPal® account, or a certificate of deposit. It can be. As another example, a portion of the funds received may be passed on to other users registered with the payment network. As another example, the rules engine 188 can be used to configure how a notification is sent to the recipient notifying the recipient that a funds transfer request has been made by the sender. For example, according to one implementation, a rule may specify the channel(s) through which the notification is sent (e-mail, text message, voicemail, and other), the e-mail account(s) through which the notification is sent, and/or telephone. It may be configured to specify number(s), and others. As another example, if the funds transfer amount is greater than the threshold, the user may receive an automated phone call instead of an e-mail message, or an e-mail/phone call instead of no message. As another example, if the funds transfer request is originating from a particular sender, the user may specify the notification mode (eg, e-mail, voice mail, or text message). As another example, rules engine 188 can be used to determine the payment channel used to transfer funds to a recipient (e.g., ACH transfer, credit card network, PayPal network, printed or mailed check, and others). can be configured. As another example, the rules engine 188 may be used to configure the speed at which funds are transferred to recipients (e.g., immediate, same-day, overnight, 2-day payments, and others). As another example, transaction limits may be configured using the rules engine 188 (e.g., to ensure that no more than $500 is charged for a particular token during a predetermined period of time, such as a day, a week, a month, etc.) .

Token generation logic 190 may be configured to generate additional public tokens for users. Token creation logic 190 may work with rules engine 188 to generate different tokens comprised of different attributes. For example, a business may wish to use different individual tokens depending on who is responsible for the processing of a particular transaction in the business. For example, a recipient who is a landlord who owns several apartment buildings may want to generate different tokens for each apartment building. For example, the additional tokens may be based on a user-provided alphanumeric string, may be system generated based on a pseudo random string, or may be generated in some other manner. For example, if the landlord recipient already uses an e-mail address (e.g. landlord@mail.com) as a public token, the additional public token may be a variation of the public token the recipient is already using (e.g. landlord@mail.com). @mail.com/buildingl, landlord@mail.com/building2, landlord@mail.com/building3 and others). Such tokens can then be configured with different properties using the rules engine 188. For example, if each of the different buildings has a different building manager, an e-mail may be sent to the e-mail address of each building manager for a particular apartment building when the tenants of that apartment building pay rent. .

As another example, the landlord recipient could provide each tenant with a different public token for the tenant to use to pay rent. Again, for example, additional tokens may be variants of public tokens already used by the recipient (e.g., landlord@mail.com/unit 101, landlord@mail.com/unit l02, landlord@mail.com/unit 103, and Other) may be. Bank computer system 150 may then receive funds from each tenant, and all funds may be transferred to one or more accounts belonging to the landlord. Account processing logic 154 generates a report showing the funds received associated with each token (thereby showing, for example, which tenants paid in a given month and which tenants did not pay in a given month). It can be configured to do so. The token may also be programmed with additional information, such as the amount of the expected monthly payment. Account processing logic 154 may then be configured to compare the actual received amount with the expected monthly payment to ensure that the tenant has paid in full and to track the tenant's overall account status.

As another example, the recipient may also construct a single-use token. For example, a recipient can organize an event where other users are expected to contribute financially to the event. The recipient can then construct a token that can be provided to other users (e.g., johnsmith@mail.com/moms-birthday-party). Account processing logic 154 may then generate a report showing funds received from various users, among other users associated with that token.

As another example, the sender may also configure other tokens. For example, a sender could use a first token (e.g., johnsmith@mail.com) as its default token and an additional special-purpose token (e.g., college savings) if the payment is from another account. johnsmith@mail.com/collegesavings) for tuition payments from funds.

As another example, as described above, information directories 128, 158, 168 may provide search services that users can use to establish connections with other users. In such implementations, users can configure aspects of their tokens that are displayed to other users. For example, if an individual does business under a different name (e.g., Joseph Smith DBA "Joe's Lawn Service"), the user configures the token so that the business name is displayed to other users, even though the name on the account is actually the individual's full name. It may be desirable to be able to do so. In this way, the operator's customers can easily establish a connection with the operator.

Referring to FIGS. 3A and 3B , FIGS. 3A and 3B depict a process by which funds may be received by a registered or unregistered recipient, according to an example implementation. 3A and 3B, a funds transfer message is received from a sender at sender bank computer system 120 and propagated to the recipient bank computer system, which causes the funds to be deposited into the recipient's account. Specifically, at step 301 of Figure 3A, the sender's bank computer system 120 receives a funds transfer request from the sender that identifies the recipient using a token. At 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's bank (i.e., a transfer from the same bank). If the token is associated with a user registered with the sender's bank, at step 313 the recipient's account information is retrieved from the information directory 128. Subsequently, at step 315, the funds are transferred to the recipient's account. As discussed more specifically below in connection with Figures 4-6, funds may be transferred to the recipient's financial account based on the preferences of the sender and recipient.

If, at step 311, the recipient is not registered with the sender's bank, the process proceeds to step 321. At step 321, banking computer system 120 transmits an inquiry to payment services computer system 160, and it is determined whether the token is associated with a user registered with another member entity of the funds transfer payment network. For example, if this is the first time the sender has transferred funds to this particular recipient, bank computer system 120 may transmit the recipient's public token as provided by the sender. In this scenario, sponsor identification logic 182 may perform a search of information directory 168 to determine if the token is associated with a user registered with another member principal. If the public token is located within the directory, payment services computer system 160 may return a unique ID associated with the public token, along with identification of the financial institution or other member entity associated with the sender bank computer system 120. . The sender's 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, an alias or other name the sender wishes to use to identify the recipient).

As another example, if the sender has previously transferred funds to this recipient, banking computer system 120 may transmit the recipient's unique ID to payment services computer system 160. In this scenario, sponsor identification logic 182 may use the unique ID as an index into a database implementing information directory 168 to locate the recipient within information directory 168. Assuming that the unique ID is still valid and is still located in information directory 168, payment services computer system 160 may return the financial institution or other member entity associated with the sender banking computer system 120. As another example, if the sender has previously transferred funds to such recipient, bank computer system 120 may make the connection based on the unique ID itself (e.g., if the unique ID is embedded in information identifying the financial institution). Identify the member subject that becomes the member. At step 323, the sender's registry is updated to include an entry for identifiers, including the recipient's unique identifier. At step 325, the funds are transferred to the member entity (e.g., the recipient bank in the example of Figure 1) for deposit along with the recipient's unique ID. The information directory 158 may be accessed by the recipient bank computer system 150 to identify the recipient's account number, based on the unique ID. The funds can then be deposited into the recipient's bank account.

If, at step 321, the recipient is not a registered user with another member entity of the funds transfer payment network, the process proceeds to step 331 shown in FIG. 3B. At step 331, sponsor identification logic 182 of payment services computer system 160 sends an inquiry to another payment network (e.g., PayPal®, Star, Blink, Interlink, Plus, etc.) and determines whether the token is It is determined whether it is associated with a user registered on another payment network. For example, sponsor identification logic 182 may send a query 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 inquiries to other affiliated payment networks until the payment network with which the recipient registered an account is identified. At step 333, if the recipient is registered with another payment network, information may also be stored within the information directory 168 identifying the payment network determined to be associated with the token in question, thereby allowing additional access to that token in the future. We can help you transfer funds. Next, at step 335, the funds may be transferred to the recipient by routing the funds through another payment network. Accordingly, in such an arrangement, funds may be deposited to a recipient who is not registered with the funds transfer payment network without the sender needing to know or be concerned whether the recipient is registered with the funds transfer payment network.

If, after the search for other payment networks is completed, no other payment network in which the recipient is registered is identified, it is assumed that the recipient is not a registered user of any payment network. Accordingly, at step 341 an invitation is sent to the recipient to invite him or her to join the payment network. For example, if the token used by the sender is an e-mail address, an e-mail is sent to the recipient informing him that another user wants to transfer funds to the recipient and invites him to join the payment network. A link within the e-mail may, for example, direct the recipient to a website provided by bank computer system 120. As another example, if the token used by the sender is a cell phone number, a text message containing a URL inviting the recipient to join the payment network may be sent to the recipient. As can be appreciated, in other circumstances, for example, if the recipient is not a registered user of the funds transfer payment network, even if the user is a registered user of another payment network, such an invitation may be sent to the recipient. You can.

At step 343, the recipient may be prompted to provide account information. At step 351, based on account information, it may be determined whether the user is a customer of one of the member entities. For example, a bank routing number for a demand deposit account may be used to determine whether a user is a customer of one of the member entities. If the recipient is a customer of the member entity, at step 353 the recipient may be forwarded to the member entity (e.g., the recipient bank in the example of Figure 1) for registration. The unique ID is associated with the recipient within the information directory 158 of the recipient bank computer system 150 and within the information directory 168 of the payment services computer system 160. At step 355, the sender's registry is updated to include the recipient, including the recipient's unique identifier. At step 357, funds are transferred to the recipient.

If the recipient is not a customer of the member entity, at step 363 the recipient is registered by the payment services computer system 160. At step 365, the sender's registry is updated to include an entry for the recipient, including the recipient's unique identifier. At step 367, funds are transferred to the recipient. As can be appreciated, if the recipient has customized fund transfer preferences, the fund transfer may be processed by rules engine 188 according to the recipient preferences. An example of token customization to reflect such preferences was previously described in relation to the rule engine 188 and token generation logic 190.

Figure 4 is a screen shot of a web page 400 that may be presented to a user when the user selects the preferences 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 registered for the payment network). The web page 400 includes a plurality of fields including a default notification settings field 401, a connection management field 411, and a recipient management field 431. The default notification settings field 401 provides the user with information related to the current default notification settings for fund transfer events. As shown in the screen shot of Figure 4, notification settings field 401 contains settings (field 403) for specifying the phone number to which automatic phone call notifications or text message notifications should be sent and e-mail notifications to be sent. The e-mail address to be addressed (field 405) may be included. The user may also specify the name on the account (field 407) as should be displayed to other users when they receive funds transfer notification. Information specified within field 407 may also be used in other situations, for example, when another user searches for a connection through a search service within information directories 128, 156, 168. A user may configure the rules engine 188 to notify a user regarding a transaction based on user preferences received from the user prior to the transaction occurring. If the user is unable to configure custom notification settings, default notification settings may be used. In various implementations, the user can select different/custom notification settings for each talk the user has registered for.

In the example shown in Figure 4, the phone number that can receive a call, text message, or voice message when a predetermined event occurs is 949-555-7878. Additionally, the e-mail address that can be used to notify the user that a fund transfer has occurred from or for the user's account is pat@mail.com. Users can choose to be notified by e-mail or phone, or both.

Token field 413 may display special tokens that the user has registered or is in the process of registering. Status field 415 may display 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 money. For example, for an inactive phone number (i.e., 650-555-5555), a user can send/receive funds using this token for a connection established before the token was deactivated. However, users cannot establish new connections with other users based on these tokens. For example, this could be a mobile number that the user previously owned. Since the Unique ID serves as the basis for fund transfers after the connection is established, previously established connections are still valid (since they are based on the Unique ID and not on the mobile number), but (if other users Establishing a new connection is not allowed (since the token may now be in use).

Account number field 419 may display the type of account and 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 taken from/deposited into the account specified in field 419. If the account number is not associated with an e-mail 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 settings specified in field 701 are used for notification or whether other/customized settings are used.

Action field 423 may include several links that allow the user to take various actions. For example, links can include edit, remove, and confirm. If the token's status is verified, an edit field may allow the user to edit the token's properties as specified in rules engine 188. For example, account and notification preferences (fields 719 and 721) can be edited to be more specific. If the account number is verified, a removal link may also be displayed, and if the account is not verified or inactive, a confirmation link may be displayed that sends an e-mail or SMS and displays a verification code. Edit and remove links may also be displayed for unverified or inactive e-mails or phone numbers. The user can also add a new token using the new connection link 425.

As will become clear from fields 401 and 411, separate payment and notification channels may be used for fund transfers. For example, for the 415-555-4001 token, the payment channel is through the 415-555-4001 token, but the notification channel is through the 949-555-7878 and pat@mail.com tokens. Additionally, if the user decides to set up a custom notification channel for the 415-555-4001 token, the user can do so without disrupting the connection already established using the 415-555-4001 token. there is. Interrupting one channel (for example, by changing the token) does not affect other channels.

The connection management field 431 allows the user to perform various functions related to managing the user's connections with other users. Field 431 shows the registry of connections established by the user. Within field 431, various information related to each different user, such as name (field 433), alias (field 435), email/mobile (field 437), status ( Field 439), and an action (field 441) and a link 443 allowing the user to add a new recipient may be displayed. Although not specifically shown, it will be appreciated that a unique ID may also be stored for each of the users within the registry, shown in field 431. As described above, there is no need for the user to know the unique ID, and the unique ID remains more secure.

Name field 433 may be the recipient's name, as may be seen on an account associated with another user (e.g., as specified by another user). Alias field 435 may be an alias assigned to another user (e.g., as specified by the user). The email/mobile field 437 may display the public token used by the recipient. Status field 437 may display whether a permanent connection has been established for a particular contact. The action field 441 may be determined based on the status field. For example, if a link has been established, action field 441 may display a link that allows the user to send money to the recipient. If a link has not been established, the action field may display a second money transfer link, but action field 441 may also display a View Details link. The View Details link may display another screen to the user, where the user may provide additional details to establish a connection with the recipient. Other actions that can be displayed are edit and remove. Edit allows the user to edit each of the fields described above, and Remove allows the user to remove the recipient and related 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.

The money transfer form 601 may prompt the user to select a recipient from a pull down menu 603. The list of recipients provided using menu 603 may be recorded using the list of recipients contained within field 431 discussed in FIG. 4 . The list in the recipient menu 603 may include the names of users to whom the user has sent funds in the past, received funds from them, or otherwise attached. The alias may be a unique ID within the token management logic 129. Because they can be directly correlated with each other, account information can be derived from the alias through a unique ID. Therefore, as described above, the connection between two users is not interrupted even if their cell phone number or e-mail address becomes obsolete. After selecting a recipient, the user can use the drop-down menu 605 to select , you can select an account to transfer funds to the recipient. A drop-down menu can be pre-filled with a list of all accounts held by the user. The user can enter the dollar amount that the user wishes to transfer to the recipient in the amount field 607. The user's name may be provided along with an optional field description 609 that allows the user to confirm that payment was made for a specific product or service provided by the recipient.

Additionally, funds available for the recipient field 623 may be displayed along with each payment channel. For example, a credit card method can make funds available to the recipient within 2-days of processing the transfer request.

The remittance date field 633 lists the date on which the user initiated the remittance request.

Payments outside the network

In an alternative implementation to Figures 3A and 3B, the sender may transfer funds to a recipient who is not a registered user of any member of any payment network - the Funds Transfer Payment Network or another existing payment network. For example, at a participating bank (i.e., remittance bank) through the remittance bank's online interface, a user may enter a token for the intended recipient (e.g., a cell phone number or e-mail address) and the dollar amount they wish to transfer to the recipient. Enter . The dollar amount and token are then transmitted to the funds transfer payment network for service merging. Because the recipient is outside the funds transfer payment network, is not part of any known payment network, or is not both, the funds transfer payment network will not be able to match the token in the payment network's directory. In response, the funds transfer payment network sends a message to the sending bank indicating that the token is unknown. The funds transfer payment network also creates a pending payment, which may include some or all of the following fields: unknown token, sending bank, dollar amount, user name, and recipient name.

The remittance bank then uses the token to send a message to the recipient. For example, the sending bank may send a message to the recipient indicating that the sender wishes to transfer the recipient's money. Alternatively, a funds transfer payment network may transmit a message to the recipient. If the recipient is not a registered user of any member of any payment network, the recipient is directed to a link to the funds transfer payment network's website to begin the process of registration to accept pending payments. If the token entered by the sender is the recipient's e-mail address, the recipient receives the link at his e-mail address. If the token entered by the sender is the recipient's cell phone number, the recipient receives a link on his phone number.

7 shows a screen shot of an example web page 700 that may be presented to a recipient upon accepting an invitation within a link. As shown in Figure 7, when the recipient is notified of a pending payment, the recipient is prompted to enter a token. The user enters the token within a field within web page 700. The funds transfer payment network merges entered tokens with pending payments. In one implementation, the recipient may proceed only if the entered token matches the unknown token for the pending payment.

In one implementation, a recipient who is not registered with any member of the funds transfer payment network may participate in the funds transfer payment network and receive funds only if the non-registered recipient is invited by a registered sender. Information about the recipient and account ownership can be verified and collected even before the recipient can join the funds transfer payment network. Accordingly, it should be understood that the funds transfer payment network may confirm that a payment is pending before an unregistered, out-of-network recipient can join the funds transfer payment network. As used herein, “out-of-network” refers to a user of a financial institution who is not a member of a funds transfer payment network. Alternatively, “out-of-network” can also refer to a financial institution that is not a member of a funds transfer payment network. An in-network user must transfer a payment to an out-of-network user before the out-of-network user can join the funds transfer payment network. This can prevent fraud by ensuring that all users or entities involved in a transaction can be verified. Additionally, because out-of-network users must be invited to the funds transfer payment network by an in-network user, fraud and fraudulent transactions are further reduced or eliminated.

Once the recipient registers with the funds transfer payment network, the funds transfer payment network can transmit the recipient's bank account information to the sending bank to complete the originating transaction. Transactions may be completed via ACH, for example. As is known in the art, ACH transactions can be either “pull” transactions or “push” transactions. When an in-network user transfers money to an out-of-network user, the sending bank can use a deposit transaction.

If the recipient is a registered user of the funds transfer payment network, the funds transfer payment network and funds transfer system 100 may maintain information about the recipient within an off-network database. Figure 8 depicts an example funds transfer system 800. Funds transfer system 800 is similar to funds transfer system 100, except that the payment service computer system includes an out-of-network database 167. The out-of-network database 167 may store information collected during financial transactions involving out-of-network users. For example, a funds transfer payment network may conduct a fund transfer to an out-of-network user and store banking information regarding the out-of-network recipient within an out-of-network database 167. In one implementation, funds transfer system 800 may store token and bank account information for out-of-network users in out-of-network database 167.

In an alternative implementation, the funds transfer system 800 stores bank account information for out-of-network users in the out-of-network database 167, but stores token information for out-of-network users in the out-of-network database 167. It is not stored in the database 167. Instead, the funds transfer payment network associates the recipient with a private identifier as described above. Private identifiers may be stored within information directory 168. Alternatively, the private identifier may be stored within information directory 128 or information directory 158. Accordingly, the user's token information is stored in a separate directory, e.g., information directory 168, from the out-of-network database 167, and the user's bank account information is stored in the out-of-network database 167. do. It should be understood that this alternative implementation improves user security by not storing the user's token and the user's banking information within the same database. Additionally, it should be understood that no publicly available information is stored with the user's banking information, thereby reducing the risk of fraud or theft. Accordingly, a money transfer payment network can securely process payments and transactions for out-of-network recipients by using private identifiers to match the recipient's token with the recipient's banking information.

In one implementation, information directory 168 does not store bank account information. Although the out-of-network database 167 is shown in FIG. 8 as external to the payment services computer system 160, in one implementation, the out-of-network database 167 is internal to the payment services computer system 160. It can reside.

In future transactions involving recipients, the funds transfer payment network utilizes an out-of-network database 167 to facilitate the transfer of funds from members. 9 is a flow diagram illustrating an example process 900 to facilitate payment or transfer of funds to an out-of-network recipient, in accordance with an example implementation of the present invention. Although process 900 is described with reference to the flow diagram shown in FIG. 9, it will be appreciated that many other methods of carrying out the acts associated with process 900 may be used. For example, the order of many blocks can be changed, certain blocks can be combined with other blocks, and many blocks described are optional.

To pay funds to an out-of-network recipient whose information is already stored in the out-of-network database 167, the data is stored in the remitter computer system 110 and the payment service computer, which includes the out-of-network database 167. Fund transfers may be communicated between a payment network utilizing or implementing system 160, and a recipient computer system 130. The sender may wish to transfer funds to the recipient using the token, as shown in block 902. The remittance bank transmits the token and dollar amounts to the funds transfer payment network. The funds transfer payment network notes that the token is for an out-of-network recipient, as shown at block 904, and sends a message indicating that the recipient is out-of-network, as shown at block 906. Send to the remittance bank. The sending bank may send a confirmation to the funds transfer payment network to continue the transaction, as shown at block 908. Upon receiving the confirmation, the funds transfer payment network contacts a separate out-of-network database 167, as shown at block 910. The funds transfer payment network matches the token with the recipient's banking information stored in the off-network database 167, as shown at block 912. The funds transfer payment network encrypts the recipient bank account information and opaquely transmits the recipient's bank account information to the sending bank, as shown at block 914. The sending bank decrypts the encryption and transmits the recipient's bank account information and any other information needed to complete the transaction to ACH 170.

Fund transfer system 100 also allows communication to non-customers of a financial institution. For example, when a bank is a member of a money transfer payment network, such bank may send messages to users who are not customers of that bank. Accordingly, the money transfer payment network may act as a communications intermediary. For example, when a new user is prompted to apply to register with a member principal, such user may be presented with a screen explicitly seeking permission to send that user message. In other words, in one implementation, a user must consent to receive messages from members as a condition of joining the funds transfer payment network and funds transfer system 100. Accordingly, once a user applies, such user may be contacted by other members.

In one implementation, financial institutions that are members of a funds transfer payment network may send, receive, and request funds from non-customers on behalf of their customers. Accordingly, financial institutions that are members of a money transfer payment network should understand that they may assist their customers in doing business with entities other than those that are customers of the financial institution.

In one implementation, funds transfer system 100 can track the status of a payment and provide notifications to the sender and recipient regarding the status of the payment.

In one implementation, the information is encrypted by the sender bank and decrypted by the recipient bank, such that the payment network does not have access to any sender or recipient information. For example, a sender bank may use an encryption algorithm known to the recipient bank but not known to the funds transfer payment network. In these cases, the sending bank encrypts the account information before any information is given to the payment network. The payment network processes the information, including transmitting encrypted sender and recipient information to the receiving bank. The receiving bank knows how to decrypt encrypted information. In this way, the payment network has no access to any information communicated by one bank to another. Accordingly, the transfer of the entire funds is not exposed to the funds transfer payment network.

In one implementation, the funds transfer system 100 relies on the bank's existing fraud system for risk management. In one implementation, the payment system does not actually move any money from one entity to another or from one bank to another. There is no account owned by the payment service that can hold the money, even for a temporary period. In one implementation, the payment system merely assists in transferring money from one bank to another.

In one implementation, funds transfer system 100 or funds transfer payment network may transfer payments from an out-of-network user to an in-network user. A funds transfer payment network may create a separate out-of-network database or use an existing database to store information about out-of-network senders.

In one implementation, users of member banks may use funds transfer system 100 to provide bills or invoices. Invoices may be provided to consumers of products or services provided by users of member banks. A consumer may be an in-network user or an out-of-network user. Invoice presentation may include an electronic file, such as an Adobe PDF® document, Microsoft Word® document, text file, image file, or any other suitable document that displays the invoice to the consumer. The electronic file, such as an Adobe PDF® document, may contain terms for payment provided by the claimant. In one implementation, funds transfer system 100 may provide items other than bills, such as, for example, mortgage documents, business documents, subpoenas, or patent applications or applications.

The funds transfer system 100 can also be used to securely deliver documents, and the bank verifies the identity of the consumer receiving the documents. The sender can also use the bank to confirm receipt of the documents. In one implementation, the biller can track whether the consumer has received the bill. For example, a biller may receive a notification from funds transfer system 100 that the consumer has received a bill. The sender can also confirm that the consumer has viewed the bill, for example, opened or accessed the electronic file on a computer or mobile phone. It will be appreciated that verification or tracking of receipt is useful because the biller can confirm that the consumer received the bill, and the consumer cannot deny it.

In the case of in-network billing provision, the biller transmits a request for money, or a bill or invoice, to the funds transfer payment network. The request or bill includes a token identifying the recipient or consumer of the bill. The biller attaches the request ID to the payment ID and transmits the bill to the funds transfer payment network. The biller may also attach payment instructions to the bill. The funds transfer payment network delivers bills or invoices to consumers based on tokens. The consumer responds by paying. The funds transfer payment network then notifies the claimant of the payment. The payment ID is sent to the bank and then merged against the account. It should be understood that the biller or the biller's bank is not required to have the consumer's routing number or account number, thereby increasing security and convenience for the consumer and biller.

In the case of an out-of-network consumer, instead of sending a payment ID along with the request ID, the funds transfer payment network provides instructions to the charging bank to debit the account. The funds transfer payment network also provides the consumer's ACH information plus the payment ID, plus the request ID, to the biller's bank for debiting.

In one implementation, an out-of-network user can send a payment to a member bank customer even if the member bank customer did not send a payment request to the out-of-network user. Accordingly, a registered out-of-network user, i.e., a user appearing within the out-of-network database 167, can transfer money to a customer of a member bank. A member bank customer may receive money using the channel of such member bank customer's choice. Member bank customers should understand that they do not have to provide recognized confidential information, such as bank account numbers, to out-of-network users who wish to receive money from them. The funds transfer system 100 can be used to support debit accounts, electronic funds transfers, credit card transactions, Amazon® payments, payments simply facilitated via email, business-to-business or merchant payments, expedited payments, and rent, maid, or weekly babysitter payments. It can be used for scheduled payments, such as. In one implementation, the funds transfer payment network verifies account access through a trial deposit. The sender provides the transaction amount, and the funds transfer system 100 verifies that the out-of-network sender has accessed the account and approved the debit transaction.

In one implementation, an out-of-network user transferring money may be subject to transfer restrictions. Remittance limits may be daily, rolling 7-day, or 30-day indefinite periods. Remittance restrictions can be enforced for each out-of-network user regardless of the destination of the payment. If an out-of-network user wishes to transfer a payment that exceeds the transfer limit, funds transfer system 100 may notify the out-of-network user that the payment exceeds the transfer limit. In one implementation, a money transfer payment network may charge a transaction fee when an out-of-network user transfers money to a customer of a member bank.

The decision to accept and execute money transfers from consumers outside the network wishing to send money may be managed by the user's bank within the network, i.e. the member bank receiving the money. As described above for the out-of-network database 167, out-of-network users must register with the out-of-network service before they can transfer money to member bank customers. Accordingly, it should be understood that registered out-of-network users can both initiate payments to registered customers of a member bank and respond to requests for money (e.g., bills) from customers of the member bank. do.

Debit transactions from an out-of-network user's bank account can be initiated via the ACH rail by a member bank. In one implementation, a member bank requests at least one of the following to process a transaction over the ACH rail: sender name, transaction amount, transaction fee, recipient profile ID, recipient name as provided by the sender, payment memo, Origination date, bank account number, routing number, and account type, such as checking or savings. When an out-of-network user transfers money to an in-network user, the sending bank can use a withdrawal transaction.

For security reasons, in one implementation, out-of-network users may not be able to initiate payment requests and may not be able to transfer payments to other out-of-network users. It should be understood that these features prevent fraud and also encourage financial institutions to join the money transfer payment network.

FIG. 10 is a flow diagram illustrating an example process 1000 to facilitate a payment or transfer of funds from an out-of-network sender to an in-network recipient, in accordance with an example implementation of the present invention. Although process 1000 is described with reference to the flow diagram shown in FIG. 10, it will be appreciated that many other methods of carrying out the acts associated with process 1000 may be used. For example, the order of many blocks can be changed, certain blocks can be combined with other blocks, and many blocks described are optional.

To transfer funds from an out-of-network sender to an in-network recipient where the information is already stored in the out-of-network database 167, the data includes the sender computer system 110 and the out-of-network database 167. A funds transfer payment network utilizing or implementing payment service computer system 160 may be communicated between a funds transfer payment network, and a recipient computer system 130 . The sender may wish to transfer funds to the recipient using tokens, as shown in block 1002. The remittance bank transmits the token and dollar amount to the funds transfer payment network. The funds transfer payment network notes that there is a request from an out-of-network sender, as shown at block 1004. The funds transfer payment network may use a test deposit to verify account access, as shown at block 1006. The funds transfer payment network sends a message to the receiving bank indicating that the sender is out-of-network, as shown at block 1008. The receiving bank may send a confirmation to the funds transfer payment network to continue the transaction, as shown at block 1010. Upon receiving the confirmation, the funds transfer payment network contacts a separate out-of-network database 167, as shown at block 1012. The funds transfer payment network matches the sender to the sender's banking information stored within the out-of-network database 167, as shown at block 1014. The funds transfer payment network encrypts the sending bank account information and transmits the sending bank's account information back to the receiving bank without revealing it, as shown at block 1016. The receiving bank decrypts the encryption and transmits the sender's account information and any other information needed to complete the transaction to ACH 170.

prompt payment

In one implementation, the sender can make “real-time” or expedited payment of funds to the recipient. It should be understood that a payment may be considered “real-time” if the funds paid are available to the recipient significantly sooner than they normally are. For example, a payment may be considered near real-time if the funds are deposited into the recipient's account within a few minutes. In one implementation, a payment may be considered real-time if funds from the sender to the recipient are deposited in the recipient's account within the amount of time required to transmit the message from the sender's bank to the recipient's bank. Messages may be sent between the sending bank, the funds transfer payment network, and the recipient bank through a messaging service such as IBM® WebSphere MQ.

However, some systems that seek to provide real-time payments require leveraging debit card systems, which can be inconvenient. Other systems utilize the ACH system, which can take several days to process and does not provide the speed of real-time or rapid payments currently available. Other systems require the sender to create an account with some alternative payment provider. Still other systems require that they have a direct connection to the financial institution's core processing platform.

Another system allows for quick payment from the sender's credit card. Fund transfer payment networks allow for the real-time transfer of funds from a sender's financial institution, such as the sender's primary financial institution, to a recipient. It should be understood that transferring funds from the sender's primary financial institution allows the sender to focus his/her financial transactions and manage his/her money more easily and conveniently. The sender can use any number of financial institutions, as long as each financial institution is a member of a funds transfer payment network and the sender uses a different token (e.g. email address, phone) at each financial institution. , you can send/receive money from any of those financial institutions.

Other systems allow faster payments when the sending bank is the same as the recipient bank. Fund transfer payment networks enable real-time payments from senders to recipients, even when the senders and recipients use different banks. The funds transfer payment network can work with any core financial institution's system through a system of APIs and does not require a direct connection to the financial institution's core processing platform. The funds transfer payment network may alternatively work with non-bank financial institutions, such as brokerages or investment firms, for example.

In one implementation, both the sending and receiving banks are in-network banks. The sending bank and receiving bank may need to agree to provide real-time payments to each other before the real-time payment is made. For example, a funds transfer payment network can provide real-time payment services to sending and receiving banks, and the banks agree to facilitate real-time payments. A funds transfer payment network may additionally or alternatively require that, before becoming a member bank, a bank must agree to send and receive real-time payments from other member banks. Individual users may also apply to their respective financial institutions to send and/or receive expedited payments for service fees.

FIG. 11 is a flow diagram illustrating an example process 1100 to facilitate a real-time payment or transfer of funds from an in-network sender to an in-network recipient, in accordance with an example implementation of the present invention. Although process 1100 is described with reference to the flow diagram shown in FIG. 11, it will be appreciated that many other methods of carrying out the acts associated with process 1100 may be used. For example, the order of many blocks can be changed, certain blocks can be combined with other blocks, and many blocks described are optional.

To disburse funds in real time from an in-network sender to an in-network recipient, data may be transferred to a funds transfer payment network utilizing or implementing a sender computer system 110, a payment services computer system 160, and a recipient computer system 130. ) can be passed between. The sender may wish to transfer funds to the recipient in real time, as shown in block 1102. In one implementation, the recipient must be eligible to receive real-time payments, for example, by subscribing to a service at the recipient's financial institution. The sending bank may query the funds transfer payment network as to whether the recipient is eligible to receive real-time payments. The funds transfer payment network, as shown at block 1104, checks whether the recipient is eligible to receive the real-time payment and, if so, the sending financial institution, as shown at block 1106. Send a confirmation message to . Upon receiving confirmation that the recipient is eligible, the sending bank removes the funds from the sender's account, as shown at block 1108. Accordingly, at this stage in process 1100, the funds have been removed from the sender's bank account.

The sending bank then transmits a prompt payment message to the funds transfer payment network, as shown at block 1110. The funds transfer payment network again transmits a prompt payment message to the recipient bank indicating a real-time payment, as shown at block 1112. The recipient bank then deposits the recipient's account, as shown at block 1114. It should be understood that at this stage in process 1100, the funds have been deposited into the recipient's bank account. Additionally, it should be understood that at this stage of process 1100, the recipient bank has deposited funds in its possession into the recipient's bank account, but the sending bank has not yet deposited the money at the recipient bank.

Reconciliation or settlement between the sending bank and the recipient bank may take place some time after the funds are credited to the recipient's account. Settlement or reconciliation between the sending bank and the recipient bank may not occur for hours or even days after payment is made to the recipient. The amount of time between funds being deposited in the recipient's account and reconciliation between the sending bank and the recipient bank may be referred to as reconciliation delay. It should be understood that a funds transfer payment network effectively prevents recipients from having to wait for reconciliation delays before receiving funds. In some cases, a money transfer payment network may provide a maximum amount of time during which the money will be available to the recipient, for example two hours. It should be understood that money can be made available to a recipient substantially within the amount of time required to transmit an electronic message to the recipient's bank.

Referring back to Figure 1100, after the recipient's account has been credited, the recipient bank notifies the funds transfer payment network that the recipient's account has been credited, as shown at block 1116. The funds transfer payment network then notifies the sending bank that the funds have been credited to the recipient's account, as shown at block 1118. The sending bank may send a payment confirmation message to the sender indicating that the money has been deposited into the recipient's account. The sending bank then settles the funds with the recipient bank, such as via an ACH payment, as shown at block 1120.

In one implementation, for faster payment, the sending bank may not collect funds from the sender's account until after they have been deposited into the recipient's account. However, the sending bank may prohibit the sender from choosing to transfer more money than is available in the sender's account. In this way, sending back ensures that the sender's account has sufficient funds to repay the sending bank.

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

In one implementation, a funds transfer payment network may request an unregistered recipient to register with an in-network financial institution before being able to receive funds in an expedited manner.

Embodiments of the present invention have been described with reference to the drawings. The drawings illustrate specific details of specific implementations of the systems and methods and programs of the present invention. However, illustrating the invention using drawings should not be construed as imposing on the invention any limitations that may exist within the drawings. The present invention contemplates a method, system, and program product on any machine-readable medium for accomplishing its operations. Embodiments of the invention may be implemented using existing computer processors, by special purpose computer processors integrated for this or other purposes, or by hardwired systems.

As previously noted, implementations within the scope of the invention include program products that include a machine-readable medium for containing or having machine-executable instructions or data structures stored thereon. Such machine-readable media may be any available media that can be accessed by a general-purpose or special-purpose computer or other machine with a processor. By way of example, such machine-readable medium may be RAM, ROM, EPROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage, or as desired in the form of machine-executable instructions or data structures. It may include any other non-transitory medium that can be used to store program code and that can be accessed by a general-purpose computer or special-purpose computer or other machine with a processor. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions include instructions and data that cause, for example, a general-purpose computer, a special-purpose computer, or a special-purpose processing machine to perform a particular function or group of functions.

Embodiments of the invention may be implemented in one embodiment by a program product comprising machine-executable instructions, such as program code, for example in the form of program modules to be executed by machines in a networked environment. The general situation of the method steps is explained. Typically, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement special abstract data types. Machine-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. Such particular sequences of executable instructions or structures of associated data represent examples of corresponding actions to implement the functionality described in those steps.

As mentioned above, implementations of the invention may be practiced in a networked environment utilizing logical connections to one or more remote computers having processors. Those skilled in the art will recognize that such a networked computing environment includes many devices, including personal computers, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and others. It will be understood that this may include any type of computer. Implementations of the invention may also be practiced in a distributed computing environment, where the task consists of processing devices on-premise and linked through a communications network (by hard-wired links, wireless links, or a combination of hard-wired or wireless links). It is performed by a remote processing device. In a distributed computing environment, program modules may be located in both on-premises and remote memory storage devices.

An exemplary system for implementing the entire system or portions of the present invention includes a general-purpose computing computer in the form of a computer, including a processing unit, a system memory, and a system bus coupling various system components including the system memory to the processing unit. may include. System memory may include read only memory (ROM) and random access memory (RAM). A computer may also include a magnetic hard disk drive for reading from and writing to a magnetic hard disk, a magnetic disk drive for reading from and writing to an erasable magnetic disk, and an erasable optical disk such as a CD ROM or other optical media. It may include an optical disk for reading from and recording thereon. Drives and their associated machine-readable media provide non-volatile storage of machine-executable instructions, data structures, program modules, and other data for a computer. Additionally, it should be noted that the word “terminal” as used herein is intended to include computer input and output devices. Input devices as described herein include keyboards, keypads, mice, joysticks, or other input devices that perform similar functions. Output devices as described herein include computer monitors, printers, facsimile machines, or other output devices that perform similar functions.

It should be noted that although the drawings herein may illustrate a specific order and configuration of method steps, it is understood that the order of such steps may differ from that shown. For example, two or more steps may be performed simultaneously or partially simultaneously. Additionally, some method steps performed as distinct steps may be combined, steps performed as combined steps may be separated into distinct steps, and the sequence of a particular process may be reversed or otherwise altered. and the characteristics and number of separated processes may be changed or changed. The order or sequence of any elements or equipment may be altered or substituted according to alternative embodiments. Accordingly, all such modifications are intended to be included within the scope of the present invention as defined in the appended claims. Such changes will depend on the software and hardware systems selected and designer choices. It will be understood that all such changes are included within the scope of the invention. Similarly, software and web implementations of the invention can be accomplished with standard programming techniques, including rule-based logic and other logic to accomplish the various database search, correlation, comparison, and decision steps. The foregoing description of embodiments of the invention has been provided for purposes of description and explanation. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and modifications and variations may be possible reflecting the foregoing teachings or acquired from practice of the invention. The embodiments have been selected and described to illustrate the principles of the invention and its practical applications, to enable those skilled in the art to utilize the invention in various embodiments and with various modifications as suited to the particular application contemplated. Other substitutions, modifications, changes, and omissions may be made in the design, operating conditions, and arrangement of the embodiments without departing from the scope of the invention as expressed in the appended claims.

Secure fund transfers through non-financial institutions

In various implementations, the sender and/or recipient may access an online payment process or a physical payment terminal maintained by a non-financial institution (eg, a service provider). As used herein, a “sender” of funds may include an entity (individual, company, corporation, etc.) that provides instructions to transfer an amount of funds from the sender's financial institution to the recipient. As used herein, the “recipient” of funds may refer to the intended recipient of funds from the sender (e.g., the recipient of funds may receive the funds from the recipient’s account at the recipient’s financial institution). . As used herein, a “participant in a transfer of funds” may refer to either the sender of the funds or the recipient of the funds.

A “financial institution” or FI is an entity that primarily deals with financial transactions such as investments, loans, and/or deposits. Exemplary financial institutions include organizations such as commercial banks, investment banks, insurance companies, securities firms, investment firms, money transfer entities, trust companies, savings and loan companies, credit unions, shadow banks, or others.

As used herein, “non-financial institution” or “non-FI” 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 and exchange of goods and services. Examples of such business entities include service entities and retail entities (e.g., brick-and-mortar retail stores and online retailers). In some implementations, non-financial institutions include social networking entities that provide social networking services to users and/or other individuals. Examples of such social networking entities include Facebook®, Linkedln®, the social network provided by Alphabet®, Inc., and Snapchat®.

Non-financial institutions can support online payment systems. As used herein, an “online payment system” means a server system that allows goods/services to be browsed, reviewed, and/or paid for by an individual (e.g., sender or recipient) using the individual's digital device. It can also refer to a website or networked application. For example, a non-financial institution may provide a physical device and/or online service for payment of past bills or payment of services rendered to the non-financial institution. In another example, an online retailer (eg, GAP) may provide payment processing servers that communicate 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 an application on a smartphone.

In various implementations, a non-financial institution may include a physical payment terminal that accepts funds from individuals for payment of goods and/or services. Non-financial institutions' physical payment terminals may also allow individuals to obtain funds (e.g., physical currency, digital currency, or other).

Financial institutions can act as financial intermediaries between the sender and recipient and assist in the transfer of funds. Financial institutions may be regulated by government(s) and/or other regulatory agencies. “Remittance financial institution” may refer to a financial institution that provides financial services to an entity seeking to transfer funds to another entity. For example, the sender's financial institution may be the sender's bank. The sender's bank may include any number of bank accounts associated with the sender. Each of the sender's accounts may include one or more sender account numbers (eg, an account number that identifies the sender's account). The sender's financial institution may provide access to funds (physical currency, digital currency, line(s) of credit, etc.) that the sender can use to transfer funds to the recipient.

“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 recipient financial institution may be the recipient's bank. The recipient's bank may include any number of bank accounts associated with the recipient. Each of the recipient's accounts may include one or more recipient account numbers (eg, an account number that identifies the recipient's account). The recipient financial institution may provide access to funds (physical currency, digital currency, line(s) of credit, etc.) that the recipient can use to receive funds from the sender.

FIG. 12 depicts a diagram of a funds transfer system 1200 for securely transferring funds from a sender non-financial institution system to a recipient non-financial institution system, according to some implementations. The funds transfer system 1200 includes a sender system 1202, a recipient system 1204, a first non-FI system 1206, a second non-FI system 1208, a sender FI system 1210, and a recipient FI system ( 1212), a payment service system 1218, an automated clearing house (ACH) system 1220, a public network 1214, and an ACH network (e.g., a private network) 1216.

Remittance sender system 1202 may include one or more digital devices associated with a remittance sender (e.g., a user). For example, a sender may use a non-financial institution's website or a non-financial institution's physical payment terminal (e.g., use a credit card, debit card, or smart device with a terminal provided by the non-financial institution). may be a person who transfers funds to a third-party recipient. By way of example, the sender may be a person who has a connection to a networked application or webpage (e.g., first non-FI system 1206) managed by the retailer. The transfer of funds by the sender may be backed by the sender's financial institution, as further described below. By way of example, the sender may maintain an account with the sender's financial institution that provides access to the funds the sender wishes to transfer to the recipient.

The money transmitter system 1202 may have some or all of the components of a digital device, an example of which is shown in FIG. 19 and described further below. For example, the sender system 1202 may be a computer (e.g., a desktop or laptop computer), a cellular phone, a smartphone, a mobile handheld wireless e-mail device, a personal digital assistant, a portable gaming device, or other suitable digital device. It could be a device. The remitter system 1202 may also include one or more processors configured to execute instructions stored within memory.

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

In some implementations, sender system 1202 may cause funds to be transferred to recipient system 1204. For example, the remitter system 1202 may include a browser or application configured to interact with an online payment process (e.g., an online payment system) supported by the first non-FI system 1206.

Client application 1228 may include program logic configured to implement one or more of the functionality of remitter system 1202. In some implementations, client application 1228 may be or include an application configured to receive and display content (e.g., on display device 1224) or web pages from remitter FI system 1210. Can be or include a web browser configured to receive and display. For example, client application 1228 may include a mobile web browser, short messaging service (SMS) or other text messaging application, a dedicated application, or other computer program configured to send/receive information over network 1214. .

12 illustrates the sender system 1202 within the funds transfer system 1200, in some implementations, the sender system 1202 may not reside within the funds transfer system 1200 or within the sender system 1202. It should be noted that some or all of the functionality may be implemented by the first non-FI system 1206. For example, in some implementations where the first non-FI system 1206 includes a physical payment terminal, the funds transfer system 1200 may not include a remitter system 1202 and/or the first non- FI system 1206 may implement some or all of the functionality attributed to remitter system 1202.

Recipient system 1204 may include a digital device associated with the recipient. For example, the recipient may transfer funds certified by the sender (e.g., from the sender system 1202) through a non-financial institution's online payment process (e.g., a first non-FI system 1206). It could be the recipient. The transfer of funds to the recipient may include a transfer from the recipient's financial institution to an account held by the recipient. In some implementations, funds are transferred into a recipient account held by the recipient at the recipient financial institution (e.g., recipient FI system 1212) before the funds are available to the recipient. In various implementations, the recipient FI system 1212 may provide funds to the recipient before the funds are transferred from the sender's account at the sender FI system 1210 (e.g., via the ACH network 1216). there is.

Recipient system 1204 may have some or all of the components of a digital device, an example of which is shown in FIG. 19 and described further below. Similar to the sender system 1202, the recipient system 1204 may be a computer (e.g., a desktop or laptop computer), a cellular phone, a smartphone, a mobile handheld wireless e-mail device, a personal digital assistant, or a portable gaming device. , or other suitable digital device. Recipient system 1204 may also include one or more processors configured to execute instructions stored within 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 their counterparts in remittance sender system 1202. Client application 1236 may include program logic configured to implement one or more of the functionality of recipient system 1204. In various implementations, the client application 1236 includes a first non-FI system 1206, a second non-FI system 1208, a sender FI system 1210, a payment service system 1218, and a recipient FI system ( 1212), or from any combination, an application configured to receive and display content or a web browser configured to receive and display web pages. Client application 1236 may include a mobile web browser, short messaging service (SMS) or other text messaging application, dedicated application, or other computer program configured to send/receive information over network 1214.

In various implementations, the recipient system 1204 may send a notification request requesting permission to receive funds from the sender, a notification request requesting approval of a transaction, a notification indicating the status of the transfer of funds, and/or a notification request requesting permission to receive funds from the sender. You may receive notification of a successful fund transfer. Recipient system 1204 may be configured to interact with an online payment process supported by a first non-FI system 1206, a second non-FI system 1208, or both.

Although FIG. 12 illustrates recipient system 1204 within funds transfer system 1200, in some implementations, recipient system 1204 may not reside within funds transfer system 1200 or be a member of recipient system 1204. It should be noted that some or all of the functionality may be implemented by a second non-FI system 1208. For example, in some implementations where the second non-FI system 1208 includes a physical payment terminal, the funds transfer system 1200 may not include a recipient system 1204 and/or the second non- FI system 1208 may implement some or all of the functionality attributed to recipient system 1204.

First non-FI system 1206 may include any number of digital devices configured to support the functions of a first non-financial institution. For example, the first non-FI system 1206 may be a server that hosts a retail store's website. A website may allow a user (e.g., a sender or recipient) to browse products and/or services. The Website may also allow users to purchase goods and/or services. In some implementations, first non-FI system 1206 may be a server for interacting with an application (e.g., client application 1228 or client application 1236) on any number of digital devices. The application may allow a user to pay for goods and/or services.

In various implementations, the first non-FI system 1206 may provide services to assist 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 services system 1218. The interface may also enable the sender system 1202 to identify the recipient and indicate the amount to be transferred to the recipient. The first non-FI system 1206 may provide all or part of the information to the payment service system 1218, the remitter FI system 1210, or any other system described further herein. In such implementations, the first non-FI system 1206 may include one or more servers each having one or more processes configured to execute instructions stored in memory. The server may be configured to process payment information provided by a client application 1228 on the remitter system 1202.

The first non-FI system 1206 may have some or all of the components of a digital device, an example of which is shown in FIG. 19 and described further below. In some implementations, the first non-FI system 1206 includes a physical payment terminal configured to manage payments for the sender non-financial institution. In this implementation, the physical payment terminal may include circuitry, other hardware, and/or software configured to process payment information from or from the sender (e.g., a credit card in the physical terminal) or from the sender system 1202. You can.

First non-FI system 1206 may include network interface 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 their counterparts described herein.

Non-FI application 1244 may be configured to manage payments for a sender non-financial institution. For example, non-FI application 1244 may provide information about a physical device, a web page, or an application (e.g., including client application 1228). Non-FI applications 1244 may, in some implementations, allow users to pay for previously purchased goods/services, browse goods/services, and purchase goods/services. and/or may provide a request to transfer money to another user. In some implementations, the sender non-FI application 1244 may include program logic to process payment information provided to a physical payment terminal supported by the first non-FI system 1206. The sender non-FI application 1244 may include program logic to support the online payment process managed by the first non-FI system 1206.

In some implementations, the non-FI application 1244 or financial service provider (e.g., MasterCard network) may collect a number of other identifying information associated with the sender or recipient's financial instrument to generate a token for the sender or recipient. For example, a credit or debit card number) can be tokenized (e.g., encrypted). The issuing financial institution or backing financial institution of the financial instrument may de-tokenize the tokens to recover information as disclosed herein. The non-FI institution 1244 may store the sender's or recipient's tokenized financial instruments for future transactions. Non-FI applications 1244 may also retrieve or identify a financial identifier that identifies the financial institution associated with the financial instrument (e.g., the financial institution that issued the financial instrument).

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

Similar to first non-FI system 1206, second non-FI system 1208 may include any number of digital devices configured to support the functions of a second non-financial institution. For example, the second non-FI system 1208 may provide a physical interface for receiving the sender's or recipient's public identifier and/or account number to transfer funds to any number of individuals. In another example, the second non-FI system 1208 may be a server that hosts a retailer's website. The website may allow a user (e.g., a sender or recipient) to browse past and/or future purchases of goods or services. The Website may also allow users to purchase goods and/or services. In some implementations, the second non-FI system 1208 may be a server for interacting with an application (e.g., client application 1228 or client application 1236) on any number of digital devices. The application may allow a user to pay for goods and/or services.

In various implementations, the second non-FI system 1208 may provide services to assist users in directing funds to other users. For example, the second non-FI system 1208 may provide an interface (e.g., on a physical device) that allows a sender or recipient to register with the payment services system 1208. The interface may also enable the sender system 1202 to identify the recipient and indicate the amount to be transferred to the recipient. The second non-FI system 1208 may provide all or part of the information to the payment services system 1218, the first FI system 1206, or any other system described further herein. In such implementations, the second non-FI system 1208 may include one or more servers each having one or more processes configured to execute instructions stored in memory. The server may be configured to process payment information provided by a client application 1236 on the recipient system 1204.

The second non-FI system 1208 may have some or all of the components of a digital device, an example of which is shown in FIG. 19 and described further below. The second non-FI system 1208 may have some or all of the components of a digital device, an example of which is shown in FIG. 19 and described further below. In some implementations, the second non-FI system 1208 includes a physical payment terminal and/or a server configured to manage payments for the recipient non-financial institution. A physical payment terminal may include circuitry, other hardware, and/or software configured to process payment information within the payment hardware on the recipient system 1204.

In some implementations, the second non-FI system 1208 may be configured to support online payment processing for recipient non-financial institutions. In such implementations, the second non-FI system 1208 may include one or more servers each having one or more processes configured to execute instructions stored in memory. The server may be configured to process payment information provided by a client application 1236 on the recipient system 1204.

The 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 their counterparts described herein. Non-FI application 1252 may be configured to manage payments. Recipient non-FI application 1252 may include program logic to process payment information provided to a website or physical payment terminal supported by second non-FI system 1208. In some implementations, the recipient non-FI application 1252 may include logic to tokenize the sender's or recipient's financial instrument(s), as well as an online payment process managed by a second non-FI system 1208. Includes program logic to support.

The remitter FI system 1210 may be any digital device that is operated by or provides services to a financial institution (e.g., a remitter financial institution). Sender FI system 1210 may have some or all of the components of a digital device, an example of which is shown in FIG. 19 and described further below. The remitter FI system 1210 may maintain one or more accounts for the remitter. The sending financial institution may maintain accounts held by the customer, such as demand deposit accounts, credit card accounts, home mortgage loans, student loans, or others. The remitter FI system 1210 may include one or more servers each having one or more processors configured to execute instructions stored in memory, transmit and receive data stored in memory, and perform one or more operations. The sender FI system 1210 may include network interface logic 1254, account processing logic 1256, account database 1258, information directory 1260, and token management logic 1262. Network interface logic 1254 may include program logic that connects the sender FI system 1210 to the network 1214. Network interface logic 1254 may assist in secure communication between the sender FI system 1210 and other elements of FIG. 12 .

Account processing logic 1256 processes the account holder's accounts (such as account credits and debits for checking and savings accounts, credits and debits for home mortgage and home equity accounts, credits and debits for student loan accounts, and others). ) may be configured to process transactions in relation to In some implementations, when funds are transferred into or out of an account holder's account (e.g., a participant's account), account processing logic 1256 may reflect the appropriate debit or credit within account database 1258. Account processing logic 1256 may also process funds transfer requests to transfer funds from a sender to a recipient. Funds may be transferred using the techniques described herein.

Account database 1258 may be configured to store account information (e.g., transactions, information about account holders, and other) for accounts maintained by the bank for the bank's customers.

Information directory 1260 may be configured to store tables correlating user identifiers with account information used to effect fund transfers. When a user identifier that does not specify account information is used to effect a fund transfer, information directory 1260 may be used. In some implementations, information directory 1260 may associate the sender's private identifier with the sender's account in account database 1258. Information directory 1260 is further described herein.

As used herein, “account information” may refer to information used to effect a fund transfer to or from a participant in the fund transfer. Account information may include, for example, account number, routing number, credit card number, digital currency code to effect a fund transfer, and others.

As used herein, a “user identifier” or interchangeably a “user token” may refer to information that, for the purpose of transferring funds, identifies a participant in the transfer of funds. A user identifier may include or be associated with a public identifier/public token and a private identifier/private token.

“Public identifier” or interchangeably “public token” may refer to information that identifies a participant in a fund transfer but does not identify account information associated with the participant. In some implementations, public identifiers may be configured for participants to share with each other. By way of example, a participant may wish to share a public identifier with another participant who is a participant to whom the participant wishes to send funds or to receive funds from the participant. A public identifier may be an e-mail address or other information that can be used to identify a participant (e.g., sender or recipient), such as a phone number, for example.

As used herein, a “private identifier” or interchangeably a “private token” is one that identifies a user (e.g., a user with an account in a FI system) and/or provides account information associated with the participant (e.g., For example, it may refer to information that may be related to an account number). A private 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, routing number, credit card information, or other. In some implementations, the private identifier does not include a bank account number, routing number, credit card number, or other.

The private identifier may be known to one or more financial institutions and entities that are members of the payment network that conduct fund transfers to the participant. In one example, remitter server FI system 1210 may generate a private identifier associated with the remitter. However, a private identifier may not reveal any private information to any other entity. The remitter FI system 1210 may share the remitter's private identifier with the payment service system 1218. The sender's private identifier may not be provided to the sender system 1202, the sender, the recipient's 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 recipient FI system 1212 can identify any account number or other private information from the sender's private identifier.

FI systems (e.g., sender FI system 1210 and recipient FI system 1212) may interact with entities other than the FI system (e.g., each other), the automated clearinghouse system 1220 described herein, and/ Alternatively, the payment service system 1218 may not share the private identifier with the payment service system 1218. Similarly, the payment service system 1218 may not share the private identifier received from the FI system with any entity other than the FI system. As described, participants to transfer funds between non-financial institutions can use the techniques described herein to transfer funds to each other using public identifiers that the participants may provide to each other. This arrangement allows the sender to send information (e.g., using an e-mail address or other identifier) without the need to have private/personal information about the recipient (i.e., the recipient's bank account/routing number). ) allows the recipient to be uniquely identified. In addition to the public and private identifiers already described herein, additional identifiers may also be used. For example, such additional identifiers may be treated with variable security levels. As another example, as described in more detail below, changes to existing public identifiers may be used to implement special-purpose public tokens, public tokens with custom functionality, and others.

The remitter FI system 1210 may include an account database 1258 and an information directory 1260. Once a user registers with the payment services system 1218 described herein, the remitter FI system 1210 may generate a private identifier associated with the user's public identifier. The user's private identifier may be associated with both the user's account in the remitter FI system 1210 as well as the user's public identifier (e.g., the user's e-mail address, phone number, or other contact information). Account database 1258 can include users' accounts, and information directory 1260 can associate public identifiers, private identifiers, and account information (e.g., account numbers). Account database 1258 may contain any number of accounts for any number of users. Information directory 1260 may contain information about any number of private identifiers and public identifiers for any number of users.

Token management logic 1262 may be configured to manage tokens (e.g., public identifiers and/or private identifiers). In various implementations, token management logic 1262 may be configured to register tokens, accept tokens, create tokens, and so on. Token management logic 1262 may also assist with identification of the recipient when the token is not recognized. Token management logic 1262 may also be used to customize the properties of the token, such that a particular account is used, a particular notification method is used, or others. Token management logic 1262 may have some or all of the properties of token management logic 129 shown in Figure 2 and described in connection therewith.

In some implementations, token management logic 1262 is configured to recognize, identify, approve, and de-tokenize tokens of financial instruments (e.g., tokenized by first non-FI system 1206). It can be. Once de-tokenized, token management logic 1262 can recover financial information, such as account numbers or routing numbers, associated with a financial instrument as described herein.

Recipient FI system 1212 may include a digital device operated by a financial institution that provides financial services to recipient system 1204. Recipient FI system 1212 may have some or all of the components of a digital device, an example of which is shown in FIG. 19 and described further below. The recipient financial institution may maintain accounts held by the customer, such as demand deposit accounts, credit card accounts, home mortgage loans, student loans, or others. Recipient FI system 1212 may include one or more servers each having one or more processors configured to execute instructions stored in memory, transmit and receive data stored in memory, and perform one or more operations. 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 their counterparts within sender FI system 1210. .

The payment service system 1218 can transfer money from a sender to a recipient (e.g., from a sender account in the sender FI system 1210 as directed by the sender system 1202 via a first non-FI system 1206). may include a digital device configured to enable or assist with payment services that enable the secure transfer of funds (to a recipient account in the FI system 1212). Payment service system 1218 may have some or all of the components of a digital device, an example of which is shown in FIG. 19 and described further below. Payment services system 1218 may include one or more servers each having one or more processors configured to execute instructions stored in memory, transmit and receive data stored in memory, and perform one or more operations.

In some implementations, payment services system 1218 is between one or more of a sender FI system 1210, a recipient FI system 1212, a sender non-FI banking system 1214, and a recipient non-FI banking system 1216. Assists in transferring funds.

The payment service system 1218 may provide payment services to participants who have accounts at member banks. More particularly, in some implementations, financial institutions associated with sender FI system 1210 and recipient FI system 1212 may include member banks. As used herein, “member bank” may refer to a financial institution that is a member of the payment services system 1218 and follows protocols established by government agencies, regulatory agencies, or others to transfer funds to one another. there is. In various implementations, payment services system 1218 provides payment services to participants who have accounts at financial institutions other than member banks.

Payment service system 1218 includes network interface logic 1295, account processing logic 1276, account database 1278, information directory 1280, token management logic 1282, account transfer logic 1284, and registration logic. May include (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 their counterparts within sender FI system 1210. .

In various implementations, participants in a fund transfer may use network 1214 to share their information with information directory 1280. Network interface logic 1274 may be configured to receive information via network 1214. Account processing logic 1276 may determine whether a participant's public identifier has been registered by determining whether there is an account associated with the public identifier in account database 1278. A participant may be added to the information directory 1280 when registering with the funds transfer system 1200, either through the sender FI system 1210 or through the first non-FI system 1206. Upon registration, a new entry may be created for the newly registered user within a database implementing information directory 1280. In some implementations, the information directory 1280 is automatically recorded with public and private identifiers during secure online banking involving the sender FI system 1210.

In some implementations, information directory 1280 stores a registry of other participants linked to a particular participant. For example, for each user, information directory 1280 may store a registry that contains a list of each other user with whom the user has established connections. Such a connection may be established, for example, when a user first sends or receives funds to or from another user. Connections may also be established by a user interface that allows users to add connections to other users through search services within information directory 1280 and/or other information directories. An example of such a user interface is described in conjunction with FIG. 4 and further herein. As described in more detail below, users may include registered users within a funds transfer payment network, as well as other affiliated payment networks. For each user within the registry, additional information may be stored, such as their unique ID and/or other information. As another example, information about other users may be stored in separate database entries within information directory 1280.

In various implementations, information directory 1280 may include one of a plurality of information directories, each maintained by a different organization or entity. Each information directory may store information about participants associated with the digital device containing such information directory. Each information directory may allow relevant participants to register with such information directory.

Fund transfer logic 1284 may be configured to assist in transferring funds between two participants. Fund transfer logic 1284 is further described with respect to FIG. 13 . A fund transfer may include the transfer of funds from a sender to a recipient. In various implementations, all participants in the transfer may be registered for the funds transfer service provided by payment service system 1218. However, in some implementations, at least one participant may be registered solely for the financial institution's financial services and/or to utilize the non-financial institution's purchasing process (physical purchase terminal, online purchase process, etc.). You can. As noted herein, registration for fund transfer services provided by payment service system 1218 may include a public identifier for the participant's account and/or the recipient of the participant's redemption instrument (e.g., a financial instrument); or it may include registering both as described further below. In various implementations, the recipient of a fund transfer may not be required to take any action to accept the payment (e.g., the recipient may be able to -accepted" status). In some implementations, the recipient may be required to passively accept at least some or all of the funds transfer.

In some implementations, payment services system 1218 may provide a web portal provided for an online community of individuals, where such individuals obtain a username/login ID or otherwise become registered members. Individuals may use a web portal, for example, to interact with each other and/or to interact with services provided by the online community. Examples of online communities include MSN®, iPhone® users, Facebook®, Linkedln®, etc. A payment service may be an additional service provided to members of an online community, for example, by a web portal. As another example, the payment service may be provided by, for example, one of a financial institution, such that the financial institution may include a sender FI system 1210, a recipient FI system 1212, and a sender non-FI banking system. 1214, and both operations described herein as performed by the recipient non-FI banking system 1216.

In implementations where the second non-FI system 1208 corresponds to a physical purchase terminal, transfer logic 1284 may manage the transfer of funds from the sender FI system 1210 to the second non-FI system 1208. there is. Funds obtained in the second non-FI system 1208 may take the form of physical currency, digital currency, etc. Recipients can obtain it from a physical purchase terminal. In implementations where the second non-FI system 1208 supports online payment processing, the transfer logic 1284 may transfer from the sender FI system 1210 to the second non-FI system 1208 and/or the recipient system 1204. You can manage fund transfers to. Funds obtained from the second non-FI system 1208 and/or the recipient system 1204 are maintained by the recipient FI system 1212 and/or the second non-FI system 1208 and/or the recipient system. This may take the form of digital currency, which may be deposited into an online account accessed by 1204. In some implementations, transfer logic 1284 may assist in transferring funds to unregistered participants. In some implementations, transfer logic 1284 may instruct sender FI system 1210 and recipient FI system 1212 to extract public identifiers from transaction data. Transfer logic 1284 may further instruct sender FI system 1210 and/or recipient FI system 1212 to retrieve the DDA after the public identifier has been extracted.

Registration logic 1286 may be configured to manage registration of non-registered participants for fund transfers. Registration logic 1286 is further described with respect to FIG. 14 . In some implementations, registration logic 1286 may issue a participant account to access that participant account. As used herein, “participant account” may refer to a registered account maintained by payment services system 1218 to facilitate the transfer of funds between financial institutions. Participant accounts may be linked to and/or backed by funds in a financial account provided by a financial institution. Participant accounts may be identified by account number and/or other account identifier.

Registration logic 1286 may generate tokenized account data for a participant account when the participant wishes to register a user identifier for that participant account. As used herein, “tokenized account data” may include a representation of account information that secures the account information from external discovery. In some implementations, tokenized account data may include a proxy number or encrypted version of account information. Tokenized account data may further include the name/identifier/etc. of the financial institution associated with the account information. In various implementations, registration logic 1286 may allow a user to register a user identifier for a participant account.

An automated clearing house (ACH) system 1220 may include one or more digital devices used to transfer funds to and from the bank accounts of senders and recipients. The Automated Clearing House (ACH) system 1220 may be used to transfer funds to and from the bank accounts of the sender and recipient. In some implementations, ACH system 1220 may facilitate the secure transfer of funds and/or information between a sender FI computer system 1210 and a recipient FI computer system 1212. ACH system 1220 may include a computer system configured similarly to ACH system 170 shown in FIG. 1 .

In some implementations, ACH system 1220 may enable a batch processing system. As used herein, a “batch processing system” may include a system that allows a financial institution to accumulate transactions over a specific period of time. In some implementations, financial institutions transferring funds to each other through a batch processing system may accumulate transactions over a specific period of time (hours, days, weeks, etc.) or until a specific event occurs. After a certain period of time or a certain event, financial institutions may settle amounts held by each other using a private network (e.g., ACH network 1216 and/or ACH system 1220). In some implementations, A batch transfer system allows financial institutions to transfer funds to each other as needed and settle amounts held by each other at specific times of the day, week, etc. Settlement times may be supported by regulation. For example, National Automated Clearing House Association (NACHA) rules may require financial institutions that utilize a batch processing system to settle credits before the end of the next business day after a particular funds transfer.

In various implementations, ACH network 1220 may enable sender FI system 1210 and recipient FI system 1212 to transfer funds electronically. Instead of using paper to convey the necessary transaction information, such as with a check, transactions over the ACH network 1220 can be transmitted electronically over a private network, resulting in faster, more secure processing times and cost savings. can make it possible. ACH network 1220 may process different types of transactions, including, but not limited to, direct deposit transactions and direct payment transactions. Direct deposit transactions may include deposits of funds for payroll, employee expense reimbursements, government wages, tax and other refunds, pensions, and interest payments. Direct deposit transactions may include ACH credit payments from a business or government to a consumer. A direct payment transaction may involve using funds to make a payment. In some implementations, individuals and/or institutions can make payments directly through ACH as 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 processed as ACH credit transactions deposit funds into your account. An example of this is when a consumer initiates a payment through his bank or credit union to pay a bill. Direct payments processed as ACH debit transactions can withdraw funds from your account. An example of this is when a consumer establishes a recurring monthly payment on a mortgage or utility bill and his account is automatically debited.

12 illustrates a sender system 1202 and a recipient system 1204, it will be appreciated that the sender system 1202 and recipient system 1204 may be optional. For example, the sender may interact directly with the first non-FI system 1206, which may include, for example, a physical device configured to receive a credit or debit card number from the sender. The physical device may further receive the sender's public identifier. In some implementations, a physical device or other part of the sender system 1202 may further receive the amount for transfer to the recipient as well as the recipient public identifier. In these examples, a physical device, transmitter system 1202, or financial service provider (e.g., MasterCard or Visa) may tokenize a credit card number or debit card number and/or back up or issue a financial instrument. An identifier for a financial institution may be provided. The non-FI system 1206 and/or financial service provider must provide the sender public identifier, the financial institution's identifier (e.g., identifying the sender FI system 1210), the amount desired to be transferred, and/or the recipient identifier. It may be provided to the service system 1218 and/or the remitter FI system 1210.

Figure 13 shows a diagram of funds transfer logic 1284, according to some implementations. Funds transfer logic 1284 may include transaction data management logic 1302, payment confirmation 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 confirmation logic 1304, information directory management logic 1306, payment notification logic 1308, and payment status management logic 1310 are stored within funds transfer logic 1284. It may be implemented using physical computer processor(s) and memory. The memory may be configured by a physical processor ( You can store computer program instructions for instructing.

Transaction data management logic 1302 is responsible for processing transaction data to and from payment services system 1218 as well as participant systems (e.g., sender system 1202, recipient system 1204, first non-FI system). 1206, and a second non-FI system 1208). As used herein, “transaction data” refers to information used to effect a transfer of funds from one participant to another participant (e.g., from a sender to a recipient received from first non-FI system 1206). request, the sender's public identifier, the recipient's public identifier, a transaction identifier that identifies the transaction for the transfer of funds, the sender's private identifier, the recipient's private identifier, a financial institution (FI) identifier associated with the sender, or an FI identifier associated with the recipient; or May refer to data related to transactions, including any combination. In some implementations, the transaction data includes the amount of funds desired to be transferred.

Transaction data management logic 1302 may, in some implementations, process transaction data indicating that a sender wishes to provide funds to a recipient (e.g., sender system 1202, first non-FI system 1206, The remittance may be received from the FI system 1210, and/or from the 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 for the transfer. Transaction data management logic 1302 determines whether the sender is registered by comparing the sender's public identifier to a list of registered users (e.g., to information in the account database 1278, information directory 1280, or otherwise). ) can be determined. If registered, transaction data management logic 1302 may provide a success message to first non-FI system 1206 and/or sender system 1202 that the sender has been registered. Additionally, the transaction data management logic 1302 may provide the sender's public identifier and the amount desired to be transferred to the sender FI system 1210. Transaction data management logic 1302 may also provide the recipient's public identifier, the recipient's private identifier, the recipient FI identifier, the sender's public identifier, and/or any other information to the sender FI system 1210.

Transaction data management logic 1302 may receive an acknowledgment from sender FI system 1210 indicating that sender FI system 1210 has identified 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 a transaction for transferring funds from a sender to a recipient, and transmit such transaction identifier to the sender FI system 1210 and/or the recipient FI system ( 1212).

In some implementations, transaction data management logic 1302 provides logic and/or instructions to first non-FI system 1206 to enable first non-FI system 1206 to provide fund transfer options to users of the system. It can be provided. For example, transaction data management logic 1302 may be logic that the first non-FI system 1206 wishes to replace or embed within a physical device, web page, or code provided to the sender or sender system 1202. (e.g., code or software) may be provided to the first non-FI system 1206. The logic allows the sender to view options for transferring money, allows the sender to enter or select the recipient's public identifier, allows the sender to enter or select their own public identifier, and allows the sender to enter or select a public identifier of the funds to transfer. It may display the amount, receive the sender's debit or credit card number, and/or any other information.

Confirmation logic 1304 may be configured to confirm payment details associated with transaction data. Verification involves determining whether the sender public identifier is registered, determining whether the recipient public identifier is registered, or determining whether the FI identifier is associated with a known financial institution (or member financial institution). It can be included. An FI identifier is created as part of the tokenization of the sender's debit or credit card number or in any number of ways (e.g., by deriving information from the sender's debit or credit card or information provided by the sender) You will understand that it can be done.

In various implementations, confirmation logic 1304 implements one or more confirmation protocols (e.g., confirmation interfaces) that request confirmation from a financial institution that the sender has authorization to provide the requested funds. . Confirmation logic 1304 may further implement one or more checks to verify that the public identifier provided in connection 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 implementations, information directory management logic 1306 may add, delete, and/or otherwise modify or manage information directory 1280.

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

Payment status management logic 1310 may be configured to manage status updates indicating whether funds transfer is possible or if there is an error. In some implementations, payment status management logic 1310 may request additional information to assist in the process of transferring funds.

Figure 14 shows a diagram of registration logic 1286, according to some implementations. It will be appreciated that in some implementations, registration logic 1286 may register the sender and/or recipient once. Registration logic 1286 may include participant account creation 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 creation logic 1402, user identification verification logic 1404, tokenization logic 1406, financial institution identification logic 1408, and account verification logic 1410 are stored in registration logic 1286. It may be implemented using physical computer processor(s) and memory. The memory may be configured with a physical processor ( You can store computer program instructions for instructing.

Participant account issuance logic 1402 may be configured to assist in issuance of participant accounts. In some implementations, participant account issuance logic 1402 may provide an account number and/or other account identifier that a participant can use as the basis for a participant account (e.g., that may assist in transferring funds between financial institutions). can be created.

User identification verification logic 1404 may be configured to verify a user identifier when the user identifier is provided for participant account registration. In various implementations, 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 may be further configured to determine whether the user identifier and/or participant account information provided by the participant is associated with an account at a financial institution or whether the financial institution can be identified.

Verification of a public identifier requires that the public identifier is in an appropriate format (e.g., an appropriate alphanumeric format), that the public identifier has not been previously assigned to another participant, and that the public identifier is in an appropriate format (e.g., an appropriate alphanumeric format). It may contain one or more verification techniques, such as not including information.

Tokenization logic 1406 may be configured to tokenize participant account information. In various implementations, tokenization logic 1406 may encrypt participant account information or associate a proxy number with participant account information to keep participant account information safe from discovery by external entities, including non-financial institutions. can be assigned to .

Financial institution identification logic 1408 may be configured to identify the 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 implementations, financial institution identification logic 1408 may utilize the name/identifier/etc. of the financial institution included in the tokenized account to identify the appropriate participant financial institution. As an example, in an implementation where the participant system corresponds to the sender system 1202, the financial institution identification logic 1408 may identify the sender FI system 1210. In implementations where the participant system corresponds to the recipient system 1204, the financial institution identification logic 1408 may identify the recipient FI system 1212.

Account verification logic 1410 may provide status updates and/or other information to indicate whether the participant account has been successfully registered. Account verification logic 1410 may verify the owner of the public identifier and instruct the participant system to transmit the public identifier and account information to the non-FI system corresponding to the participant system. As an example, account verification logic 1410 may verify ownership of a public identifier and instruct sender system 1202 to transmit the public identifier and account information to first non-FI system 1206. As another example, account verification logic 1410 may verify ownership of a public identifier and instruct recipient system 1204 to transmit the public identifier and account information to a second non-FI system 1208.

Account verification logic 1410 may instruct a non-FI system corresponding to the participant system to transmit the public identifier and tokenized account data to payment service system 1218. In some implementations, the public identifier and tokenized account data are transmitted directly to the payment services system 1218, while in other implementations, the public identifier and tokenized account data are transmitted directly to the remitter non-FI banking system 1214. It is transmitted to the payment service system 1218 through . Account verification logic 1410 may instruct the relevant participant FI system to obtain the identifier of the financial institution associated with the participant using tokenized account data. Account verification logic 1410 may instruct the participant FI system to perform a DDA search, map the DDA number to a public identifier, and associate the public identifier with the associated user account. In various implementations, account verification logic 1410 may provide confirmation of whether a participant has successfully registered for fund transfer at a non-financial institution.

15 shows a diagram of a data flow 1500 for securely transferring funds from a sender to a recipient within a funds transfer system, according to some implementations. The data flow 1500 shown in FIG. 15 may be, for example, an example in which both the sender and the recipient are already registered with the payment service system 1218. Data flow 1500 includes components of funds transfer system 1200, shown in FIG. 12 and discussed further herein. More specifically, the data flow 1500 includes 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) and includes one or more operations. Note that the elements of data flow 1500 are examples only, and that various implementations may utilize more or fewer elements without departing from the scope and essence of the inventive concepts described herein. shall.

At operation 1502, remitter system 1202 may receive transaction data related to a fund transfer from remitter system 1202. The transaction data may include the amount of funds desired to be transferred, a public identifier of the sender (e.g., a participant associated with the sender system 1202), and a recipient's (e.g., participant associated with the second non-FI system 1208) information. A public identifier can be specified. As further noted herein, public identifiers of the sender and recipient can assist in the routing of fund transfers to the recipient and reconciliation between the sender and recipient financial accounts without the need to provide account information to an external financial institution. can help

In operation 1504, remitter system 1202 may provide transaction data to first non-FI system 1206 over public network 1214 (or any network). In various implementations, remitter system 1202 may provide transaction data to a physical purchase terminal or to an application, website, or other powered by an online purchase process supported by first non-FI system 1206. there is. Transaction data may include the amount of funds for the transfer, as well as public identifiers of the sender and recipient.

It will be appreciated that operations 1502 and 1504 are optional. For example, as described herein, the non-FI system 1206 may receive funds transfer information (e.g., sender public identifier, credit or debit card number, amount desired to be transferred) from the sender without the sender system 1202. , or other) may include a physical device configured to receive.

In operation 1506, the first non-FI system 1206 may route transaction data to the payment services system 1218. The first non-FI system 1206 may recognize that the public identifiers of the sender and recipient are in a format corresponding to the funds transfer managed by the payment services system 1218. In operation 1508, the first non-FI system 1206 may provide transaction data to the payment services system 1218 over the public network 1214 (or any other network).

In operation 1510, payment service system 1218 may verify payment details with respect to transaction data. As noted herein, verification may include determining whether the sender's public identifier is valid, whether the recipient's public identifier is valid, whether the sender has authorization to provide the requested funds, and/or others. there is. In some implementations, payment services system 1218 verifies that the sender's public identifier is associated with the sender's private identifier and a FI system (e.g., sender FI system 1210). Similarly, payment service system 1218 may verify that the recipient's public identifier is associated with the recipient's private identifier and a FI system (e.g., recipient FI system 1212). Payment confirmation logic 1304 may perform operation 1510.

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

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

In operation 1516, payment service system 1218 may provide payment notification to remitter FI system 1210 via public network 1214 (or any network). The payment notification may inform the sender FI system 1210 that the funds transfer request has been successfully added to the information directory 1280. The payment notification may include at least some of the transaction data, including the amount of the funds transfer request, the sender's private identifier, and the recipient's private identifier. The payment notification may include instructions or information to the sender FI system 1210 to facilitate the transfer of funds to the recipient FI system 1212. Payment notification logic 1308 may perform operation 1516.

At operation 1518, sender FI system 1210 may retrieve one or more accounts (e.g., DDA) associated with the sender's private identifier. In various implementations, sender FI system 1210 may use the sender's private identifier to search for DDA in information directory 1260. The remitter FI system 1210 may identify any number of accounts and/or other information associated with the remitter system 1206.

At operation 1520, sender FI system 1210 may determine whether the sender account has sufficient find to effect a funds transfer. In operation 1522, the sender FI system 1210 may perform checks related to whether the sender account has sufficient funds, whether transaction data is likely to be false/suspicious, or perform any other checks that may be based on regulatory compliance. Internal checks can be performed like other checks.

At operation 1524, remitter FI system 1210 provides instructions to payment service system 1218 to update any relevant status regarding whether funds for transfer have been approved and/or will be effected. can do. At any time, payment service system 1218 may generate a transaction identifier that identifies the transaction. The transaction identifier may be shared by the payment service system 1218 with the sender FI system 1210 and the recipient FI system 1204. Payment services system 1218 may provide first notification of updated status to first non-FI system 1206, including whether funds for the transfer will be transferred.

At operation 1526, payment services system 1218 sends a second notification of the updated status, including whether funds are to be transferred, to remitter system 1202 (or first non-FI system 1206). can be provided. In various implementations, payment status management logic 1310 may perform operations 1524 and 1526.

In operation 1528, sender FI system 1210 may provide recipient FI system 1212 with a batch transfer to settle a transfer of funds between two financial institutions using ACH network 1216. In various implementations, a request to settle a payment includes a transaction identifier (which identifies the transaction and may be linked to the amount sought to be transferred, an identifier in the sender FI system 1210, and any other information). and/or may include or be associated with an ACH message specifying the amount of the funds transfer. In some implementations, a batch transfer may involve a sender private identifier, a sender public identifier, a recipient private identifier, a recipient public identifier, a FI identifier of the sender FI system 1210, and/or any other information. Alternatively, the sender private identifier, the sender public identifier, the recipient private identifier, the recipient public identifier, the FI identifier of the sender FI system 1210, and/or any other information may be provided at a later time. In some implementations, payment status management logic 1310 may perform operation 1528.

At operation 1530, the recipient FI system 1212 may identify the transaction identifier and retrieve information related to the transfer, including, for example, the recipient and the amount of money to be transferred. For example, recipient FI system 1212 may use a transaction identifier to identify the recipient and retrieve one or more accounts (e.g., DDA) associated with the recipient.

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

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

At operation 1536, recipient FI system 1212 may provide updated status to payment services system 1218 indicating that funds have been transferred into the recipient account. At operation 1538, payment service system 1218 may provide updated status to first non-FI system 1206 or sender system 1202 indicating that funds have been transferred into the recipient account.

Figures 16A and 16B illustrate flow charts of methods 1600A and 1600B for securely transferring funds from a sender to a recipient within a funds transfer system, according to some implementations. The flowcharts of methods 1600A and 1600B may include operations similar to those of FIG. 15 . Methods 1600A and 1600B may be practiced by one or more of the systems or system components shown in FIGS. 12-14. It should be noted that methods 1600A and 1600B may include more or less operations than explicitly shown.

At operation 1602, transaction data management logic 1302 may receive transaction data from first non-FI system 1206 via public network 1214. The transaction data may specify the transfer amount of a funds transfer between a sender and a recipient (e.g., between a sender system 1202 and a second non-FI system 1208 or a recipient system 1204). In some implementations, transaction data may include a sender public identifier to identify the sender of a fund transfer. A sender public identifier is something that identifies the sender, such as an e-mail address, username, phone number, alphanumeric string, or other information that uniquely identifies the sender but does not contain financial information about the sender for security purposes. May contain information that can be used to contact you. The transaction data may include a recipient public identifier to identify the recipient of the fund transfer. Recipient public identifiers may similarly include an e-mail address, username, phone number, alphanumeric string, or others. The recipient public identifier can also uniquely identify the recipient, but keeps the recipient's financial information safe from outside discovery.

At operation 1604, transaction data management logic 1302 of payment services system 1218 may determine that the sender and recipient are respectively registered to effect a funds transfer using the sender public identifier and the recipient public identifier. In various implementations, transaction data management logic 1302 may determine that the sender and recipient are registered in the information directory 1280. Transaction data management logic 1302 may determine, for example, that public and/or private identifiers of the sender and/or recipient are registered within information directory 1280.

In operation 1606, transaction data management logic 1302 may use the sender public identifier to collect the identifier of the sender financial institution with the sender financial account and the sender private identifier. At operation 1608, transaction data management logic 1302 may use the recipient public identifier to collect the identifier of the recipient financial institution with the recipient financial account and recipient private identifier. The transaction data management logic 1302 may obtain the remitter financial institution and/or the recipient financial institution using the name, identifier, etc. included in the transaction data to identify the remitter financial institution and the recipient financial institution.

At operation 1610, payment notification logic 1308 may transmit at least a portion of the transaction data and retrieved information to the sender financial institution to effect the funds transfer. In various implementations, the sender private identifier, the recipient public identifier, the recipient FI system 1212, and the transfer amount may be transmitted to the sender FI system 1210 by payment notification logic 1308. Some of the transaction data may include data sufficient to identify the sender of the funds transfer, the recipient of the funds transfer, and the transfer amount of the funds transfer.

In operation 1612, the sender FI system 1210 may retrieve the sender account using the sender private identifier. In some implementations, sender FI system 1210 may identify the sender account by using the sender private identifier to query information directory 1260. Based on fetching the sender's account, a resulting response can be formed. As previously discussed, during registration, a sender private identifier is created by the sender FI system 1210 during registration and links the sender to one or more account numbers of the sender's accounts maintained or managed by the sender FI system 1210. It can be used to do so. The sender's private identifier may not be an account number or an encrypted account number. For example, although the sender private identifier is not provided to the sender system 1202, the recipient system 1204, or the first non-FI system 1206, the sender private identifier may not be reverse engineered (e.g., The account number cannot be obtained from the sender's private identifier). Due to its association with other account information, the sender private identifier may be the only identifier that can be used by the sender FI system 1210. In operation 1614, the sender FI system 1210 may evaluate whether the sender financial account has sufficient funds to effect the transfer of funds. In some implementations, the sender FI system 1210 may send one or more instructions to the sender FI to ensure that the sender has account access, sufficient funds, and other information necessary to use the public identifier to effect a funds transfer. Can be transmitted to system 1210.

In operation 1616, the sender FI system 1210 may evaluate whether the funds transfer is likely fraudulent based on the transaction data. In some implementations, payment confirmation logic 1304 may determine whether the circumstances of the sender's transfer appear likely to indicate that the sender is not who he or she claims to be. The remitter FI system 1210 determines whether the remitter's Internet Protocol (IP) address, etc. is valid, and/or whether the remitter attempted to transfer funds from an approved system or a system previously used by the remitter, and whether the remitter attempted to transfer funds in a short period of time. You can evaluate whether or not it was repeated. If the transfer authorization passes, the sender FI system 1210 may provide notification that the funds transfer can be effected. At operation 1618, payment service system 1218 may receive notification that sender FI system 1210 may effect a funds transfer.

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

At operation 1620, payment notification logic 1308 may provide status of the funds transfer to one or more of the sender system 1202 and the first non-FI system 1206 indicating that the funds transfer will occur. .

In operation 1622, the sender FI system 1210 or payment service system 1218 identifies the transaction identifier, the recipient private identifier, the transfer amount, the sender financial institution's identifier, and/or the sender's private identifier for the recipient financial institution. Transaction data may be provided to the recipient FI system 1212. In various implementations, a private identifier is provided so that account information does not have to be transmitted over public network 1214 (or another network).

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

17 shows a diagram of a data flow 1700 for securely transferring funds from a sender to a recipient within a funds transfer system, according to some implementations. Data flow 1700 may be where one participant, for example a remitter, has not previously registered with the payment service system 1208. Data flow 1700 includes components of funds transfer system 1200, shown in FIG. 12 and discussed further herein. More specifically, data flow 1700 may be directed to a remitter system 1202, a first non-FI system 1206, a second non-FI system 1208, a remitter FI system 1210, a payment services system 1218, and Includes operations of one or more of the recipient FI systems 1212. Note that the elements of data flow 1700 are examples only, and that various implementations may utilize more or fewer elements without departing from the scope and essence of the inventive concepts described herein. shall.

At operation 1702, remitter system 1202 may receive transaction data related to the transfer of funds. Transaction data may specify the amount of funds desired to be transferred. The transaction data may specify the public identifier of the sender (e.g., a participant associated with the sender system 1202) and the public identifier of the recipient. As further noted herein, public identifiers of the sender and recipient can assist in the routing of fund transfers to the recipient and reconciliation between the sender and recipient financial accounts without the need to provide account information to an external financial institution. can help It will be appreciated that the recipient system 1204 may also receive transaction data related to the transfer of funds.

In operation 1704, sender system 1202 (and recipient system 1204) may provide transaction data to first non-FI system 1206 via public network 1214. In various implementations, remitter system 1202 may provide transaction data to a physical purchase terminal or to an application, website, or other powered by a payment process supported by first non-FI system 1206. . Similarly, recipient system 1204 may provide transaction details to a second non-FI system 1208 or a first non-FI system 1206. In some implementations, the first non-FI system 1206 and the second non-FI system 1208 are owned by the same entity. In some implementations, the sender system 1202 provides the sender's first financial instrument or the sender's tokenized financial instrument (to generate a sender token) to the first non-FI system 1206, and the recipient system ( 1204 provides the recipient's second financial instrument or the recipient's tokenized financial instrument (to generate a recipient token) to the first non-FI system 1206 or the second non-FI system 1208.

It will be appreciated that operations 1702 and 1704 are optional. For example, as described herein, the non-FI system 1206 may receive funds transfer information (e.g., sender public identifier, credit or debit card number, amount desired to be transferred) from the sender without the sender system 1202. , or other) may include a physical device configured to receive.

It will be appreciated that the first and second non-FI systems may not be essential. For example, sender system 1202 and recipient system 1204 each provide transaction information (e.g., the funds desired to be transferred, tokenized financial tools to generate tokens from the sender and sender, and public information from the sender and recipient). It may be a smartphone configured to share an identifier). Transaction information may be provided to payment service system 1218.

In operation 1706, the first non-FI system 1206 may route transaction data to the payment services system 1218. In operation 1708, the first non-FI system 1206 may provide transaction data to the payment services system 1218 over the public network 1214 (or any other network). Transaction data may include a sender public identifier, a recipient public identifier, the amount desired to be transferred, a recipient token, and a sender token. In some implementations, first non-FI system 1206 can receive account numbers associated with any number of financial instruments. The first non-FI system 1206 may tokenize the account number of the financial instrument or may provide the account number to a financial service provider associated with the financial instrument to tokenize the account number. Subsequently, the first non-FI system 1206 or financial service provider associated with the financial instrument may provide the token(s) of the account number(s) to the payment services system 1218.

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

Similarly, payment service system 1218 may use the recipient's public identifier to verify that the recipient is registered with payment service system 1218. If the recipient has already registered, the recipient may not need to re-register. If the recipient is not registered, the payment service system 1218 may request an attachment from the recipient, recipient system 1204, first non-FI system 1206, or second non-FI system 1208 to identify the sender. You may request specific information.

In some implementations, the first non-FI system 1206 or an entity associated with the sender's financial instrument tokenizes the sender's financial instrument and/or the recipient's financial instrument (to generate a sender token and/or a recipient token). can do. The first non-FI system 1206 may also transmit to the payment services system 1218 the FI identifier associated with the sender's financial instrument (e.g., the bank that issued the financial instrument) and the FI identifier associated with the recipient's financial instrument. You can. If the payment service system 1218 determines that the sender should register (e.g., when requesting the sender to register), the payment service system 1218 may identify the sender FI system 1210 with the FI identifier and the sender The token and the remitter public identifier may be provided to the remitter FI system 1210.

In operation 1712, payment services system 1218 may add transaction data to information directory 1280 to temporarily log the transaction. The non-FI system 1210 may provide, for example, the sender public identifier, the funds desired to be transferred, the recipient public identifier, the financial identifier associated with the financial instrument, the financial instrument's tokenized account number (e.g., the sender's token and It will be understood that information relating to the transfer of funds may be logged or stored, including the recipient's token), or any combination thereof.

At operation 1714, the payment service system 1218 sends a notification to the public network 1214 (or any It can be provided to the remitter's FI system (1210) through a network). Payment service system 1218 may also send a notification to the recipient via public network 1214 (or any network) containing the sender public identifier, the recipient public identifier, the sender's token, the funds desired to be transferred, or any other information. It can be provided to the FI system 1212.

At operation 1716, the sender FI system 1210 may de-tokenize the sender's token to identify a financial instrument number (e.g., a credit or debit card number). At operation 1718, sender FI system 1210 may retrieve one or more de-tokenized numbers to identify the sender and any number of accounts (e.g., DDA) associated with the sender. In various implementations, the sender FI system 1210 may use the sender's public identifier to further verify the account. Remitter FI system 1210 may identify accounts and/or other information associated with remitter system 1206, for example. If the sender and the sender's account(s) are identified in the sender FI system 1210, in operation 1720, the sender FI system 1210 may generate a sender private identifier and send the private identifier to the payment service system 1218. and payment service system 1218 may then store such information in an information directory.

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

At operation 1726, payment services system 1218 may provide first notification of updated status to first non-FI system 1206, including whether funds for the transaction can be transferred. there is. At operation 1728, the payment service system 1218 sends a second notification of the updated status, including whether funds for the transfer can be transferred, to the first non-FI system 1206 or the remitter system ( 1202). In various implementations, payment status management logic 1310 may perform operations 1726 and 1728.

At any time, payment service system 1218 may generate a transaction identifier associated with the transaction. In one example, payment services system 1218 may generate a transaction identifier once a sender private identifier is received from a sender FI system 1210 and a recipient private identifier is received from a recipient FI system 1212. Payment service system 1218 may provide the transaction identifier and any other information to recipient FI system 1212 and sender FI system 1210.

In operation 1730, recipient FI system 1212 may de-tokenize the recipient token. At operation 1734, recipient FI system 1212 may retrieve one or more DDAs associated with the recipient's public identifier. The recipient FI system 1212 may use the recipient's public identifier to search the information directory 1270 for a DDA associated with the sender system 1202.

In operation 1734, the sender FI system 1210 may provide a batch payment to the recipient FI system 1212 to settle payment for the funds transfer over the ACH network 1216. In various implementations, a request to settle a payment may include both transfers over the ACH network 1216 and may be accompanied by a transaction identifier and the amount of the funds transferred.

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

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

In some embodiments, recipient FI system 1212 may place funds in the recipient's account before the funds are received from sender FI system 1210 via the ACH network. The recipient FI system 1212 may then be reimbursed when the batch payment is received.

Figures 18A and 18B illustrate flow charts of methods 1800A and 1800B for securely transferring funds from a sender to a recipient within a funds transfer system, according to some implementations. The flowchart within 1800A and 1800B may be similar to the flow discussed in FIG. 17. Methods 1800A and 1800B may be practiced by one or more of the systems or system components shown in FIGS. 12-14. It should be noted that methods 1800A and 1800B may include more or less operations than explicitly shown.

At operation 1802, transaction data management logic 1302 of payment services system 1218 may receive transaction data from first non-FI system 1206 over public network 1214. Transaction data may include the transfer amount of a funds transfer between a sender and a recipient (e.g., between the sender system 1202 and a second non-FI system 1208 or the recipient system 1204), the transfer amount, and the transfer amount to identify the sender of the funds transfer. Sender public identifier, Recipient public identifier to identify the recipient of the funds transfer, Sender token of the sender's tokenized financial instrument, Recipient token of the recipient's tokenized financial instrument, Sender FI identifier associated with the sender's financial instrument (e.g. For example, the issuing bank of the sender's financial instrument), and/or the recipient's FI identifier associated with the recipient's financial instrument. It will be appreciated that transaction data may be received from any number of sources. For example, transaction data management logic 1302 may receive portions of transaction data from first non-FI system 1206, including a sender token of the sender's tokenized financial instrument and a recipient's tokenized financial instrument. The recipient token, or both, may be received from any number of entities.

At operation 1804, transaction data management logic 1302 may determine that the sender and recipient have not each registered to effect a funds transfer using the sender public identifier and the recipient public identifier. In various implementations, transaction data management logic 1302 may determine that the sender and recipient are registered with a non-financial institution. In various implementations, the sender, the recipient, or both may not be registered.

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

At operation 1808, payment notification logic 1308 may transmit at least a portion of the transaction data to the sender financial institution to effect the funds transfer. In various implementations, the sender public identifier, recipient public identifier, transfer amount, recipient FI identifier, and/or the sender's token may be transmitted to the sender FI system 1210 by the payment notification logic 1308. Some of the transaction data may include data sufficient to identify the sender of the funds transfer, the recipient of the funds transfer, and the transfer amount of the funds transfer.

At operation 1810, payment notification logic 1308 may transmit at least a portion of the transaction data to the recipient financial institution to effect the funds transfer. In various implementations, the recipient public identifier, sender public identifier, transfer amount, sender FI identifier, and/or recipient's token may be transmitted to recipient FI system 1212 by payment notification logic 1308. Some of the transaction data may include data sufficient to identify the sender of the funds transfer, the recipient of the funds transfer, and the transfer amount of the funds transfer.

In operation 1812, remitter FI system 1210 may de-tokenize the remitter private identifier. In operation 1814, the sender FI system 1210 may use information from the de-tokenized sender private identifier (e.g., using the sender's credit or debit card number) to retrieve the sender's account. there is.

In operation 1816, the sender FI system 1210 may evaluate whether the sender financial account has sufficient funds to effect the transfer of funds. In some implementations, the sender FI system 1210 may ensure that the sender has account access, sufficient funds, and other information necessary to use the public identifier to effect the funds transfer.

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

In operation 1822, recipient FI system 1212 may de-tokenize the recipient's token. In operation 1824, the recipient FI system 1212 uses the de-tokenized recipient's token (e.g., using the recipient's credit card number or debit card number) to generate one token at the recipient FI system 1212. The account of one or more recipients can be identified. If successful, recipient FI system 1212 may, in operation 1826, provide notification to payment services system 1218 that the recipient's account has been determined. The payment service system 1218 provides a transaction identifier for the transfer and a notification to the recipient FI system 1212 and/or the sender FI system 1210 indicating that one or both of the financial institutions is ready to effect the transfer. can do.

In operation 1828, the sender FI system 1210 collects, through the ACH system 1220 and/or the ACH network 1216, funds for transfer as part of a batch funds transfer process that includes an indication of a transaction identifier. Can be provided to the recipient FI system 1212. At operation 1830, payment status management logic 1310 may receive notification regarding the deposit of a funds transfer into a recipient financial account at a recipient financial institution.

19 shows a diagram of a data flow 1900 for registering a participant within a funds transfer system, according to some implementations. Data flow 1900 includes components of funds transfer system 1200, shown in FIG. 12 and discussed further herein. The data flow may include a payment service system 1218, and a participant system 1902, a participant non-FI system 1904, and a participant FI system 1906. In some implementations, participant system 1902 corresponds to a remitter system 1202, participant non-FI system 1904 corresponds to a first non-FI system 1206, and participant FI system corresponds to a remitter FI system ( 1210). In various implementations, a participant system 1902 corresponds to a recipient system 1204, a participant non-FI system 1904 corresponds to a second non-FI system 1208, and a participant FI system 1906 corresponds to a recipient system 1204. Corresponds to the FI system (1212). Data flow 1900 further includes a plurality of operations corresponding to instructions and registration logic 1286 may provide components of funds transfer system 1200. Note that the elements of data flow 1900 are examples only, and that various implementations may utilize more or fewer elements without departing from the scope and essence of the inventive concepts described herein. shall.

In operation 1908, participant FI system 1906 may create a participant account. Participant accounts may be linked to financial accounts at financial institutions. In various implementations, a participant account may include an account number and/or other account identifier that can be used to identify the account when the participant wishes to register a public identifier for the account. Participant accounts may be linked to financial accounts at financial institutions containing financial data such as debit/credit card information, routing numbers, account numbers, etc. Financial data may include identifiers (name, routing number, etc.) of financial institutions providing financial services to participant system 1902. At operation 1910, participant FI system 1906 may create a financial instrument (e.g., a debit/credit card may be printed and/or an online account may be created for the participant account).

In operation 1912, participant FI system 1906 may share the financial instrument with a participant (user of participant system 1902), participant system 1902, and/or payment service system 1218. Participant FI systems 1906 may share financial tools with financial service providers (e.g., MasterCard). In some implementations, a code may be mailed and/or transmitted electronically to the participant or participant system 1902 so that the participant can register user identifier(s) for a participant account.

In some implementations, participant systems 1902 may interact with participant non-FI systems 1904. In other implementations, a participant may interact with the participant non-FI system 1904 (e.g., using a credit card and the participant non-FI's physical device). Although operations 1914-1920 are described herein from utilizing participant system 1902, it will be understood that other implementations may not require all or any of such operations.

At operation 1914, participant system 1902 may receive a request from a participant to register a participant account using a financial tool. In operation 1916, participant system 1902 may present one or more participant registration screens to the participant. In operation 1918, participant system 1902 may receive the participant's public identifier. In some implementations, public identifiers and account information may be provided into input devices of participant system 1902. Public identifiers may contain alphanumeric characters or other strings that can identify the participant. Participant system 1902 may receive a password, biometric authentication technology, other authentication technology, or others that enable verification of a public identifier.

In operation 1920, participant system 1902 may transmit the public identifier and participant account information to participant non-FI system 1904. In some implementations, a participant system 1902 or a participant (e.g., a user) provides a financial instrument (e.g., an account number, routing number, or other associated with the financial instrument) to a participant non-FI system 1904. Alternatively, the financial instrument may be tokenized to create a token of the financial instrument and provide the token to a participant non-FI system 1904 or financial service provider. Participant system 1902 may also transmit the identifier of the FI that issued the financial instrument to 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 an encrypted version of participant account information. In some implementations, tokenized account data may include a proxy number representing a card number, debit/credit/other, within the participant account information. At operation 1926, a participant non-FI system 1904 (or a financial service provider) may identify tokenized account data representing participant account information.

In operation 1924, the participant non-FI system 1904 and/or the financial service provider may transmit the public identifier and tokenized account data to the payment services system 1218. In operation 1926, participant non-FI system 1904 may optionally transmit a public identifier and/or tokenized account data to participant FI system 1906. In some implementations, 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 transmit a public identifier and/or tokenized account data to payment services system 1218. In one example, information may be shared by a participant non-FI system 1904 with a participant FI system 1906, which in turn may optionally share all or part of the information with the payment service system 1218. Share it with

In operation 1930, payment service system 1218 may verify the unused public identifier. Verification of a public identifier may include reviewing an information directory to determine whether another user has already registered a public identifier associated with another account. In some implementations, if the public identifier is already in use, the payment service system 1218 may return a failure message. User identity verification logic 1404 may perform operation 1930.

In operation 1932, payment service system 1218 may use tokenized account data or financial institution identifiers from participant system 1902 and/or participant non-FI system 1904 to identify the participant financial institution. there is. In some implementations, payment services system 1218 may evaluate tokenized account data for a name, identifier, or other corresponding to a financial institution. In various implementations, payment services system 1218 de-talks tokenized account data to extract information to identify a participant financial institution (e.g., a financial institution that manages participant FI system 1906). You can age.

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

In operation 1936, participant FI system 1906 may de-tokenize the tokenized account data. The participant FI system 1906 can perform decryption, random proxy number translation, etc. to obtain account information about the participant account. In operation 1938, participant FI system 1906 may perform a DDA search, for example, using account information for the participant's account. In operation 1940, participant FI system 1906 may map the DDA to the user's public identifier. Participant FI system 1906 may generate a private identifier associated with the participant's account number in participant FI system 1906. In some implementations, participant FI system 1906 may record account numbers (e.g., DDA), public identifiers, and private identifiers in an information directory stored within participant FI system 1906. In operation 1942, participant FI system 1906 may update the public identifier status to reflect the fact that the public identifier may be used for future fund transfers and other transactions involving the participant.

In operation 1944, participant FI system 1906 may provide confirmation to payment services system 1218 that the public identifier may be used for future fund transfers and other transactions involving the participant. Participant FI system 1906 may also share the participant's private identifier with payment service system 1218.

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

In operation 1950, participant non-FI system 1904 may configure participant system 1902 to show a success message indicating that the participant was successfully registered. In operation 1952, participant non-FI system 1904 may provide a success message to participant system 1902 that the public identifier may be used for future fund transfers and other transactions involving the participant. In operation 1954, a success message may be displayed on participant system 1902.

FIG. 20 illustrates a flowchart diagram of a method 2000 for registering a participant within a funds transfer system, according to some implementations. Method 2000 may be implemented by one or more modules shown in FIGS. 12-14. It should be noted that method 2000 may include more or less operations than those explicitly shown.

In operation 2002, participant account creation logic 1402 creates a participant financial account. Participant account creation logic 1402 may create a sender financial account corresponding to a specific sender or a recipient account corresponding to a specific recipient. Participant account creation logic 1402 may link the participant account to a financial account maintained/backed by a financial institution. In some implementations, participant accounts may be linked to collateral, cash, etc. Participant account issuing logic 1402 may store information about participant accounts in information directory 1280.

In operation 2004, user identity verification logic 1404 receives the presented public identifier from the participant. A presented public identifier may or may not include an e-mail address, an alphanumeric username, a Universal Payment Identification Code (UPIC), a telephone number, a user-generated or system-generated number or character string, etc. The presented public identifier may provide a basis for identifying participants and/or participating systems.

In operation 2006, user identity verification logic 1404 verifies whether the presented public identifier is associated with any participant. User identity verification logic 1404 verifies that the presented public identifier is an appropriate e-mail address, alphanumeric username, universal payment identification code (UPIC), telephone number, user-generated or system-generated number or character string, etc. You can verify whether it is included or not. User identity verification logic 1404 may verify whether the presented public identifier corresponds to a public identifier used to identify other participants.

In operation 2008, if the presented public identifier is not associated with any participant, user identity verification logic 1404 registers the presented public identifier as a participant public identifier. As discussed herein, participant public identifiers and any other financial information (e.g., tokens, financial instrument numbers, and others) may be shared with the participant's financial institution. Alternatively, the participant may interact with the financial institution (e.g., log into the participant's account), and the financial institution may verify the participant's account. The financial institution may create a participant private identifier associated with the participant and the participant's account number at the financial institution and may provide the participant private identifier to the payment service system.

User identity verification logic 1404 may store the presented public identifier along with the private identifier and associated account information within information directory 1280.

21 shows an example of a digital device 2100, according to some implementations. The 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 Includes bus (2135). Bus 2135 may be communicatively coupled to processor 2105, memory system 2110, storage system 2115, communication network interface 2120, I/O interface 2125, and display interface 2130. You can.

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

Storage system 2115 may include any storage device configured to retrieve and store data. Some examples of storage systems 2115 are flash drives, hard drives, optical drives, and/or magnetic tape. In some implementations, 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 capable of storing instructions or programs that can be executed by a computer processor, including processor 2105.

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

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

Those skilled in the art will understand that the hardware elements of digital device 2100 are not limited to those shown in FIG. 21. Digital device 2100 may include more or fewer hardware elements than shown. Additionally, hardware elements may share functionality and still be included in multiple implementations described herein. In one example, encoding and/or decoding may be performed by processor 2105 and an auxiliary processor located on the GPU.

The above-described functions and components may be implemented in commands stored on a storage medium such as a computer-readable medium. The processor can take those instructions and execute them. Some examples of instructions are software, program code, and firmware. Some examples of storage media are memory devices, tapes, disks, integrated circuits, and servers. Instructions are operative when executed by a processor, directing the processor to operate in accordance with some implementation. Those skilled in the art are familiar with instructions, processor(s), 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 clear to those skilled in the art that implementations of the disclosure may be practiced without these specific details. In some cases, modules, structures, processes, features, and devices are shown in block diagram form in order to avoid obscuring the description of the invention. In other cases, functional block diagrams and flow diagrams are shown to represent data and logic flow. Components (e.g., modules, blocks, structures, devices, features, etc.) of block diagrams and flow diagrams may be variously combined, separated, removed, rearranged, and replaced in ways other than those explicitly described and shown herein. It can be.

As used herein, “one embodiment,” “an embodiment,” “some embodiments,” “multiple embodiments,” “a specific embodiment,” “another embodiment,” “a series of embodiments,” or otherwise means an embodiment. means that a particular feature, design, structure, or characteristic described together with is included in at least one implementation of the disclosure. For example, the appearances of the phrases “in one embodiment” or “in an implementation” in various places within the specification do not necessarily all refer to the same implementation, and separate or alternative implementations may not be interchangeable with other implementations. It's not exclusive either. Additionally, various features are described that may be included in various combinations in some implementations, but may also be variously omitted in other implementations, whether or not there is explicit reference to "implementations" or otherwise. Similarly, several features are described that may be a preference or requirement for some implementations, but not others.

The language used herein has been selected primarily for readability and instructional purposes and may not have been selected to delineate or limit the subject matter of the invention. Accordingly, the scope is not limited by this specific description, but rather by any claims raised in the application based on such description. Accordingly, the disclosure of embodiments is intended to be illustrative, not limiting, of the scope set forth in the claims below.

Claims (20)

1. A method executed by a payment service computer system:
Receiving, at the payment services computer system, transaction data related to a funds transfer from one or more institutional computer systems of one or more institutional entities, the transaction data identifying a transfer amount of the funds transfer, a sender of the funds transfer, a sender public identifier to identify the recipient of the transfer of funds, a financial institution identifier for the sender financial institution entity, a financial institution identifier for the recipient financial institution entity, and the sender's tokenized financial information. Specifying an instrument, wherein the one or more institutional entities are different from the sender financial institution entity, the recipient financial institution entity, and the sender;
determining, at the payment services computer system, the remitter financial institution entity using the financial institution identifier for the remitter financial institution entity, wherein the remitter financial institution entity is a member of a payment network associated with the payment services computer system. In, the decision step;
From the payment service computer system, to enable the remitter financial institution computer system to de-tokenize the tokenized financial instruments of the remitter and the remitter financial institution entity's account associated with the remitter. providing the sender's tokenized financial instrument to the sender financial institution computer system of the sender financial institution entity so as to enable identification;
receiving, at the payment services computer system, from the sender financial institution computer system a sender private identifier generated by the sender financial institution computer system, wherein the sender financial institution computer system determines that the sender financial institution entity associated with the sender generating and receiving said remitter private identifier when verifying an account;
at the payment service computer system, associating the remitter private identifier with the remitter public identifier;
to enable the sender financial institution computer system to determine, from the payment services computer system, available funds in an account of the sender financial institution entity associated with the sender to satisfy the transfer amount of the funds transfer; providing a transfer amount, the recipient public identifier, and a financial institution identifier for the recipient financial institution entity to the sender financial institution computer system;
determining, at the payment service computer system, a payee private identifier based on the payee public identifier;
generating, at the payment services computer system, a transaction identifier associated with the funds transfer;
transmitting the transaction identifier from the payment service computer system to the remitter financial institution computer system; and
the transaction identifier and the recipient to enable the recipient financial institution computer system to identify the recipient financial institution entity's account associated with the recipient so that the recipient financial institution computer system can receive ACH messages over an ACH network; providing a private identifier from the payment service computer system to a recipient financial institution computer system of the recipient financial institution entity, wherein the ACH message represents a payment from the sender financial institution computer system to the recipient financial institution computer system, and wherein the ACH The message is generated by the sender financial institution computer system and includes a transaction identifier to identify the transfer of funds between the sender and the recipient, and the ACH message allows the recipient financial institution computer system to retrieve funds from an ACH batch transfer. and enabling the funds to be deposited into an account of the recipient financial institution entity associated with the recipient. According to paragraph 1,
The method further comprising authenticating, at the payment service computer system, that the sender has authorization to use the sender public identifier to effect the funds transfer. According to paragraph 1,
receiving, at the payment services computer system, the recipient's tokenized financial instrument and the financial institution identifier for the recipient financial institution principal;
determining, at the payment services computer system, the recipient financial institution entity using the financial institution identifier for the recipient financial institution entity, wherein the recipient financial institution entity is a member of the payment network associated with the payment services computer system. member, stage; and
From the payment services computer system, the recipient financial institution computer system can de-tokenize the tokenized financial instrument of the recipient and identify the account of the recipient financial institution entity associated with the recipient. The method further comprising providing the recipient's tokenized financial instrument to the recipient financial institution computer system. According to paragraph 3,
The method of claim 1, wherein the transaction data related to the funds transfer is received from a first online reseller computer system of a first online reseller of goods, and wherein the one or more institutional computer systems include the first online reseller computer system. According to paragraph 4,
The method of claim 1, wherein the first online reseller of the product tokenizes the sender's financial instrument to create the sender's tokenized financial instrument. According to clause 5,
The method of claim 1, wherein the financial instrument of the sender is issued by the sender financial institution entity. According to paragraph 4,
The recipient's tokenized financial instrument is received from a second online reseller computer system of a first online reseller of the product and a second online reseller of a different product, the one or more institutional computer systems of the second online reseller A method, comprising a computer system. In clause 7,
The method of claim 1, wherein the second online reseller of the product tokenizes the recipient's financial instrument to create the recipient's tokenized financial instrument. According to any one of claims 1 to 8,
The method of claim 1, wherein the recipient financial institution computer system transfers the funds to an account of a recipient financial institution entity associated with the recipient before the recipient financial institution computer system receives the ACH message. According to any one of claims 1 to 8,
The method further comprising providing a request from the payment service computer system to a recipient system associated with the recipient requesting that the recipient accept a transfer of funds from the sender. As a payment service computer system:
One or more processors;
A non-transitory computer-readable medium coupled to the one or more processors, the non-transitory computer-readable medium storing executable instructions, the executable instructions being executed by the one or more processors to:
In the payment services computer system, receive transaction data related to a funds transfer from one or more institutional computer systems of one or more institutional entities, wherein the transaction data includes a transfer amount of the funds transfer, a sender of the funds transfer, Specifies a sender public identifier, a recipient public identifier to identify the recipient of said funds transfer, a financial institution identifier for the sender financial institution entity, a financial institution identifier for the recipient financial institution entity, and the sender's tokenized financial instrument; the one or more institutional entities being different from the sender financial institution entity, the recipient financial institution entity, and the sender;
At the payment services computer system, using the financial institution identifier for the sender financial institution entity to determine the sender financial institution entity, wherein the sender financial institution entity is a member of a payment network associated with the payment services computer system. , to decide;
From the payment service computer system, to enable the remitter financial institution computer system to de-tokenize the tokenized financial instrument of the remitter and to identify the remitter financial institution entity's account associated with the remitter. providing the remitter's tokenized financial instrument to the remitter financial institution computer system of the remitter financial institution principal;
At the payment services computer system, receive, from the sender financial institution computer system, a sender private identifier generated by the sender financial institution computer system, wherein the sender financial institution computer system determines that the sender financial institution entity associated with the sender generating and receiving said sender private identifier when verifying an account;
in the payment service computer system, associating the sender private identifier with the sender public identifier;
to enable the sender financial institution computer system to determine, from the payment services computer system, available funds in an account of the sender financial institution entity associated with the sender to satisfy the transfer amount of the funds transfer; providing the transfer amount, the recipient public identifier, and a financial institution identifier for the recipient financial institution entity to the sender financial institution computer system;
determining, at the payment service computer system, a recipient private identifier based on the recipient public identifier;
generating, at the payment services computer system, a transaction identifier associated with the funds transfer;
transmitting the transaction identifier from the payment service computer system to the remitter financial institution computer system; and
the transaction identifier and the recipient to enable the recipient financial institution computer system to identify the recipient financial institution entity's account associated with the recipient so that the recipient financial institution computer system can receive ACH messages over an ACH network; providing a private identifier from the payment service computer system to a recipient financial institution computer system of the recipient financial institution entity, wherein the ACH message represents a payment from the sender financial institution computer system to the recipient financial institution computer system, and wherein the ACH message is generated by the sender financial institution computer system and includes the transaction identifier to identify the transfer of funds between the sender and the recipient, and the ACH message allows the recipient financial institution computer system to retrieve funds from an ACH batch transfer. A payment services computer system configured to provide, and enable depositing of said funds into an account of said recipient financial institution entity associated with said recipient. According to clause 11,
The executable instructions are further configured to: effect, in the payment services computer system, authenticating that the sender has authorization to use the sender public identifier to effect the funds transfer. According to clause 11,
The executable instructions are:
receiving, at the payment services computer system, the recipient's tokenized financial instrument and a financial institution identifier for the recipient financial institution principal;
At the payment services computer system, using the financial institution identifier for the recipient financial institution entity to determine the recipient financial institution entity, wherein the recipient financial institution entity is a member of the payment network associated with the payment services computer system. In, to decide; and
From the payment services computer system, the recipient financial institution computer system can de-tokenize the tokenized financial instrument of the recipient and identify the account of the recipient financial institution entity associated with the recipient. A payment services computer system further configured to effect providing a recipient's tokenized financial instrument to the recipient financial institution computer system. According to clause 13,
wherein the transaction data related to the funds transfer is received from a first online reseller computer system of a first online reseller of goods, wherein the one or more institutional computer systems comprise the first online reseller computer system. . According to clause 14,
wherein the first online reseller of the product tokenizes the sender's financial instrument to generate the sender's tokenized financial instrument. According to clause 15,
and wherein the financial instrument of the sender is issued by the sender financial institution entity. According to clause 14,
The recipient's tokenized financial instrument is received from a second online reseller computer system of a first online reseller of the product and a second online reseller of a different product, the one or more institutional computer systems of the second online reseller Payment service computer systems, including computer systems. According to clause 17,
and wherein the second online reseller of the product tokenizes the recipient's financial instrument to generate the recipient's tokenized financial instrument. According to any one of claims 11 to 18,
wherein the recipient financial institution computer system transfers the funds to an account of the recipient financial institution entity associated with the recipient prior to the recipient financial institution computer system receiving the ACH message. A non-transitory computer-readable medium containing executable instructions, wherein the executable instructions are executed by a processor of a payment service computer system:
In the payment services computer system, receive transaction data related to a funds transfer from one or more institutional computer systems of one or more institutional entities, wherein the transaction data includes a transfer amount of the funds transfer, a sender of the funds transfer, Specifies a sender public identifier for the sender financial institution entity, a recipient public identifier to identify the recipient of said funds transfer, a financial institution identifier for the sender financial institution entity, a financial institution identifier for the recipient financial institution entity, and the sender's tokenized financial instrument; , wherein the one or more institutional entities are different from the sender financial institution entity, the recipient financial institution entity, and the sender;
At the payment services computer system, using the financial institution identifier for the sender financial institution entity to determine the sender financial institution entity, wherein the sender financial institution entity is a member of a payment network associated with the payment services computer system. , to decide;
From the payment service computer system, to enable the remitter financial institution computer system to de-tokenize the tokenized financial instrument of the remitter and to identify the remitter financial institution entity's account associated with the remitter. providing the remitter's tokenized financial instrument to the remitter financial institution computer system of the remitter financial institution principal;
receiving, at the payment services computer system, from the sender financial institution computer system a sender private identifier generated by the sender financial institution computer system, wherein the sender financial institution computer system determines that the sender financial institution has an account associated with the sender; When verifying, the sender receives, generates a private identifier;
in the payment service computer system, associating the sender private identifier with the sender public identifier;
to enable the sender financial institution computer system to determine, from the payment services computer system, available funds in an account of the sender financial institution entity associated with the sender to satisfy the transfer amount of the funds transfer; providing the transfer amount, the recipient public identifier, and a financial institution identifier for the recipient financial institution entity to the sender financial institution computer system;
determining, at the payment service computer system, a recipient private identifier based on the recipient public identifier;
generating, at the payment services computer system, a transaction identifier associated with the funds transfer;
transmitting the transaction identifier from the payment service computer system to the remitter financial institution computer system; and
the transaction identifier and the recipient to enable the recipient financial institution computer system to identify the recipient financial institution entity's account associated with the recipient so that the recipient financial institution computer system can receive ACH messages over an ACH network; providing a private identifier from the payment service computer system to a recipient financial institution computer system of the recipient financial institution entity, wherein the ACH message represents a payment from the sender financial institution computer system to the recipient financial institution computer system, and wherein the ACH message is generated by the sender financial institution computer system and includes a transaction identifier to identify the transfer of funds between the sender and the recipient, and the ACH message allows the recipient financial institution computer system to retrieve funds from an ACH batch transfer. and depositing said funds into an account of said recipient financial institution entity associated with said recipient.

Images