Computer system, system and method for processing transaction requests

Abstract

The present invention relates to computer systems, systems and methods for processing transaction requests. The present invention provides systems, methods and computer-readable media for processing and settling financial transactions. An example method includes receiving a transaction from an initiator. The transaction includes information associated with an identification of an initiating user or the account. The method includes determining an actual account number, sending a financial service transaction request including the actual account number to a financial institution, receiving a response and sending a response back to the initiator. Another method includes receiving a request from a user device to associate a financial account with a user account. The method includes generating and sending an association message to a payment network and receiving a key associated with the financial account for initiating a financial transaction. Another method includes generating and processing a transaction request using such a key. Other systems, methods and media are also provided.

Description

[0001] This application is a divisional application of the original invention patent application with application number 201410640355.7 (application date: November 13, 2014, invention name: Computer system, method and transaction origin point for real-time account access). Technical Field

[0002] The disclosed embodiments are generally directed to systems and methods for real-time account access. Background Art

[0003] Network processing infrastructure such as EFT (Electronic Funds Transfer) network processing is used to process payments from traditional credit or debit card transactions. EFT enables account information and other relevant information to be provided for debits, credits, account-to-account transfers, purchases, bill payments, and other purposes. For example, when a cardholder seeks to purchase an item at a store, the cardholder will typically hand her card to the merchant and the merchant will swipe the card through a terminal capable of reading magnetic stripe information to read the card information. The card information includes, for example, the card number, expiration date, and the cardholder's name. The card number is typically 13-19 digits long and uniquely identifies the user's credit or debit account.

[0004] After the card number is captured by the merchant's terminal, the merchant's terminal sends information about the card and the transaction to the payment network, such as, for example, the card number, expiration date, cardholder name, transaction price, transaction date, transaction time, and transaction location. The first set of digits in the card number typically identifies the payment company or registration authority that licenses or registers the card prefix to the "issuer" (e.g., the financial institution that issued the card). So, for example, a card number that begins with '4' (e.g., 40001234 5678 9012) identifies VISA as a payment company that licenses the card prefix to a specific card issuer. Each financial institution issuer typically has a set of numerical identifiers (card prefixes) (e.g., a number of leading digits in the card number) used on its cards that it issues. The payment network routes the information received from the merchant's terminal to the appropriate card issuer based on the card number.

[0005] The appropriate issuer (in the case of a card transaction, a financial institution or its contractual transaction authorization processor) will then consult its records to determine the appropriate account and verify whether the account contains sufficient funds or credit to approve the transaction (e.g., purchase). The result of this determination is returned to inform the merchant whether the cardholder can purchase the item.

[0006] However, this process requires the cardholder to give a potentially untrusted entity (the merchant) a uniquely identifiable card number. An unscrupulous merchant employee or unauthorized person who intercepts the card data may try to reuse the card number without the cardholder's permission, for example, to purchase items for himself or to obtain cash at an ATM.

[0007] In addition, in some cases, the card number for accessing the customer's account is unavailable. For example, if a customer decides to pay by check, the merchant must capture the RTN (routing transfer number) of the financial institution that issued the check and the customer's personal account number. The merchant must then use the service provided by the bank or check cashing provider to access the automated clearing house (ACH), request the check to be cleared, and request credit. The ACH system is a batch-driven process that can take much longer time than card-based transactions to provide funds for purchases. Therefore, using checks as payment increases the amount of time for merchants to obtain the promised funds. ACH use also includes the possibility of being found to be irrecoverable payments (also known as "bad checks") after acceptance. Check guarantee providers can be used by merchants to reduce this risk. However, such providers usually charge a high percentage of the check amount, making this service potentially more expensive than credit or debit card payments.

[0008] Improvements in techniques for processing financial transactions are desirable. Summary of the invention

[0009] In one disclosed embodiment, a first method for processing a financial transaction at a payment network is disclosed. The method includes receiving a transaction request associated with an initiating user or financial institution account from an initiating device. The transaction request includes information associated with the initiating user or financial institution account. The method also includes determining an account identifier of the account based on the identification, and sending a financial services transaction including the account identifier associated with the account to a financial institution associated with the account over a network. The method also includes receiving a response to the financial services transaction from the financial institution, and sending a response to the transaction request to the initiating device.

[0010] A system for processing financial transactions is also disclosed. The system includes a processor system (ie, one or more electronic processors) and a memory storing instructions. When executed, the instructions cause the processor system to perform the above-mentioned first method.

[0011] In another disclosed embodiment, a second method for associating a financial institution account with an originator account is disclosed. The method includes receiving a request from a user device to associate a financial institution account with an originator account. The method also includes generating an association message including details about the financial institution account and sending the association message to a payment network. The method includes: receiving an association response; determining whether the association response includes a key associated with the financial account, and if so, storing the received key for initiating a transaction request and sending an indication to the user device that the accounts are associated.

[0012] A system for associating a financial institution account with an originator account is also disclosed. The system includes a processor system (i.e., one or more electronic funds transaction processors) and a memory storing instructions. When executed, the instructions cause the processor system to perform the above method.

[0013] In another disclosed embodiment, a third method for processing a transaction request is disclosed. The method includes receiving a transaction request from an associated device. The transaction request includes a request to initiate a transaction on behalf of a user and information about a financial account. The transaction request does not include an account number associated with the financial account. The method also includes incrementing a transaction counter associated with the financial account, determining a key associated with the financial account, and generating a financial services transaction message. The financial services transaction message includes a ciphertext. The ciphertext is based on the determined key, the information from the transaction request, and the transaction counter. The method also includes sending the financial services transaction message to a payment network for processing.

[0014] A system for processing financial transactions is also disclosed. The system includes a processor system (i.e., one or more electronic funds transaction processors) and a memory storing instructions. When executed, the instructions cause the processor system to perform the third method described above.

[0015] In another disclosed embodiment, a fourth method for processing a transaction request is disclosed. The method includes receiving a transaction request from an associated device. The transaction request includes a request to initiate a transaction on behalf of a user and information about a financial account. The method also includes incrementing a transaction counter associated with the financial account, determining a key associated with the financial account, and generating a financial services transaction message. The transaction message includes a ciphertext generated based on the determined key, the information from the transaction request, and the transaction counter. The method also includes sending the financial services transaction message to a payment network.

[0016] A system for processing financial transactions is also disclosed. The system includes a processor system (ie, one or more electronic funds transaction processors) and a memory storing instructions. When executed, the instructions cause the processor system to perform the fourth method described above.

[0017] In another disclosed embodiment, a fifth method for processing a transaction request is disclosed. The method includes receiving a transaction request from an initiator. The transaction request includes a ciphertext and does not include an account number of a financial institution account. The method includes determining a key associated with the financial institution account and verifying the ciphertext using the key associated with the financial institution account. The method also includes: determining an account identifier of the financial institution account; generating a transaction request based on information stored in the ciphertext and the determined account identifier; sending the transaction request to the financial institution; and receiving a response. The method also includes sending the response to the initiator.

[0018] A system for processing financial transactions is also disclosed. The system includes a processor system (ie, one or more electronic funds transaction processors) and a memory storing instructions. When executed, the instructions cause the processor system to perform the fifth method described above.

[0019] Additional aspects related to the embodiments will be set forth in part in the following description, and in part will be apparent from the description, or may be learned through practice of the embodiments. The accompanying drawings illustrate various embodiments and together with the description are used to explain the principles of the embodiments, and the accompanying drawings are incorporated into and constitute a part of this specification. It should be understood that both the foregoing general description and the following detailed description are exemplary and illustrative only and do not constitute limitations on the invention as claimed. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 An example network of devices for implementing embodiments of the present disclosure is illustrated.

[0021] Figure 2 Implementations of payment networks consistent with the disclosed implementations are illustrated.

[0022] Figure 3 An example process for processing a transaction request at a payment network consistent with the disclosed embodiments is illustrated.

[0023] Figure 4A An example process for initializing keys necessary for a transaction origination point (TOP) to operate in conjunction with a payment network consistent with the disclosed embodiments is illustrated.

[0024] Figure 4B An example process for associating a financial institution account with an originator user account consistent with the disclosed embodiments is illustrated.

[0025] Figure 4C An example optional process for associating a financial institution account with a user account using an initiating user is illustrated.

[0026] Figure 4D An example process for processing transactions using TOP consistent with the disclosed embodiments is illustrated.

[0027] Figure 5 An example computer system for implementing the disclosed embodiments is illustrated. DETAILED DESCRIPTION

[0028] Reference will now be made in detail to embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. Whenever possible, the same reference numerals will be used throughout the drawings to refer to the same or like parts.

[0029] Embodiments of the present disclosure enable, for example, the use of a payment network to process financial transactions. For example, a payment network may receive a transaction from an initiator such as a merchant or a bank. A transaction may include information associated with an identification of an initiating user or financial institution account. However, a transaction may not necessarily include an account number associated with a financial institution account. Using the identification information, the payment network is able to determine an account identifier and generate and send a financial services transaction request to the financial institution. The payment network is then able to receive a response to the financial services transaction request from the financial institution and is able to send a response back to the initiator. Other embodiments and variations are described herein.

[0030] Figure 1 An example of a specific network for implementing embodiments of the present disclosure is illustrated. Figure 1 The illustrated network includes blocks representing an originating user 101, an originator 102, a processor 103, a payment network 105, a database 105A, a receiver processor 106, a receiver 107, a customer information file (CIF) 107A, an external receiver processor 108, an external receiver 109, and a CIF 109A. Figure 1 The various blocks illustrated in the figure may be implemented using software, hardware, firmware, or a combination thereof.

[0031] Initiating user 101 represents a user who wants to initiate a transaction using initiator 102. Initiating user 101 uses a device, such as a mobile phone or a computer, that can store and execute a transaction origination application in some embodiments. The application enables initiating user 101 to cause a transaction, such as an online purchase, a bill payment, etc. The transaction origination application also enables the sending of credentials associated with initiating user 101 initiating such a transaction. Initiating user 101 represents a customer who provides a payment device or token (e.g., a username or other identifier) ​​to initiator 102 in other embodiments to facilitate the transaction.

[0032] Originator 102 represents an entity that initiates a financial services transaction request on behalf of initiating user 101. Financial services transaction requests can take many forms. In some embodiments, requests can include balance requests (requests for current balances in accounts), check authorization requests (to determine whether an account has sufficient funds for purchases made by checks), account funding requests (to request that a current account be used to fund a new account), account verification or health requests (to determine whether information about a financial institution account provided by initiating user 101 is valid, open, in collection, in good standing, etc.), international remittance funding requests, bill payment funding requests, person-to-person (P2P) fund transfer requests, withdrawal requests, purchase requests, refund requests, various lender requests (loan proceeds, insurance proceeds, etc.), transaction reversal / adjustment requests, etc.

[0033] The initiator 102 may be any of a financial institution, an electronic funds transfer (EFT) network, a merchant or merchant processor, a remittance platform, a payment service, a mobile wallet provider, a mobile prepaid remittance service, and the like. Financial institutions include, for example, banks, savings banks, credit unions, brokerage companies, or mutual fund providers. Financial institutions can, for example, process transactions on behalf of the initiating user 101 or other entity or transfer money between accounts at the financial institution and / or accounts outside the financial institution. Unlike payment networks, financial institutions manage accounts on behalf of users, for example, by maintaining records of deposits and withdrawals on the account and maintaining records of balances on the account.

[0034] Merchants include, for example, traditional merchants, online or electronic merchants, or service providers that bill users for services, such as wireless telephone carriers, utility companies, insurance providers, or local, state, or federal government entities. In some embodiments, merchants are equipped to personally initiate financial services transactions. However, in other embodiments, merchants can use merchant processors for that purpose. The merchant processor receives financial transaction details from the merchant and generates corresponding financial services transactions on behalf of the merchant. In other words, the merchant can transmit the financial transaction details to the merchant processor, and the merchant processor can create a financial services transaction for sending to the payment network.

[0035] EFT networks include interbank networks and other electronic funds transfer networks that enable funds to be transferred between different banks. EFT networks, in some implementations, transfer money using batch Automated Clearing House (ACH) transactions.

[0036] Remittance platforms include systems for sending money from person to person. As an example of a known remittance platform, the Western Union system enables a person to deposit money into the system and enables another user to withdraw money at another location within the system. A person of ordinary skill will appreciate that other types of remittance platforms are also possible.

[0037] The mobile wallet provider includes a system that enables the initiating user 101 to use a mobile device to send account details (such as routing transit number (RTN) and account number or account alias information) to the merchant. In some embodiments, the mobile wallet provider provides the initiating user 101 with a mobile application that enables the initiating user 101 to initiate a transaction with the merchant or initiator.

[0038] The initiator 102 receives an instruction from the initiating user 101 requesting that a financial transaction occur. The initiator 102 generates and sends a financial services transaction to another device or entity, the request including information associated with the financial services transaction requested by the initiating user 101. As an example, the initiator 102 (e.g., a first financial institution) may receive an instruction from a cardholder to send money to an account at a second financial institution. The initiator 102 generates the financial services transaction and sends it to the processor 103.

[0039] Originator 102 may receive credentials from initiating user 101 to initiate a financial services transaction. The credentials from initiating user 101 include one or more forms of information used to identify initiating user 101. The credentials can include a physical token (such as an electronic device or payment card-like mechanism), information that initiating user 101 knows (such as a social security number, user name, email address, date of birth, password or PIN, etc.), information that initiating user 101 has (such as a dynamically generated string of characters), etc.

[0040] In some embodiments, the initiator 102 represents an entity that the initiator user 101 contacts in advance in order to register as a user. The initiator user 101 may provide credential information such as information associated with a deposit account at a financial institution or identification information such as name, address, social security number, or date of birth in order to register with the initiator 102. This registration process may include the initiator user 101 establishing new credential information for the relationship between the initiator user 101 and the initiator 102 (such as a user ID and password established specifically for initiating a transaction with the initiator 102). Thereafter, when an instruction for a financial transaction is received from the initiator user 101, the initiator user 101 is able to provide those credentials to the initiator 102, the initiator 102 is able to perform a lookup in a database to determine the information necessary to process the instruction, and the initiator 102 may then determine how to initiate a corresponding financial services transaction, and may generate a financial services transaction request corresponding to the transaction.

[0041] In some embodiments, originator 102 may be a "sponsored entity." A sponsored entity is an entity that is not a financial institution, but is "sponsored" by a financial institution that has a relationship with payment network 105. The financial institution that "sponsors" the sponsored entity assumes all liability for the actions or inactions of the sponsored entity, including all payment network transactions initiated by the sponsored entity. An example of a sponsored entity would be a merchant. Liability for settlement of funds associated with a transaction would be assumed by the financial institution that sponsors the merchant.

[0042] In one mode of operation, "native mode", the initiator 102 creates a financial services transaction request that complies with a known standard (e.g., the ISO 8583 standard). ISO 8583 is a standard communication format for systems that exchange electronic transactions conducted by cardholders using payment cards. In a typical ISO 8583 message, a primary account number (PAN) (such as, for example, a card number corresponding to an account that a user is using to pay for a purchase) is included in a field called a "PAN field". In some embodiments, this PAN field can vary in length from 13 to 19 digits. In some embodiments, the payment card and payment number are not used by the initiator 102 to process financial services transactions. In these embodiments, the initiator 102 generates a financial services transaction request that complies with the ISO 8583 standard but does not include the payment card number in the PAN field. In native mode, the financial services transaction request includes replacement information in the PAN field. This information is called "RTA" ("routing transit and account number"; also known as "account routing number" (ARN) or "constructed PAN"). The RTA includes a value (e.g., '59') that indicates that the digits following the value should be interpreted as account information rather than a card number. The RTA also includes account information identifying at least one cardholder's account. The RTA may be stored in a financial services transaction request as:

[0043] 5 9 x x x x x x x x x y y y y y y y y

[0044] Each 'x' in the above table symbolizes a digit in a routing transit number ("RTN", also known as an "American Banking Association Number" or "ABA Number") associated with the financial institution that manages or maintains the account of the originating user 101. Each 'y' in the table indicates a digit of an account associated with the originating user 101. In some embodiments, the full account number is included in the RTA, while in other embodiments only a portion of the account number (such as the rightmost eight digits of the account number) is stored in the string, with the remaining digits of the account number or the account number itself included in another field within the financial services transaction. The length and composition of the RTA may vary in some embodiments.

[0045] If initiating user 101 initiates a financial services transaction through originator 102 to pay for a purchase, the 'x' digits in the RTA may include a routing number associated with initiating user 101's account, and the 'y' digits in the RTA may include at least some of the account numbers associated with initiating user 101's account.

[0046] In the second mode "cross reference" or "X-REF", the initiator 102 generates a financial services transaction request including identification information associated with a financial institution account. However, neither the RTN nor the account number is included in the financial services transaction request. Instead, the identification information can be included in the form of an account access token (AAT). The AAT enables the unique identification of a user's account at a financial institution but does not directly include the account information of the account. Instead, the AAT includes identification information such as a username, personal identification information (e.g., social security number, name, address, email address, telephone number, login ID), a substitute account number (e.g., a number similar to a valid account number but not the actual account number of the account), etc. The AAT can be generated by various entities on behalf of the initiating user 101. For example, in some embodiments, the AAT is generated by the initiator 102, the payment network 105, the recipient 107, or an external recipient 109. In other embodiments, the AAT is generated by another entity such as a central bank or monetary authority (e.g., the Federal Reserve or the European Central Bank). In other embodiments, the AAT is generated by a party authorized by payment network 105 to generate the AAT (an “authority party”).

[0047] In some embodiments, the financial services transaction request may be generated in XML format, or in accordance with a standard such as ISO 20022 or ISO 8583. The financial services transaction request generated by the initiator 102 includes one or more types of transactions. Although some examples are provided herein, the skilled person will appreciate that other types of financial services transactions can be generated by the initiator 102.

[0048] As a first example, a financial services transaction request generated by initiator 102 indicates a request for the current balance of an account referenced by initiator user 101. If initiator 102 is a merchant, initiator user 101 may attempt to pay for a purchase using a check. Initiator 102 may generate a request to determine whether it should honor the check. The transaction request may include the amount of the check that initiator user 101 has written and provided to initiator 102 for payment and an identifier associated with the account. Initiator 102 may receive a response as to whether the check will clear in a timely manner based on the funds available at that moment, and may be able to deny or approve the transaction from initiator user 101.

[0049] As a second example, the financial services transaction request generated by the initiator 102 indicates a request for verifying the ownership or existence of a specific account. In this example, the initiator user 101 may attempt to associate an account at the initiator 102 with a financial institution account (e.g., a bank account) owned by the initiator user 101. The initiator user 101 may provide the initiator 102 with financial institution account details (e.g., account number) to facilitate the establishment of the initiator account. The initiator 102 may generate a request for verifying the existence and / or ownership of the financial institution account. The transaction request may include an entity associated with the financial institution account. The initiator 102 may then receive a response confirming or denying that the financial institution account exists and / or is actually owned by the initiator user 101. If confirmed, this enables the initiator user 101 to initiate a transaction using the account at the initiator 102.

[0050] As a third example, the financial services transaction request generated by the initiator 102 indicates a request for sending credit to an account cited by the initiator user 101. If the initiator 102 is a remittance platform (e.g., a platform for sending money from one person to another), the initiator user 101 can request a specific amount of money to be deposited in the cited account or to be provided to the second user via another payment method. The initiator user 101 can give the initiator 102 the details of the destination account, such as RTN and account number, the user name or address associated with the second user, or other information associated with the destination account or its owner. The initiator 102 can generate a request for providing credit to the account cited by the initiator user 101 or providing the requested funds to the second user. The transaction request can include the identity of the account and the initiator user 101 hopes that the amount of money that will provide credit to the account. The initiator 102 can then receive a response indicating whether the credit is successful.

[0051] As a fourth example, a financial services transaction request generated by the initiator 102 indicates a request to debit funds from an account referenced by the initiating user 101. In this example, the initiating user 101 may attempt to pay a bill issued by the initiator 102 by providing account information. The initiating user 101 may give the initiator 102 details of the source account, such as the RTN and / or account number. The initiator 102 may generate a request to debit the account referenced by the initiating user 101. The transaction request may include the identity of the account and the amount that the initiating user 101 wishes to debit the account. The initiator 102 may then receive a response indicating whether the debit was successful.

[0052] As a fifth example, the financial services transaction request generated by the originator 102 includes an exception request. In some embodiments, the originator 102 can generate an exception request when it is determined that there is a discrepancy between the settlement amount received from the payment network 105 and the amount that the originator 102 believes it should have received. For example, the originator 102 can initiate an adjustment exception request (a request to correct the financial condition of the originator 102 based on an error associated with a specific transaction within ten calendar days of the settlement date of the transaction), a redraw exception request (a dispute of a chargeback initiated by the recipient 107), a good faith adjustment request (a request to correct the balance of the originator 102 based on an error associated with a specific transaction, for example, more than 45 days after the settlement date of the transaction), a post-adjustment exception request (a request to correct the balance of the originator 102 based on an error associated with a specific transaction, for example, more than 10 days but within 45 days after the settlement date of the transaction), etc.

[0053] The initiator 102 may also be associated with one or more transaction initiator points (TOPs). A TOP enables the initiator user 101 to send information about an account owned by the initiator user 101 to the initiator 102 and to implement transactions using the initiator 102. So, for example, if the initiator 102 provides a mobile wallet for use by a user, the associated TOP may be a wallet provider application that receives instructions to pay for purchases on a mobile device. As another example, if the initiator 102 is a wireless service provider, the associated TOP may be a bill payment website or a bill payment application implemented on a website. As another example, if the initiator 102 is a financial institution, the associated TOP may be an in-branch account access terminal (e.g., an automated teller machine or ATM) or a funds transfer website. In addition, in some embodiments, an initiator account at the initiator 102 may be accessed through a TOP associated with the initiator 102 (and may then be referred to as a "TOP user account").

[0054] In some embodiments, the initiator 102 may also store a payment instrument key (PIK) associated with the account referenced by the initiating user 101. In some embodiments, the PIK may be generated by the payment network 105 or another entity using a key associated with the initiator 102 and a key associated with the recipient 107. The initiator 102 can utilize the PIK when generating a financial services transaction request on behalf of the initiating user 101.

[0055] Processor 103 may be programmed to receive financial services transactions from originator 102. Processor 103 may be implemented as a device specifically programmed to receive financial services transaction requests, determine an appropriate payment network for forwarding the transaction request, and forward the transaction request to the determined payment network. Processor 103 may receive settlement requests on behalf of originator 102, reformat messages to and from payment networks into messages that can be processed by originator 102 in its format, maintain a database (e.g., containing data about users and / or associated accounts) on behalf of originator 102, handle exceptions on behalf of originator 102, etc. In some embodiments, processor 103 and originator 102 may have a contractual relationship with each other and / or with payment network 105.

[0056] In some embodiments, the payment network 105 is an interbank network that enables various devices (such as automated teller machines (ATMs), mobile wallet providers, point of sale (POS) devices, merchants, TOPs, etc.) to communicate with each other and access financial institution accounts. The payment network 105 can be, for example, local, national, or international in scope. The payment network 105, in some embodiments, sends financial service transactions to the recipient processor 106 or the recipient 107 to request account ownership, balance information, or the holding, crediting, or transfer of funds associated with the financial transaction and verification of its corresponding account holder.

[0057] In some embodiments, the payment network 105 performs a settlement process as part of processing a financial services transaction. In some embodiments, when the payment network 105 receives a transaction request, the payment network 105 calculates the amounts that need to be transferred between the parties and will "settle" the net of those amounts. As an example, if the initiating user 101 initiates a transaction to pay $100.00 to the second user and the second user initiates a transaction to pay $80.00 to the initiating user 101, the payment network 105 will combine the two transaction amounts to determine a net settlement amount, which represents the amount of money that must be debited and credited to the financial institutions representing the respective users. In this example, each financial institution provides (or "credits") the full amount of each individual transaction (i.e., the example $100.00 and $80.00) as a debit to the respective account of each user, and the payment network 105 will initiate a debit entry of $20.00 to one financial institution and a credit entry of $20.00 to another financial institution to achieve the appropriate net settlement between the two parties. The payment network 105 enables funds to move between parties by preparing automated clearing house (ACH) files, which are initiated by an ACH bank associated with the payment network 105 to the respective financial institutions, issuer processors, merchants / merchant processors, EFT networks, remittance platforms, etc. of each user. These ACH files reflect the net settlement amounts to be settled between the parties involved in the transaction flow. The amount balances of each user are debited or credited as a result of approved online transaction requests. In some embodiments, settlement entries in such ACH files are created at the end of a specific time period (such as, for example, a 24-hour period between 3:30 PM local time of one day and 3:30 PM of the next day).

[0058] In some embodiments, the payment network 105 performs a conversion process for routing the financial services transaction request to a financial institution or other recipient. Based on the information in the received financial services transaction request, the payment network 105 is able to determine whether additional or alternative information is needed to route the request. For example, if the financial services transaction request includes an AAT (account access token) associated with the initiating user 101, and the transaction request indicates the use of "X-REF mode", the payment network 105 can use the database 105A to determine the RTN and account number associated with the initiating user 101 based on the AAT in the financial services transaction request. The payment network 105 can also use the database 105A to determine an account identifier that does not include an account number but is associated with an account referenced in the financial services request.

[0059] If the received financial services transaction includes an RTN and an account number and indicates the use of "native mode", payment network 105 can use database 105A to determine whether the received RTN and account number are associated with an alternative RTN or account number. Payment network 105 can also determine that the financial services transaction request was not generated in X-REF mode and it does not require an alternative RTN or account number, and can assume that the received RTN and account number are actual numbers associated with the account of initiating user 101. In such a situation, payment network 105 can route the financial services transaction request to another payment network (not shown) for processing.

[0060] The payment network 105, in some embodiments, also generates keys for processing financial services transaction requests. For example, the payment network 105 may generate a service provider master key (SPMK) corresponding to the initiator 102 or an associated transaction origin point (TOP), may utilize the SPMK to generate a participant authentication key (PAK) associated with a financial institution (such as the receiver 107), and may utilize the PAK to generate a payment instrument key (PIK) associated with an account in a financial account (such as an account owned by the initiating user 101). In some embodiments, the payment network 105 may include a hardware security module (HSM) to generate and store these keys. The HSM may be implemented in hardware, software, firmware, or a combination thereof.

[0061] The receiver processor 106 is an entity that receives financial transaction requests from the payment network 105. In some embodiments, the receiver processor can be implemented as a payment gateway or electronic funds transfer network that is programmed to forward financial services transactions to the receiver 107. The receiver processor 106 receives the financial services transaction, determines the appropriate receiver (such as a financial institution or entity holding account information, etc.), and sends the financial transaction request to the receiver. In some embodiments, the receiver processor 106 enables communication with financial institutions or other account holder companies that have contracts with the receiver processor 106 for online transaction processing services.

[0062] Receiver 107 represents an entity that receives a financial services transaction request. In some embodiments, receiver 107 is a financial institution. Financial institutions include, for example, banks, savings banks, credit unions, brokerage firms, or mutual fund providers. Financial institutions can, for example, process transactions or transfer money between accounts at financial institutions and / or accounts outside of financial institutions. Unlike payment networks, financial institutions manage accounts on behalf of users, for example, by maintaining records of deposits and withdrawals on accounts and maintaining records of balances on accounts.

[0063] In some embodiments, receiver 107 receives the financial services transaction requests directly from payment network 105. In other embodiments, receiver 107 receives the financial services transaction requests from receiver processor 106, which receives them from payment network 105.

[0064] In some embodiments, the recipient 107 initiates a financial services transaction request including an exception request. For example, the recipient 107 can generate and send a financial services transaction request including a chargeback exception request (indicating that the financial services transaction request corresponding to the debit or credit is erroneous and should be reversed or repaid in whole or in part) or a chargeback revocation exception request (indicating that the chargeback exception request originally initiated by the initiator is erroneous and should be reversed).

[0065] Customer Information File (CIF) 107A, for example, contains information about accounts held by Recipient 107. (An account is "held" by Recipient 107 if the account and / or its funds are maintained by Recipient 107.) CIF 107A includes account owner information such as name, address, zip code, date of birth, Social Security / Taxpayer Identification Number, phone number, email address, workplace address, driver's license number, token information, username / password, etc. Recipient 107 uses CIF 107A to verify / authenticate ownership of an account held by Recipient 107 when requested by an entity such as Originator 102.

[0066] External receiver 109 represents a company located in a country other than the country in which payment network 105 is located. External receiver 109 communicates with payment network 105 either directly or through its external receiver processor 108. Payment network 105 may cause international financial services transaction requests to be processed (e.g., a request for a debit from an initiating user 101 to an account at external receiver 109). External receiver processor 108, which may be located in a country other than the country of payment network 105, may receive financial services transaction requests on behalf of external receiver 109 and forward them to external receiver 109 for processing. External receiver processor 108 may also represent a company that pays remittances directly to recipients instead of forwarding requests to external receiver 109.

[0067] Figure 2 An embodiment of a payment network 105 consistent with the disclosed embodiments is illustrated. The payment network 105 includes a switch 201, a portal 202, a settlement engine 203, and an integration engine 204. Figure 2 The various blocks illustrated in the figure may be implemented using software, hardware, firmware, or a combination thereof.

[0068] The switch 201 receives financial services transactions from, for example, an initiator and a processor. The switch 201 may be implemented using software, hardware, firmware, or a combination thereof. In some embodiments, the switch 201 determines information about the financial services transaction, such as, for example, the mode of the financial services transaction (e.g., X-REF or native mode) and where the request should be routed based on the information. The switch 201 may also send information to any one of the portal 202, the settlement engine 203, and the integration engine 204, and receive information from any one of the portal 202, the settlement engine 203, and the integration engine 204. The switch 201 may also receive transactions originating from devices such as automated teller machines (ATMs) or POS devices, communicate with other payment networks (e.g., for forwarding financial services transactions or receiving forwarded financial services transactions), etc. In some embodiments, the switch 201 may be implemented using electronic funds transfer payment software on a fault-tolerant, self-healing platform. For example, the switch 201 may be implemented using FIS CONNEX software implemented on an HPNONSTOP platform.

[0069] The portal 202 is an access point for an initiator, processor, recipient processor, recipient, external recipient processor, or recipient to initiate and receive exception requests, retrieve files sent by the payment network 105, or access supporting documents issued by the payment network 105. The portal 202 enables initiators and recipients to retrieve reports on activities conducted using the payment network 105. For example, initiators and recipients can retrieve daily settlement reports, exception transaction reports, and expense invoices. Initiators, recipients, and processors can also view transaction histories, send negative documents (indicating, for example, specific users who should be blocked from receiving or sending communications through the payment network 105), etc. The portal 202 can be implemented using software, hardware, firmware, or a combination thereof.

[0070] The settlement engine 203 enables the switch 201 to settle transaction requests received from the initiator and the processor. In some embodiments, the settlement engine 203 performs a periodic settlement process, wherein the settlement engine 203 calculates the net amount that needs to be transferred between the parties based on the approved transactions, and generates an ACH file with entries corresponding to the net amount of funds that need to be moved between the settlement accounts. The settlement engine 203 then generates the ACH file and related reports. The ACH file is sent to the ACH bank associated with the payment network 105 to obtain settlement. Related reports are made available for retrieval and sent to the appropriate parties or made available through the portal 202.

[0071] In some embodiments, the settlement engine 203 performs such a settlement process on a daily basis for all transaction requests received during a particular 24-hour period. For example, at 3:30 PM Eastern Standard Time each day, the settlement engine 203 may perform a settlement process for all transaction requests that required the movement of funds (including abnormal transactions) received prior to 3:30 PM Eastern Standard Time that day. The settlement engine 203 may then generate an ACH entry file indicating the net result of the settlement process.

[0072] Settlement engine 203 may receive transaction messages from switch 201. These transaction messages may be received in real time, periodically in batches throughout the day, or at the end of a 24 hour period. Settlement engine 203 may also perform integrity checks on those transaction messages and prepare ACH files corresponding to the calculated "net settlement" value. Net settlement means that for every debit entry in one settlement account, there is a corresponding credit entry in at least one other settlement account.

[0073] The settlement engine 203 may be implemented using software, hardware, firmware, or a combination thereof. In some implementations, the settlement engine 203 may be implemented using electronic funds transfer settlement software on a host platform. For example, the settlement engine 203 may be implemented using FIS CONNEX software implemented on an IBM platform.

[0074] The integration engine 204 may be a system (such as a device or software) for integrating and aggregating information from various sources. The integration engine 204 may enable the switch 201 to communicate with various other services that are not necessarily implemented as part of the payment network 105. For example, the integration engine 204 may provide communications with fraud and compliance systems, third-party payment providers, bank teller systems, person-to-person payment systems, etc. The integration engine 204 may enable interconnectivity of third-party applications, publishing services, and the payment network 105. The integration engine 204 may also be programmed to enable auditing, logging, monitoring, routing, and security processes related to processing data from these sources, third-party applications, and the payment network 105. The integration engine 204 may be implemented using software, hardware, firmware, or a combination thereof.

[0075] Figure 3 An example process 300 for processing a financial services transaction consistent with the disclosed embodiments is illustrated. The process 300 begins at step 301, where an initiator 102 receives a transaction request from an initiating user 101. For example, the initiator 102 can receive a transaction request from the initiating user 101 to pay for a good or service. The initiating user 101 can reference an account for the transaction. In some embodiments, the initiating user 101 can provide an RTN and an account number associated with the account, an AAT (account access token) associated with the user / account, etc.

[0076] The initiator 102 may generate a financial services transaction request including the information provided by the user. The financial services transaction request may also include information about the purpose of the financial services transaction request. For example, the transaction request may include any of the following: a request for the current balance of an account owned by the initiating user 101, a request to verify ownership of an account referenced by the initiating user 101, a request to deposit funds into an account referenced by the initiating user 101, a request to withdraw funds from an account referenced by the initiating user 101, etc.

[0077] In step 302, the initiator 102 sends the generated financial services transaction request to the payment network 105. In some embodiments, the initiator 102 sends a request to a processor (such as Figure 1 In some embodiments, the initiator 102 sends the request to the processor 103 for forwarding to the payment network 105, but in other embodiments, the initiator 102 sends the request directly to the payment network 105.

[0078] In step 303, the payment network 105 determines whether the financial services transaction request was generated using the X-REF mode or using the native mode. The payment network 105 makes this determination based on information contained in the financial services transaction request. For example, if the request contains an RTN number, a bank account number, a portion of a bank account number, a card type number, or other number indicating that the financial services transaction request was generated in the native mode, the payment network 105 can determine that the request was generated using the native mode and can proceed to step 304 for further processing of the request. Otherwise, if the payment network 105 determines that the financial services transaction request includes an AAT (account access token), such as a username, personal identification information (e.g., social security number, name, address, email address, phone number, etc.), a substitute account number (e.g., an account number that resembles a valid account number but is not the actual account number of the account), etc., the payment network 105 can determine that the request was generated using the X-REF mode and can proceed to step 309 for further processing of the transaction.

[0079] If the payment network 105 determines that the request was generated using native mode, then in step 304, the payment network 105 determines whether the financial services transaction request includes an RTA (routing and account number) with a specific indicator value. The indicator value can be stored at the beginning of the PAN field within the request in some embodiments. In some embodiments, the indicator value can be selected so that it can be distinguished from the initial value associated with the payment card to avoid conflicts with payment card transactions. For example, VISA cards have a '4' at the beginning of their card numbers and AMERICAN EXPRESS cards have a '3' at the beginning of their card numbers. The indicator value can be selected to avoid conflicts with other card providers. In some embodiments, the indicator value is '59'.

[0080] If the received financial services transaction request does not include an RTA with an indicator value, process 300 may continue to step 305, where payment network 105 forwards the financial transaction request to an electronic funds transfer (EFT) or other payment network for forwarding to a final destination (e.g., recipient 107). However, if payment network 105 determines in step 304 that the RTA in the financial transaction request includes an indicator value, process 300 continues to step 306.

[0081] In step 306, payment network 105 determines an appropriate financial institution based on the information received in the financial services transaction request. There are multiple ways to determine an appropriate financial institution. For example, payment network 105 may determine a financial institution based on the RTN included in the financial services transaction request. As another example, payment network 105 may consult a database such as Figure 1 The database 105A in the payment network 105A) determines the substitute RTN corresponding to the data in the request. After the payment network 105 determines the appropriate RTN, the process 300 continues to step 307.

[0082] In step 307, payment network 105 determines the account number associated with the initiating user based on the information received in the financial services transaction request. There are multiple ways to determine the appropriate account number. For example, payment network 105 may determine that the entire account number is included in the request. As another example, the financial services transaction request may include only a portion of the account number, such as the leftmost eight digits. In that case, payment network 105 may consult a database (such as Figure 1 The payment network 105 may consult database 105A to determine the remaining digits of the account number. As another example, the account number included in the request may include a non-existing account number and / or a substitute for the actual account number. In those cases, the payment network 105 may consult database 105A to determine the substitute account number.

[0083] In some embodiments, step 307 represents payment network 105 determining an account identifier associated with the ARN and the account. In some embodiments, this account identifier does not include the account number associated with the account. The recipient that manages the account stores the correspondence between the account identifier and the actual account number associated with the account (e.g., stored in association with each other in a database).

[0084] After the payment network 105 determines the appropriate account number or account identifier, the process 300 proceeds to step 308. In step 308, the payment network 105 generates a new financial services transaction request. This request includes information from the received financial services transaction request and any determined substitute RTN, account number or account identifier. The payment network 105 sends the generated financial services transaction request to the recipient / receiver processor associated with the determined RTN.

[0085] If in step 303, the payment network 105 determines that the financial services transaction request is generated using the X-REF mode, the process 300 continues to step 309. In step 309, the payment network 105 consults the conversion file to determine the account information associated with the financial services transaction. In the X-REF mode, the financial services transaction request includes identification information associated with the account number and / or RTN. However, neither the RTN nor the account number is included in the financial services transaction. Alternatively, the identification information can be in the form of an AAT (account access token). The AAT enables the identification of a user's account at a financial institution without an account number associated with the financial institution. The AAT includes identification information such as a user name, personal identification information (e.g., social security number, name, address, email address, telephone number, etc.).

[0086] Payment network 105 may consult the conversion file to determine the RTN and account number pair associated with the AAT in the financial services transaction. In some embodiments, the conversion file may be stored in a database (such as a database) accessible by payment network 105. Figure 1 In the database 105A).

[0087] In some embodiments, step 309 represents payment network 105 determining an account identifier associated with the AAT and the account. In some embodiments, this account identifier does not include the account number associated with the account. The recipient that manages the account stores the correspondence between the account identifier and the actual account number associated with the account (e.g., stored in association with each other in a database).

[0088] Process 300 may then proceed to step 310. In step 310, payment network 105 generates a financial services transaction. This transaction may include information from the received financial services transaction as well as the determined RTN and account number or determined account identifier. Payment network 105 then sends the generated financial services transaction to the determined recipient.

[0089] Regardless of the information in the financial services transaction request received in step 302, in step S311, the payment network 105 receives a response from the recipient determined in one of steps 305, 308, or 310. The response may include information related to the financial services transaction request and may represent an "answer" from a recipient processor, recipient, external recipient, or external recipient processor related to the account referenced in the request.

[0090] The response includes one or more indications about the account. Possible indications of various types may include: an indication that the available balance is less than (or exceeds) the amount in the transaction request; an indication that the ledger balance is less than (or exceeds) the amount in the transaction request (the ledger balance differs from the available balance by any pending debits or credits on the account); an indication of the actual current ledger or available balance; an indication of the health of the account (e.g., whether the account is open and / or in good standing); an indication of how long the account has been open; an indication of any negative history associated with the account; an average balance range; an indication of verification of the identity / account ownership information provided by the initiating user; data indicating the name, address, or date of opening of the account owner; or other information about the owner or account.

[0091] Figure 4A An example process 400 for initializing keys necessary for a transaction origination point (TOP) 402 to operate in conjunction with a payment network 105 is illustrated consistent with the disclosed embodiments. TOP 402 represents an originator (such as a payment network 105) for the purpose of processing transactions initiated by users using payment network 105. Figure 1 A device or mechanism through which an initiator 102 in receives data about a user.

[0092] Each originator may have one or more of TOPs 402 associated with it for processing transactions initiated by users. So, for example, if the originator provides a mobile wallet for use by the user, TOP 402 may be a wallet provider system that receives instructions to pay for purchases. As another example, if the originator is a wireless service provider, TOP 402 may be a bill payment website or a mobile bill payment application. As another example, if the originator is a financial institution, TOP 402 may be a teller desk, a kiosk, an in-branch account access terminal (e.g., an automated teller machine or ATM), or a funds transfer website.

[0093] Process 400 enables TOP 402 to establish an authenticated relationship with payment network 105 in a secure manner. This relationship enables those associated with TOP 402, such as users, merchants, remittance platforms, EFT networks, or financial institutions, to use TOP 402 to securely initiate financial transactions with payment network 105. In step 401, TOP 402 sends a request to payment network 105 requesting initialization of an authenticated connection between TOP 402 and payment network 105.

[0094] In some embodiments, the request sent in step 401 also includes a request to establish a key exchange key (KEK) for exchanging information between TOP 402 and payment network 105. TOP 402 and payment network 105 can implement a process for establishing a KEK. For example, TOP 402 and payment network 105 can implement a known Diffie-Hellman key exchange algorithm. However, a specific method for generating a system for a KEK is not required in all embodiments.

[0095] Process 400 then proceeds to step 403. In step 403, payment network 105 generates a service provider master key (SPMK). TOP 402 has an SPMK generated by payment network 105. In some embodiments, the SPMK can be generated using a random or pseudo-random number generator or a key generation algorithm. In addition, in some embodiments, no two TOPs will have the same SPMK. However, in other embodiments, TOPs associated with the same initiator can share an SPMK.

[0096] In step 403, the payment network 105 may also generate a KEK. The KEK may be utilized to securely exchange information between the TOP 402 and the payment network 105, and may be generated using a random or pseudo-random number generator or a key generation algorithm. The payment network 105 may also generate a token key (TK). The TK enables the TOP 402 to encrypt specific elements in a financial services transaction request. In some embodiments, the TK may be used to encrypt data elements for which distribution should be restricted, such as account numbers, account identifiers, PANs, or other sensitive information.

[0097] In step 405, the payment network 105 encrypts the generated SPMK and stores it in a hardware security module (HSM). In some embodiments, the HSM generates encryption and decryption keys, stores encryption and decryption keys and other data, encrypts and decrypts data using the stored keys, and generates a "master file key" (MFK) for encrypting other encryption and decryption keys. The HSM can be implemented in hardware, software, firmware, or a combination thereof. In some embodiments, the payment network 105 can encrypt the SPMK using the MFK associated with the HSM. In step 405, the payment network 105 can also store the generated KEK (or a portion thereof) and TK in the HSM. The payment network 105 can also send the KEK and TK to the TOP 402, which receives it in step 406. In some embodiments, the TOP 402 stores the KEK and TK in its own HSM.

[0098] Figure 4B An example process 408 for associating a financial institution account with a TOP user account according to the disclosed embodiment is illustrated. In step 407, the initiating user 101 operates a device, such as a computer or mobile device, to associate a financial institution account (e.g., a deposit account) with a TOP user account. In step 409, TOP402 receives a request from the initiating user 101 to associate a financial institution account with a TOP user account, and generates an account authentication request message to associate the financial institution account with the TOP user account for sending to the payment network 105. The request includes information about the financial institution account. This includes, for example, an RTN and account number pair, RTA, a primary account number (PAN) such as a card type number, an account access token (AAT), etc. TOP 402 then forwards the account authentication request message to the payment network 105.

[0099] Payment network 105 may operate Figure 4C , which enables a higher level of security for user 101 and TOP 402 when associating a financial institution account with a TOP user account. (This process may be provided to TOP 402 as an optional service or for an additional fee.) If payment network 105 operates this optional process on behalf of TOP 402, the process continues to Figure 4C However, if the payment network does not operate Figure 4C If the optional process illustrated in is not present, the process instead continues to step 411 .

[0100] In step 411, the payment network 105 receives and processes the account authentication request message. The payment network 105 uses a hardware security module (HSM) to generate a participant authentication key (PAK). The PAK can be generated by encrypting information about the following financial institution, that is, the financial institution that manages the initiating user 101 and wishes to be associated with the TOP user account, using a service provider master key (SPMK) stored in the HSM and associated with the TOP 402 as a key. In some embodiments, this information encrypted using the SPMK includes an RTN, a bank identification number (BIN), or other identifier related to the financial institution. In some embodiments, the algorithm used to encrypt and generate the PAK information is Triple-DES (3DES).

[0101] In step 413, payment network 105 generates a payment instruction key (PIK) using the HSM. In some implementations, the PIK can be generated by generating a keyed cryptographic hash (also known as a "message authentication code" or "MAC") of information about a financial institution account using the PAK generated in step 411 as a key. For example, the PIK can be generated by hashing a bank account number associated with the account, a PAN associated with the account, or other identifier associated with the account.

[0102] In step 415, payment network 105 encrypts the PIK using a key exchange key (KEK). The KEK is encrypted during an earlier process (e.g., in Figure 4A ) between TOP 402 and payment network 105.

[0103] In step 417, payment network 105 generates a response including the encrypted PIK and sends it to TOP 402. In step 419, TOP 402 receives and processes the response message including the PIK. TOP 402 then decrypts the PIK using the KEK and stores the PIK in a hardware security module (HSM) operated by TOP 402. In step 421, TOP 402 sends a message to initiating user 101 indicating that the request to associate a financial institution account with a TOP user account is approved. TOP 402 is then able to utilize the PIK to initiate a financial services transaction request on behalf of initiating user 101.

[0104] Figure 4C An example optional process 424 for associating a financial institution account with the user account of the initiating user 101 is illustrated. As explained above, if the payment network 105 Figure 4C If the process is provided as an optional service to TOP 402, the process will be Figure 4BContinue after step 409 in step 425. Figure 4B 409 in the process, during which TOP 402 receives a command to associate a financial institution account (e.g., a deposit account) with a TOP (transaction origin point) user account. In response, TOP 402 generates a request and sends the request to initiating user 101. The request includes a prompt for a specific piece of information (referred to as a "snippet") known to both initiating user 101 and financial institution 413. Example snippets requested from initiating user 101 include the current balance in the account, specific digits of the social security number / taxpayer identification number associated with initiating user 101 (such as the last five digits), the card verification value (CVV) from the back of the payment card associated with the account, specific digits of the phone number associated with initiating user 101 (such as the first three digits after the area code), a shared secret between initiating user 101 and financial institution 413 (such as a password), etc.

[0105] In step 427, the initiating user 101 receives the snippet request and enters the snippet on the device for sending to TOP 402. In some implementations, the response sent in step 427 is sent in clear text to TOP 402. However, in other implementations, the initiating user 101 encrypts, scrambles, or otherwise obfuscates the information before generating and sending the response to TOP 402.

[0106] In step 429, TOP 402 receives the response and inserts the received fragment (in plain text, hashed, encrypted, or other form) into the Figure 4B The authentication request message generated in step 409 of . In some embodiments, the authentication request message includes data elements populated with the received fragments. Each fragment is marked with a "tag" indicating what it represents.

[0107] For example, a data element may include a tag indicating that the data element includes a segment corresponding to the initiating user 101, the length of the data element, and multiple subsets of information, each subset corresponding to a different segment received from the user 101. Each subset includes (in plain text or obfuscated form) a subtag indicating what the information represents, the length of the segment, and the value corresponding to the segment. So, if the data element includes 5 segments, the data element can be represented as:

[0108] Tags Len ST L V ST L V ST L V ST L V ST L V

[0109] Where "Tag" indicates that the data element includes a segment corresponding to the initiating user 101, "Len" indicates the length of the data element, each "ST" indicates the type of information represented by the segment, each "L" indicates the length of the segment, and each "V" represents the segment itself. This particular layout is provided only as an illustrative example.

[0110] TOP 402 then sends an authentication request message to payment network 105. In some embodiments, the authentication request message is sent in clear text to payment network 105. However, in other embodiments, TOP 402 encrypts, scrambles, or otherwise obfuscates the information in the authentication request message before sending it to payment network 105.

[0111] In step 431, payment network 105 receives the authentication request message and generates an account identification request message. The account identification request message includes the data received from TOP 402, including data elements and corresponding fragments. This account identification request message is sent to financial institution 413.

[0112] In step 433, financial institution 413 verifies the information in the account identification request message by comparing it with information in a database associated with financial institution 413. For example, financial institution 413 can compare the received information to Figure 1 402 with the information in a CIF ("Customer Information File") such as CIF 107A. If the fragment in the data element from the initiating user 101 is in plain text, the financial institution 413 compares the data element from TOP 402 with the information stored in the CIF.

[0113] However, if the segments in the data element are in an obfuscated form, such as a hashed format, an encrypted format, etc., financial institution 413 determines the subtags in the data element, collects data corresponding to those subtags from the CIF, and obfuscates that data in the same manner that the collected data was obfuscated (e.g., by encryption or hashing) by originating user 101 or TOP 402. Financial institution 413 then compares the obfuscated segments to determine if they are identical.

[0114] Regardless of the type of comparison, in step 435, financial institution 413 generates a response indicating which segments received from initiating user 101 match the data in the CIF. For example, if the first, third, and fourth segments received from initiating user 101 match the data in the CIF but the second and fifth segments received from initiating user 101 do not match the data in the CIF, financial institution 413 can generate a response indicating that only some of the segments match. In some implementations, the corresponding response can be implemented as a bitmap indicating which segments match the information in the CIF.

[0115] Financial institution 413 generates an account verification response message, including the generated response indicating the number of matching segments, and sends it to payment network 105. In step 437, payment network 105 receives the response message from financial institution 413 and returns it to Figure 4B Proceed to step 410.

[0116] exist Figure 4B In step 410 above, the payment network 105 determines whether to associate the financial institution account with the TOP user account and generates a corresponding message for sending to the initiating user 101. For example, the payment network 105 can determine that the financial account and the TOP user account should be associated with each other if the majority (i.e., more than 50%) of the fragments provided by the user 101 in step 427 match the data stored by the financial institution 413. If so, the process continues to step 411, where the payment network 105 generates a PAK key as described above. However, if the payment network 105 determines that the financial institution 413 does not match sufficient information with the fragments provided by the user 101, the process can continue to step 422, where a response (including a bitmap or other indication of the results of the fragment matching in some embodiments) can be forwarded to TOP 402, indicating that the request to associate the financial institution account with the TOP user account should be denied. TOP 402 then forwards a response to the initiating user 101 in step 423 indicating that the request to associate the financial institution account with the TOP user account is denied.

[0117] Figure 4D An example process 438 for initiating a transaction request using TOP 402 is illustrated. Process 438 involves communications between initiating user 101, initiator 102, TOP 402, payment network 105, and financial institution 403. The steps in process 438 enable initiating user 101 and initiator 102 to implement a financial transaction through payment network 105 using an account (such as a deposit account) at financial institution 413 associated with a TOP user account at TOP 402.

[0118] The TOP application provided to the initiating user 101 includes, in some embodiments, an application programmed to transmit information related to a purchase or other financial transaction that the initiating user 101 wishes to conduct to a merchant or merchant terminal (such as a point of sale (POS) device). For example, the TOP application can wirelessly transmit information related to a mobile wallet user account. The TOP application can be implemented as a mobile wallet application, a bill payment website, etc.

[0119] In step 439, the initiating user 101 utilizes the TOP application to initiate a transaction regarding the purchase. For example, the TOP application may generate a message including a request to initiate the purchase, information about the TOP user account, the amount of money to be paid, etc., and send it to the initiator 102. In step 441, the initiator 102 generates a financial services transaction and sends the financial services transaction to TOP 402.

[0120] In step 443, TOP 402 receives a financial services transaction request from TOP 402 and increments a wallet transaction counter (WTC). The WTC may be used by TOP 402 and the payment network to verify that the use of the TOP application and / or TOP 402 is authorized by initiating user 101.

[0121] In step 445, TOP 402 generates an application request cryptogram (ARQC). In some embodiments, generating the ARQC includes using a hardware security module (HSM) to encrypt various data using a payment instrument key (PIK) associated with a user account. The data encrypted to generate the ARQC may include, for example, a code representing the currency of the transaction (e.g., "USD" or "840" for U.S. dollars), a date associated with the transaction, an amount of the transaction, a country code associated with the initiator 102, a wallet transaction counter incremented in step 407, a random number, etc. In some embodiments, the ARQC is generated to comply with the EMV specification (short for Europay, MasterCard, and Visa), which defines requirements for implementing "chip and pin" transactions using integrated circuit payment cards. In some embodiments, specific data elements included in the ARQC can be encrypted before being placed in the ARQC. For example, data elements for which distribution should be restricted (such as account numbers, PAN, or other sensitive information) can be encrypted using a token key (TK). (In some embodiments, TOP 402 generates the ARQC by using a token key (TK) in a format such as Figure 4A TK is acquired by receiving it through a process described in .)

[0122] In step 447, TOP 402 generates a financial services transaction request and populates it with the generated ARQC and data elements about the requested transaction. These data elements include, for example, information about the TOP user account or financial institution account, the amount of money involved in the transaction, etc. In step 447, TOP 402 forwards the message to payment network 105.

[0123] In step 449, the payment network 105 obtains the PIK (Participant Authentication Key) and the PAK (Payment Instrument Key). In some embodiments, the PIK and the PAK are based on the Service Provider Master Key (SPMK) associated with the TOP 402. The PAK is related to the financial institution 413 and is generated using the SPMK. The PIK is related to a specific account at the financial institution 413 and is generated using the PAK. Therefore, because the SPMK is accessible to the payment network 105, the payment network 105 is able to use the SPMK to obtain the PAK and is able to use the obtained PAK to obtain the PIK.

[0124] In step 451, the payment network 105 uses the PIK to verify the received ARQC. For example, the payment network 105 uses the obtained PIK to ensure that the ARQC was actually sent by TOP 402 (e.g., by decrypting the ARQC using the PIK or by generating a copy ARQC and comparing it to the received ARQC). If the payment network 105 verifies the ARQC, the process 400 continues to step 453. In step 453, the payment network 105 verifies the wallet transaction counter (WTC) value included in the financial services transaction request. The payment network 105 determines whether the WTC value is within an acceptable range of previously received WTC values. For example, the payment network 105 can determine that the WTC value received in the current financial services transaction request is within three digits of the WTC value received in the previous financial services transaction request (e.g., if the WTC value in the previous financial services transaction request is 50, then determine whether the WTC value in this request is between 51 and 53). If payment network 105 determines that the WTC value is within an acceptable range of previous WTC values, process 400 continues to step 455 .

[0125] In step 455, payment network 105 reformats the financial services transaction request and forwards it to financial institution 413 for processing. Financial institution 413 may serve as a receiving processor (e.g., Figure 1 Receiver processor in ), receiver (for example, Figure 1 Receiver 107 in the example), an external receiver processor (e.g., Figure 1 108) or an external recipient (e.g., Figure 1 In some embodiments, forwarding the reformatted message to the financial institution 413 can include at least one of: forwarding the request to a recipient processor for forwarding to the recipient, forwarding the request to the recipient directly, forwarding the request to an external recipient processor for forwarding to the external recipient, etc. (In some embodiments, the process in step 455 can be similar to the above with respect to Figure 3303-310 in the description. )

[0126] In step 457, financial institution 413 receives the reformatted financial services transaction request and determines how to respond. For example, if the reformatted request includes a request from the originator to determine whether there are sufficient funds in the account for the purchase, financial institution 413 determines whether there are sufficient funds and generates an appropriate response. Financial institution 413 then sends a response to the financial services transaction request to payment network 105.

[0127] In step 459, payment network 105 receives, forwards, and records the response routed to it in step 457. Payment network 105 then sends a response message to TOP 402. In step 461, TOP 402 receives, forwards, and records the response, and forwards it to originator 102. Originator 102 accepts and processes the message and provides an appropriate response to initiating user 101. For example, if initiating user 101 attempted to purchase an item from initiator 102 in step 439 and the response received in step 461 indicates insufficient funds in the account referenced by initiating user 101, then originator 102 may deny the purchase transaction.

[0128] Figure 5 An example computer system 500 is illustrated for implementing the disclosed embodiments. Figure 1 The various components depicted in FIG. 5 (e.g., user 101, initiator 102, processor 103, payment network 105, database 105A, receiver processor 106, receiver 107, CIF 107A, external receiver processor 108, external receiver 109, or CIF 109A) may be implemented as illustrated in computer system 500. In some embodiments, the components may be copied, substituted, or omitted. Figure 5 In some embodiments, the system 500 can be used as a cellular phone, a mobile device, a POS (point of sale) device, a server, a wireless device, or a device including Figure 5 Any other system in which at least some of the components are implemented.

[0129] The system 500 includes a power supply unit 501. The power supply unit 501 can be implemented as a battery, a power supply, etc. The power supply unit 501 provides the power necessary to power other components in the system 500. For example, the CPU 502 requires power to operate. The power supply unit 501 can provide the necessary current to power this component.

[0130] System 500 includes a central processing unit (CPU) 502 that enables data to flow between other components and otherwise manages the operation of other components in computer system 500. CPU 502 can, in some embodiments, be implemented as a general-purpose processor (such as Intel or AMD branded processors), a special-purpose processor (e.g., a graphics card processor or a mobile processor), or any other kind of processor that enables input and output of data.

[0131] The system 500 also includes an output device 503. The output device 503 can be implemented as a monitor, printer, speaker, plotter, or any other device that represents data processed, received, or transmitted by the computer system 500.

[0132] The system 500 also includes a network adapter 504. The network adapter 504, in some embodiments, enables communication with other devices implemented in the same or similar manner as the computer system 500. The network adapter 504, in some embodiments, can allow communication to and / or from a network such as the Internet. The network adapter 504 can be implemented using any or all of known or still unknown wired or wireless technologies such as Ethernet 802.11a / b / g / n (also known as Wi-Fi), cellular (e.g., GSM, CDMA, LTE, etc.).

[0133] System 500 also includes an input device 505. In some embodiments, input device 505 can be any device that enables a user or other entity to input data. For example, input device 505 can be a keyboard, a mouse, a keypad on a touch screen, etc. Input device 505 can be used to control Figure 5 The operations of other components illustrated in .

[0134] System 500 also includes storage device 506. Storage device 506 stores data that can be used by other components in system 500. Storage device 506 can be implemented as a hard disk, temporary memory, permanent memory, optical memory, or any other type of permanent or temporary storage device in some embodiments. Storage device 506 can store one or more modules of computer program instructions and / or code that create an execution environment for the computer program described, such as, for example, processor firmware, a protocol stack, a database management system, an operating system, or a combination thereof.

[0135] The term "processor system" as used herein refers to one or more processors (such as CPU 502). The disclosed system can be partially or completely implemented on various computers, electronic devices, computer-readable media (such as CD, DVD, flash drive, hard disk or other storage unit) or other electronic devices or storage devices. The methods and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating outputs. The process and logic flow can also be performed by a dedicated logic circuit, and the device can also be implemented as a dedicated logic circuit, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). Although the disclosed process includes a specific process flow, alternative processes or sequences are also possible in alternative embodiments.

[0136] Certain features described in the context of separate embodiments for clarity in this specification may also be provided in combination in a single embodiment. Conversely, various features described in the context of a single embodiment for clarity may also be provided separately in multiple embodiments or in any suitable sub-combination. Moreover, although features may be described above as acting in a particular combination and even initially claimed as such, one or more features from the claimed combination can be deleted from the combination in some cases, and the claimed combination may be directed to sub-combinations or variations of sub-combinations.

[0137] Certain implementations have been described. Other implementations are within the scope of the following claims.

Claims

1. A computer system for processing a transaction request, the computer system comprising: processor; as well as a memory including instructions that, when executed by the processor, cause the processor to perform operations comprising: Receiving a transaction request associated with an initiating user and an account from a transaction origination point, the transaction request comprising an application request ciphertext encrypted using a payment instrument key, wherein the payment instrument key is generated by encrypting account information using a participant authentication key, and the participant authentication key is generated by encrypting institution information using a service provider master key associated with the transaction origination point; identifying the participant authentication key and the payment instrument key using the service provider master key associated with the transaction origin point; decrypting the application request ciphertext using the identified payment instrument key; determining an account identifier associated with the account number of the account by searching a database; sending a transaction including the determined account identifier to a second computer system, the second computer system including an identifier associated with the initiating user; receiving a response to the transaction from the second computer system; and A response to the transaction request is sent to the transaction origin point.

2. The computer system of claim 1, wherein: The transaction request includes the identification of the initiating user or the account, The identification includes an alternate account identifier different from the account identifier and an indicator value, and The account identifier is determined by searching a database for the account identifier and a routing transit number associated with the account using the alternate account identifier.

3. The computer system according to claim 1, wherein: The transaction request also includes information associated with an identification of the initiating user or the account.

4. The computer system according to claim 3, wherein: The account identifier is determined by searching the database using the identification of the initiating user or the account.

5. The computer system according to claim 1, wherein: The payment means key is generated in response to a request from the transaction origin point.

6. The computer system according to claim 5, wherein: The operations also include: forwarding at least one piece of information to the second computer system; receiving a response to the transaction from the second computer system; and A response to the transaction request is sent to the transaction origin point.

7. The computer system according to claim 1, wherein: The application request ciphertext further includes a transaction counter, and wherein the operations further include comparing the previously received transaction counter with the decrypted transaction counter.

8. The computer system according to claim 1, wherein: The operations also include: determining a netting amount applicable to at least two settlement accounts based on the transaction request received from the transaction origination point; and At least two entries are created in an automated clearing house file indicating a debit and a credit to the at least two settlement accounts reflecting the net settlement amount.

9. The computer system according to claim 1, wherein: The transaction origination point is one of a financial institution, an electronic funds transfer network, a merchant, a merchant processor, a remittance processor, and a mobile wallet provider.

10. A method for processing a transaction request comprising steps performed by a processor, the steps comprising: Receiving a transaction request associated with an initiating user and an account from a transaction origination point, the transaction request comprising an application request ciphertext encrypted using a payment instrument key, wherein the payment instrument key is generated by encrypting account information using a participant authentication key, and the participant authentication key is generated by encrypting institution information using a service provider master key associated with the transaction origination point; identifying the participant authentication key and the payment instrument key using the service provider master key associated with the transaction origin point; decrypting the application request ciphertext using the identified payment instrument key; determining an account identifier associated with the account number of the account by searching a database; sending a transaction including the determined account identifier to a second computer system, the second computer system including an identifier associated with the initiating user; receiving a response to the transaction from the second computer system; and A response to the transaction request is sent to the transaction origin point.

11. A system for processing a transaction request, the system comprising: processor; as well as a memory including instructions that, when executed by the processor, cause the processor to perform operations including: receiving a transaction request from a transaction origination point, the transaction request comprising a request to perform a transaction on behalf of a user, the transaction request not including an account number; determining a payment instrument key associated with a financial account, wherein the payment instrument key associated with the financial account is based on a participant authentication key associated with a financial institution holding the financial account, and the participant authentication key associated with the financial institution is based on a service provider master key associated with the system regarding the transaction origination point; generating a transaction message including an application request cryptogram, the application request cryptogram being generated by encrypting information associated with the transaction using the payment instrument key associated with the financial account; sending the transaction message to a second computer system; and A response is received from the second computer system.

12. The system according to claim 11, wherein: The transaction request also includes information associated with an identification of the user or the account.

13. The system according to claim 11, wherein: The operations also include incrementing a transaction counter associated with the financial account.

14. The system according to claim 11, wherein: The information associated with the transaction includes at least one of: a code representing a currency used for the transaction, a date associated with the transaction, an amount of the transaction, a country code, a transaction counter, and a random number.

15. The system of claim 11, wherein: The payment instrument key associated with the financial account is generated by encrypting information associated with the financial account, and The participant authentication key associated with the financial institution is generated by encrypting information associated with the financial institution.

16. The system of claim 11, wherein: The transaction origination point is associated with an initiator; and The second computer system is associated with a payment network.

17. The system of claim 11, wherein: The system is associated with at least one of: a merchant, a merchant processor, a remittance processor, a mobile wallet provider, a bill payment provider, a kiosk, an account access terminal, and a funds transfer website.

18. A method for processing a transaction request comprising steps performed by a processor, the steps comprising: receiving a transaction request from a transaction origination point, the transaction request comprising a request to perform a transaction on behalf of a user, the transaction request not including an account number; determining a payment instrument key associated with a financial account, wherein the payment instrument key associated with the financial account is based on a participant authentication key associated with a financial institution holding the financial account, and the participant authentication key associated with the financial institution is based on a service provider master key associated with a system regarding the transaction origination point; generating a transaction message including an application request cryptogram, the application request cryptogram being generated by encrypting information associated with the transaction using the payment instrument key associated with the financial account; sending the transaction message to a second computer system; and A response is received from the second computer system.

Images