Patent Application
20220172209
The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.
While about three billion endpoints are serviced by the major card processing networks, that is only about one half of world's adults with bank accounts. Some countries have low payment card penetration or have regulatory restrictions that limit payment instrument usage.
Features and advantages described in this summary and the following detailed description are not all-inclusive. Many additional features and advantages will be apparent to one of ordinary skill in the art in view of the drawings, specification, and claims hereof. Additionally, other embodiments may omit one or more (or all) of the features and advantages described in this summary.
In some embodiments, a system allows financial transfers between endpoints that are outside a traditional card-based financial system. A set of application program interfaces (APIs) allow non-card payment instructions to be generated and routed between endpoints over networks previously restricted to card payment processing only. A single send payouts API provides domestic and cross-border payout options to both card-based recipient endpoints and non-card based recipient endpoints. A payouts service provider (PSP) may be assigned a pseudo or token bank identification number (BIN) for the purpose of having a routable destination in the system. The PSP may then use its own information about a participating recipient to transfer funds to the recipient's account.
For new endpoints, minimum information for anti-money laundering (AML) and know your customer (KYC) regulations may be required. Additionally, overall processing efficiency may be improved when a pre-check of an endpoint is performed. Therefore, prior to initiating a financial transaction, an endpoint inquiry may be sent to a recipient PSP to verify the account destination information as well as gather AML and KYC information. These data may be used to populate many required data fields for new customers as well as validate endpoint availability for all transfers. After this initial data gathering step, the actual transfer may be initiated.
The figures depict a preferred embodiment for purposes of illustration only. One skilled in the art may readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.
A system that allows distribution of funds over a card-based transaction network uses assigned pseudo identities as a proxy that allows institutions outside a card-based network to send and receive payments to participating bank accounts or third party payment accounts, such as WeChat pay. Any number of Payment Service Provider/Payouts Service Provider (PSP) may each be assigned a pseudo bank identification number (BIN) that allows payments made via a card network to be routed to the PSP with additional instructions that allow the PSP to identify the requested endpoint.
Turning to
A Payouts Service Provider (PSP) 108 may have a relationship with one or more banks 110 hosting one or more recipient accounts 112. In some cases, the bank 110 may be an alternate financial institution such as a digital wallet provider or other payment system. In some embodiments, the PSP 108 may be a financial service supporting cross-border payments, such as Earthport. An acquirer 118 may be a participant in the final settlement of the transaction. In some embodiments, the requestor/payor 104 and the acquirer 118 may be the same entity. As used herein, the “originator” is the requestor/payor 104 (or the acquirer 118 if the same entity) that connects with application program interfaces (APIs) of the transaction processor 106 to originate push-to-account payouts (see further details below). A database 120 that stores lookup information as well as onboarding data for non-standard endpoints may be used by the transaction processor 106 to identify when the requested endpoint, such as recipient account 112, requires extended handling.
Onboarding is the process of adding a client/PSP to the payment network. In an exemplary onboarding process, a PSP may be assigned its BIN. There may be one BIN per country/currency to be supported. A recipient base URL may also be required. This is a URL provided by the PSP to which HTTP messages may be sent. The client may also provide public domain and IP addresses that may be used by the transaction processor for an approved list to which to send traffic. The client may be provisioned with IP addresses from which to expect traffic for firewall setup. Security information such as key identifiers and one or more shared secret keys may be provisioned for encryption, decryption, and signing. In some cases, the establishment of communication between the parties may involve mutual SSL authentication based on a root and intermediate certificates tied to a trusted certificate authority (CA).
The database 120 may also serve as an onboarding database and may be used to store information previously gathered about PSPs and individual recipients including local and foreign government restrictions. Onboarding may include not only assignment of a BIN to a PSP, but also assignment of a virtual PAN to the PSP for use as a proxy in an existing transaction, allowing routing to the correct PSP. The pseudo-BIN/pseudo-PAN combination allows reuse of existing rails for carrying transaction payloads between endpoints as well as for settling transactions.
In operation, a request 1 for funds transfer may be made to the transaction processor 106 with the request including sender and recipient details and one or more additional fields or a pseudo-BIN/pseudo PAN according to a send payout application program interface (API) or a push API front end 114. Although the following discussion focuses on funds transfer to non-card based endpoints, the send payout API/push API 114 may be a single unified API that receives funds transfer requests and assists in pushing funds to both card-based and non-card based accounts. The transaction processor 106 may consult the database 120 to allow qualification of the requested endpoint. In some embodiments, the request may include only a recipient identifier and the transaction processor 106 may be responsible to identify the PSP 108 associated with a particular endpoint.
The transaction processor 106 may access a second push API 116 associated with the PSP to populate a push message to the PSP 108. As discussed above, the PSP 108 may have been through an onboarding process that sets up access points and cryptographic security for use with the transaction messages. The PSP 108, in near real time, may check its information about the recipient account 112 for account status and recipient details, in some embodiments, to return 3 a response to the transaction processor 106 acknowledging the request and providing an estimated posting date. The return response from the PSP 108 may ultimately be sent 4 to the requestor/payor 104.
Just as PSP's require onboarding, some transaction endpoints may also require onboarding which is a process that may require an initial participant to fill out a significant amount of detail related to end recipient details. These may include AML and KYC information for regulatory compliance. In addition, even previously approved recipients may have had changes to an account, been added to a watchlist, or have other factors that may affect the ability to deliver a payment. To address this problem, a look-ahead query may be presented that allows a number of those details to be returned to the originator, including account verification, legal status, routing information and some regulatory data. The look-ahead query, unlike a simple credit hold transaction, returns more than an issuer approval for funds, but may include data from the PSP about the intended recipient. This data may then be used for onboarding and subsequent account verifications and thereby greatly decrease the rate of rejected transactions.
Further information about the request and response are detailed below in Tables 1-3. The PSP 108, based on the information in the request, and having found no abortive information about the recipient account 112 may issue 5 the funds. Exemplary code for a request message for funds transfer including payment and recipient details is shown below.
Exemplary code for a response message indicating successful authorization, destination amount, and expected posting date to recipient's account is shown below.
Approved payouts may be sent to a settlement service. Settlement may occur after the transaction, following a normal (business as usual) settlement process where information about the transaction is shared 6 with an acquirer 118 and the PSP 108. After which, the funds may be transferred 7 from the acquirer 118 to the transaction processor 106 and subsequently transferred 8 to the PSP 108.
Several interfaces may be used for accomplishing extended reach funds transfers. A front-end API or send payouts API 114 may expose methods for receiving payment instructions for non-card transactions while still using existing messaging and settlement systems. Transactions may be processed between card networks, automated clearing house (ACH) networks, real-time transport protocol (RTP) networks, and digital wallet networks.
The receive-side Original Credit Transaction (OCT) API that enables push funds to card accounts may be expanded to include additional fields supporting transfers to non-card accounts via PSPs to provide the send payouts API. The additional fields may be parsed from those OCT fields not necessarily applicable to the payment.
Because a delay between transaction acceptance and settlement may still exist, an API may be developed to allow the modified OCT transaction supported by the API above to be reversed if at some point the transaction fails to settle. Such cases may include closing of the recipient account or a regulatory ban on the account, to name just two such reasons.
Advanced routing logic allows routing non-card payment instructions to PSP's based on various criteria including cost, country coverage, and delivery payment timeliness. This routing may be aided by the assignment of pseudo-BINs to the PSPs participating in the system. A pseudo-PAN may be assigned to the endpoint, associated with the PSP in the same way a PAN of a card holder may be associated with an issuer. For example, a non-card payment message may be routed to a PSP using its BIN while the payload may contain more than a prior card-based transaction to include client-specific information used by the PSP to complete the payment. The routing logic may base routing decisions on information such as, Sender country, Recipient country, Currency, BAI (transaction code), Amount, Payout method, and Merchant (CAID), if any. Digital wallet credentials may increase the number of fields over a current OCT payment payload.
An API hosted by a PSP may allow transaction requests to be received on behalf of a constituent, where the PSP then completes the payment and is responsible for the settlement of the transaction. The API may accept JSON requests using, for example, an HTTP Post method. In an embodiment, the elements of such an API may include, for the original request, exemplary methods shown below (see Table 1). API fields may include, for example, bank ID, bank country code, bank name, originator ID, originator name, merchant category code, bank address, amount, transaction currency code, local transaction date and time, first and last name if the recipient is an individual, company name if the recipient is a company, and recipient address. In each case, information beyond what is described may be present in the actual implementation.
API responses may include details provided by the PSP, including several fields repeated from the initial request (see Table 2).
A response code received at the push API 114 (or another API) from the push API 116 may provide code indicating the success or failure of a requested transaction, examples of which are shown in Table 3. Other success or failure codes may be included in the response in actual implementation.
Should a transaction be unsuccessful, the PSP 108 may request to return the funds to the originator via a return API 117. The return API 117 exposes methods for indicating the transaction to be refunded and, if available, the reasons (see Table 4 below).
The transaction detail object in the return API may include a reason for the return. Exemplary codes providing reasons for return are shown below in Table 5.
Responses to the request to return funds may include the API methods exemplified in Table 6 below.
A source field 156 may be used to designate a source of funds for the transfer. As indicated in the illustration, a default source may be set up, such as a bank account. In other embodiments, accounts from wallets or payment services may be uses as a source just as destination accounts may not be associated with a card issuer/acquirer. The ‘To Account’ field 158 may allow selection from a list although in other embodiments, free form entry of an account alias or account details may be supported. Once the entry data is entered, the ‘send’ button 160 may be used to initiate the transaction. The funds transfer application may include local field qualifiers, remote field qualifiers, or both. That is, data that has been entered may be checked for consistency and conformance to input formatting criteria as well as qualitative checks such as the source account having sufficient funds for the designated transfer amount. For example, a lookup module may access the requestor/payor 104 so that a determination may be made of the pseudo-BIN of the PSP 108.
Location optimizations may allow lower costs and quicker delivery by utilizing region, country, currency, and PSP information to select better routes for transactions and settlements. Both the source and destination characteristics are factored into decisions about routing, prepayments, and settlement choices.
A schematic representation of various APIs available on the transaction processor 106 or another server or processor of the extended reach system 100 is shown in
A return notifications API 175 includes protocols that allow the originator to receive notifications about payouts that get returned or rejected and the reasons for the return (see Table 5). A cancel payout API 176 includes protocols that allow the originator to request cancelation of an existing payout request provided the payout is still being processed. Responses to requests for cancelation include: 1) cancelation successful (payout has been returned), 2) cancelation request pending (not yet confirmed), and 3) cancelation unsuccessful. Additionally, a watchlist API 178 includes protocols for screening the payment sender and the recipient against global watchlists.
Turning to
A technical effect of the system and method of the present disclosure is the single, unified send payout API that includes fields to support domestic and cross-border financial transfers to both card-based accounts and non-card based accounts via PSPs, expanding the reach of the payment system. Multiple APIs are provided to support interactions between entities of the extended reach system to initiate and manage payouts to recipient endpoints. Another technical effect of the system and method of the present disclosure is the return of data by the destination PSP for use by the initiator to complete AML and KYC information, among others, for the onboarding process at the requestor/payor side. Another technical effect is the ability to pre-qualify the endpoint prior to a funds transfer being initiated. Yet another technical effect is the use of card-based payment rails for non-card based endpoints, such as simple bank accounts.
These techniques benefit both networks and end users. Networks may expand the endpoints available for transactions while end users may as much as double the destinations available for making payments for goods and services.
The figures depict preferred embodiments for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein
Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for the systems and methods described herein through the disclosed principles herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those skilled in the art, may be made in the arrangement, operation and details of the systems and methods disclosed herein without departing from the spirit and scope defined in any appended claims.
This application is filed under the Patent Cooperation Treaty claiming priority to U.S. provisional application No. 62/858,105 filed on Jun. 6, 2019.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US20/36366 | 6/5/2020 | WO | 00 |
| Number | Date | Country | |
|---|---|---|---|
| 62858105 | Jun 2019 | US |
