Patent Application
20180197167
Person-to-person (P2P) payment systems have become popular for transferring money between individuals. P2P payment systems provide many benefits, including convenient transfer of payments, as well as providing accessible electronic records of the payments. However, many P2P payment systems require that both the person making payment (payer) and the person receiving payment (payee) be enrolled with the system. Enrolling typically includes providing preferences, such as the payer account from which payment funds will be taken and payee account to which payment funds will be deposited.
The convenience of P2P payments is affected, however, when both parties have not already enrolled or pre-registered with the payment system. In those circumstances, one party (usually the payee) will need to go through the process of enrolling and providing preferences prior to receiving payment, which can delay the receipt of payment. Since the number of different P2P payment systems has increased in recent years, a payee may need either to have pre-registered or to register at the time the payment with a number of P2P providers, depending on which provider and system is being used by the payer. Some consumers are hesitant to provide financial information (such as account preferences) to a number of different entities because of the risk that such information might compromised (e.g., by hackers surreptitiously gaining access to the payment systems). Thus, a payer (or payee) may prefer to conduct most if not all of the payers transactions using only one or two preferred payment systems (to limit the risk that financial information might be compromised), which payment systems may not be the payment system preferred by the other party.
While some P2P payment systems may permit a payer to enter payee account information (so that the payee need not be registered with the system), the extra steps required of the payer to conduct the transaction (knowing how the payee would like to be paid and providing that information to the system) make the system less convenient for the payer to use.
Further, some consumers simply do not want to receive payments electronically, but rather prefer being paid either in cash or by check. Where a payee has not registered or does not want to register with a P2P system, a payer is not be able to achieve the benefits of using a P2P payment system.
Thus, current P2P payment systems are not always able to achieve features and advantages for which they are designed.
There is provided, in accordance with embodiments of the present invention, a network/system and method for providing for person-to-person payments, where payment can be provided to any payee (whether pre-registered or not) based on the preferences of the payee, but without the payer needing to know those preferences or having to provide them for purposes of completing the transaction.
In one embodiment, a person-to-person payment system for providing payment from a payer to a payee using a mobile device of the payer includes a payment setup system and a risk assessment system. The payment setup system is programmed for: enrolling the payer, including receiving from the payer an account identifier for identifying an account of the payer that is used to fund payment from the payer to the payee; receiving, through a payment messaging system, a payment request message from a payer device, the payment message request including a payment amount and payee identification information, the payee identification information including at least one of a payee phone number, a payee email address and a payee mailing address; determining whether the payee phone number and the payee email address have been provided, and whether at least one of the provided payee phone number and payee email address is usable to communicate with the payee; upon determining that the at least one of the provided payee phone number and payee email address is not usable to communicate with the payee, determining that a payee mailing address has been provided as part of the payee identification information, and generating correspondence to the payee using the payee mailing address; upon determining that the at least one of the provided payee phone number and payee email address is usable to communicate with a payee, sending an electronic communication through the payment messaging system to the payee device requesting that the payee select one payment method from a group of payment methods for receiving payment from the payer, the group of payment methods comprising: 1) receiving a paper check, 2) receiving a check image electronically, and 3) receiving an electronic deposit to an account of the payee; after selection by the payee, as the one payment method, for receiving a paper check or for receiving a check image electronically, providing the paper check or the check image to the payee; and after selection by the payee, as the one payment method, for receiving an electronic deposit to an account of the payee, receiving at the payment settlement system from a payee device an account identifier for identifying the account of the payee. The risk assessment system is programmed for: receiving from the payment settlement system at least the identifier for the identified account of the payer and the identifier for the identified account of the payee; and generating, in response to receiving the identifiers for the identified account of the payer and identified account of the payee, a risk score reflecting the degree of risk associated with the requested payment from the identified account of the payer to the identified account of the payee, and providing the risk score to a first financial institution maintaining the identified account of the payer. The payment system receives, from the first financial institution maintaining the identified account of the payer, and in response to the risk score, a message having a payment guarantee for the amount of the payment to a second financial institution maintaining the account of the payee, the payment guarantee based at least in part on the risk score. The payment guarantee is provided to the second financial institution maintaining the identified account of the payee in order to immediately credit the identified account of the payee with at least a portion of the amount payment.
A more complete understanding of the present invention may be derived by referring to the detailed description of the invention and to the claims, when considered in connection with the Figures.
There are various embodiments and configurations for implementing the present invention. One such implementation is shown in
The payment settlement system 100 includes a payment setup system 108 for setting up payment in response to payment information from a party to a transaction, a messaging system 110 used for receiving and generating messages as part of the payment process, an account management system 112 for managing information provided during enrollment and for maintaining a settlement account between banks (for purposes to be described in greater detail later), and a risk assessment system 114 that may be used to assess the risk of any payment transaction (for purposes also to be described in greater detail later). The payment settlement system 100 also maintains and manages several memory or database systems in order to carry out its functions, the databases including an enrollment database 120, a settlement account database 122, and a transaction database 124. In some embodiments, the databases 120, 122 and 124 may be accessed at a location remote from the payment settlement system 100.
The payment settlement system 100 communicates with the payer and payee over a communications network 130, which may include the Internet, dedicated telecommunications networks, or combinations thereof. The payer and payee may communicate with the network 130 using various electronic devices, such as mobile smart phones, personal computers, tablet computers and other similar devices, although in some embodiments, as will be described later, one party (e.g., the payee 104) may use the payment settlement system 120 for purposes of receiving payment without the use of an electronic device.
Also illustrated in
The operation of the various systems illustrated in
Through various messages handled by the messaging system 110, the payment settlement system 100 determines how to contact the payee 104 and determine how the payee would like payment made. One feature of the present invention is that the payee need not be enrolled with the payment settlement system, but rather can be reached through a phone number, email address or physical address provided by the payer 102. The payee can select, for example, payment to be made into a payee account at one of the banks 140, using the messaging system 110. As another example, the payee 104 may elect to receive a paper check through the mail. When the payee elects to have funds automatically or electronically transferred to an account, the risk assessment 114 may be used to assess the risk of the transaction. This risk assessment may be used by the bank of the payer to determine whether it is willing to guarantee (or make “a promise to pay”) the amount to the bank of the payee. Risk assessment may be accomplished, for example, by accessing the transaction database 124, which may include data pertaining to any payer account(s), any payee account(s), and transactions at those accounts. Based on analysis of that data, the risk assessment system can develop a risk assessment or score related to the payment transaction. The transaction database 124 may collect data across many financial institutions (such as banks 140) and accounts at those institutions, in order to have access to sufficient data to develop a risk assessment. One example of a risk assessment system and related databases can be found in U.S. Pat. No. 8,682,766, issued to Robin S. Love et al., commonly owned with the present application, and hereby incorporated by reference. The transaction database 124 may also store (for use independent of the risk assessment system 114) P2P payment transactions completed by the system 100 (e.g., stored as a record accessible by the payer or payee).
In alternative embodiments, where a less comprehensive risk assessment is acceptable, the risk assessment system 114 may simply request a “good funds” response from the payer bank, namely that the payer has sufficient funds in the account being used to fund the amount of the payment and that such amount has been either debited for the benefit of the payee or has been subjected to a “hold” so that the funds are committed for the P2P payment. In some embodiments, a “good funds” response may be used as part of broader risk assessment at the system 114, e.g., even though sufficient funds are available in the payer account, other elements of risk, such as the risk that someone other than the payer is attempting to make payment using the payer's identity, might be desired by the banks/parties involved.
The account management system 112 may be used to manage settlement accounts between the banks 140. For example, if the bank of the payee immediately credits the payee account based on a payer bank's guarantee or promise to pay, a settlement account between those two banks receives a credit for the payee bank, and a debit for the payer bank. The payment settlement system may reconcile the settlement account, for example, at the end of each day, such that any transfers posted between two banks (whether credits or debits) are accounted for, and a payment can made by any one bank to another bank in order to bring their settlement account to a zero balance.
It should be noted that the functions performed by payment settlement system 100 as just described relating to facilitating payments between a payer and a payee offer numerous advantages to the payer and payee, as well as improved and efficient operation of computing devices making up the payment settlement system 100. For example, the payer need not know the method by which the payee would like to receive payment, but simply identifies a method of communicating with the payee in order for the payee to make that selection. Furthermore, the payee need not have registered or pre-enrolled with the payment settlement system, but only needs to interact with the payment settlement system when it wants to be paid and then only one time for purposes of receiving a payment. Furthermore, when a payer bank determines that the transaction is an acceptable risk level (as determined by the risk assessment system 114), payment can be immediately credited to a payee account for access by the payee, with the settlement account between the payer bank and payee bank reconciled later to take into account any such payments.
Turning now to
At step 202, the payer uses a device (such as a mobile smart phone) to access the payment settlement system 100. As mentioned earlier, access may be accomplished, as examples, through an app on the payer device or through a website hosted at a server at the payment settlement system. Alternatively, the payer may have a P2P service provided by the payer's bank (one of the banks 140), and access to the payment settlement system may be by way of the payer bank website. As an example, the operator of the payment settlement system 100 may be a third-party that offers, through member banks, a P2P service that can be used by any customer of those member banks.
As part of step 202, the payer may provide a username and password that permits the system to authenticate the payer and also retrieve personal information and preferences of the payer from the enrollment database 120.
At step 204, the payer provides payment information through the network 130 to the payment settlement system. The payment information in one embodiment could be the name of the payee, the amount of the payment, and one or more of a physical address of the payee, an email address of the payee, and a phone number the payee. An example of a screen that appears on the payer's device for purposes of entering payment information is illustrated in
In the embodiment of
As noted earlier, one important feature of the payment settlement system 100 is its operation that permits payment to a payee, regardless of whether the payee has registered with the system and regardless of whether the payer has any information on how the payee prefers to be paid. This operation is largely carried out by the functionality and underlying messages transmitted and received at the system 100 that are represented by steps 210-234 in
At step 210, the system determines the nature of the identifying information that has been provided about the payee from the payer, and in particular whether a usable phone number or email address has been provided. The system 100 will generate (to the payee) a mobile message (e.g., SMS text message) if a usable mobile phone number is provided or generate an email message if a usable email address is been provided (or in some embodiments, generate both). If neither a usable phone number or email address is received from the payer at step 210, then the system determines whether a valid physical mailing address has been provided, step 212. If no valid mailing address is provided at step 212, then the system sends a message back to the payer requesting the needed contact information for the payee, step 214.
It should be appreciated that when the payer provides payment information, such as through the use of the input screen seen in
If a valid physical mailing address has been provided at step 212, then the system 100 automatically prints a check (similar to the check image 320 in
If a usable phone number or email address has been provided at step 210, then the payment system 100 generates an electronic message (at messaging system 110) to the payee informing the payee of the payment that is being made by the payer, step 220.
It should be noted that in some cases, the payee may have previously enrolled with the system 100, even though not required for purposes of receiving payment. In such case, identifying information (such as a phone number or email address) provided at step 204 may be used to look up the payee account and the payee's preferences for receiving payment (e.g., at the enrollment database 120).
An example of a message (such as a text message) sent to the payee at step 220 is seen in
Returning to
As described earlier, the risk assessment system 114 may use transaction account data associated with any payer account and any payee account to assess the risk of fraud or other improper/illegal activity associated with the payment (i.e., evaluate account status and past transaction data posted to the accounts being used, and also data posted to any other accounts held by the same payer and payee). A confirmation message may be sent at step 226 to the payer bank and, assuming that the risk score indicates an acceptable level of risk to the payer bank, the payer bank will guarantee payment to the payee bank (in order to permit the payment settlement system 100 to immediately credit the amount to the payee account, assuming that an electronic funds transfer is involved). The payer bank generates a return message to the payment settlement system indicating the guarantee or promise to pay, step 228. In response to the guarantee or promise to pay by the payer bank, the payment settlement system 100 sends a message to the payee bank indicating the payment may be immediately credited, step 234.
For purposes of implementing these steps, it is assumed that the banks connected to the payment settlement system through the network 130 have each agreed to accept payment guarantees and immediately credit accounts based on those guarantees, and have further agreed that the guarantees or promises to pay between banks will be managed by settlement accounts managed by the payment settlement system 100. These settlement accounts are managed and maintained by the account management system 112 and the settlement account database 122. Finally, at periodic intervals (e.g., at the end of each day), the account management system 112 of the payment settlement system reconciles the settlement accounts between the banks step 240. As mentioned briefly earlier, each bank connected to system 100 has a settlement account with every other bank so that, for example, the amounts of promises to pay (guaranteed payments) between the two banks are credited to the settlement account (for the bank receiving the guarantee) and amounts deposited to a payee account are debited from the settlement account (for the bank making the guarantee). The two banks associated with each settlement account will transfer money to one another depending on guarantees and payee deposits during that day, in order to balance out the account (essentially, trying to achieve a zero balance at the end of the day), so that each bank owes nothing to the other after reconciliation).
Turning now to
The initial message sent to the payment settlement system is a payment request message 510 from the payer device (e.g., mobile device). The payment request message initiates the process seen in
Once the payment settlement system has received information on the payment from the payer device, a request message 514 is made to the payee from the payment settlement system for selection of the payment method. The request is sent to the payee device, where the payment selection is made and a reply message 516 is returned to the payment settlement system. It should be noted that the messages to be described assume that an electronic transfer will be made to the payee and that a phone number or email address of the payee has been provided by the payer. However, as indicated in dotted lines at message 520 in
When an electronic transfer of funds to the payee is selected (at the payment selection message 516) and sent to the payment settlement system, the payment settlement system generates a message 530 requesting confirmation of the payer and payee accounts (from the payer and payee banks or financial institutions) and also request a risk assessment or score (from the risk assessment system 114). A message 532 from the payer financial institution confirms the payer account and a message 534 from the payee financial institution confirms the payee account to the payment settlement system, and in response, the payment settlement system sends a message 540 to the payer financial institution requesting a guarantee or promise to pay for the amount of the payment being made by the payer. The message 540 requesting a guarantee may include a risk score provided by the risk assessment system 114.
In response to the message 540 (assuming that payer has sufficient information to guarantee payment), a payment guarantee message 550 is sent back to the payment settlement system, which in turn sends a message 552 to the payee device that the amount is being immediately paid or deposited in the payee's account and the payee device displays a message 556 to the payee indicating the immediate availability of funds. The message 552 may also be simultaneously sent to the payee financial institution, requesting the immediate deposit to the payee's account, resulting in an account posting message 558 within the payee financial institution system that causes such immediate deposit.
After all funds have been transferred between banks at the end of the day, the payment settlement system requests by message 560 that the account management system 112 reconcile settlement accounts between the various payer and payee financial institutions or banks. After the reconciliation is performed, messages 562 are sent to each payer financial institution and payee financial institution providing settlement account balances, and indicating any amount needing to be paid by each financial institution to balance or true up (to zero) the settlement account that it has with each other financial institution.
The computer system 600 is shown comprising hardware elements that can be electrically coupled or otherwise in communication via a bus 605. The hardware elements can include one or more processors 610, including, without limitation, one or more general-purpose processors and/or one or more special-purpose processors (such as digital signal processing chips, graphics acceleration chips, and/or the like); one or more input devices 615, which can include, without limitation, a mouse, a keyboard and/or the like; and one or more output devices 620, which can include, without limitation, a display device, a printer and/or the like.
The computer system 600 may further include one or more storage devices 625, which can comprise, without limitation, local and/or network accessible storage or memory systems having computer or machine readable media. Common forms of physical and/or tangible computer readable media include, as examples, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, an optical medium (such as CD-ROM), a random access memory (RAM), a read only memory (ROM) which can be programmable or flash-updateable or the like, and any other memory chip, cartridge, or medium from which a computer can read data, instructions and/or code. In many embodiments, the computer system 600 will further comprise a working memory 630, which could include (but is not limited to) a RAM or ROM device, as described above.
The computer system 600 also may further include a communications subsystem 635, such as (without limitation) a modem, a network card (wireless or wired), an infra-red communication device, or a wireless communication device and/or chipset, such as a Bluetooth® device, an 802.11 device, a WiFi device, a WiMax device, a near field communications (NFC) device, cellular communication facilities, etc. The communications subsystem 635 may permit data to be exchanged with a network, and/or any other devices described herein. Transmission media used by communications subsystem 635 (and the bus 605) may include copper wire, coaxial cables and fiber optics. Hence, transmission media can also take the form of waves (including, without limitation radio, acoustic and/or light waves, such as those generated during radio-wave and infra-red data communications).
The computer system 600 can also comprise software elements, illustrated within the working memory 630, including an operating system 640 and/or other code, such as one or more application programs 645, which may be designed to implement, as an example, the processes, messaging and displays seen in
As an example, one or more methods discussed earlier might be implemented as code and/or instructions executable by a computer (and/or a processor within a computer). In some cases, a set of these instructions and/or code might be stored on a computer readable storage medium that is part of the system 600, such as the storage device(s) 625. In other embodiments, the storage medium might be separate from a computer system (e.g., a removable medium, such as a compact disc, etc.), and/or provided in an installation package with the instructions/code stored thereon. These instructions might take the form of code which is executable by the computer system 600 and/or might take the form of source and/or installable code, which is compiled and/or installed on the computer system 600 (e.g., using any of a variety of generally available compilers, installation programs, compression/decompression utilities, etc.). The communications subsystem 635 (and/or components thereof) generally will receive the signals (and/or the data, instructions, etc., carried by the signals), and the bus 605 then might carry those signals to the working memory 630, from which the processor(s) 610 retrieves and executes the instructions. The instructions received by the working memory 630 may optionally be stored on storage device 625 either before or after execution by the processor(s) 610.
While various methods and processes described herein may be described with respect to particular structural and/or functional components for ease of description, methods of the invention are not limited to any particular structural and/or functional architecture but instead can be implemented on any suitable hardware, firmware, and/or software configuration. Similarly, while various functionalities are ascribed to certain individual system components, unless the context dictates otherwise, this functionality can be distributed or combined among various other system components in accordance with different embodiments of the invention. As one example, the various systems within payment settlement system 100 may each be implemented individually or collectively by a single system having one or more storage device and processing elements. As another example, the various systems within payment settlement system 100 may each be implemented by plural systems, with their respective functions distributed across different systems either in one location or across a plurality of linked locations.
Moreover, while the various flows and processes described herein (e.g., those illustrated in
