US20140214677A1 - Remittance system with improved service for unbanked individuals - Google Patents

Abstract

A service provider computer receives a request for a transfer of a remittance amount from a sender's payment card account to a recipient without an account. The service provider computer transmits a transaction authorization request and a hold on the sender's payment card account for the remittance amount via a payment card system to the sender's financial institution (FI), receives transaction request approval, and establishes a transaction data record. The service provider computer then transmits the transaction identification code to the sender, receives a transaction identification code and a transaction data record validity request from a receiving FI, provides the transaction data record, and receives the transaction identification code and a newly issued recipient payment card account number from the receiving FI. The service provider computer then initiates a payment transaction in a payment card system to route the remittance amount from the sender's payment card account to the recipient's newly issued payment card account.

Description

CROSS REFERENCE TO RELATED APPLICATIONS
• This continuation application claims priority to U.S. patent application Ser. No. 12/940,671 filed on Nov. 5, 2010, the entire contents of which are incorporated herein by reference.
BACKGROUND
• Embodiments disclosed herein relate to remittance systems. In particular, some embodiments relate to methods, apparatus, systems, means and computer program products for implementing a remittance system on the basis of a payment card system.
• Many individuals regularly send money to family or friends either domestically or across international borders. The total annual volume of international person-to-person remittances is measured in the hundreds of billions of U.S. dollars (including transactions that involve U.S. dollars and transactions that do not involve U.S. dollars) and is increasing from year to year.
• Conventional remittance channels may be expensive and/or potentially unreliable. To overcome these disadvantages, it has been proposed to base a remittance system on a payment card system, such as the very well known, worldwide system operated by MasterCard International Inc., which is the assignee hereof. In particular, MasterCard has introduced a service known as “MoneySend” by which remittances are routed from the remittance sender's payment card account to the remittance recipient's payment card account via the MasterCard payment system. U.S. published patent application No. 2008/0249929, also assigned to MasterCard, describes a remittance system based on a payment card system. The '929 published application is incorporated herein by reference.
• The present inventors have now recognized that a remittance system based on a payment card system may be enhanced to provide improved services for individuals who lack payment card accounts.
BRIEF DESCRIPTION OF THE DRAWINGS
• Features and advantages of some embodiments of the present invention, and the manner in which the same are accomplished, will become more readily apparent upon consideration of the following detailed description of the invention taken in conjunction with the accompanying drawings, which illustrate preferred and exemplary embodiments and which are not necessarily drawn to scale, wherein:
• FIG. 1 is a block diagram that illustrates a remittance system provided according to some aspects of the present invention.
• FIG. 2 is a block diagram that illustrates a computer system that may be operated by a service provider as part of the system ofFIG. 1.
• FIG. 3 is a block diagram that illustrates a computer system that may be operated by a receiving financial institution (FI) as part of the system ofFIG. 1.
• FIG. 4 is a flow chart that illustrates a process that may be performed in the system ofFIG. 1 in accordance with aspects of the present invention.
• FIG. 5 is a flow chart that illustrates other aspects of operations of the system ofFIG. 1.
DETAILED DESCRIPTION
• In general, and for the purpose of introducing concepts of embodiments of the present invention, the sender in a proposed remittance transaction may designate as a recipient an individual who does not have a payment card account. The sender may designate the sender's payment card account as the source of funds for the remittance transaction. A remittance service provider may initiate an authorization request in the payment card account system to place a hold on the sender's payment card account in an amount sufficient to cover the remittance transaction. The service provider may then issue a unique transaction identification code to identify the proposed remittance transaction and may establish a data file or record for the proposed transaction. The sender may receive the transaction identification code from the service provider and may communicate it to the recipient. The recipient may visit a branch office of a financial institution (the receiving FI) that participates in the remittance system. The recipient provides the transaction identification code to the receiving FI, which uses the transaction identification code to access the relevant data record in the service provider's computer system. The receiving FI then issues a new payment card account to the recipient and communicates the payment card account number for the new account to the service provider. The service provider initiates a payment transaction in the payment card system to route the funds to be transferred from the sender's payment card account to the recipient's (newly issued) payment card account. Subsequent remittances from the sender to the recipient may be routed directly in the payment card system to the recipient's payment card account.
• FIG. 1 is a block diagram that illustrates aremittance system100 provided according to some aspects of the present invention.
• At the heart of theremittance system100 is apayment system102. As will be seen, thepayment system102 operates to route and clear funds transfers from the payment card accounts of senders to the payment card accounts of recipients. One example of a suitable payment system is the Banknet system, which is well-known to those who are skilled in the art, and which is operated by the assignee hereof.
• A major strength of a payment system such as the Banknet system is that it interlinks numerous financial institutions around the world. In practice theremittance system100 may include many financial institutions that act as issuers of payment card accounts, but for purposes of illustration only two such FIs are shown inFIG. 1, namely the financial institution (sending FI104) that issued the payment card account of the sender of a remittance, and the financial institution (receiving FI106) that serves the designated recipient for the remittance. As indicated respectively at108 and110, the sendingFI104 and the receivingFI106 are both connected by suitable data communication paths to thepayment system102. In some cases, thereceiving FI106 may be located in a different country from FI104 so that any remittance transmitted between the twoFIs104,106 is an international remittance.
• Also shown as part of theremittance system100 is aservice provider112 that provides functionality in accordance with aspects of the present invention. Theservice provider112 may, for example, be a remittance services provider (RSP), and may be a point of contact between theremittance sender114 and theremittance system100. As will be understood in light of subsequent discussion, the service provider may initiate transactions in the payment system102 (as indicated at116), and may exchange information (as indicated at118) with the receivingFI106, to implement services that are provided in accordance with aspects of the present invention. Theservice provider112 may obtain its access to thepayment system102 under contract with thepayment system102 or alternatively may be directly affiliated with and/or operated by thepayment system102.
• Each block shown inFIG. 1, with the possible exception ofblock114, should be understood to represent the indicated entity and also one or more computers operated by the indicated entity. Thus, in addition to showing relationships among various parties that make up theremittance system100,FIG. 1 also depicts a network of computers that exchange information for the purpose of implementing remittance transactions in thesystem100.
• FIG. 2 is a block diagram representation of acomputer system202 that may be operated by theservice provider112, and that may effectively constitute theblock112 shown inFIG. 1. Some or all of the activities ascribed below to theservice provider112 may in fact be implemented by operation of thecomputer system202.
• Thecomputer system202 may be conventional in its hardware aspects but may be controlled by software to cause it to operate in accordance with aspects of the present invention.
• Thecomputer system202 may include acomputer processor200 operatively coupled to acommunication device201, astorage device204, aninput device206 and anoutput device208.
• Thecomputer processor200 may be constituted by one or more conventional processors.Processor200 operates to execute processor-executable steps, contained in program instructions described below, so as to control thecomputer system202 to provide desired functionality.
• Communication device201 may be used to facilitate communication with, for example, other devices (such as computers operated by thepayment system102 or the receiving FI106).
• Input device206 may comprise one or more of any type of peripheral device typically used to input data into a computer. For example, theinput device206 may include a keyboard and a mouse.Output device208 may comprise, for example, a display and/or a printer. (Input and/or output with the computer system may also or alternatively be via other channels, such as mobile telephone applications, SMS, web pages, etc.)
• Storage device204 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., magnetic tape and hard disk drives), optical storage devices such as CDs and/or DVDs, and/or semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices, as well as so-called flash memory.
• Storage device204 stores one or more programs for controllingprocessor200. The programs comprise program instructions that contain processor-executable process steps ofcomputer system202, including, in some cases, process steps that constitute processes provided in accordance with principles of the present invention, as described in more detail below.
• The programs may include anapplication210 that allows thecomputer system202 to handle remittance transactions as described herein. Another orrelated application program212 allows thecomputer system202 to update user profiles, as will also be described herein.
• Storage device204 may also store one ormore databases214 that contain data related to transactions initiated by theservice provider112, and/or data related to remittance services customers of theservice provider112.
• Thestorage device204 may also store other programs (not shown) that control operation of thecomputer system202, such as one or more conventional operating systems, device drivers, communications software, web hosting software, software for performing server functions, etc.
• FIG. 3 is a block diagram representation of acomputer system302 that may be operated by the receiving FI106 (FIG. 1). Thus thecomputer system302 may constitute theblock106 shown inFIG. 1. Some or all of the activities ascribed below to the receivingFI106 may be implemented via operation of thecomputer system302.
• In its hardware aspects, thecomputer system302 may be conventional, and similar to the hardware components described above in connection with thecomputer system202. The hardware aspects of thecomputer system302 will therefore not be further described, except to mention that thecomputer system302 may include aprocessor300 in communication with acommunication device301, astorage device304, aninput device306, and anoutput device308.
• Thestorage device304 may store anapplication program310 to control thecomputer system302 to handle remittance transactions in accordance with aspects of the present invention and as described herein. The storage device may also store anapplication program312 that manages issuance of payment card accounts in connection with remittance transactions, as described herein.
• Continuing to refer toFIG. 3, thestorage device304 may also store one ormore databases314 that contain data related to remittance transactions handled by thecomputer system302 and data related to payment card accounts issued by the receivingFI106. Thestorage device304 may also store other software programs for controlling thecomputer system302, such as one or more conventional operating systems, device drivers, communications software, etc.
• FIG. 4 is a flow chart that illustrates a process that may be performed in theremittance system100 in accordance with aspects of the present invention.
• At402 inFIG. 4, the sender who wishes to make the remittance transaction gets in contact with theservice provider112. For example, the sender may visit a store-front location operated by theservice provider112. Alternatively, the sender's contact with theservice provider112 may be via electronic communication. For example, the sender may operate a personal computer (not shown) or a smart mobile telephone (not shown) to establish a session with thecomputer system202 operated by theservice provider112. In such cases, it is to be understood that the sender may previously have enrolled as a user with theservice provider112 and thus may have an online user account that is stored and serviced by thecomputer system202. Thus, if the sender electronically contacts theservice provider112, the sender may do so by accessing his/her user account with thecomputer system202.
• At404, the sender provides information to the service provider to specify details of the remittance transaction that the sender wishes to undertake. For example, the sender may specify the amount of money to be transferred and the sender's payment card account that is to be used for funding the remittance transaction. In at least some cases, the latter information (sender's payment card account number) may previously have been stored in thecomputer system202 as part of the sender's user profile. It will be appreciated that the sender's payment card account number may identify a payment card account (e.g., a credit card account, debit card account or prepaid payment card account) that was previously issued to the sender by the sendingFI104. The transaction information provided by the sender also may identify the recipient, at least by name. For present purposes, it will be assumed that the recipient does not have a payment card account, and indeed does not have any kind of account with a financial institution.
• At406, theservice provider112 may initiate a transaction authorization request in thepayment system102. The transaction authorization request may be routed via thepayment system102 to the sendingFI104 using the payment card account number that identifies the sender's payment card account issued by the sendingFI104. The purpose of the transaction authorization request is to confirm the availability of funds or credit in the sender's account to support the proposed remittance transaction. Another purpose of the authorization request is to put a hold on the funds or credit in the sender's account, in the amount of the requested remittance, until the remittance transaction is completed.
• At408, theservice provider112 receives a response to the transaction authorization request. The response may be initiated via the sendingFI104 and routed via thepayment system102 back to theservice provider112. For present purposes it is assumed that the authorization response indicates approval of the transaction authorization request. If such is not the case, then the proposed remittance transaction may not go forward.
• At410, thecomputer system202 operated by theservice provider112 may set up a transaction file/data record that represents the proposed remittance transaction. For example, this may include establishing and assigning a unique transaction identification code for the remittance transaction. In addition to the identification code, the transaction data record may store the remittance amount, the date of the request, the sender's name and funding payment card account number and the recipient's name. In some embodiments, the transaction data record may also indicate the country and/or region/city/town to which the remittance is being sent.
• At412, theservice provider112 discloses the transaction identification code to the sender, with the expectation that the sender will provide the code to the recipient, who will in turn use the code to claim the remittance. At the same time, theservice provider112 may inform the sender of the identities of financial institutions in the recipient's area that participate in theremittance system100. That is, theservice provider112 may advise the sender as to the names of FIs that are able to serve as the receiving FI for the particular transaction.
• In some embodiments, a retailer or other nonbank entity may perform at least some of the functions ascribed herein to the receiving FI. Accordingly, the term “receiving FI” should be understood to include any party that facilitates delivery of the remittance at the receiving end. In some embodiments, the service provider may manage card issuance to the recipient on behalf of an FI, and the recipient may visit an affiliated retail location to obtain the remittance in cash form while the recipient's card is being issued and mailed to the recipient.
• At414, the sender communicates the transaction identification code to the recipient. This may occur, for example, via a telephone conversation, an electronic mail message or a text message. In the same message, the sender may inform the recipient about participating FIs available to serve as the receiving FI for the transaction. At the same time, the sender may inform the recipient as to the amount of the proposed remittance.
• At416, the recipient visits the branch location of one of the participating FIs. (Alternatively, the location to be visited by the recipient may be a retail location belonging to a service provider that has a relationship with one or more participating FIs.)
• At418, the recipient provides to the participating FI (now to be referred to as the receiving FI106) the transaction identification code that the recipient received from the sender. At the same time, the recipient may provide one or more personal identifying documents for himself/herself to the receivingFI106. For example, the identifying documents may include a driver's license or other form of government issued identification document. With these documents, the receivingFI106 may take steps to satisfy its “know your customer” (KYC) obligations as provided under governmental regulations.
• At420, thecomputer system302 operated by the receivingFI106 may use the transaction identification code to access the transaction data record that was generated for the transaction by thecomputer system202 operated by theservice provider112. For example, this may occur by thecomputer system302 accessing a web page hosted by thecomputer system202 for the purpose of facilitating remittance transactions and submitting the transaction identification code to thecomputer system202. With access by thecomputer system302 to the data record for the transaction, the receivingFI106 may recognize that the validity of the transaction is confirmed (block422,FIG. 4) and that funding is available and has been set aside for the remittance transaction. As part of confirming the validity of the transaction, the receivingFI106 may confirm that the identity of the recipient as stated in the transaction data record at thecomputer system202 matches the identifying document(s) provided by the recipient at the receiving FI branch location.
• At424, after confirmation of the validity of the transaction, the receivingFI106 may issue a payment card account to the recipient. This account may, for example, be a debit card account linked to a demand deposit account (DDA) that is also opened at the same time for the recipient at the receivingFI106, or alternatively the newly issued payment card account may be a prepaid payment card account. As part of the issuance of the recipient's payment card account, the receivingFI106 assigns a payment card account number that identifies the account for purposes of routing transactions to the recipient's account via thepayment system102.
• At426, the receivingFI106 communicates, to thecomputer system202 operated by theservice provider112, the payment card account number for the recipient's newly issued payment card account number. The communication from the receiving FI106 (from the computer system302) to thecomputer system202 may again identify the relevant remittance transaction via the transaction identification code so that thecomputer system202 recognizes that the payment card account number identifies a target recipient account for the remittance transaction.
• At428, and in response to receiving the recipient's payment card account number from the receivingFI106, theservice provider112 may initiate a payment transaction in thepayment system102 to route a transfer of funds from the sender's payment card account to the recipient's newly issued payment card account. The routing of the payment transaction in thepayment system102 may use the payment card account number communicated from the receivingFI106 to theservice provider112. It will be appreciated that the payment transaction consummates the remittance for which authorization was requested by theservice provider112 atstep406. As is explained in the above-referenced '929 published patent application, and as is known to those who are skilled in the art, a “payment transaction” in a payment card system is one in which funds are to be transferred via the payment card system from a funding FI to a target payment card account; this is in contradistinction to a conventional “purchase transaction” in a payment card system, in which funds flow in the opposite direction, i.e., out of the payment card account in question.
• At this point, the receivingFI106 may, in some embodiments, disburse some or all of the remittance to the recipient in cash, as indicated at430. The receivingFI106 may be willing to do this because (a) it effectively already has an assurance via theservice provider112 that a transfer of funds to the recipient's payment card account will be consummated shortly; and (b) the receivingFI106 may believe that it has obtained adequate proof of the recipient's identity. The disbursement of cash at this point may also make the remittance system attractive and convenient for the recipient, as part of the recipient's introduction to the system. In addition or alternatively, the receivingFI106 may issue a payment card to the recipient by which the recipient will be able to access the newly issued payment card account. However, in some embodiments, issuance of the payment card itself to the recipient may require a day or a few days for processing by the payment card supplier for the receivingFI106. For example, the payment card may be personalized by the payment card supplier and then mailed by the payment card supplier to the recipient's mailing address.
• At432 inFIG. 4, the payment transaction is routed, cleared and settled. This may take place in accordance with conventional payment card system practices for payment transactions. For example, the funds may be transferred from the sender's account to a settlement account at the sendingFI104, and then from the sending FI settlement account to the receivingFI106 for posting to the recipient's newly issued account. Then, at434, the funds transfer is credited to the recipient's account (e.g., to cover the cash disbursement that may have previously been made by the receivingFI106 to the recipient).
• At436, theservice provider112 may use the recipient's payment card account number, as provided by the receivingFI106, to update the sender's user profile to add the recipient and his/her payment card account number as a potential recipient for future remittance transactions. With this information added to the sender's user profile, the sender may be enabled to easily select the recipient for additional remittance transactions in the future, which may be readily routed from the sender's payment card account to the recipient's payment card account, in accordance with known techniques. The foregoing assumes that the sender has a user profile with theservice provider112. Alternatively, however, the service provider may communicate the recipient information (e.g., recipient's name and payment card account number) to another party (such as the sending FI104) to allow the other party to update the sender's user profile with the other party.
• The process as depicted inFIG. 4 assumes that the recipient claims the remittance within a fairly short time, say within a few days or a week. In some embodiments, the hold placed on the sender's payment card account for the remittance amount may only last for a limited number of days, and may be released at the end of that time, at which point the remittance transaction would be deemed “stale”, and would no longer be claimable by the recipient or supported by theservice provider112. However, there may also be a process available wherein the sender is able to renew the hold on his/her payment card account to extend the available life of the remittance transaction.
• One beneficial feature of the system may be that the funding is not charged to the sender's account until the remittance transaction is ready to be completed.
• With the process as described herein in conjunction withFIG. 4, a payment-card-system-based remittance system is operative to consummate a remittance transaction directed to a recipient who is not the holder of a payment card account at the time that the sender first launches the remittance transaction. With this process, the recipient selects the receiving FI from among participating locations, claims the remittance using a dedicated transaction identification code, and is issued a new payment card account by the receiving FI in aid of the current transaction. In this way the remittance system can conveniently serve a previously “unbanked” recipient, while transforming the recipient into a bank customer and holder of a payment card account. This also adds to the opportunities for the receiving FI to serve as the receiving end of remittance transactions for individuals who are not yet customers of the receiving FI.
• FIG. 5 is a flow chart that illustrates other aspects of operations of theremittance system100.Block502 inFIG. 5 represents the initial remittance transaction to benefit the previously unbanked recipient as depicted inFIG. 4.Block504 represents subsequent remittance transactions to the same recipient, which may use as a target payment card account the account that was issued to the recipient in connection with the transaction ofblock502. It will be appreciated that one or more of theblock504 remittance transactions may take place a week or more later than the initial remittance transaction ofblock502. These may be like conventional remittance transactions in a payment-card-account-to-payment-card-account remittance system.
• In embodiments described above, the remittance transaction may be funded from a payment card account that belongs to the sender. Alternatively, however, the funding may be from another source, such as cash delivered by the sender to the sending FI, or from a demand deposit account (DDA) or other account owned by the sender at the sending FI, or from an account at another institution. In the latter case, it may be advisable for the sender to have a relationship with the sending FI so that “know your customer” (KYC) requirements may be met.
• Processes portrayed herein as being performed by one computer may in practice be divided among two or more computers. Processes portrayed herein as being performed by two or more computers may in practice be performed by a single computer. For example, in the case of the receiving FI, one computer (e.g., a client computer) may be operated by an employee of the receiving FI to enter information about the recipient and the remittance transaction, in cooperation with a separate server computer (not shown; also operated by the receiving FI) which handles communication with the service provider, issuance of the new payment card account, maintenance of customer and account databases, etc.
• As used herein and in the appended claims, the term “computer” refers to a single computer or to two or more computers in communication with each other and/or operated by a single organization or by two or more organizations that are partly or entirely under common ownership and/or control.
• As used herein and in the appended claims, the term “processor” refers to one processor or two or more processors that are in communication with each other.
• As used herein and in the appended claims, the term “memory” refers to one, two or more memory and/or data storage devices.
• The flow charts and descriptions thereof herein should not be understood to prescribe a fixed order of performing the method steps described therein. Rather the method steps may be performed in any order that is practicable.
• As used herein and in the appended claims, the term “payment card account” includes a credit card account or a deposit account that the account holder may access using a debit card, or a prepaid payment card account. The term “payment card account number” includes a number that identifies a payment card account or a number carried by a payment card, or a number that is used to route a transaction in a payment system that handles debit card and/or credit card transactions. The term “payment card” includes a credit card or a debit card or a prepaid payment card.
• Although the present invention has been described in connection with specific exemplary embodiments, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art can be made to the disclosed embodiments without departing from the spirit and scope of the invention as set forth in the appended claims.

Claims (17)

What is claimed is:

1. A method comprising:

receiving, at a service provider computer, a request for a transfer of a remittance amount from a sender having a payment card account issued by a sender's financial institution (FI) to a recipient without a payment card account;

transmitting, by the service provider computer via a payment card system to the sender's FI, a transaction authorization request and a hold on the sender's payment card account in an amount to cover the remittance amount;

receiving, by the service provider computer via the payment card system, an approval of the transaction authorization request by the sender's FI;

establishing, by the service provider computer, a transaction data record identified by a unique transaction identification code and comprising the remittance amount, the date of the request, the sender's name, the sender's payment card account number and the recipient's name;

transmitting, by the service provider computer to the sender, the transaction identification code;

receiving, by the service provider computer from a receiving financial institution (FI), the transaction identification code and a transaction data record validity request;

providing, by the service provider computer to the receiving FI, the transaction data record;

receiving, by the service provider computer from the receiving FI, the transaction identification code and a recipient payment card account number of a payment card account newly issued to the recipient; and

initiating, by the service provider computer in a payment card system, a payment transaction to route the remittance amount from the sender's payment card account to the recipient's newly issued payment card account.

2. The method ofclaim 1, wherein transmitting the transaction identification code further comprises transmitting an identity of at least one receiving FI in the recipient's area to the sender.

3. The method ofclaim 1, further comprising:

transferring the remittance amount from the sender's payment card account to a settlement account at the sender's FI; and

transferring the remittance amount from the settlement account to the recipient's newly issued payment card account.

4. The method ofclaim 1, further comprising updating, by the service provider computer, a user profile associated with the sender with recipient account information comprising at least the recipient's name and the recipient payment card account number.

5. The method ofclaim 1, further comprising transmitting, by the service provider computer to the sender's FI, recipient account information comprising at least the recipient's name and the recipient payment card account number for updating of a user profile associated with the sender.

6. The method ofclaim 1, wherein the hold is valid for a predetermined time period, and wherein the remittance transaction is canceled when the recipient fails to claim the remittance amount before the predetermined time period expires.

7. The method ofclaim 6, further comprising, when the remittance transaction is canceled due to expiration of the predetermined time period, extending, by the service provider computer, the predetermined time period in response to a request by the sender.

8. The method ofclaim 1, wherein the remittance amount is charged to the sender's payment card account only upon consummation of the transfer.

9. The method ofclaim 1, wherein the sender's FI is in a first country and the recipient's FI is in a second country different from the first country.

10. An apparatus, comprising:

a processor;

a communication device operably connected to the processor; and

a non-transitory storage device operably connected to the processor, the storage device storing instructions configured to cause the processor to:

receive a request for a transfer of a remittance amount from a sender having a payment card account issued by a sender's financial institution (FI) to a recipient without a payment card account;

transmit, via a payment card system to the sender's FI, a transaction authorization request and a hold on the sender's payment card account in an amount to cover the remittance amount;

receive an approval of the transaction authorization request by the sender's FI;

establish a transaction data record identified by a unique transaction identification code and comprising the remittance amount, the date of the request, the sender's name, the sender's payment card account number and the recipient's name;

transmit the transaction identification code to the sender;

receive the transaction identification code and a transaction data record validity request from a receiving financial institution (FI);

provide the transaction data record to the receiving FI;

receive the transaction identification code and a recipient payment card account number of a payment card account newly issued to the recipient from the receiving FI; and

initiate a payment transaction in a payment card system to route the remittance amount from the sender's payment card account to the recipient's newly issued payment card account.

11. The apparatus ofclaim 10, wherein the instructions stored in the storage device for transmitting the transaction identification code further comprises instructions configured to cause the processor to transmit an identity of at least one receiving FI in the recipient's area to the sender.

12. The apparatus ofclaim 10, wherein the instructions stored in the storage device further comprise instructions configured to cause the processor to:

transfer the remittance amount from the sender's payment card account to a settlement account at the sender's FI; and

transfer the remittance amount from the settlement account to the recipient's newly issued payment card account.

13. The apparatus ofclaim 10, wherein the instructions stored in the storage device further comprise instructions configured to cause the processor to update a user profile associated with the sender with recipient account information comprising at least the recipient's name and the recipient payment card account number.

14. The apparatus ofclaim 10, wherein the instructions stored in the storage device further comprise instructions configured to cause the processor to transmit recipient account information to the sender's FI, the account information comprising at least the recipient's name and the recipient payment card account number for updating of a user profile associated with the sender.

15. The apparatus ofclaim 10, wherein the instructions for transmitting a hold on the sender's payment card account in an amount to cover the remittance amount further comprises instructions configured to cause the processor to enforce a predetermined time period for the hold causing cancellation of the remittance transaction when the recipient fails to claim the remittance amount before the predetermined time period expires.

16. The apparatus ofclaim 15, further comprising instructions stored in the storage device configured to cause the processor to:

notify the sender that the remittance transaction was cancelled due to expiration of the predetermined time period; and

extend the predetermined time period in response to a request by the sender.

17. The apparatus ofclaim 10, wherein the instructions stored in the storage device further comprise instructions configured to cause the processor to charge the remittance amount to the sender's payment card account only upon consummation of the transfer.

Images