Implementations generally relate to processing a transfer of funds, and more particularly, to electronically transferring funds from a provider account to a beneficiary account.
Point of sale payment transactions between consumer and merchants is well known. The transactions or “purchases” may be sales, leases, rentals, assignments, or licenses of the resources, where the consumer exchanges some form of currency (e.g., money or “points” in a loyalty program) with the merchant for the resources (e.g., goods or services) of the merchant. The transactions may be cashless such that currency is transferred from the accounts of consumers to the respective merchants. Examples of these consumer accounts include accounts that are issued to the consumers by financial institutions (“issuers”) within a transaction processing system.
Unlike payment transactions with merchants, consumers do not have similarly convenient options to electronically transfer funds to a beneficiary such as to a person or entity that may not have an established account in which to deposit the funds. For example, a consumer may want to transfer funds to an unbanked friend, an underbanked relative, or to a retailer without having to transfer the funds to an established account of the retailer. Here, the consumer would have to send a check or use conventional electronic funds transfer systems, such as a money order. For example, the consumer may have to get a money order from a bank by physically going to a money transfer agent, requesting the transfer of the money to a partnering transfer agent in the vicinity of the friend or relative, and asking the friend or relative to go to the partnering transfer agent to physically pick up the money. Moreover, if the money is converted into a different currency, the value of the money transferred may depreciate by the time the friend or relative goes to pick up the money.
On an international scale, remittance of funds across geographical borders is further complicated by the potential for abuse, such as money laundering or terrorist financing. Remittance can be difficult to track, thus making it a particularly attractive means to illicitly traffic funds.
Accordingly, it would be an advantage to provide solutions for electronically transferring funds.
In one implementation, a host in a transaction processing system receives a transfer request from a provider to electronically transfer funds from a provider account to a beneficiary account of a beneficiary. The host sends an authorization request to the issuer associated with the provider account and receives a response back from the issuer authorizing the funds transfer. The host sends to the provider a transfer code associated with the transferring of the funds that is to be included in a load request. The provider sends the transfer code to the beneficiary, for the beneficiary to include in the load request, which represents a request to load the funds into the beneficiary account. The host receives, from the beneficiary, the load request including the transfer code sent to the beneficiary. Prior to remitting the funds, the host determines if a transfer condition has been satisfied, such as by comparing the transfer code received in the load request with the transfer code sent to the provider, for example. In another example, the transfer condition may be that an identifier of the provider, the beneficiary, or their respective accounts is not on a money laundering watch list. When the transfer condition is satisfied, the host sends a remittance request to the issuer to transfer the funds from the provider account and the host sends data to the beneficiary issuer sufficient for the beneficiary issuer to facilitate the distribution of a personalized card associated with the beneficiary account. As such, a system opens any kind of payment card for any beneficiary account type, where the funds transfers terminates in a new beneficiary account opening, followed by funding of that new beneficiary account.
In another implementation, a server apparatus includes a server and a server readable medium. The server communicates with both an Internet network and a proprietary transaction processing network, including a provider issuer computing device (PICD) of an issuer associated with a provider account and a beneficiary issuer computing device (BICP) associated with the beneficiary issuer. The server readable medium includes stored server readable code that is executable by a processor apparatus. The server receives, via the transaction processing network, an authorization approval to transfer funds from a provider account of a provider to a beneficiary account of a beneficiary that is associated with a first identifier. The server receives, via the Internet, a load request from the beneficiary and a second identifier of the beneficiary. The server determines when a transfer condition is satisfied including authenticating the beneficiary by matching the first identifier with the second identifier. When the transfer condition is satisfied, the server forms a remittance request for delivery, via the transaction processing network, to the PICD. The server also forms a card generation request for delivery to the BICD via the transaction processing network for generation of a personalized card corresponding to the beneficiary account.
In yet another implementation, a machine has means for loading an account (e.g.; prepaid or another type of account) with funds. The machine receives an authorization approval from an issuer of a provider account to transfer funds from the provider account to a prepaid account that is to be activated and loaded in the future, for example, by a beneficiary. Thereafter, the machine receives an activation request and facilitates the activation of the prepaid account. The machine receives a load request to load the prepaid account and determines if the transfer conditions for the funds transfer is satisfied by, for example, matching a code received from the beneficiary with a known code for the beneficiary. When the transfer condition is satisfied, the machine sends a load request to the issuer of the provider account to transfer the funds from the provider account. As such, a system opens any kind of payment card for any beneficiary account type, where the funds transfer terminates in a new account opening, followed by funding of that new account.
Implementations will become more apparent from the detailed description set forth below when taken in conjunction with the drawings, in which like elements bear like reference numerals.
Referring to
Referring still to
The provider device 116, beneficiary device 118, host device 120, provider issuer device 122, or beneficiary issuer device 124, may each be a computing device (e.g., a special purpose computer) such as a server, a mainframe computer, a mobile telephone, a personal digital assistant, a personal computer, a laptop, an email enabled device, or a web enabled device, each having one or more processors (e.g., a Central Processing Unit, a Graphical Processing Unit, or a microprocessor) that executes an algorithm (e.g., software) to transfer funds by receiving data, transmitting data, storing data, or performing methods. Each device further includes input/output capabilities (e.g., a keyboard, a mouse, a stylus and touch screen, or a printer), and one or more data repositories (e.g., one or more hard disk drives, tape cartridge libraries, optical disks, or any suitable volatile or nonvolatile storage medium, storing any combination of databases, or the components thereof, in a single location or in multiple locations, or as an array such as a Direct Access Storage Device (DASD), redundant array of independent disks (RAID), virtualization device, . . . etc., structured by a database model, such as a relational model or a hierarchical model). The computing devices can also include wired and wireless communication devices which can employ various communication protocols including near field (e.g., “Blue Tooth”) and far field communication capabilities (e.g., satellite communication or communication to cellular sites of a cellular network), and which may support a number of services such as: Short Message Service (SMS) for text messaging, Multimedia Messaging Service (MMS) for transfer of photographs and videos, or electronic mail (email) access. In some applications, the computing devices can also include a cash register, a point of sale device, or a point of interaction (POI) device. Provider and beneficiary devices, in particular, can also include devices for reading magnetic strips and RFID devices. Provider and beneficiary devices can also include corresponding devices, including a payment card, a gift card, a smartcard, a smart media, a payroll card, a healthcare card, a wrist band, a machine readable medium containing account information, a keychain device, such as a SPEEDPASS® device commercially available from ExxonMobil Corporation, or a supermarket discount card, and can include a volatile or non-volatile memory to store information such as the account number, a provider name, account or other identifier.
The networks 108, 114, or other networks described in this application, may be public or private networks, and may include any of a variety of one or more suitable means for exchanging data, such as: the Internet, an intranet, an extranet, a storage area network (SAN), a wide area network (WAN), a local area network (LAN), a virtual private network, a satellite communications network, an Automatic Teller Machine (ATM) network, an interactive television network, or any combination of the foregoing. The networks may contain either or both wired or wireless connections for the transmission of signals including electrical connections, magnetic connections, or a combination thereof. Examples of these types of connections are known in the art and include: radio frequency connections, optical connections, telephone links, a Digital Subscriber Line, or a cable link. Moreover, networks may utilize any of a variety of communication protocols, such as Transmission Control Protocol/Internet Protocol (TCP/IP), for example.
In one example, the network 114 includes a private network transaction processing system that is or includes a system of the type operated by: American Express Travel Related Services Company, Inc; MasterCard International, Inc.; Discover Financial Services, Inc.; First Data Corporation; Diners Club International, LTD; Visa Inc.; and agents of the foregoing. In one particular implementation, for example, the transaction processing system is the VisaNet® system operated in part by Visa Inc., which can include one or more data centers for processing transactions, where each transaction can include up to 100 kilobytes of data or more. Accounts in the transaction processing system can include a debit account, a credit account, a charge account, a stored-value account, a demand deposit account (DDA), a prepaid account (e.g., a gift account, reloadable account, Flexible Spending Account, Healthcare Savings Account . . . etc.), or a loyalty account where points can be redeemed (e.g., 50 reward points in a loyalty program are equal to $US20 toward a purchase).
Referring again to
To verify and transfer funds, the data stored in the DB 130 of the host device 120 may include information about the users (the provider, the beneficiary, the host, and the issuers of accounts) of the funds transfer system 100, their respective communication devices, or the user's past usage of the funds transfer system 100. The information about the users may include: a profile for the provider; a profile for the beneficiary; or data transfer capabilities of each bidirectional communication channel within the funds transfer system 100, for example. To illustrate, a user profile of the provider may include data about each of multiple provider accounts of the provider or data about past usages of each of the provider accounts to remit funds within the funds transfer system 100.
During a transaction, when requesting a transfer of funds, the provider presents a corresponding provider account identifier to the host device 120, which forms an authorization request for the issuer of the provider account that includes transaction information about the transfer from the provider to the beneficiary. The transaction information may have several data fields. For example, as is known by those of ordinary skill in the relevant art, the data fields may include: a name of the provider, the account identifier (e.g., Primary Account Number or “PAN”), an expiration date of the provider device, a Card Verification Value (CVV), a Personal Identification Number (PIN), a discretionary code of the issuer of the account, a date, a time of the transaction, a merchant identifier (e.g., merchant indicator) of the corresponding merchant, data usable to determine a location of the merchant, a Point of Interaction (POI) identifier, a total transaction amount, a Universal Product Code of the resource being purchased, a Stock Keeping Unit of the resource being purchased, a promotion code, an offer code, or a code corresponding to the financial institution associated with the provider.
To facilitate transfer of funds from the provider account to the beneficiary account, the host device 120 may send the funds transfer request as an authorized request to the provider issuer device 122 in order to transfer funds out of the provider account into the beneficiary account. The provider issuer device 122 may analyze the authorization request and form an authorization response for delivery back to the host device 120 via the network 114. The authorization response may include an authorization of the funds transfer or a decline to authorize the funds transfer. The provider issuer device 122, or the host device 120, may authorize the funds transfer after a determination that the account has sufficient funds to cover the funds transfer.
The funds can then be removed from the available balance of the provider account such that the provider no longer has access to the removed funds. When processing funds transfer, the funds can be cleared and settled and automatically transferred to the beneficiary account, after any transfer conditions specified for the transaction, discussed below, are satisfied. For example, prior to finalizing the remittance to the beneficiary account, the beneficiary may first be authenticated; the currency exchange rate may be compared with a threshold exchange rate; or the identifier of the provider, the beneficiary, or their respective accounts may be compared against data in a money laundering watch list. Moreover, if the transfer conditions are not met, then the funds may spring back so that they are transferred to a different account specified by the provider. To this end, the transfer of funds from the accountholder to the beneficiary may afford the benefits and protections associated with authorization requests, authorization responses, fraud analyses, data mining capabilities, loyalty program incentives, and funds transfer guarantees associated with payment transactions upon the accounts to merchants within the transaction processing system as known by those of ordinary skill in the art. The settlement of the transaction, for example, may include depositing an amount of the transaction settlement from a settlement house, such as a settlement bank, into a clearinghouse, such as a clearing bank. There may be intermittent steps in the foregoing process, some of which may occur simultaneously. The transaction processing system will preferably have network components suitable for scaling the number and data payload size of transactions that can be authorized, cleared and settled in both real time and batch processing. These include hardware, software, data elements, and storage network devices for the same. Thus, a typical payment transaction involves various entities to request, authorize, and fulfill processing the payment transaction.
During funds transfer transactions, the host device 120 may maintain a log or history of the transactions as they pass through the funds transfer system 100. The transaction log may be later analyzed or mined. In one implementation, the host device 120 may store the transaction information received during the processing of the transaction in the DB 130, such as: the transaction information received in the authorization request, the authorization response, or data received during the clearing and settlement process. The data corresponding to the transaction can also include information about offers, coupons, rebates, rewards, loyalty, discounts, returns, exchanges, cash-back transactions, etc. The data concerning transactions can also be stored in the DB 130, and can be data mined and used for advertising, merchant offers, account holder and merchant loyalty incentives and rewards, fraud detection and prediction, and to develop tools to demonstrate savings and efficiencies made possible by use of the transaction processing system.
Referring to
At step 302, the provider uses the provider device 116 to access a web site associated with the host device 120 via the network 108. The web site is rendered through a user interface allowing the provider to designate the beneficiary and other data for the transfer of funds as shown in
The provider may select other features for the funds transfer. For example, as depicted in user interface 500 of
At step 304 of
In another implementation, the transfer condition may be a designated currency exchange rate. For example, the transfer conditions may be that the currency exchange rate between United States dollars and English pounds should be equal to or greater than $US2/£1 on the day of loading of the beneficiary account. Here, if the currency exchange rate is below $US1/£1 on the day of receipt of the loading request then the funds are not loaded. Alternatively, or in combination, the remittance can be set to automatically occur upon the satisfaction of the transfer condition. In the above example, the remittance can be set to occur on the first subsequent day that the currency exchange rate is equal to or greater than $US2/£1. Other transfer conditions are also applicable, such as specified funds transfer fee thresholds, transmission security setting of the beneficiary device 118, threshold frequency of load requests made, or other transfer conditions.
Any of the users of the funds transfer system 100 or method 200 may designate the transfer conditions for the funds transfer. For example, the host or the provider issuer may designate one of the transfer conditions to be a maximum amount of currency for the funds transfer within the method 200 (e.g., a upper threshold of $US1000). In another implementation, the transfer condition may require verification that none of the participants or accounts that are parties to a transfer are suspected or known to be involved in money laundering. This transfer can be achieved by comparing identifiers of the provider, the provider account, the beneficiary, or the beneficiary account to a money laundering watch list that delineates individuals, entities, accounts, or other identifiers that are known or expected to be associated with money laundering, or by comparison to an anti-money laundering watch list that delineates individuals, entities, or accounts that are known not to be associated with money laundering. In another example, the beneficiary issuer may designate one of the transfer conditions to be a specified currency such that the beneficiary issuer will only process funds transfers that are for a particular currency (e.g., dollars or pounds). In yet a further example, the beneficiary may designate one of the transfer conditions to be a designated beneficiary account, such that the beneficiary will not accept a funds transfer unless it is to a specified beneficiary account.
Predetermined business rules may dictate how the transfer conditions or spring back conditions are applied. For example, the provider, the beneficiary, the host, the provider issuer, or the beneficiary issuer may have previously set up the predetermined business rules that dictate an algorithm for determining whether a transfer condition is satisfied or if there is a transfer condition hierarchy (e.g., if transfer condition 1 is satisfied then transfer condition 2 need not be satisfied) such as a required sequential flow of satisfaction of transfer conditions (e.g., a chronology dictating a temporal sequence of satisfaction of the transfer condition 1 before satisfaction of transfer condition 2).
Alternatively, or in combination, the predetermined business rules may dictate a scoring system for the transfer conditions. For example, if a first transfer condition is satisfied, a score is given to the request to transfer funds. The satisfaction or dissatisfaction of a second transfer condition then augments the score. This continues until the relevant transfer conditions are analyzed. The score can be used to determine whether to proceed with or halt the funds transfer at any point throughout the funds transfer process (e.g., the method 200). For example, the host may determine a score associated with the satisfaction or dissatisfaction of the money laundering transfer condition described above. The host device 120 may transmit this score to the provider issuer device 122, which may use the score when approving or denying authorization for the funds transfer from the provider account. In another example, the host device 120 may transmit the score to the beneficiary issuer device 124, which may use the score to determine whether to approve or deny the transfer of funds to the beneficiary account. Therefore, the users of the funds transfer system 100 may dictate the transfer conditions and their application to effectuate a transfer of funds from the provider account to the beneficiary account.
Referring to
The host device 120 submits an authorization request to the provider issuer device 122 via network 114 within the method 200 to authorize the transfer of the funds from the provider account. The provider issuer may analyze characteristics of the provider account in order to determine whether to authorize or decline the transfer of funds. For example, the provider issuer may check the available balance of the provider account, check a credit limit of the provider account, or run fraud analysis algorithms prior to determining whether to authorize the transaction. At step 904, the host device 120 receives the authorization response from the provider issuer device 122, including the determination of the provider issuer to authorize or decline the funds transfer.
At a step 906, if there are no transfer conditions on the funding, the funds are transferred (e.g., in real time), and are therefore remitted to the identified beneficiary account at step 908, where the sub-method 900 and the method 300 end. Alternatively, if the funds transfer is conditional then the sub-method 900 moves from step 906 to a step 910.
In some implementations, although the funds are not transferred into the beneficiary account until the transfer condition is satisfied, the provider no longer has access to the funds once the funds transfer is authorized by the provider issuer. Here, at step 910, the host device 120 facilitates transferring the funds from the provider account to a temporary account (e.g., escrow) or suspending the funds in the provider account until such time that the funds can be transferred to the beneficiary account or another provider designated account (“spring back” option, above, to a provider account or a charity account). For example, the authorization request sent from the host device 120 to the provider issuer device 122 may include sufficient information for the provider issuer to remove the funds from the provider account and place the funds into a separate, temporary account that is inaccessible to the provider. To illustrate, the authorization request may include the account numbers of each of the provider account and the temporary account with a request to transfer the funds from the former to the later. In another illustration, the host device 120 may send a separate transmission to the provider issuer device 122 with instructions to transfer the funds to a temporary account of the provider issuer's choosing.
Alternatively, or in combination, the host may facilitate suspending the funds in the provider account such that the funds remain in the provider account but the provider no longer has access to the funds. For example, the authorization request from the host device 120 may include sufficient information for the provider issuer to maintain the funds in the provider account but to remove the funds from the available balance of the provider account. This process is akin to funds suspension in payment transactions with merchants. In a payment transaction, an issuer may remove a purchase amount from an available balance of an account for a period of time, typically two to three days, until the merchant clears and settles the transaction. After clearing and settling of the payment transaction, the funds are removed from the account and transferred to the acquirer of the merchant. Similarly, here, the funds may be suspended in the provider account for future transfer to the beneficiary account; however, unlike the payment transaction, the release of the suspended funds is based on the satisfaction of the transfer condition or the spring back condition.
Referring back to
Referring back to
Although sub-method 300 depicts the provider receiving the transfer code to relay to the beneficiary, other implementations are also possible. For example, the host device 120 may send the transfer code to the beneficiary device 118 directly without having the provider notify the beneficiary of the transfer code. In yet another implementation, the beneficiary receives the transfer code and relays the transfer code to the provider to forward to the host device 120. To illustrate, the beneficiary may physically go to a prepaid card distributor to obtain a new prepaid card contained with a sealed envelope that also includes the transfer code. The beneficiary then informs the provider of the transfer code contained in the envelope. The provider, in turn, sends the transfer code to the host device 120 when making a request to transfer the funds (e.g., at step 306,
Referring now to
At step 602 of
To begin the process of claiming the funds, the beneficiary submits a load request to the host device 120 at step 604 by, for example, accessing the transfer web site at host device 120 through a beneficiary device 118 which, as discussed above, can be a web-enabled or other network device such as a computer, cell phone, or Personal Digital Assistant (PDA). Here, if the beneficiary was informed of the transfer code, as described above, the beneficiary also supplies the transfer code to the host device 120. For example, the beneficiary may enter the transaction code in an entry field 702 of user interface 700 for delivery to the host device 120 as part of the load request. The host device 120 may utilize the received transfer code to authenticate the beneficiary by matching the received transfer code from the beneficiary with the transfer code sent to the provider (step 306,
Referring to
Referring to
At step 608 of sub-method 600, the beneficiary designates data for the funds transfer. For example, the beneficiary may designate a currency for the redeemed funds, a location to physically redeem the funds, or the beneficiary may designate the beneficiary account. To illustrate, the beneficiary may select a currency in which to redeem the funds or a location at which to redeem, as shown at data entry elements 806 and 808, respectively, of user interface 804 in
Similarly, the beneficiary may designate the beneficiary account at step 608. If the beneficiary has registered beneficiary accounts with the funds transfer system 100 or method 200, the beneficiary may select to transfer the funds to one of these existing accounts, as depicted in data entry element 802 of user interface 800 in
Referring to
In one implementation, the host device 120 facilitates the activation of the new beneficiary account upon receiving an activation request from the beneficiary device 118. For example, the beneficiary device 118 sends an activation request to the host device 120 including an account number embossed on a newly obtained prepaid card, such as by entering the account number into a data entry field of a user interface within the website hosted by the host device 120. The host device 120, in turn, forwards the activation request to the beneficiary issuer device 124 via the network 114 (e.g., Internet or private network such as VisaNet®). The beneficiary issuer device 124 activates the beneficiary account and submits an activation confirmation back to host device 120. Other means for activation of a new beneficiary account are also applicable. For example, in some applications, the beneficiary device may be operated by a merchant. Here, the beneficiary may transmit the activation request to the host device 120 via a merchant device such as a point of sale terminal that is communicatively connected with the newly obtained prepaid card. To illustrate, the beneficiary may swipe the newly obtained prepaid card at the Point of Sale (POS) terminal of the merchant, such as a supermarket. The activation request may be transmitted from the POS terminal to merchant's financial institution, which then forwards it to the host device 120 via Network 114. After the new beneficiary account is activated, the sub-method 1000 moves from step 1008 to step 1010.
At step 1010, the host device 120 determines whether the transfer condition(s) have been satisfied. As stated previously, predetermined business rules dictate the hierarchy or sequence for satisfaction of the transfer conditions. As with the transfer condition of authenticating the beneficiary using the transfer code above, the host device 120 may compare data received in the load request with known data stored in the DB 130 to find a match at step 1010. For example, the provider may have designated that the beneficiary must request the transfer of funds by a predetermined date, depicted as Jun. 15, 2010 in data entry element 509 of
If the transfer condition is satisfied, the sub-method 1000 moves from the step 1010 to a step 1012 where the funds are remitted to the beneficiary account and a notification is sent to either or both the beneficiary and the provider at subsequent step 1014 (via off-page reference G to either or both step 310 of
At the step 1016, a query determines if there is a spring back provision to the funds transfer. Here, if there is a spring back provision and the spring back condition is satisfied, then the funds are routed, at step 1020, to another account specified by the provider, such as back to the provider account or another account (e.g., an account of a charity organization). Here, the host device 120 sends a spring back request to the provider issuer device 122. The provider issuer device 122 may then release the suspended funds, for example, so that the funds return to the available balance of the provider account. Alternatively, or in combination, the provider issuer device 122 may transfer the funds from the temporary account to an account of a charity organization or an account of another beneficiary.
On the other hand, if there is no spring back provision or the spring back condition is not satisfied, the funds are disbursed according to contractual agreements at a step 1018. For example, the provider issuer device 122 may be notified that the transfer condition is not satisfied, such as where the dissatisfaction is caused by the expiration date having passed. The contractual agreement may be that the funds then become the property of the provider issuer or the funds are to escheat to a government organization.
In yet another implementation, the provider transfers funds to an account of the beneficiary that is associated with a card (e.g., plastic card). As described above, the provider device 116 requests to transfer the funds from the provider account to the beneficiary account. Here, however, the beneficiary may not access the funds until a card is issued to the beneficiary and activated by the beneficiary. The card may be issued, for example, by a money transfer agent or distribution partner, such as a bank or a supermarket. The distribution partner may have an automated system, such as a kiosk or Automatic Teller Machine.
The table below delineates exemplary steps that can be taken to transfers funds to an account of the beneficiary that is associated with a card.
In yet another implementation, the host facilitates the funds transfer from the provider account to a new beneficiary account using a Master Account that is identified by a Master Account Number, and can be associated with any number of currently existing or subsequently activated beneficiary accounts. Here, a first provider requests a funds transfer to a beneficiary. After the transfer condition(s) are satisfied, the beneficiary issuer opens the Master Account for the beneficiary. The Master Account may then be associated with currently existing or subsequently activated beneficiary accounts. In this manner, multiple requests to transfer funds from different providers, for example, to the beneficiary may be processed in the funds transfer system 100.
To illustrate, a first provider may utilize the provider device 116 to log onto a website hosted by the host device 120 to transfer funds to a beneficiary that does not have a beneficiary account or a Master Account established with the funds transfer system 100. The first provider may select an account of the first provider from which to withdraw funds (
The first provider may then make a funds transfer request. Here, the host computer 120 sends an authorization request to the first provider's issuer (e.g., the provider issuer device 122) and receives and authorization response back. If the transfer is authorized, the funds are eligible to be transferred to the designated account or held in escrow depending on whether the transfer conditions are satisfied.
In this example, an initial transfer condition may be to validate or authenticate the beneficiary prior to the funds being transferred out of escrow (or the provider account). For example, the beneficiary may provide the GUID to the distribution partner agent or enter the GUID into a terminal that is communicatively connected to the host device 120. As stated previously, the agent may locally validate the beneficiary, such as by checking the name of the beneficiary against a list of beneficiaries authorized to receive respective cards. Alternatively, or in combination, the validation may occur remotely from the distribution partner facility. Here, a transmission may include the GUID or other identifying data of the beneficiary that is then compared by the host device 120 or a third party and matched against identifiers of corresponding authorized beneficiaries. If a match is found, the beneficiary is authorized to activate the account and access the corresponding transferred funds.
Alternatively, or in combination, the initial condition may be that an identifier (e.g., name, phone number, or other GUID) of the first provider or the beneficiary, for example, is not included in a money laundering watch list. Here, an analysis can be conducted to determine if the initial money laundering transfer condition is satisfied. The host or a third party may compare the identifier(s) of the first provider or beneficiary against the money laundering watch list. If a match is not found, then the initial transfer condition is satisfied. In one implementation, the third party may be a government agency that conducts the validation or conducts one of the validations of the beneficiary. For example, the government agency may receive a transmission including the GUID or other identifying data of the beneficiary to match against a watch list (e.g., such as the money laundering watch list). If the beneficiary GUID matches data on the watch list, the government agency may notify the host device 120 to decline the funds transfer. Subsequently, the host device 120 may send a transmission to the distribution partner indicating that the beneficiary has been declined and access to the funds is denied. The decline may occur even if the host device 120 had previously validated the beneficiary.
If the funds transfer conditions are satisfied, the beneficiary receives a notification of the funds transfer from the first provider, such as by receiving an email or SMS notification that the money transfer is pending. The beneficiary may use the beneficiary device 118 to request activation of the Master Account and the new beneficiary account from the beneficiary issuer device 124, via the host device 120. The beneficiary issuer device 124 may activate the Master Account and the beneficiary account and submit a response to the activation request back to the beneficiary device 118.
The host device 120 may, in turn, transmit sufficient data to the beneficiary issuer device 124 for the beneficiary issuer to facilitate the distribution of a personalized card to the beneficiary. The beneficiary may facilitate the distribution of the personalized card by contacting the distribution partner to generate an encoded or personal card. To this end, the distribution partner may have a stock of blank cards or previously embossed cards. The distribution partner may have a terminal that is coupled to an embossing or printing machine. For example, the embossing or printing machine may prepare the card associated with the new beneficiary account by embossing or printing a number of the new beneficiary account or other information onto one of the cards in the stock. The terminal may then issue the card to the beneficiary. The Master Account can then be used for subsequent funds transfers to other beneficiary accounts (e.g., sub-method 300 of
The various steps or acts in a method or process may be performed in the order shown, or may be performed in another order. Additionally, one or more process or method steps may be omitted or one or more process or method steps may be added to the methods and processes. An additional step, block, or action may be added in the beginning, end, or intervening existing elements of the methods and processes. Based on the disclosure and teachings provided, a person of ordinary skill in the art will appreciate other ways or methods for various implementations. Moreover, it is understood that a functional step of described methods or processes, and combinations thereof can be implemented by computer program instructions that, when executed by a processor apparatus, create means for implementing the functional steps. The instructions may be included in computer readable medium that can be loaded onto a general purpose computer, a special purpose computer, or other programmable apparatus.
In certain implementations, instructions are encoded in computer readable medium wherein those instructions are executed by hardware to perform one or more of the steps of the flowcharts seen in
It is understood that the described examples and implementations are for illustrative purposes only and that various modifications or changes in light thereof will be suggested to persons skilled in the art and are to be included within the spirit and purview of this application and scope of the appended claims.
This application claims priority to, and the benefit of, U.S. Application Ser. No. 61/318,194, filed on Mar. 26, 2010, titled “Electronic Account-To-Account Funds Transfer,” which is incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
61318194 | Mar 2010 | US |