Non-local account processing

Abstract

A technique for enabling non-local accounts to be processed by a processing system may include receiving an account identifier scheme used by a third-party entity to provide access to an account associated with the third-party entity, and assigning an entity identifier to the third-party entity, wherein the entity identifier conforms to a local format used by the processing system. An application programming interface may be modified to recognize the account identifier of the third-party entity. A transaction request may be received to perform a transaction, wherein the transaction request includes a resource provider identifier of the third-party entity and an account identifier of an account of the third-party entity. The entity identifier assigned to the third-party entity may be determined using the modified application programming interface, and the transaction may be processed using the entity identifier assigned to the third-party entity.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Provisional Application No. 62 / 882,377, filed on August 2, 2019, which is incorporated herein by reference in its entirety. Background Art

[0003] Processing systems that process and route transactions typically require that entities transacting have accounts established with the processing system. However, this requirement creates a closed system where only entities that subscribe to the processing system's account infrastructure can use the services provided by the processing system. This creates barriers to interoperability between different processing systems and prevents accounts from interacting with each other.

[0004] Embodiments of the invention address these and other problems, both individually and collectively. Summary of the Invention

[0005] A technique for enabling non-local accounts to be processed by a processing system may include receiving an account identifier scheme used by a third-party entity to provide access to an account associated with the third-party entity, and assigning an entity identifier to the third-party entity, wherein the entity identifier conforms to a local format used by the processing system. An application programming interface may be modified to recognize the account identifier of the third-party entity. A transaction request may be received to perform a transaction, wherein the transaction request includes a resource provider identifier of the third-party entity and an account identifier of an account of the third-party entity. The entity identifier assigned to the third-party entity may be determined using the modified application programming interface, and the transaction may be processed using the entity identifier assigned to the third-party entity.

[0006] In some embodiments, a process for executing a transaction may include receiving a transaction request for executing a transaction, wherein the transaction request includes a resource provider identifier of a third-party entity and an account identifier of an account of the third-party entity. An entity identifier may be determined based on the resource provider identifier of the third-party entity. The entity identifier may conform to a local format used by processing logic of a transaction processor. The account identifier may be verified to conform to an account identifier scheme of the third-party entity. The transaction may then be executed using the entity identifier in the local format used by the processing logic of the transaction processor.

[0007] A computing system and / or processing server may be used to perform the above-described techniques. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1A block diagram illustrating a processing system environment for account lookup and verification according to some embodiments.

[0009] Figure 2 A block diagram of a processing system environment for processing transactions involving non-local accounts is shown according to some embodiments.

[0010] Figure 3 An example of an entity identifier mapping table according to some embodiments is shown.

[0011] Figure 4 A block diagram of a processing server is shown according to some embodiments.

[0012] Figure 5 A flow diagram illustrating a process for enabling a processing system to handle non-local accounts according to some embodiments.

[0013] Figure 6 A flow diagram illustrating a process for performing transactions involving non-local accounts according to some embodiments. DETAILED DESCRIPTION

[0014] The technology disclosed herein provides a processing system that has the ability to process transactions associated with third-party accounts that are not established with the processing system. Such accounts may be referred to as non-local accounts. In some embodiments, the application programming interface (API) used by the processing system to process transactions can be modified to recognize non-local accounts, enabling the processing of transactions for non-local accounts. In this way, non-local account holders can take advantage of the processing system's infrastructure and capabilities, such as the ability to route transactions globally through the processing system's interconnected network.

[0015] Before discussing various embodiments, a description of some terms may be helpful in understanding the technology disclosed herein.

[0016] The server computer may comprise a powerful computer or computer cluster. For example, the server computer may be a mainframe, a minicomputer cluster, or a group of servers operating as a unit. In one example, the server computer may be a database server coupled to a network server. The server computer may be coupled to a database and may include any hardware, software, other logic, or combination thereof for servicing requests from one or more client computers. The server computer may comprise one or more computing devices and may use any of a variety of computing structures, arrangements, and compilations to service requests from one or more client computers.

[0017] A credential is any suitable piece of information that serves as reliable evidence of value, ownership, identity, or authority. A credential can be a string of numbers, letters, or any other suitable characters, as well as any object or document that can be used for verification. Examples of credentials include certificates of value, identification cards, authentication documents, access cards, passwords, and other login information.

[0018] A primary account number (PAN) is a type of account identifier and may include any string, sequence of digits, or other identifier suitable for identifying an account associated with a payment processing network. In some cases, a PAN may include an issuer identification number, a personal account identifier, and a check digit. For example, a PAN may include a 16-digit sequence: "4123-4567-8901-2345" (the sequence has been broken down into 4-digit groups for readability). However, a PAN may be constructed in any other suitable manner.

[0019] An AFT (Account Funding Transaction) is a transaction designed to supply funds to another account, such as a credit, prepaid, debit, ATM, or online account. In this invention, the AFT is paying the resource provider bank for sending the funds to the recipient, and causing the sender's card account to be debited. The debit amount is the credit amount to be delivered to the recipient plus any fees charged by the service provider, such as transfer fees or currency conversion fees when the transfer gateway performs a currency conversion and its acquirer submits the transaction in the recipient's preferred currency.

[0020] An OCT (Original Credit Transaction) is typically a clearing and settlement credit transaction designed for commercial applications, such as commercial transfers or business-to-consumer reimbursements. When used in the context of transfers in this invention, an OCT is the transaction used to deliver funds to the recipient's account. It occurs separately from and after the AFT transaction. This timing ensures the security of the funds before they are sent to the recipient.

[0021] A sending account can include any account associated with the party sending funds in a transaction. For example, a sending account can be an account associated with a payment processing network, such as a credit card or debit card account. In other cases, a sending account can be a bank account or other account not associated with a payment processing network. In still other cases, a sending account can refer to a non-account instrument, such as a cash payment.

[0022] A recipient account may include any account associated with receiving funds in a transaction. In some cases, a recipient account may be an account associated with a payment processing network, such as a credit card account, a debit card account, or an account associated with a payment token. In other cases, a recipient account may be a bank account or other account not associated with a payment processing network (e.g., a prepaid account, a deposit account or merchant with a billing machine, a transit transponder account, a mobile account, etc.). For example, in some cases, a recipient account may not be associated with a PAN. The recipient account may be maintained by the recipient's bank.

[0023] An authorization request message may be an electronic message requesting authorization for a transaction. In some embodiments, the authorization request message is sent to a transaction processing computer and / or the issuer of a payment card to request authorization of the transaction. According to some embodiments, the authorization request message may comply with ISO 8583, a standard for systems for exchanging electronic transaction information associated with payments made by a user using a payment device or payment account. The authorization request message may include an issuer account identifier that may be associated with the payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information," including, by way of example only: a service code, a CVV (card verification value), a dCVV (dynamic card verification value), a PAN (primary account number or "account number"), a payment token, a username, an expiration date, and the like. The authorization request message may also include "transaction information," such as any information associated with the current transaction, such as the transaction amount, merchant identifier, merchant location, acquirer bank identification number (BIN), card acceptor ID, information identifying the item being purchased, and any other information that may be used to determine whether to identify and / or authorize the transaction.

[0024] The authorization response message can be a message in response to the authorization request. In some cases, the authorization response message can be an electronic message generated by the issuing financial institution or a transaction processing computer in response to the authorization request message. By way of example only, the authorization response message can include one or more of the following status indicators: approved—the transaction is approved; rejected—the transaction is not approved; or call center—the response is pending and the merchant must call a toll-free authorization number for more information. The authorization response message can also include an authorization code, which can be a code returned by the credit card issuing bank to the merchant's access device (e.g., a POS device) in response to the authorization request message in an electronic message (directly or through a transaction processing computer) indicating that the transaction is approved. The code can serve as evidence of authorization.

[0025] The verification request message may include a message that can be used to request at least verification of one or more personal data elements. In some embodiments, the data element may be an address, name, personally identifiable information, etc. In some embodiments, the verification request message may include other types of data elements, such as an account identifier including a source account identifier, a target account identifier, etc. The verification request message may be in any suitable data format (e.g., ISO 8583, XML, etc.).

[0026] The verification response message may include any suitable message in response to the verification request message. The verification response message may include the personal data element verification result, such as the address verification result. The verification response message may be in any suitable data format (e.g., ISO 8583, XML, etc.).

[0027] The technology disclosed herein provides a receiving-side platform to enable entities to connect directly to a transaction processing network to receive push payments. The platform may be referred to as "OPEN" (Open Payment Enablement Network). The platform's capabilities may be used by digital wallet providers, neo-banks, and traditional financial institutions that wish to receive instant funds transfers without the need for issuing cards / accounts for transaction processors. OPEN may include standardized APIs and may provide straight-through processing and guaranteed settlement, but may use simpler permissions and regulations, and support processing of non-local values ​​(account identifiers) and / or credentials, such as IBANs (International Bank Account Numbers) or wallet IDs.

[0028] By simplifying how digital entities enter the network, OPEN can strengthen the role of transaction processors as a global network that enables senders and receivers to connect in a programmatic, standards-based manner rather than through bilateral agreements.

[0029] The following functions are available to support OPEN:

[0030] Transaction processors may have established contracts and stable settlement processes. For example, banks in certain countries may not issue certain types of transaction processor cards. However, transaction processors may still regularly settle billions of dollars with these banks for international ATM transactions. From a "corporate settlement" perspective, transaction processors may have long-term contracts and can perform net settlement and manage liquidity with nearly every major retail bank in the world.

[0031] • Handling non-native values ​​(account identifiers): Sophisticated account range mapping / routing capabilities can allow transaction processors to manage authorization, clearing, and settlement of transactions using non-native credentials in a seamless manner.

[0032] Deliver authorization, recommendations, and reports based on an application programming interface (API) and / or secure file transfer protocol (SFTP): The OCT sender API and the OCT receiving API can be extended to handle non-native credentials. Settlement reports can also be delivered via API and SFTP channels.

[0033] Using the above functions, OPEN can stack multiple layers of components together.

[0034] 1. Modified Scheme License: OPEN can be governed by a new / modified service license. This license can be issued standalone to wallets / non-native issuers or added as an optional addendum to an existing primary license. One criterion for assessing client eligibility for an OPEN license is regulatory licensing related to money transfers, AML (Anti-Money Laundering) ratings, and Know Your Customer (KYC) procedures. Credit settlement risk is typically a higher bar for most issuers and fintechs, but is not a significant factor, as OPEN licensees are typically net recipients of transaction processor funds.

[0035] 2. Common Minimum Rules: OPEN can have a cohesive set of rules to ensure trust and service levels, and to govern dispute resolution between originators and OPEN recipients. These rules can be similar to OCT rules, but can be more flexible, focusing primarily on AML / KYC obligations, value and speed limits, rules on issuance speed and authorization rates, and adherence to dispute protocols and technical specifications.

[0036] 3. Settlement: OPEN transactions can be settled to existing SREs, if available. In the case of wallets or new platform licensees, new settlement accounts can be set up. The settlement currency can be determined by existing market practices for ATM acquisitions—because the flow of funds for OPEN recipients is similar to that for ATM acquirers; for example, the client provides funds to the customer based on a settlement guarantee, and the transaction processor debits the same funds to the client during the next settlement cycle.

[0037] 4. Non-native value handling: This makes it easier for receiving clients to integrate transaction messages and reconciliation reports with their core systems without having to build their own mapping and conversion services to link PAN / tokens to their account numbers. To this end, OPEN can provide support for values ​​such as: country code, bank routing code, customer account number; SWIFT code and IBAN as valid values; and / or a combination of country code and wallet account ID.

[0038] 5. API / Web Services for Authorization, Recommendations, and Reporting: Receive-side APIs can be enhanced to carry non-native credentials associated with incoming credits, along with rationalized approval and rejection codes. Settlement reports will be delivered via SFTP / API channels—and can be redesigned and streamlined to meet the needs of OPEN receivers. In addition to authorization and reporting services, OPEN can also support new APIs for account name verification and payment requests.

[0039] In order to enable the processing system to process third-party accounts, the processing system can load (onboard) the third-party entity by obtaining the account identifier scheme used by the third-party entity and assigning the entity identifier to the third-party entity. The entity identifier can conform to the local format of the account identifier used by the processing system. In this way, the transaction involving the account of the third-party entity can be internally processed by the processing system using the entity identifier. For example, the card processing system such as Visa or Mastercard uses a 16-digit card account number to process transactions, wherein the first 6 digits can be used as a bank identification code (BIN). Use BIN to process transactions and route them to appropriate authorized entities (for example, the issuing bank of the account). In such embodiments, a BIN can be assigned to a third-party entity such as a mobile wallet service provider that does not use a 16-digit account number by the processing system, and the transaction involving the account of the mobile wallet service provider can be internally processed by the processing system using the BIN assigned.

[0040] Each assigned BIN may also be associated with a set of transaction parameters for a third-party entity, such as an application identifier level (e.g., used by the processing system to distinguish between different types of supported push payments, such as payment transfers, peer-to-peer transfers, merchant payments, etc.), domestic and / or cross-border transfer support, and transaction limits such as transaction speed limits and / or maximum transaction amounts. Transaction parameters may also include parameters such as foreign exchange settings, billing currency, and settlement currency. More generally, transaction parameters may include parameters used by the processing system's logic to make processing decisions.

[0041] In some embodiments, the processing system can adopt a non-local numerical scheme to identify transaction requests involving third-party entity accounts. For example, the non-local numerical scheme can include a combination of the following: a resource provider type indicating the account type supported by the third-party entity, a country code indicating the country associated with the third-party entity, and a resource provider identifier such as an entity name or entity classification code (e.g., SWIFT code, IBAN code, routing number, etc.), if any. Each unique combination of these elements can be mapped to a unique entity identifier assigned by the processing system. In some embodiments, the third-party entity can have account ranges corresponding to different service levels, and each account range of the third-party entity can have a unique entity identifier. The application programming interface used by the processing system to receive and process transactions can be modified to parse incoming requests for non-local numerical schemes. The processing system can then use the elements of the non-local numerical scheme to retrieve the entity identifier associated with the third-party account and use the entity identifier to process transactions internally.

[0042] To initiate a transfer, a sender may send a transfer request by calling a transfer request API with parameters {resource provider type, country, resource provider identifier, and target account}. For example, to send funds to a PayPal mobile wallet account belonging to bob@gmail.com, the sender may send a transfer request by calling a transfer request API with parameters “W:US:Paypal:bob@gmail.com”, where “W” indicates a mobile wallet account, “US” indicates a US entity, “PayPal” indicates the name of the service provider, and bob@gmail.com indicates an account identifier in the PayPal system. As another example, to send funds to a Barclays UK bank account, the sender may send a transfer request by calling a transfer request API with parameters “B:UK:BUKBGB22:0256587785”, where “B” indicates a bank account, “UK” indicates a UK entity, “BUKBGB22” indicates the bank’s IBAN number, and 0256587785 indicates an account identifier in the Barclays bank system. A processing system (e.g., Visa) receiving the transfer request API call can parse the parameters and determine the entity identifier (e.g., BIN) associated with the recipient service provider and process the transaction using the entity identifier in the processing system's native format.

[0043] Figure 1A block diagram of a processing system environment 100 according to some embodiments is shown. The processing system environment 100 can provide account lookup and verification services before processing transactions using non-local accounts. For example, the account lookup and verification services can be used to verify the target account and obtain transaction parameters for the account to ensure that transactions involving non-local accounts comply with the account provider's parameters.

[0044] The processing system environment 100 may include an initiator 110, a processing server 120, core processing logic 130, and a third-party entity 140. The initiator 110 may be an entity associated with the sender of funds, such as an acquirer, a transaction service provider, or other financial institution. The third-party entity 140 may be a resource provider, such as a transaction service provider. Examples of third-party entities 140 may include mobile wallet providers, peer-to-peer transaction providers, banks, or other financial institutions that provide accounts. In some embodiments, the accounts provided by the third-party entities 140 may be unrelated to the transaction processing system implemented by the processing server 120 and / or the core processing logic 130, and transactions involving such accounts are not traditionally processed by the transaction processing system.

[0045] The processing server 120 may be a server associated with a transaction processing system that may receive incoming transaction requests. The core processing logic 130 implements the processing network of the transaction processing system and may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception document services, and clearing and settlement services. An exemplary transaction processing system is Visa, and the core processing logic 130 may include VisaNet TM For example, VisaNet TM Transaction processing systems such as VisaNet can process credit card transactions, debit card transactions and other types of funds transfer transactions. TM Specifically, it includes the VIP system (Visa Integrated Payment System) that processes authorization requests, and the Base II system that performs clearing and settlement services. The transaction processing system can use any suitable wired or wireless network including the Internet.

[0046] Figure 1Messages between the components shown may be sent using communication protocols such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS); SSL; ISO (e.g., ISO 8583), etc. Communication networks that allow computers to communicate may include any one and / or a combination of the following: direct interconnections; the Internet; a local area network (LAN); a metropolitan area network (MAN); Operational Mission as a Node on the Internet (OMNI); secure custom connections; a wide area network (WAN); a wireless network (e.g., using protocols such as Wireless Application Protocol (WAP), I-mode, etc.); etc.

[0047] The communication network can use any suitable communication protocol to generate one or more secure communication channels. In some examples, the communication channel can include a secure communication channel, which can be established, for example, by using mutual authentication and session keys and establishing a secure socket layer (SSL) session. In some embodiments, the communication sent to the processing server 120 can be in the form of an API call made over the secure communication channel.

[0048] At step 1A, the initiator 110 may send an account lookup / verification request to the processing server 120. The account lookup / verification request may be in the form of an API call or a verification request message to a programming interface of the processing server 120 and may include at least a resource provider identifier and an account identifier. The resource provider identifier may be a string containing the name of the resource provider, a classification code such as a SWIFT code, an IBAN code, or a routing number. The account identifier may be, for example, a string of letters or alphanumeric characters that identifies a target account (e.g., an email address or username of an account holder) or a numerical account number. In some embodiments, the account lookup / verification request may also include the actual name of the account holder and / or other data elements, such as the type of resource provider, the country associated with the account, etc.

[0049] At step 1B, the processing server 120 may parse the account lookup / verification request to obtain a resource provider identifier to identify the third-party entity, and forward the account lookup / verification request with the account identifier to the third-party entity 140. Upon receiving the account lookup / verification request, the third-party entity 140 may verify that the account identifier is valid and that the account associated with the account identifier is active and in good standing. In some embodiments, the third-party entity 140 may also perform additional verification, such as checking the name of the account holder. The third-party entity 140 may also send a notification to the account holder to inform the account holder that an account lookup / verification request for the account has been received.

[0050] At step 1C, the third-party entity 140 may send an account lookup / verification response (e.g., a verification response message) to the processing server 120. The account lookup / verification response may include an indication of whether the account is active and whether the name matches the account holder of the account. If the lookup / verification response indicates that the account is inactive (e.g., invalid account number, suspended account, etc.), or the name does not match the account holder, the processing server 120 may send an error message to the originator 110 indicating the problem.

[0051] If the lookup / verification response indicates that the account is active and the name matches the account holder, the processing server 120 can retrieve transaction parameters associated with the account and the third-party entity at step ID. For example, the processing server 120 can use a combination of the resource provider type, country, and resource provider identifier to look up the entity identifier associated with the third-party entity 140. In some embodiments, if account scope is supported, the set of data elements used to look up the entity identifier can also include an account identifier. In some embodiments, the resource provider identifier itself can be sufficient to retrieve the entity identifier.

[0052] Once the entity identifier is retrieved, the processing server 120 may provide the entity identifier to the core processing logic 130 to obtain transaction parameters associated with the entity identifier. In some embodiments, the processing server 120 may store the transaction parameters locally and, therefore, may obtain the transaction parameters without involving the core processing logic 130. The transaction parameters may include, for example, information such as the types of push payments supported (e.g., fast funds, original credit transactions, etc.), whether domestic and / or cross-border transfers are supported, the accounting currency and / or settlement currency, transaction restrictions, etc. The transaction parameters are then incorporated into a lookup / verification response and sent to the initiator 110 to inform the initiator 110 of the account status and the transaction types permitted for the account as indicated by the transaction parameters.

[0053] Figure 2 A block diagram of a processing system environment 200 for processing transactions involving non-local accounts according to some embodiments is shown. The processing system environment 200 may include Figure 1 Similar components include an initiator 110 , a processing server 120 , a core processing logic 130 , and a third-party entity 140 . Figure 2 Also shown are a sender 180 and a receiver 190 in a processing system environment 200. The sender 180 and / or the receiver 190 may be an individual or entity, such as a business or merchant.

[0054] For example, the sender 180 may perform a transaction to send $100 to the recipient's UK bank account at Barclays Bank. At step 2A, to initiate the transaction, the sender 180 may provide the details of the transaction (e.g., the amount of $100), the bank's resource provider identifier (e.g., BUKBGB22), and the recipient's account identifier (e.g., 0256587785) to the initiator 110.

[0055] At step 2B, initiator 110 may generate a transfer request API function call based on the received information and send the API call to processing server 120. For example, the transfer request API call may include the string "B:UK:BUKBGB22:0256587785" with a transaction amount of $100, where "B:UK" indicates that the target account is a bank account in the United Kingdom. In some embodiments, the information may be sent using different forms and / or formats. For example, the transfer request may be sent in the form of an authorization request message, or the information may be sent in the form of a file, message, or other communication format.

[0056] At step 2C, the processing server 120 may receive the transfer request and parse the request to obtain information that can be used to retrieve the entity identifier in the local format of the processing server 120. For example, the processing server 120 may parse the parameters of the API call to obtain the IBAN code "BUKBGB22" of the recipient bank. The processing server 120 may retrieve the entity identifier assigned to the IBAN code "BUKBGB22" from a database or mapping table. Figure 3 As shown in mapping table 300 , the entity identifier mapped to the resource provider identifier "BUKBGB22" is "486483." Processing server 120 may also obtain transaction parameters associated with entity identifier "486483" and determine that the target account supports cross-border transactions, that the accounting and settlement currencies are in British Pounds (GBP), and that foreign exchange transactions will be executed by the transaction processing system. The transaction parameters may also include transaction restrictions, such as a transaction speed limit and a maximum amount limit.

[0057] The entity identifier in a format native to the core processing logic 130 can be used by the core processing logic 130 to perform functions such as authentication, authorization, and transaction routing. The core processing logic 130 can verify that the transaction details of the transfer are within the permissible transaction parameters of the destination account (e.g., within the transaction limits) and perform the foreign exchange transaction indicated by the transaction parameters. For example, assuming the transaction processing system's exchange rate is 1 USD to 0.7 GBP, the core processing logic 130 can convert a transaction amount of 100 USD into a billing currency / settlement currency of 70 GBP.

[0058] At step 2D, after processing logic 130 has processed the transaction, processing server 120 may send a transfer request including the account identifier and the converted transaction amount of £70 to third-party entity 140, which in this example would be Barclays Bank. At step 2E, third-party entity 140 may deposit £70 into the recipient's account and send a deposit notification to recipient 190. At step 2F, third-party entity 140 may send a transfer response to processing server 120 indicating the successful transfer. The transfer response may be in the form of a transfer response API or an authorization response message, for example. At step 2G, processing server 120 may then forward the transfer response to initiator 110.

[0059] At a later point in time, clearing and settlement processing can occur. At step 2H, processing server 120 may withdraw $100 from initiator 110. At step 2I, core processing logic 130 performs clearing and settlement using the entity identifier "486483" associated with third-party entity 140 or the recipient's bank. At step 2J, £70 is deposited into third-party entity 140 to complete settlement. By using an entity identifier that conforms to the native format used by the transaction processing system, settlement assurance and subsequent reporting can be performed using the transaction processing system's infrastructure.

[0060] Figure 3 An example of an entity identifier mapping table 300 is shown that may be maintained by a transaction processing system (eg, processing server 120 and / or core processing logic 130) according to some embodiments. It should be understood that entity identifier mapping table 300 may be implemented using a database or other data structure.

[0061] Entity identifier mapping table 300 stores one or more entries for each third-party entity. The third-party entities listed in entity identifier mapping table 300 may not necessarily provide accounts associated with the transaction processing system, and therefore the transaction processing system is traditionally unable to process transactions involving the accounts of these third-party entities. However, by assigning entity identifiers that conform to the local format used by the transaction processing system to process transactions, these third-party entities can utilize the transaction processing system's infrastructure to route and process transactions involving the third-party entities' accounts.

[0062] Entity identifier mapping table 300 may include various fields associated with a third-party entity, including account type 302, recipient country 304, resource provider identifier 306, account scope 308, entity identifier 310, and transaction parameters 312. Account type 302 indicates the type of account provided by the third-party entity. For example, account type 302 may indicate whether the third-party entity provides a mobile wallet account, a bank account, or another type of transaction account. Recipient country 304 indicates the country in which the account provided by the third-party entity is located.

[0063] The resource provider identifier 306 indicates who the third-party entity is. The resource provider identifier 306 can be a string of letters, a string of numbers, or an alphanumeric string. The resource provider identifier 306 can be the name of the third-party entity, or can be a classification code associated with the third-party entity (e.g., a SWIFT code, an IBAN code, a routing number, etc.). The resource provider identifier 306 can have a different number of characters than the number of characters of the entity identifier 310 used by the transaction processing system to process transactions, so the transaction processing system traditionally cannot use the resource provider identifier 306 to process transactions. Some third-party entities can support account ranges, in which different levels of services and products are provided to account identifiers of different ranges. For such third-party entities, the entity identifier mapping table 300 can store different account ranges 308, and each account range can be associated with a different entity identifier 310.

[0064] Entity identifier 308 is an identifier that conforms to the local format used by the transaction processing system. Depending on the transaction processing system, the entity identifier that conforms to the local format can be an alphanumeric string, a numeric string, or an alphanumeric string. For example, transaction processing systems such as Visa traditionally use a 6-digit BIN that begins with "4" to identify the issuing bank for routing and processing transactions. The 6-digit BIN is typically the first 6 digits of a 16-digit account identifier. Therefore, in order to conform to this local format used by the transaction processing system, the entity identifiers 310 listed in the entity identifier mapping table 300 are 6-digit strings that each begin with "4". It should be noted that third-party entities may not necessarily issue account identifiers with BINs that begin with "4", and therefore the transaction processing system may traditionally be unable to process transactions involving the accounts of these third-party entities.

[0065] Transaction parameters 312 may include a set of parameters that the transaction processing system may use to process transactions associated with a particular third-party entity. For example, transaction parameters 312 may include a billing currency (BC), indicating the currency used to debit the account, and a settlement currency (SC), indicating the currency used to settle the account. Transaction parameters 312 may also include an indication of whether domestic transfers (DOM) and / or cross-border transfers (XB) are permitted on the account. Transaction parameters 312 may also include the designation of the entity that performs any foreign exchange (FX). For example, FX may be performed by the transaction processing system (e.g., Visa) or by the third-party entity partner itself. Transaction parameters 312 may also include an indication of whether the account accepts push payments (PP) and / or grease funds transfers (FF). Transaction parameters 312 may also include transaction limits, such as a transaction velocity limit (VEL) and a maximum transaction amount limit (MAX). The transaction velocity limit may indicate the maximum number of transactions allowed per day for a particular account, and the maximum transaction amount limit may indicate the maximum amount allowed per transaction. The maximum transaction amount may, for example, be expressed in the settlement currency. It should be understood that these are merely a few examples of transaction parameters that may be stored in the entity identifier mapping table 300, and that other embodiments may include other parameters not specifically shown, and / or may include fewer parameters or more parameters than shown.

[0066] For example, the first entry in entity identifier mapping table 300 is for Alipay, a mobile wallet provider. The country associated with the Alipay account is China, and Alipay does not use account scopes. The entity identifier assigned to Alipay is "401218." The transaction parameters associated with Alipay indicate that both the accounting and settlement currencies are Renminbi (RMB), and that the account supports domestic and cross-border transfers. Foreign exchange transactions will be processed by Visa, and the account supports push payments, but not fast funds. The transaction rate is limited to 10 transactions per day, with a maximum amount per transaction of RMB 50,000.

[0067] As another example, the third entry in the entity identifier mapping table 300 is Rakuten Bank, which is a Japanese bank. The resource provider identifier is listed as "RAKTJPJT", which is the SWIFT code for Rakuten Bank. The country associated with the account at Rakuten Bank is Japan, and account ranges are not supported. The entity identifier assigned to Rakuten Bank is "454200". The transaction parameters associated with Rakuten Bank indicate that both the accounting currency and the settlement currency are Japanese Yen (JPY), and that the account supports domestic transfers and cross-border transfers. Foreign exchange transactions will be executed by Rakuten Bank itself, and the account supports push payments and fast funds. The transaction rate is limited to 20 transactions per day, and the maximum amount per transaction is 1,000,000 yen.

[0068] As another example, the fifth entry in entity identifier mapping table 300 is for UBS Bank, a Swiss bank. The resource provider identifier is listed as "026007993," the routing number for UBS Bank. The country associated with the UBS Bank account is Switzerland, and two account ranges are not supported. The entity identifier assigned to the first account range of account identifiers 02300000 to 02319999 is "490001," and the entity identifier assigned to the second account range of account identifiers 02320000 to 02349999 is "490002."

[0069] The transaction parameters associated with the first account range indicate that the accounting currency is in US dollars (USD) and the settlement currency is in Swiss francs (CHF). Accounts in this range support both domestic and cross-border transfers. Foreign exchange transactions are executed by UBS Bank itself, and the accounts support push payments and fast funding. The transaction rate is limited to 25 transactions per day, with a maximum amount of CHF 20,000 per transaction.

[0070] The transaction parameters associated with the second account range indicate that both the accounting and settlement currencies in this account range are in US dollars (USD). Accounts in this range only support cross-border transfers. Foreign exchange transactions will be executed by UBS Bank itself, and the accounts support push payments and fast funds. The transaction speed is limited to 50 transactions per day, and

[0071] Figure 4 A block diagram of a processing server 400 (e.g., processing server 102) is shown in accordance with some embodiments. In some embodiments, for example, one or more token servers 400 may be used to implement a networked system of processing servers. The processing server 400 may include a processor 401 coupled to a network interface 402 and a computer-readable medium 406. In some embodiments, the processing server 400 may also include a hardware security module (HSM) 420. The processing server 400 may also include an entity identifier database 404, which may be internal or external to the processing server 400. The entity identifier database 404 may store mappings of entity identifiers to third-party entities, and may store, for example, Figure 3 Information such as that shown.

[0072] Processor 401 may include one or more microprocessors to execute program components for performing server functionality 430. Network interface 402 may be configured to connect to one or more communication networks to allow processing server 400 to communicate with other entities. Computer-readable medium 406 may include any combination of one or more volatile and / or non-volatile memories, such as RAM, DRAM, SRAM, ROM, flash memory, or any other suitable memory component. Computer-readable medium 406 may store code executable by processor 401 for implementing some or all of server functionality 430. For example, computer-readable medium 406 may include a third-party registration module 408, a transaction API 410, an entity identifier generator 412, a lookup and verification module 414, and a routing module 416.

[0073] The third party registration module 408 may register a third party entity with the entity identifier database 404. The third party entity payment provides information about the third party entity, such as the account identifier scheme and transaction parameters used by the third party entity, and e.g. Figure 3 Upon receiving the registration or enrollment request, the third-party registration module 408 may authenticate the third-party entity, request the entity identifier generator 412 to generate an entity identifier for the third-party entity, and store information about the third-party entity, including an entity identifier mapping, in the entity identifier database 404.

[0074] The entity identifier generator 412 may generate an entity identifier for a third party entity that may not have an entity identifier used by the transaction processing system. The generated entity identifier conforms to the local format used by the transaction processing system. In some embodiments, the entity identifier may be generated randomly, pseudo-randomly, incrementally (e.g., counting up), or using another suitable scheme. If an entity identifier generated by a scheme is already in use, another entity identifier may be generated for the third party entity being registered. Once the third party entity has been registered, the lookup and verification module 414 may be used to perform account lookup and verification functions, such as referencing Figure 1 The routing module 416 may be used to route requests and responses to third-party entities.

[0075] The transaction API 410 may include a set of APIs that external entities can call to interact with the core processing logic of the transaction processing system. For example, the transaction API 410 may implement a transfer request API that external entities can call to initiate transactions. In some embodiments, the transaction API may be modified to recognize transaction requests involving different third-party entities. For example, the transaction API 410 may be modified to recognize non-local account identifiers, verify that the non-local account identifiers correspond to the account identifier scheme used by a particular third-party entity, and initiate core processing logic using a local entity identifier associated with the third-party entity.

[0076] According to some embodiments, the processing server 400 may include an HSM 420 to perform security functions such as encryption and decryption operations and generate cryptographic keys for encryption and decryption operations. For example, the HSM 420 may include a cryptographic engine 422 to perform encryption algorithms such as AES, DES, TDES / TDEA, or other suitable encryption algorithms using encryption keys of any length (e.g., 56 bits, 128 bits, 169 bits, 192 bits, 256 bits, etc.). The HSM 420 may also implement a session key generator 424 to generate session keys for external communications. For example, the session keys may be used to establish a secure communication channel (e.g., TLS, SSL, etc.) between an external entity and the processing server 400. Although the processing server 400 has been described as implementing some of its functions through an HSM, it should be understood that other functions may also be implemented within the HSM. In addition, some or all of the corresponding HSM functions may also be implemented outside the HSM.

[0077] Figure 5 A flow chart illustrating a process 500 for implementing non-local account processing at a transaction processing system according to some embodiments is shown. Process 500 can be performed, for example, by a processing server. Processing of non-local accounts of third-party entities can be implemented by assigning entity identifiers that conform to the local format of the processing system and modifying processing logic (e.g., an API) utilized at the processing server associated with the processing system.

[0078] At block 502, the processing server may receive from a third-party entity an account identifier scheme used by the third-party entity to provide access to an account associated with the third-party entity. The third-party entity may be an entity that does not provide an account associated with the transaction processing system, and therefore the account of the third-party entity may be a non-local account that is not recognized by the transaction processing system. The account identifier scheme may include information about the account identifier used by the third-party entity, such as the number of characters, whether the account identifier is purely numeric or alphanumeric, hyphens or other separating characters, the presence of static characters, prefixes, suffixes, country codes, routing codes, etc. In some embodiments, the account identifier scheme may be, for example, an email address, a phone number, a username, or other personal identification information. In some embodiments, the account identifier scheme may adopt other formats used by the third-party entity to identify an account.

[0079] At block 504, an entity identifier may be assigned to the third-party entity. The assigned entity identifier conforms to the local format used by the processing server and the transaction processing system. For example, if the transaction processing system uses a 6-digit BIN to process transactions, the entity identifier assigned to the third party will be a 6-digit number similar to the BIN. By assigning an entity identifier that conforms to the local format, transactions involving the third-party entity's account can be processed and routed using the transaction processing system's infrastructure.

[0080] At block 506, an application programming interface (API) of the processing server may be modified to identify an account identifier used by the third-party entity. For example, program code may be inserted into the API used by the processing server to parse parameters sent with the API call to determine the target account of the transaction and the third-party entity associated with the target account. The program code may also be modified to verify that the account identifier conforms to the account identifier scheme used by the third-party entity. For example, if the account identifier scheme uses email as the account identifier, the API may be modified to check that the received account identifier of the third-party entity is a correctly formatted email address that includes a string followed by an "@" followed by a domain name. If the account identifier scheme uses a 10-character alphanumeric string as the account identifier, the API may be modified to check that the received account identifier of the third-party entity is a 10-character alphanumeric string. The program code may also be modified to retrieve an entity identifier associated with the third-party entity so that subsequent processing and routing of the transaction can be performed using the entity identifier.

[0081] The mapping of entity identifiers to resource provider identifiers can be stored in a third-party entity identifier database (e.g., a mapping table). In some embodiments, the resource provider type and / or country associated with the third-party entity can also be stored. If account scopes for third-party entities are supported, the account scopes can also be stored. At least, if the entity identifier is unique for a specific resource provider identifier, the resource provider identifier can be used to retrieve the entity identifier. In some embodiments, a combination of a resource provider identifier and one or more of a resource provider type, country, and account scope can be mapped to a unique entity identifier. For example, if a third-party entity has multiple account scopes, a different entity identifier can be assigned to each account scope of the third-party entity. The entity identifier database can also store transaction parameters associated with the third-party entity. Transaction parameters can include, for example, accounting currency, settlement currency, transaction speed limit, transaction amount limit, and / or, for example, see Figure 3 Other parameters such as those described.

[0082] At block 508, the processing server may receive a transaction request for executing the transaction. The transaction request may include a resource provider identifier (e.g., name, category code, etc.) of the third-party entity and an account identifier of an account of the third-party entity (e.g., the target account for the requested transaction). The transaction request may be received as part of a transaction request API call invoked by the transaction initiator or sender. The transaction request may also include a transfer amount. In some embodiments, the transaction request may also include a resource provider type of the third-party entity, the resource provider type indicating the type of account provided by the third-party entity and / or the country associated with the account. In some embodiments, the transaction request may be received via a secure communication channel.

[0083] At block 510, the processing server may use the modified application programming interface to determine an entity identifier associated with the third-party entity. For example, the modified application programming interface may parse the transfer request to obtain the resource provider identifier of the third-party entity. In some embodiments, the resource provider identifier may be sufficient to retrieve the entity identifier associated with the third-party entity from a database of third-party entity identifiers. In some embodiments, the resource provider identifier may be combined with the resource provider type and / or country parsed from the transfer request to look up the entity identifier. In some embodiments, the account identifier parsed from the transfer request may also be used to determine the account scope to which the target account belongs and to retrieve an entity identifier unique to that account scope.

[0084] Figure 6A flow chart of a process 600 for processing transactions involving non-local accounts according to some embodiments is shown. Process 600 can be performed, for example, by core processing logic implemented using one or more computing devices of a transaction processor system, and the computing device performing process 600 need not be the same as the processing server that assigns entity identifiers to third-party entities. The process blocks of process 600 can be similar to those described above with reference to Figure 5 those described above, and therefore there is no need to repeat their detailed description.

[0085] At block 602, a transaction request is received for executing a transaction. The transaction request may include a resource provider identifier for a third-party entity and an account identifier for an account of the third-party entity. At block 604, an entity identifier assigned to the third-party entity may be determined based on the resource provider identifier for the third-party entity (e.g., by looking up the entity identifier using the resource provider identifier). The entity identifier may conform to a local format used by the processing logic of the transaction processor system. At block 606, validation may be performed to verify that the account identifier in the transaction request conforms to the account identifier scheme of the third-party entity. Transaction parameters for the third-party entity may also be retrieved, and it may be verified that the requested transaction is within the transaction parameters associated with the entity identifier. At block 608, the transaction is executed using the entity identifier that conforms to the local format used by the processing logic of the transaction processor system. For example, the transaction may be executed by performing routing, authentication, authorization, clearing, and settlement of the transaction using the assigned entity identifier.

[0086] The technology disclosed herein provides various technical advantages. For example, accounts not local to a processing system that traditionally could not be processed by the processing system can be routed and executed by the processing system without requiring overhaul of the processing system's infrastructure. Updates that may be required to support non-local accounts can be implemented at the API level at the interface between the processing system and external entities. Thus, there may be no need to update the processing system's internal core processing logic. The technology disclosed herein also extends the interoperability of accounts associated with different providers and different processing systems. This also allows account holders to take advantage of services and capabilities that might not otherwise be available through third-party providers.

[0087] The various computing devices, communication devices, computers, servers, etc. described herein may be implemented using one or more processors coupled to a memory that stores code or instructions that, when executed by the one or more processors, cause the device to perform one or more of the methods and processes described herein. Memory, storage media, and computer-readable media described herein for containing code or code portions may include any suitable media known or used in the art, including storage media and communication media, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing and / or transmitting information (e.g., computer-readable instructions, data structures, program modules, or other data), including RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage devices, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, data signals, data transmissions, or any other medium that can be used to store or transmit the desired information and can be accessed by a computer.

[0088] The methods, processes, and techniques described herein are exemplary in nature, and one or more of the steps or functions may be performed in an order different from those described herein, including one or more additional steps without specifically described functions, omitting one or more steps or functions, combining one or more steps or functions into a single step / function / component, splitting one or more steps into multiple steps / functions / components, and / or any combination thereof. Furthermore, one or more features from one embodiment may be combined with another embodiment without departing from the scope of the disclosed technology.

[0089] Any software components or functions described in this application can be implemented as software code executed by a processor using, for example, conventional or object-oriented techniques and using any suitable computer language (e.g., Java, C++, or Perl). The software code can be stored as a series of instructions or commands on a computer-readable medium such as random access memory (RAM), read-only memory (ROM), magnetic media such as a hard drive or floppy disk, or optical media such as a CD-ROM. Any such computer-readable medium can reside on or within a single computing device and can be present on or within different computing devices within a system or network.

[0090] One or more features of any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the present invention.

[0091] Unless specifically indicated to the contrary, the use of "a," "an," or "the" is intended to mean "one or more."

[0092] All patents, patent applications, publications, and descriptions mentioned above are incorporated by reference in their entirety for all purposes. No admission is made that they are prior art.

Claims

1. A method comprising: receiving an account identifier scheme used by a third-party entity to provide access to an account associated with the third-party entity, wherein the third-party entity is a mobile wallet service provider; assigning an entity identifier to the third-party entity based on the account identifier scheme used by the third-party entity, wherein the entity identifier assigned to the third-party entity conforms to a local format used by a processing system; Modifying an application programming interface (API) to recognize an account identifier of the third-party entity, wherein the application programming interface is modified to recognize the account identifier of the third-party entity by inserting code into the API to parse parameters sent with the API call to determine a target account for the transaction and the third-party entity associated with the target account; receiving a transaction request for executing a transaction, the transaction request including a resource provider identifier of the third-party entity and an account identifier of an account of the third-party entity, wherein the resource provider identifier of the third-party entity identifies a name of a resource provider; determining, using the modified application programming interface, the entity identifier assigned to the third-party entity; and The transaction is processed using the entity identifier assigned to the third-party entity. 2 . The method of claim 1 , further comprising verifying that the received account identifier complies with the account identifier scheme of the third-party entity. The method according to claim 1 , wherein the transaction request further includes a resource provider type of the third-party entity.

4. The method of claim 1 , further comprising storing a mapping of entity identifiers to resource provider identifiers in a third-party entity identifier database.

5. The method of claim 4, further comprising storing transaction parameters associated with the third-party entity in the third-party entity identifier database.

6. The method of claim 5, wherein the transaction parameters include a billing currency or a settlement currency associated with the third-party entity.

7. The method according to claim 5, wherein the transaction parameters include a transaction speed limit and a transaction amount limit.

8. The method of claim 7, further comprising verifying that the transaction is within the transaction speed limit and the transaction amount limit.

9. The method of claim 1, wherein the third-party entity has multiple account scopes, and wherein each account scope is assigned a different entity identifier.

10. The method of claim 1, wherein the entity identifier conforms to a bank identifier format.

11. A computing system comprising: one or more processors; as well as a memory storing code that, when executed by the one or more processors, causes the computing system to perform operations including: receiving a transaction request for performing a transaction, the transaction request including a resource provider identifier of a third-party entity and an account identifier of an account of the third-party entity, wherein the third-party entity is a mobile wallet service provider, wherein an application programming interface (API) is modified to recognize the account identifier of the third-party entity, the modification being performed by inserting code into the API to parse parameters sent with the API call in order to determine a target account for the transaction and the third-party entity associated with the target account; determining an entity identifier based on the resource provider identifier of the third-party entity, wherein the entity identifier is assigned to the third-party entity and conforms to a local format used by processing logic of the computing system, wherein the entity identifier is based on an account identifier scheme used by the third-party entity, wherein the resource provider identifier of the third-party entity identifies a name of the resource provider; verifying that the account identifier complies with the account identifier scheme of the third-party entity; as well as The transaction is performed using the entity identifier conforming to the native format used by the processing logic of the computing system.

12. The computing system of claim 11, wherein the resource provider identifier of the third-party entity is an alphabetic string and the entity identifier is a numeric string.

13. The computing system of claim 11, wherein the resource provider identifier comprises a different number of characters than a number of characters of the entity identifier.

14. The computing system of claim 11, wherein the operations further comprise retrieving transaction parameters associated with the entity identifier, and verifying that the requested transaction is within the transaction parameters associated with the entity identifier.

15. The computing system of claim 14, wherein the transaction parameters include a transaction speed limit or a transaction amount limit.

16. A method comprising: receiving a transaction request for performing a transaction, the transaction request including a resource provider identifier of a third-party entity and an account identifier of an account of the third-party entity, wherein the third-party entity is a mobile wallet service provider, wherein an application programming interface (API) is modified to recognize the account identifier of the third-party entity, the modification being performed by inserting code into the API to parse parameters sent with the API call in order to determine a target account for the transaction and the third-party entity associated with the target account; determining an entity identifier based on the resource provider identifier of the third-party entity, wherein the entity identifier is assigned to the third-party entity and conforms to a local format used by processing logic of a transaction processor, wherein the entity identifier is based on an account identifier scheme used by the third-party entity, wherein the resource provider identifier of the third-party entity identifies a name of the resource provider; verifying that the account identifier complies with the account identifier scheme of the third-party entity; as well as The transaction is performed using the entity identifier conforming to the native format used by the processing logic of the transaction processor.

17. The method of claim 16, wherein the resource provider identifier of the third-party entity is an alphabetic string and the entity identifier is a numeric string.

18. The method of claim 16, wherein the resource provider identifier comprises a different number of characters than a number of characters of the entity identifier.

19. The method according to claim 16, further comprising: retrieving transaction parameters associated with the entity identifier; as well as Verifying that the transaction being requested is within the transaction parameters associated with the entity identifier.

20. The method according to claim 19, wherein the transaction parameters include a transaction speed limit or a transaction amount limit.

Images