US20120284175A1 - Method and system for facilitating person-to-person payments - Google Patents

Method and system for facilitating person-to-person payments Download PDF

Info

Publication number
US20120284175A1
US20120284175A1 US13/462,073 US201213462073A US2012284175A1 US 20120284175 A1 US20120284175 A1 US 20120284175A1 US 201213462073 A US201213462073 A US 201213462073A US 2012284175 A1 US2012284175 A1 US 2012284175A1
Authority
US
United States
Prior art keywords
payment
account
financial institution
receiver
sender
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US13/462,073
Other languages
English (en)
Inventor
Mark Wilson
Rod Springhetti
Diane Scott
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panther Payments LLC
Original Assignee
Panther Payments LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panther Payments LLC filed Critical Panther Payments LLC
Priority to US13/462,073 priority Critical patent/US20120284175A1/en
Assigned to Panther Payments, LLC reassignment Panther Payments, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SCOTT, DIANE, SPRINGHETTI, Rod, WILSON, MARK
Publication of US20120284175A1 publication Critical patent/US20120284175A1/en
Priority to US15/977,974 priority patent/US11748733B2/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices

Definitions

  • Conventional electronic payment systems do exist that may provide payments for a person-to-person transaction.
  • these conventional electronic payment systems usually leverage existing payment systems to transfer funds from a first party to a second party.
  • the conventional electronic payment systems usually cannot transfer funds immediately such that the second party has access to the transferred funds in a matter of seconds.
  • the second party may have access to the transferred funds within one or more business days relative to the time the transfer occurred.
  • Credit card-based solutions are usually not economical with respect to person-to-person transaction.
  • Credit card-based solutions face issues in the way their networks are constructed: credit card-based networks have multiple parties such as a merchant acquirer, an acquirer processor, an issuer processor, and/or an issuer. All of these participants in existing credit card-based solutions usually get paid for their role in processing the financial transaction.
  • Most of the credit card networks have been constructed around a consumer-merchant relationship which does not easily translate in supporting person-to-person payments.
  • the merchant in a consumer-merchant credit card based network model typically pays all of the participants who help manage the transaction for the credit card bearing consumer.
  • Such a conventional solution usually includes interchange fees and discount rates as understood by one of ordinary skill in the art.
  • the people involved in the transaction usually do not want to pay any fees for the transfer, similar to how cash may be handed from a first person to a second person without any transaction fees.
  • a first party asks a second party to have rent payments made into a PAYPALTM account rather than paying by check. Based on the financial services provided by PAYPALTM, the first party may choose to keep those funds in the PAYPALTM account rather than transferring the funds to their transaction account at their financial institution. Had the second party used a traditional check, the funds would be stored in the transaction account at the financial institution.
  • a method and system for facilitating person-to-person payments includes receiving a request from a communications network to transfer funds from a first account to a second account, including an alias that is associated with the second account.
  • the alias may include at least one of a mobile telephone number and an e-mail address.
  • a database is then checked at a Payment Switch Module to determine if the alias exists within the consumer alias registry. If the alias exists, then a message is generated for displaying one or more options on how the funds may be transferred from the first account to the second account and transmitted to the Sender Financial Institution, who contacts a Sender Portable Computing Device.
  • This message is transmitted over the Communications Network to a portable computing device.
  • a selected transfer option is received by the Payment Switch Module from the Sender Portable Computing Device, either via the Sender Financial Institution or directly.
  • a secure party identifier is generated by the Payment Switch Module.
  • the secure party identifier may include an abbreviated alphanumeric expression that is derived from at least one of a name, mobile phone number, e-mail address, and mailing address associated with the alias. This secure party identifier is then transmitted over the network along with a confirmation of the selected transfer option across the communications network.
  • the Payment Switch Module will communicate directly with the Receiving Financial Institution, and or the Receiving Portable Computing Device directly. Verification of the impending funds transfer will be provided by the Payment Switch Module, including a request for the Receiving Portable Computing Device to confirm desire to receive funds. Either the Receiving Financial Institution, and or the Receiving Portable Computing Device, responds to the Payments Switch Module, which in turn reports to the Sending Financial Institution for appropriate action.
  • Instantaneous payments will result in an end of day Net Settlement between Sending Financial Institution and Receiving Financial Institution, which is based on a Funds commitment between the parties.
  • the Sending Financial Institution will debit the Sender's Account, and the Receiving Financial Institution may immediately credit the Receiver's account for immediate use of funds. If a next day or three to four day delivery time is requested, an ACH transaction will be initiated.
  • the Payment Switch Module will track all transactions and provide an End of Day Net Settlement file to each participating Financial Institution.
  • the Payment Switch Module may also communicate with a Third Party Payment Service Provider, on behalf of a Sending Financial Institution, a Receiving Financial Institutions, or a Sending Portable Computing Device, and or a Receiving Portable Computing Device directly.
  • the Payment Switch Module will communicate to the Third Party Payment Service Provider the request from the Sending or Receiving party (as described above) to send or receive funds from a specific account held by the Third Party Payment Service Provider.
  • This request will include the alias and required password details of the sending or receiving party.
  • the Payment Switch Module will communicate with all parties confirmation details of the transaction to ensure completion. Requests of this type may come from the Payment Switch Module on an adhoc basis, or on be regularly scheduled by Sender or Receiver.
  • the Payment Switch Module may also communicate with one or more Third Party Payment Service Providers, on behalf of a Receiving Financial Institution, or a Receiving Portable Computing Device directly to enable “personal cash concentration.”
  • This request provided in either adhoc, automatic or scheduled fashions will include the alias and required password details of the receiving party.
  • funds owned by the Receiving party will be transferred to the Receiving Party's transaction account.
  • This function or feature may be characterized as a “Bring it Home” feature/function relative to the Receiving Party's account at the financial institution.
  • the method and system may further include the Payment Switch Module verifying a selected transfer option against one or more risk thresholds.
  • the risk thresholds may include at least one of a threshold assigned to a sender; a threshold assigned to a receiver; and a threshold assigned to a financial institution.
  • FIG. 1A is a diagram of a system for managing person-to-person payments in conjunction with one or more financial institutions and/or third party payment service providers;
  • FIG. 1B illustrates the person-to-person payment system of FIG. 1A in more detail
  • FIG. 2 is a functional block diagram of a payment switch module and/or a financial institution server embodied as a general purpose computer;
  • FIG. 3 is a diagram of an exemplary, non-limiting aspect of a portable computing device (“PCD”) comprising a wireless mobile telephone or tablet portable computer (“PC”) which corresponds with the portable computing devices illustrated in FIGS. 1A-1B ;
  • PCD portable computing device
  • PC wireless mobile telephone or tablet portable computer
  • FIGS. 4A-4B illustrate a flowchart of a method for processing a member financial institution customer payor to a member financial institution customer payee
  • FIG. 5 illustrates a continuation flowchart of the method of FIGS. 4A-4B for processing a member financial institution customer payor to a member financial institution customer payee;
  • FIG. 6 illustrates a continuation flowchart of the method of FIGS. 4A-4B for processing a member financial institution customer payor to a member financial institution customer payee;
  • FIG. 7 illustrates a continuation flowchart of the method of FIGS. 4A-4B for processing a member financial institution customer payor to a member financial institution customer payee;
  • FIG. 8A illustrates a separate flowchart of a method for checking on payments that have expired for lack of acceptance by a receiver
  • FIG. 8B illustrates a separate flowchart of a method for retrieving payments that have expired for lack of acceptance by a receiver
  • FIG. 9A illustrates a continuation flowchart of a method 400 E of FIGS. 4A-4B for processing a member financial institution customer payor to a member financial institution customer payee;
  • FIG. 9B illustrates a separate flowchart of a method for processing non-velocity payment options, like an ACH transfer, for a receiver does not have an account with a financial institution that is part of the system;
  • FIG. 10 illustrates a continuation flowchart of a method for processing a member financial institution customer payor to a member third-party payment service customer payee;
  • FIG. 11A illustrates a separate flowchart of a method for registering a third party payment service account (i.e. like PAYPALTM or AMAZONTM payments) for transferring funds to a financial institution;
  • a third party payment service account i.e. like PAYPALTM or AMAZONTM payments
  • FIG. 11B illustrates a separate flowchart of a method for automatically transferring funds from a third party payment service account (i.e. like PAYPALTM or AMAZONTM payments) on a recurring basis to a receiver's financial institution;
  • a third party payment service account i.e. like PAYPALTM or AMAZONTM payments
  • FIG. 12 illustrates a flowchart of a method for registering a financial account holder for a person-to-person payment supported by the payment switch module
  • FIG. 13 illustrates a continuation flowchart of a method for registering a financial account holder for a person-to-person payment supported by the payment switch module
  • FIG. 14 illustrates submethod or routine of the method of FIG. 12 described above that addresses when the customer has not entered the correct verification code after the financial institution has transmitted the code to the device associated with the alias;
  • FIG. 15A is an exemplary screen display for a portable computing device that lists person-to-person payment parameters that may be selected by a sender;
  • FIG. 15B is an exemplary screen display for a portable computing device that lists receivers that may be selected by a sender;
  • FIG. 15C is an exemplary screen display for a portable computing device that lists velocity payment options that may be selected by a sender;
  • FIG. 15D is an exemplary screen display for a portable computing device that lists a secure party identifier that may be verified by a sender before confirming a payment to a receiver;
  • FIG. 15E is an exemplary screen display for a portable computing device that lists a message that payment to a receiver has been confirmed.
  • FIG. 1A this figure is diagram of a system 100 A for managing person-to-person payments in conjunction with one or more financial institutions 104 and/or third party payment service providers 118 .
  • the system 100 A may comprise a payment switch module 102 which may be coupled to a communications network 173 that may comprise a wide area network (“WAN”), a local area network (“LAN”), the Internet, or a combination of networks.
  • the payment switch module 102 may be coupled to financial institutions (“FIs”) 104 , and third party payment service providers 118 .
  • FIs financial institutions
  • the payment switch module 102 may also communicate with an administrative console module 112 and a branded customer registration web site supported by a server 110 .
  • the financial institutions may communicate with portable computing devices 101 operated by their customers.
  • the portable computing devices (“PCDs”) 101 may take on many different forms such as desktop computers, laptop computers, tablet personal computers (“PCs”), handheld devices such as personal digital assistance (“PDAs”), in addition to other smart devices such as smartphones and cellular telephones.
  • PDAs personal digital assistance
  • Any device which may access the network 173 whether directly or via a tether to a complimentary device may be characterized as a PCD 101 .
  • the PCDs 101 as well as the payment switch module 102 along with the financial institutions 104 and third party payment service providers 118 may be coupled to the network 173 by various types of communication links 193 .
  • These communication links 193 may comprise wired as well as wireless links.
  • the communication links 193 allow each of the devices to establish direct, virtual links 196 among one another.
  • a sender portable computing device 101 A is generally a PCD that is used by a payor to make a person-to-person payment to a payee.
  • the payor in the system 100 may also be generally referred to as a “sender” in this written description.
  • the payee or recipient of a person-to-person payment may generally include a receiver portable computing device 101 B.
  • the payee in the system 100 may also be generally referred to as a “receiver” in this written description.
  • a sender's financial institution 104 A may generally comprise a bank or other type of financial services provider which has one or more accounts associated with the sender who is the operator of the sender portable computing device 101 A.
  • the sender in a person-to-person payment may generally request the sender's financial institution (“FI”) 104 A to transfer money from an account associated with the sender to an account that exists within a receiver's financial institution 104 B and that is associated with the receiver.
  • FI sender's financial institution
  • the sender in a person-to-person payment may generally request the sender's financial institution 104 A transfer money from an account associated with the sender within a third-party payment service provider 118 and/or within the sender's financial institution 104 A to an account associated with a receiver that may exist within a third-party payment service provider 118 .
  • a third-party payment service provider 118 may comprise an entity that manages nontraditional accounts such as those managed by PAYPALTM and AMAZONTM payments known as of this writing. However, the third-party payment service provider 118 may support an account which includes, but is not limited to, any type of accounts that store value.
  • third-party payment service entities 118 may include, but are not limited to, mobile phone service providers, airline accounts that have frequent flier points/miles, music accounts with value, etc.
  • the payment switch module 102 may communicate with the third-party payment service entities 118 via Simple Object Access Protocol (“SOAP”)/Hypertext Transfer Protocol (“HTTPS”) protocols as understood by one of ordinary skill in the art.
  • SOAP Simple Object Access Protocol
  • HTTPS Hypertext Transfer Protocol
  • Non-traditional accounts outside of traditional financial accounts managed by third-party payment service providers 118 may comprise, but are not limited to, reward or membership accounts that manage points, travel miles, gift cards, stored value, and other similar measures of value.
  • the system 100 is not limited to any types of specific accounts and may transfer value between a first account having a first measure of value to a second account having a second measure of value, in which the payment switch module 102 may assist in converting units of the first measure value to the units of the second measure of value.
  • the system 100 may support person-to-person payments in which a sender may transfer value from a first account having a first measure of value, such as an airline miles, to a second account associated with a receiver and in which the second account has a second measure of value such as in currency, like U.S. dollars.
  • a sender may transfer value from a first account having a first measure of value, such as an airline miles, to a second account associated with a receiver and in which the second account has a second measure of value such as in currency, like U.S. dollars.
  • the payment switch module 102 may comprise hardware and/or software for completing person-to-person payments between the sender portable computing device 101 A operated by the sender and the receiver portable computing device 101 B operated by the receiver.
  • the sender For a sender to initiate a person-to-person payment using the sender's financial institution 104 A, the sender needs to first establish a person-to-person payment account with the sender's financial institution 104 A.
  • a receiver desires to receive a person-to-person payment using the receiver's financial institution 104 B, then the receiver needs to first establish a person-to-person payment account with the second financial institution 104 B.
  • the sender's financial institution 104 A and the receiver's financial institution 104 B in order to support person-to-person payments between the sender and the receiver operating their respective portable computing devices 101 generally need to be members of and/or subscribe to the network created by the payment switch module 102 .
  • the sender's and receiver's financial institutions 104 A,B may select options and set preferences that are supported by the payment switch module 102 by utilizing an administrative console module 112 that is coupled to the payment switch module 102 .
  • Each sender's and receiver's financial institution 104 A,B may access the administrative console module 112 through using respective administrative portable computing devices 101 C.
  • the sender and receiver may establish their respective person-to-person payment accounts with their respective financial institutions 104 by using their respective portable computing devices 101 to access branded customer registration websites 110 that may be supported by and/or coupled to the payment switch module 102 .
  • branded customer registration websites 110 while supported by the payment switch module 102 , may be under the control of each respective financial institution 104 .
  • One advantage of the system 100 is that transfers of value in a person-to- person payment transaction may occur almost instantaneously from the perspective of the sender and receiver, such as on the order of minutes or even seconds, and depending upon the approvals needed for the transaction from the sender and the receiver operating their respective portable computing devices 101 A, 101 B.
  • person-to-person payments in the form of ACH bank transfers and/or personal checks may take at least one or more business days to complete.
  • One ideal scenario solved by the solution presented by the system 100 includes one in which a sender desires to transfer an amount of money from a the sender's banking account to a receiver's banking account associated with the receiver.
  • the receiver's banking account is maintained by the receiver's financial institution 104 B, which is different from the sender's financial institution 104 A.
  • this transfer of money between the sender and receiver having banking accounts in the sender's and receiver's financial institutions 104 A, 104 B may occur within minutes. This immediacy of the transfer in value may occur because sender's financial institution 104 A may immediately pull funds from the senders account while the receiver's financial institution 104 B may immediately deposit funds (taken from a general ledger account at the receiver's financial institution 104 B and place them) into the receiver's account based on a contractual obligation of the sender's financial institution 104 A to pay the receiver's financial institution 104 B at the close of business or at another designated time as determined between the sender's financial institution 104 A and the receiver's financial institution 104 B.
  • FIG. 1B this figure illustrates the person-to-person payment system 100 of FIG. 1A in more detail.
  • the payment switch module 102 is coupled to one or more financial institutions 104 , one or more third party payment providers 118 , an administrative console module 112 , and the registration website 110 .
  • Each financial institution 104 may be coupled to one or more portable computing devices (“PCDs”) 101 that are operated by the financial institution's customers, which include senders and receivers in person-to-person transactions.
  • PCDs portable computing devices
  • the payment switch module 102 may comprise one or more Application Programming Interfaces (“APIs”) 106 , a consumer alias registry database 108 A, and a transaction database 108 B.
  • the APIs may include, but are not limited to, registry management APIs 106 A, payment transaction APIs 106 B, administrative APIs 106 C, person-to-person (“P2P”) payment APIs 106 D, third party payment service APIs 106 E, as well as future risk management APIs and analytics APIs.
  • These APIs 106 allow the payment switch module 102 to communicate with various financial institutions 104 and third-party payment service entities 118 .
  • Each financial institution 104 may have its own, unique core banking computer platform.
  • These core banking platforms may be unique with respect to computer languages, structure, style, format, etc., as understood by one of ordinary skill the art.
  • the payment switch module 102 may comprise off-the-shelf software such as sold by CLEAR2PAY sold, as of this writing, under the brand name OPEN PAYMENT FRAMEWORKTM. Independent of any off-the-shelf software, the payment switch module 102 may receive and manage P2P payments by interacting with the consumer alias registry database 108 A and the transaction database 108 B.
  • Some exemplary functions of the payment switch module 102 include, but are not limited to, providing notifications to financial institutions 104 of pending person-to-person payments; tracking whether a P2P payment has been received, accepted and/or rejected; and generating and passing messages relating to person-to-person transactions between financial institutions.
  • the payment switch module 102 generally defines the payload or the content of the messages that are exchanged between two or more financial institutions 104 in connection with a person-to-person transaction.
  • the consumer alias registry 108 A maintained by the payment switch module 102 may track the senders and receivers of person-to-person transactions who are registered with respect to financial institutions 104 .
  • Account information as well as identifying information such as names and phone numbers may be associated with an alias.
  • the alias of a sender or a receiver may comprise a mobile phone number or an e-mail address.
  • the system 100 is not limited to these two forms of aliases. Other aliases may be used without departing from the scope of the system 100 as understood by one of ordinary skill in the art.
  • the consumer alias registry database 108 A maps each consumer alias to one or more financial institutions 104 or third-party payment service entities 118 in which a particular consumer may have an account.
  • the consumer alias registry database 108 A helps the payment switch module 102 to route payments to appropriate consumers who are part of a P2P transaction.
  • the transaction database 108 B also maintained by the payment switch module 102 maintains a detailed running log of P2P transactions.
  • This running log may include, but is not limited to, information such as whether a transaction is pending and/or complete, account information associated with the P2P transaction, and aliases associated with a P2P transaction.
  • Data from the transaction database 108 B may be used to create that settlement files or analytical derivatives that are exchanged between the payment switch module 102 and a financial institution 104 over a secure file transfer infrastructure 120 as understood by one of ordinary skill the art.
  • the transaction database 108 B may assist in managing the status of a payment and it may record the history of all payments that are processed through/by the payment switch 102 .
  • the transaction database 108 B allows each financial institution 104 to resolve disputes over transactions as well as permitting their consumers to view payments that they have made using the payment switch 102 .
  • Both databases 108 may comprise sequential query language (“SQL”) databases 108 sold by vendors such as the company of Oracle as understood by one of ordinary skill in the art. Both databases 108 may be generally characterized as relational databases as understood by one of ordinary skill in the art.
  • SQL sequential query language
  • the payment switch module 102 may further comprise a limits service module 116 that works in combination with a risk limit configuration module 114 .
  • the risk limit configuration module 114 may be part of an administrative console module 112 described in further detail below.
  • the limits service module 116 tracks the limits established and/or set by the risk limit configuration module 114 described below. Every P2P transaction that is passed through the payment switch module 102 is usually checked or verified by the limits service module 116 .
  • the payment switch module 102 may further comprise a secure party identifier generation module 122 which produces a unique identifier based on an alias that was matched from the consumer alias registry database 108 A.
  • the secure party identifier generation module 122 is coupled to the consumer alias registry 108 A.
  • the secure party identifier generation module 122 pulls its data from the consumer alias registry 108 A.
  • a secure party identifier may comprise the last four characters of the receiver's last name and the first three characters of the receiver's first name that are listed in the consumer alias registry 108 A.
  • characters for the secure party identifier may be retrieved from e-mail addresses, mobile telephone numbers, mailing addresses, etc.
  • One exemplary intent of the secure party identifier may include allowing the sender to confirm the identity of the intended receiver so that the sender may correct a selection of a wrong receiver in an early stage of a P2P transaction before it is completed.
  • the secure party identifier usually should contain enough information so that the sender may easily recognize the intended receiver while protecting the privacy of an unintended receiver. See FIG. 15D described below which illustrates one exemplary embodiment of a secure party identifier 1512 .
  • the payment switch module 102 may also comprise an expired payments tracking module 124 .
  • the expired payments tracking module 124 corresponds to a time element with respect to a decision block 462 of FIG. 4 (described below) in which a receiver of a payment has failed to log into his receiver financial institution 104 B within a predetermined amount of time. This predetermined amount of time may be established by the payment switch 102 . Exemplary time limits include, but are not limited to, fourteen calendar days or ten business days, or the like.
  • the expired payments tracking module 124 conducts searches the transaction database 108 B for expired payments. It searches for those payments which have exceeded the time limit established by the payment switch module 102 , and more particularly, the operator of the payment switch module 102 who uses the administrative console module 112 .
  • the APIs 106 illustrated in FIG. 1B that are part of the payment switch module 102 may employ Web Service Description Language (WSDL) and Schemas, however, other programming languages and schemas are well within one of ordinary skill in the art. Integration of FIs 104 with the payment switch module 102 occurs through various sets of standards-based service interface messages. These messages provide all the necessary capabilities to look up a payee by his alias, to initiate a payment, confirm or reject a payment, to provide notification of a pending payment transaction, and provide all financial management information for settlement between members.
  • WSDL Web Service Description Language
  • the APIs 106 may be based on open industry standards for the construction and deployment of interoperable web services. They may leverage a basic SOAP payload using WSDL defined contracts with extensible mark-up (“XML”) schema based data definitions. These standards may supported by a wide range of development tools on a variety of different platforms.
  • member FIs 104 may usually need to implement a subset of interfaces described below for the payment switch module 102 . Having each FI 104 implement these standard messages may allow the payment switch module 102 to facilitate the P2P payment process between the sender's and receiver's financial institutions 104 A, 104 B; notifying the FIs 104 of pending payments, status updates, rejections, etc.
  • the payment switch module 102 may provide the FIs 104 with the appropriate WSDL and Schema files to facilitate the implementation of these services. Rules governing the participation of member FIs 104 may be outlined in governance agreements signed by each FI 104 .
  • the ISO 20022 standard is a methodology that is used to develop standard financial business models and messages to facilitate the exchange of information between financial institutions 104 . It provides a business process catalogue and data dictionary to standardize both the message syntax and semantics for a wide breadth of financial transactions. While ISO 20022 does include flows for typical consumer to merchant payment processes, it does not specifically address person to person (“P2P) payments. Nor does it currently contain the necessary references and data elements to represent the unique exchange of funds enabled by payment switch module payment flows described below. This gap in the current standard is further reinforced by the fact that third party financial services companies, such as PAYPALTM, have created proprietary flows and schemas in this space.
  • PAYPALTM third party financial services companies
  • the payment switch module 102 has adopted the current ISO 20022 payment standards while recognizing that the person-to-person process flows and associated data elements described below may be provided as new additions.
  • the real time services supported and required by the payment switch module 102 have been grouped into three initial categories as defined below: (1) payment Transactions—Handles the sending, routing, and receiving of payments between two parties; (2) Registry Management—Handles the management of the consumer alias registry data and autopay settings; (3) Administration—Provides historical data and configuration management capabilities.
  • Register Account Stores customer alias and FI information within the Owner Consumer alias registry 108A Update Account Modifies the account owner alias information for a Owner given FI Remove Account Sets an account owner alias as inactive if they close Owner their accounts with a given FI 104.
  • the account owner history may be retained Verify Alias Used to confirm that a customer has possession of an alias.
  • the inter-day and end-of-day net settlement reports may be generated and provided at predefined intervals agreed upon by the member financial institutions 104 . These reports may be made available via standard secure file transfer protocols (“SFTP”) (infrastructure) 120 over a defined network path, i.e. SFTP or equivalent file transfer as understood by one of ordinary skill in the art.
  • SFTP secure file transfer protocols
  • Member FIs 104 A may have separate and distinct file directories and all access may be restricted to those locations based on strict user entitlements.
  • a web interface for intra-day settlement reporting, risk configuration and transaction research may also be provided to the Member FIs 104 . Detailed descriptions of each operation are provided below.
  • Table 4 defines the set of potential parties that may be involved in a P2P payment transaction. These definitions map to the corresponding ISO 20022 party terms, but are scoped to the specific context of a P2P payment flow described below in connection with FIGS. 4-14 .
  • Debtor Payer The party that owns the account that may Sender be used to make the payment; the account from which funds may be debited.
  • Creditor Payee The party that owns the account that may Receiver receive the payment from the Debtor; the account to which funds may be credited.
  • Debtor Agent Debtors The Financial Institution that holds and (Senders) services an account for the Debtor; the Bank/ account from which funds may be Financial debited. Services Provider Creditor Agent Creditors The Financial Institution that holds and (Receivers) services an account for the Creditor; the Bank/ account to which funds may be credited.
  • Financial Services Provider Initiating Party Originator The party initiating the payment. This may be the Debtor or a party that initiates the payment on behalf of the Debtor.
  • Intermediary Intermediary A financial services provider; or servicing Agent organization that sits in-between the Debtor and Creditor Agents and processes or facilitates the payment between these entities.
  • payment switch module 102 expects the Member FIs 104 to implement, support, and ensure are available in support of the integrated payments switch module 102 : (a) Customer experience; all Customer facing channel applications where the FI 104 wishes to expose payments capabilities must be modified to support and enable the desired functionality; (b) Back Office/Agent Assisted user experience: Any agent assisted channel applications in which research, dispute resolution, or registration and payment assistance is desired must be modified to support the necessary functionality; (c) Customer identification and authentication as well as verification of source account ownership and availability of funds; (d) Storage of Customer alias (or associated identifier) to the Account reference data: payment switch module 102 may usually only store a pointer to the FI 104 with which the customer has an account—Account details are maintained by the FIs 104 ; (e) The implementation of all required payment switch module 102 API's to enable the facilitation of payment transactions between two parties; (f) Core banking platform integration for intraday posting and associated account debit/credit activities; and (g) GL Account funding and
  • the payment switch module 102 may not be provided in first generations but are being considered for inclusion alternate, future exemplary embodiments. Some of the capabilities may be implemented by either the switch module 102 or the member FIs 104 . In these cases, the payment switch module 102 may support both options, allowing the FI 104 to decide which solution they may like to leverage.
  • N/A Fraud Case exceeded payment switch Generation module 102 may generate a case that is held within the Switch and accessible via the provided administrative console. The payment itself may be prevented or allowed to continue depending on FI 104 configuration. Member FI N/A Payment switch module 102 Fraud Case may provide a list of exception Generation conditions in the API response, allowing the FI 104 to generate a case within their own Fraud/Risk Management solution. No Case may be generated within payment switch module 102. Manual Risk Payment switch module 102 If payment switch module 102 Overrides may provide manual override is not generating the case, capability of a payment that responsibility for the risk triggered a risk exception via the override process and user provided Administrative interface falls on the Member console. FI 104.
  • “Black List” Payment switch module 102 Blocking a customer from payment block may provide an FI specific black registering for P2P should be list to block all payments to a implemented at the FI 104. specific alias when directed to Payment switch module 102 that FI 104. may provide API's to allow a customer to be unregistered. Risk Scoring By identifying typical usage FIs may need to determine if Through patterns, payment switch they want to process the risk Behavioral module 102 may score payment score real time allowing the Analysis transactions that fall outside the transaction to be halted or usual payment profile for a through offline case given customer and provide the generation.
  • NACHA File Payment switch module 102 N/A Creation may generate NACHA files for a Member FI 104 and either provide them back to the FI 104 for submission into the ACH network, or interface with a partner Originating Depository Financial Institution (ODFI) and submit the NACHA file on behalf of the Member FI 104.
  • Receiver Customer interaction is N/A Notification of currently owned by the Member Pending FI 104, however payment switch payment module 102 may perform the email or SMS notification to a receiver when a payment is pending if the FI 104 chooses. Bring-It-Home By leveraging third party API's N/A Candidate payment switch module 102 Identification may identify customers that maintain significant balances at third party financial service providers. Additional API Payment switch module 102 N/A Sets may continue to expand the available API sets to expose additional features and capabilities to the Member FI 104's.
  • the P2P payments API 106 D may be accessed by channels established by a
  • Payment switch module 102 may also invoke services that the FI's 104 implement and host on behalf of the switch module 102 . Payment switch module 102 may provide the FIs 104 with WSDL and XSD files that describe the SOAP message structure, its contents, and the appropriate service bindings. Each Member FI 104 may need to ensure that the availability and reliability of the hosted services adhere to the agreed upon network SLAs.
  • the payment switch module APIs 106 may be based on standard SOAP web services. While the switch module 102 itself may leverage a Java EE platform, the Member FI 104 is open to implement the APIs 106 in any language that supports industry standard SOAP based service specifications.
  • the API sets 106 are usually compliant with the following industry standard versions, as of this writing: Simple Object Access Protocol (SOAP) version 1.1; Web Service Description Language (WSDL) 1.1; XML Schema 1.0; and WS-I Basic Profile 1.1.
  • SOAP Simple Object Access Protocol
  • WSDL Web Service Description Language
  • XML Schema 1.0 XML Schema 1.0
  • WS-I Basic Profile 1.1 WS-I Basic Profile
  • the APIs 106 may leverage both transport level and message level security mechanisms to ensure that each conversation between a Member FI 104 and the payment switch module 102 enables both parties to: determine the identity of the sender; verify the identity of the sender—authenticate them; determine if the sender is authorized to perform the operation requested; transport and receive the message confidentially, so that unauthorized parties cannot view it; verify the integrity of the message, that it has not been intercepted and modified; and ensure non-repudiation, i.e., the sender cannot deny that it participated in the conversation.
  • the messaging protocol usually supports bi-directional authentication.
  • All conversations between the Member FIs 104 and payment switch module usually employ encryption.
  • payment switch module 102 and its partners will exchange public certificates through an out-of-band channel such as hand delivery or other secure transport. Using these certificates, payment switch module 102 and the Member FIs 104 may establish mutual SSL connections for all transactions as understood by one of ordinary skill in the art.
  • both the payment switch module 102 and the Member FIs 104 may digitally sign message payloads using the sender's private certificate key. This layer of security may use a separate set of certificates from the ones used to establish the SSL connection, as understood by one of ordinary skill in the art.
  • the SOAP message will include a Signature header using the sender's private key and only decrypt-able with the sender's public key. This usually guarantees that the message originated from the sender.
  • payment switch module 102 may also establish a one-time use session token, or nonce, as part of the Create payment Context service. This token will be included in the message by the Member FI 104 on subsequent calls to the switch module 102 . Once the token expires, any message submitted using it will be deemed fraudulent.
  • a one-time use session token or nonce
  • All API messages may be based on a standard SOAP 1.1 doc-literal message structure as of this writing. Other languages are well within the level of ordinary skill in the art based on this written description.
  • a SOAP message is composed of a root soap envelope which contains one or more SOAP headers and a SOAP body.
  • the APIs 106 may leverage the SOAP Header to carry identifying information and audit data.
  • payment switch module 102 may define a set of common request and response elements that may be included within the SOAP header structure.
  • the message payload which will be part of the SOAP body, may vary depending on the individual message call.
  • the response elements to the APIs 106 may share common response elements as described above. With each table provided below for each response API 106 , in addition to the common response elements which may be shared as understood by one of ordinary skill in the art, the tables generally provide parameters which are outputs to responses.
  • Each service request may contain the following set of common elements as provided by Table 6:
  • Each service response may contain the following set of common elements listed in Table 7:
  • Tables 8-12 list some data types that may be supported by the payment switch module:
  • Alias Code Types - may Represent a customer's alias Cardi- Parameter Description
  • Type nality Required AliasType The Type of alias value String 1 Y AliasValue The value of the alias type String 1 Y
  • Risk Exception Types - may Represent a risk limit exception Cardi- Re- Parameter Description
  • Type nality quired LimitCode The risk limit that was String 1 Y triggered LimitDescription Description of the String 1 Y condition that triggered the exception.
  • RiskDetailArray An array of parameters Array of 0 . . . 1 N that define the amount Name or time exceeded and Value the threshold. This will Pairs be specific to the risk thresholds.
  • Person Types - may represent an individual consumer; either acting as the Debtor or Creditor in a payment transaction.
  • Parameter Description Type Cardinality Required FirstName The Customer's first name. String 0 . . . 1* N LastName The Customer's last name. String 0 . . . 1* N CustomerFIPartyID A unique customer String 0 . . . 1* N identifier supplied and managed by a Member FI 104. The Member FI 104 must retain this field and ensure that it is unique and associated with the appropriate customer.
  • PPCustomerID A Unique ID established String 0 . . . 1* N within the Consumer alias registry 108A that identifies the associated Customer. *Cardinality will vary based on the individual requirements of each operation that leverages the PersonType
  • Payment Type - may Represent a payment transaction Parameter Description Type Cardinality Required paymentTransaction A Unique ID String 1 Y ID established within the payment switch module 102 to identify a specific payment transaction. Amount The Amount of the String 1 Y payment Debtor Represents the PersonType 1 Y customer making the payment; the Debtor or Payer. paymentTimeStamp Timestamp when the Date 1 Y payment was submitted/ created
  • Types - may Represent an error or warning Cardi- Re- Parameter Description
  • Type nality quired Code A code representing the String 1 Y individual error or warning condition. Description Short description of the String 1 Y condition Severity Describes the severity of String 1 Y this specific response code.
  • Source The system component String 0..1 N or application where the error occurred TechnicalDetails Additional technical String 0 . . . 1 N details that may be logged to provide support level debug assistance.
  • each individual service operation may have a set of response codes specific to that function, the following sets may be common across all conversations between the switch module 102 and a FI 104 .
  • Default text is provided in the ⁇ Description> field, which is intended to be human-readable.
  • the FI 104 may return this default text to the customer, or may replace it with custom text that is more specific or translated into the appropriate language.
  • the payment transaction API set 106 B implements the core processing functions of the payments switch module 102 . It provides services to facilitate the sending, routing, and receiving of payments between two parties. Some functions within this API set 106 B may be required implementations for each Member FI 104 . In order to accommodate the implementation of different functions between the switch module 102 and the Member FIs 104 , two different service objects will usually be created.
  • the payment service implements the core set of operations of the payment switch module 102 . These functions will be invoked by the Member FIs 104 according to the recommended integration guidelines.
  • Table 16 provides an Operation Summary List for the payment transaction API set 106 B:
  • the create payment context API 106 B 1 may establish a transaction specific, one-time use security token that will be included as part of each message exchange between the switch module 102 and a Member FI 104 .
  • One-time use refers to the fact that the token will usually be specific to a single payment creation flow.
  • the token has a short life span in order to mitigate the possibility of replay attacks.
  • Type Cardinality Required Debtor Represents the PersonType 1 Y customer making the payment; the Sender or Payer.
  • the Identify Payee API 106 B 2 includes a lookup of the receiver's registered destination information and their associated Secure Party Identifier (SPI) within the payment switch module 102 payments Alias Registry database 108 A as will be described below. If the alias is not found within the registry database 108 A, an informational message is returned with a limited set of velocity options. An unidentified payee is a valid response for this operation.
  • SPI Secure Party Identifier
  • the Create payment function will be used by the Sender's Member FI 104 to create a payment transaction within the payment switch module 102 and to trigger the risk threshold analysis.
  • Type Cardinality Required Debtor Represents the customer PersonType 1 Y making the payment; the Sender or Payee. Creditor Represents the receiver PersonType 0 . . . 1 N* of the payment; the Payee.Required if the CreditorAliasCode is not present.
  • CreditorAliasCode The Alias of the AliasCode 0 . . . 1 N* receiver. Required if the Type Creditor element is not present.
  • Amount The amount of the String 1 Y payment.
  • SecureToken The secure transaction String 1 Y token established in the CreatepaymentContext call. If the token has expired, this operation will fail.
  • VelocityCode The selected payment String 1 Y velocity code, chosen from the Velocity Option List returned in the Identify Payee call.
  • SourceAccountID A pointer or correlation String 0 . . . 1 N ID, to the source account from which the payment funds are being debited. It could be the last four digits of the account number, or some hash value identifier associated with the account. This is an optional field that the Member FI 104 can choose to leverage if they do not wish to retain the transaction data themselves.
  • the Set Payment Status API 106 B 4 is used to notify the payment switch module 102 of a change in the state in a payment transaction, i.e. when it is confirmed, accepted, rejected, or expires. This operation also triggers any necessary downstream processing based on the status applied.
  • the Retrieve Pending payments API 106 B 5 allows an FI 104 to query and retrieve any outstanding payments for a given receiver.
  • Type Cardinality Required paymentList A list of Array of 1 Y payments payment that are in a elements pending state. payment A payment paymentType 0 . . . n N transaction.
  • the P2P Payments APIs 106 D include the subset of operations that the Member FIs 104 usually must implement and expose to participate in the payment exchange.
  • the P2P Payment APIs 106 D may include, but are not limited to, the following three APIs 106 D: a process payment status API 106 D 1 , a process pending payment API 106 D 2 , and a process noninstant payment API 106 D 3 .
  • the Process payment status API 106 D 1 may be implemented by each Member FI 104 and is invoked by the payment switch module 102 to notify the Sender's FI 104 of a change in payment status.
  • the Process pending payment API 106 D 2 may be implemented and exposed by each Member FI 104 and will be invoked by the payment switch module 102 in order to notify a Receiver's FI 104 that a payment is pending.
  • Type Cardinality Required paymentTransactionID A Unique ID String 1 Y established within the payment switch module 102 to identify a specific payment transaction.
  • Debtor Represents the PersonType 1 Y customer making the payment; the Sender or Payee. Creditor Represents the PersonType 1 Y receiver of the payment; the Payee. Amount The amount of the String 1 Y payment.
  • DebtorsOrganization A Code assigned to Organization 1 Y each Member FI 104 Identification that is part of the Type payment switch module 102 payments Network.
  • DestinationAccountID A pointer, or String 0 . . . 1 N correlationID, to the destination account which will be credited with the payment. This Is optional and will be returned if set through the AutoPay configuration.
  • the Process NonInstant payment API 106 D 3 notifies the Member FI 104 that the Receiver has registered their account information and accepted the pending non instant payment.
  • the FI 104 will usually need to generate a transaction in their daily ACH batch for processing.
  • NonInstant payment API 106D3 Parameter Description Type Cardinality Required paymentTransactionID A Unique ID String 1 Y established within the payment switch module 102 to identify a specific payment transaction. Amount The amount of the String 1 Y payment. Debtor Represents the PersonType 1 Y customer making the payment; the Sender or Payee. SourceAccountID A pointer, or String 0 . . . 1 N correlation ID, to the source account from which the payment funds are being debited. This is an optional field that the Member FI 104 can choose to leverage if they do not wish to retain the transaction data themselves. Creditor Represents the PersonType 1 Y receiver of the payment; the Payee. CreditorsAccountNumber The full account String 1 Y number of the destination account. CreditorsRoutingNumber The RTN of the String 1 Y Receiver's destination FI 104.
  • the Registry Management APIs 106 A provide the Member FIs 104 with a means to maintain the data contained within the consumer alias registry. This includes account owner registration and Create, Read, Update, and Delete (CRUD) capabilities as well as the AutoPay and registered destination management functions.
  • CRUD Create, Read, Update, and Delete
  • the following Registry Management APIs 106 A include five according to one exemplary embodiment.
  • the five APIs 106 A may include but are not limited to, a register account owner API 106 A 1 , an update account owner API 106 A 2 , a remove account owner API 106 A 106 A 3 , a set autopay configuration AIP 106 A 4 , and a verify alias API 106 A 5 .
  • the Register Account Owner API 106 A 1 may add a Customer and their associated alias and FI 104 information to the alias registry database 108 A of the payment switch module 102 .
  • the update account owner API 106 A 2 may update the Customer alias and/or FI information within the alias registry 108 A of the payment switch module 102 .
  • the Remove Account Owner API 106 A 3 may indicate that a Customer is no longer having a relationship with a FI 104 . This will prevent future payments from being sent to the FI 104 for that Customer.
  • the verify alias AP 106 A 5 may compare an alias verification code entered by a customer against a previously generated value to determine if the two entries match. A match indicates that the customer has provided evidence of their possession of the alias.
  • the Set Autopay Configuration API 106 A 4 may store an association between the Receiver and Sender to automatically accept payments from the Sender when routed to the FI 104 specified. According to one exemplary embodiment, usually, only a single configuration may exist per Sender-Receiver-FI association.
  • the remove autopay configuration API 106 A 6 may remove an association between the Receiver and Sender set as part of the Set AutoPay Configuration call.
  • the Set Registered Destination API 106 A 7 may set the Member FI 104 supplied as the registered, or default, destination for all future payments sent to the Receiver. According to one exemplary embodiment, usually there can only be one registered destination per receiver alias.
  • a Verify Registered Destination API 106 A 8 may allow a Member FI 104 to determine if they are the current registered destination for a given Customer. According to one exemplary embodiment, it does not return the FI 104 that is registered; rather it only allows an FI 104 to determine if an FI 104 is the registered destination.
  • the branded registration website module 110 may comprise a computer server operated by a respective financial institution 104 which allows consumers of the respective financial institution to register in order to receive person-to-person payments via the payment switch module 102 .
  • the system 100 may comprise a plurality of registration websites 110 that are operated independently of one another by each respective financial institution 104 .
  • Each registration website module 110 may support a micro deposit verification function when new accounts are established by a consumer of a particular financial institution 104 or a similar verification technique as understood by one of ordinary skill in the art.
  • the administrative console module 112 may comprise a computer server running software and/or hardware associated with the payment switch module 102 . It allows the operator of the payment switch module 102 to assist financial institutions 104 with verifying registration of consumers and for setting risk limit configurations that may be individually or specifically tailored by each financial institution 104 .
  • the administrative console module 112 generally supports administrative functions for one or more operators of the payment switch module 102 .
  • the administrative console module 112 may permit financial institutions to conduct lookups for aliases within the transaction database 108 B or within the consumer alias registry database 108 A.
  • the administrator console module 112 may also allow the operator to establish credentials for permitting financial institutions 104 to access various functions enter features of the administrative console module 112 .
  • the administrative console module 112 may further comprise a risk limit configuration module 114 that supports the risk limit configurations described above.
  • the risk limit configuration module 114 may comprise software and/or hardware.
  • the risk limit configuration module 114 may allow each financial institution 104 to set individual or consumer based limits on person-to-person transactions. According to one exemplary embodiment, the risk limit configuration module 114 may be set so that it limits the number of person-to-person transactions that a particular consumer may make within a certain period of time.
  • the risk limit configuration module 114 may allow a financial institution 104 to restrict the number and/or the amount of person-to-person transactions that occur for a particular consumer within a 24-hour window.
  • a financial institution 104 may restrict a particular consumer to no more than five person-to-person transactions totaling $10,000 or less within a 24-hour window.
  • other more restrictive or less restrictive limits that address the transaction amount, time frames, and/or frequency may be employed without departing from the scope of this disclosure as understood by one of ordinary skill in the art.
  • the risk limit configuration module 114 may also set limits on a network basis that restricts the number and amount of person-to-person transactions for a respective financial institution 104 .
  • the risk limit configuration module 114 may restrict a first financial institution 104 to $1,000,000 per day for all transactions managed by the payment switch module 102 .
  • other more restrictive or less restrictive limits that address the transaction amount, time frames, and/or frequency per each financial institution 104 may be employed without departing from the scope of this disclosure as understood by one of ordinary skill in the art.
  • the risk limit configuration module 114 may also limit the total amount of funds transferred from and/or to the consumer as an aggregate level monitor. For example, the risk limit configuration module 114 may limit the consumer to $10,000 per day across all financial institutions 104 in which the particular consumer may have an account. Other types of restrictions not expressly defined, such as a combination of these restrictions, may be employed without departing from the spirit and scope of this disclosure.
  • the risk limit configuration module 114 is designed to substantially reduce or substantially eliminate the chance that fraudulent transactions may occur within and/or across the system 100 .
  • the payment switch module 102 may also comprise a secure file transfer infrastructure module 120 which is supported by each respective financial institution 104 .
  • the secure file transfer infrastructure module 120 for each financial institution 104 supports a batch transfer data.
  • a batch transfer data may be contained in a single file at the end of each business day. This single file may contain each financial institutions single net settlement reporting due for a respective business day. This single file informs each financial institution 104 of the amount and destinations for money that is owed to other financial institutions 104 that are members and who are coupled to the payment switch module 102 .
  • FIG. 2 this figure is a functional block diagram of a payment switch module 102 and/or a financial institution server 104 embodied as a general purpose computer.
  • the exemplary operating environment for the system 100 includes a general-purpose computing device in the form of a conventional computer.
  • a computer 102 , 104 includes a central processing unit 121 , a system memory 122 , and a system bus 123 that couples various system components including the system memory 122 to the processing unit 121 .
  • the system bus 123 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.
  • the system memory includes a read-only memory (ROM) 124 and a random access memory (RAM) 125 .
  • ROM read-only memory
  • RAM random access memory
  • a basic input/output system (BIOS) 126 containing the basic routines that help to transfer information between elements within computer 120 , such as during start-up, is stored in ROM 124 .
  • the computer 102 , 104 may include a hard disk drive 127 A for reading from and writing to a hard disk, not shown, a memory card drive 128 for reading from or writing to a removable memory card 129 , and/or an optional optical disk drive (not illustrated) for reading from or writing to a removable optical disk (not illustrated) such as a CD-ROM or other optical media.
  • Hard disk drive 127 A and the memory card drive 128 are connected to system bus 123 by a hard disk drive interface 132 and a memory card drive interface 133 , respectively.
  • the drives and their associated computer readable media illustrated in FIG. 2 provide nonvolatile storage of computer-executable instructions, data structures, program modules, and other data for computer 102 , 104 .
  • a number of program modules may be stored on hard disk 127 , magnetic disk 129 , optical disk 131 , ROM 124 , or RAM 125 , including, but not limited to, an operating system 135 and switch module 5 .
  • Program modules include routines, sub-routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types.
  • a user may enter commands and information into computer 1 through input devices, such as a keyboard 140 and a pointing device 142 .
  • Pointing devices may include a mouse, a trackball, and an electronic pen that may be used in conjunction with a tablet portable computing device.
  • Other input devices may include a microphone, joystick, game pad, satellite dish, scanner, or the like.
  • serial port interface 146 that is coupled to the system bus 123 , but may be connected by other interfaces, such as a parallel port, game port, a universal serial bus (USB), or the like.
  • the display 147 may also be connected to system bus 123 via an interface, such as a video adapter 148 .
  • the display 147 may comprise any type of display devices such as a liquid crystal display (LCD), a plasma display, an organic light-emitting diode (OLED) display, and a cathode ray tube (CRT) display.
  • LCD liquid crystal display
  • OLED organic light-emitting diode
  • CRT cathode ray tube
  • a camera 175 may also be connected to system bus 123 via an interface, such as an adapter 170 .
  • the camera 175 may comprise a video camera such as a webcam.
  • the camera 175 may be a CCD (charge-coupled device) camera or a CMOS (complementary metal-oxide-semiconductor) camera.
  • the computer 102 , 104 may include other peripheral output devices (not shown), such as speakers and printers.
  • the computer 102 , 104 may operate in a networked environment using logical connections to one or more remote computers 101 , 110 , such as a web server 110 as illustrated in FIG. 1A .
  • a remote computer 101 , 110 may be another personal computer, a server, a mobile phone, a router, a network PC, a peer device, or other common network node. While the web server 110 or a remote computer 101 typically includes many or all of the elements described above relative to the client device, only a memory storage device 127 E has been illustrated in FIG. 2 .
  • the logical connections depicted in the FIG. 2 include a local area network (LAN) 173 A and a wide area network (WAN) 173 B.
  • LAN local area network
  • WAN wide area network
  • the computer 102 , 104 When used in a LAN networking environment, the computer 102 , 104 is often connected to the local area network 173 A through a network interface or adapter 153 .
  • the network interface adapter 153 may comprise a wireless communications and therefore, it may employ an antenna 60 .
  • the computer 102 , 104 When used in a WAN networking environment, the computer 102 , 104 typically includes a modem 154 or other means for establishing communications over WAN 173 B, such as the Internet.
  • Modem 154 which may be internal or external, is connected to system bus 123 via serial port interface 146 .
  • program modules depicted relative to the remote computer 101 may be stored in the remote memory storage device 127 E. It may be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers 101 , 102 , 104 .
  • the present invention may be implemented in other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor based or programmable consumer electronics, network personal computers, minicomputers, mainframe computers, and the like.
  • the invention may also be practiced in distributed computing environments, where tasks are performed by remote processing devices that are linked through a communications network.
  • program modules may be located in both local and remote memory storage devices.
  • the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted as one or more instructions or code on a computer-readable medium.
  • Computer-readable media include both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another.
  • a storage media may be any available media that may be accessed by a computer.
  • such computer-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to carry or store desired program code in the form of instructions or data structures and that may be accessed by a computer.
  • any connection is properly termed a computer-readable medium.
  • the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (“DSL”), or wireless technologies such as infrared, radio, and microwave
  • coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium.
  • Disk and disc includes compact disc (“CD”), laser disc, optical disc, digital versatile disc (“DVD”), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.
  • this figure is a diagram of an exemplary, non-limiting aspect of a portable computing device (“PCD”) 101 comprising a wireless mobile telephone which corresponds with the portable computing devices 101 illustrated in FIGS. 1A-1B .
  • the PCD 101 includes an on-chip system 322 that includes a digital signal processor or a central processing unit 324 and an analog signal processor 326 that are coupled together.
  • a display controller 328 and a touchscreen controller 330 are coupled to the digital signal processor 324 .
  • a touchscreen display 332 external to the on-chip system 322 is coupled to the display controller 328 and the touchscreen controller 330 .
  • FIG. 3 further illustrates a video encoder 334 , e.g., a phase-alternating line (“PAL”) encoder, a sequential fashion Malawi memoire (“SECAM”) encoder, a national television system(s) committee (“NTSC”) encoder or any other video encoder, is coupled to the digital signal processor 324 .
  • a video amplifier 336 is coupled to the video encoder 334 and the touchscreen display 332 .
  • a video port 338 is coupled to the video amplifier 336 .
  • a universal serial bus (“USB”) controller 340 is coupled to the digital signal processor 324 .
  • a USB port 342 is coupled to the USB controller 340 .
  • a memory 112 and a subscriber identity module (“SIM”) card 346 may also be coupled to the digital signal processor 324 .
  • SIM subscriber identity module
  • a digital camera 348 may be coupled to the digital signal processor 324 .
  • the digital camera 348 is a charge-coupled device (“CCD”) camera or a complementary metal-oxide semiconductor (“CMOS”) camera.
  • CCD charge-coupled device
  • CMOS complementary metal-oxide semiconductor
  • a stereo audio CODEC 350 may be coupled to the analog signal processor 326 .
  • an audio amplifier 352 may be coupled to the stereo audio CODEC 350 .
  • a first stereo speaker 354 and a second stereo speaker 356 are coupled to the audio amplifier 352 .
  • FIG. 3 shows that a microphone amplifier 358 may be also coupled to the stereo audio CODEC 350 .
  • a microphone 360 may be coupled to the microphone amplifier 358 .
  • a frequency modulation (“FM”) radio tuner 362 may be coupled to the stereo audio CODEC 350 .
  • an FM antenna 364 is coupled to the FM radio tuner 362 .
  • stereo headphones 366 may be coupled to the stereo audio CODEC 350 .
  • FIG. 3 further illustrates a radio frequency (“RF”) transceiver 368 that may be coupled to the analog signal processor 326 .
  • An RF switch 370 may be coupled to the RF transceiver 368 and an RF antenna 372 .
  • the RF transceiver 368 may communicate with conventional communications networks as well as with global positioning system (“GPS”) satellites in order to obtain GPS signals for geographical coordinates.
  • GPS global positioning system
  • a keypad 374 may be coupled to the analog signal processor 326 .
  • a mono headset with a microphone 376 may be coupled to the analog signal processor 326 .
  • a vibrator device 378 may be coupled to the analog signal processor 326 .
  • FIG. 3 also shows that a power supply 380 may be coupled to the on-chip system 322 .
  • the power supply 380 is a direct current (“DC”) power supply that provides power to the various components of the PCD 101 that require power.
  • the power supply is a rechargeable DC battery or a DC power supply that is derived from an alternating current (“AC”) to DC transformer that is connected to an AC power source.
  • FIG. 3 also shows that PCD 101 may include a financial institution (“FI”) management module 104 C in addition to a web browser.
  • the web browser 16 and/or FI management module 104 C may comprise software that is used to communicate with branded customer registration website 110 and financial institutions 104 of FIG. 1A .
  • the touchscreen display 332 , the video port 338 , the USB port 342 , the camera 348 , the first stereo speaker 354 , the second stereo speaker 356 , the microphone 360 , the FM antenna 364 , the stereo headphones 366 , the RF switch 370 , the RF antenna 372 , the keypad 374 , the mono headset 376 , the vibrator 378 , and the power supply 380 are external to the on-chip system 322 .
  • FIGS. 4A-4B illustrate a flowchart of a method 400 A-B for processing a member financial institution customer payor to a member financial institution customer payee.
  • a member financial institution customer payor who operates a portable computing device 101 for sending a payment will be referred to as a sender in the method 400 A and in subsequent flowcharts.
  • a member financial institution customer payee who will also operate a portable computing device 101 for receiving payment will be referenced as the receiver a method 400 A.
  • one or more of the method steps described herein may be stored in the memory 112 as computer program instructions. These instructions may be executed by the digital signal processor or central processing unit 324 , the analog signal processor 326 , or another processor, to perform the methods described herein. Further, the processors, 324 , 326 , the memory 112 , the instructions stored therein, or a combination thereof may serve as a means for performing one or more of the method steps described herein.
  • block 401 is the first step in method 400 A.
  • the sender initiates a person-to-person payment using a portable computing device 101 such as illustrated in FIG. 15A .
  • the portable computing device 101 is not limited to a mobile phone and may include other devices, such as, but not limited to, a personal digital assistant, a pager, a smartphone, a tablet portable computing device, a navigation device, and a hand-held or personal computer with a wireless connection or link.
  • a receiver's alias is received with the portable computing device 101 , such as illustrated in FIG. 15B described in detail below.
  • the receiver's alias may comprise an e-mail address and/or a mobile phone number of the receiver (who will be receiving the payment).
  • the sender may select a unique identifier for associating with receiver's payment from the sender who is operating the portable computing device 101 for issuing a payment.
  • the sender may select a contact from a contacts list that has an association with the requisite alias that may comprise either an e-mail address and/or a mobile phone number of the receiver.
  • the sender's financial institution 104 A receives the alias from the portable computing device 101 .
  • the communications between the sender's financial institution 104 A and the sender's portable computing device 101 may occur over a secure communications channel as understood by one of ordinary skill the art and as described above in connection with FIG. 1B .
  • the secure communications channel between all of the devices of the system described below may be established using tokens as described above.
  • the communications channels may be established across computer networks 173 , such as the Internet, as understood by one of ordinary skill in the art.
  • the sender's financial institution 104 A will generate an inquiry with its own API that will communicate the alias with the identify payee API 106 B 2 of the payment switch module 102 .
  • the identify payee API 106 B 2 is described in detail above.
  • the payment switch module 102 will execute a query with the consumer alias registry database 108 A to determine if the alias transmitted from the sender's financial institution 104 A exists in the database 108 A.
  • decision block 408 the consumer alias registry database 108 A will determine if the receiver alias exists or not within its files. If the inquiry to decision block 408 is negative, then the “NO” branch is followed to block 902 of FIG. 9A , which will be described in further detail below. If the inquiry to decision block 408 is positive, then the “YES” branch is followed to block 410 .
  • the consumer alias registry database 108 A retrieves the record of the destination account associated with the receiver and associated with the receiver's alias.
  • the receiver's alias may also be associated with one or more velocity payment options.
  • Velocity payment options may comprise an immediate transfer of funds into the destination account. This immediate transfer of funds into the destination account may occur when the sender's financial institution 104 A in the receiver's financial institution 104 B are members of the payment system 100 .
  • the immediate transfer of funds option is one unique feature of the inventive payment system 100 .
  • each member financial institution 104 agrees to honor person-to-person payments such that when a receiver's financial institution 104 B of receives a message from the payment switch module 102 that a payment is being made from another member sender's financial institution 104 A, then the receiver's financial institution 104 B may make funds immediately available upon receiving that message from the payment switch module 102 knowing the trusted obligation from the first financial institution to settle.
  • the funds will be made immediately available when the receiver of the second financial institution 104 B acknowledges receipt of the person-to-person payment.
  • the second financial institution 104 B will then be reimbursed for these immediate funds at the end of the business day by the first financial institution 104 A associated with the sender.
  • Another velocity payment option may comprise an ACH credit to be submitted for the destination account.
  • Another velocity option may include charging up a gift card and/or adding funds to a prepaid or debit account.
  • Velocity options may include any form of payment that may be selected by the receiver.
  • the consumer alias registry database 108 A relays this information to the payment switch module 102 .
  • the payment switch module 102 relays the velocity payment options and destination account to the sender's financial institution 104 A which then relays them to the portable computing device 101 of the sender, such as illustrated in FIG. 15C described in detail below.
  • the payment switch module 102 relays this information to the sender's financial institution 104 A through the identify payee API 106 B 2 .
  • the sender receives the velocity payment options from the sender's financial institution 104 A and then the portable computing device 101 receives one of the velocity payment options selected by the sender.
  • the sender operating his portable computing device 101 selects the immediate payment velocity payment option. This selection is then relayed to the sender a financial institution 104 A.
  • decision block 414 the sender's financial institution 104 A determines if the payment should be allowed to proceed.
  • Decision block 414 may be tied or connected to an internal fraud checking mechanism such as a rules driven antifraud measure. At a minimum, decision block 414 causes the sender's financial institution 104 A to verify that the sender has sufficient funds in his account to make the payment.
  • the “NO” branch is followed to block 415 in which the payment is rejected for the lack of funds in the sender's account and/or due to a violation of one or more antifraud rules that may be controlled and established by the financial institution 104 A.
  • a rejection message may be transmitted to the sender and the method 400 may end.
  • the payment switch module 102 receives the payment request message and then creates a payment through the create payment API 106 B 3 as described above.
  • the payment switch module 102 creates a payment entry in the transaction database 108 B.
  • the payment entry in the transaction database reflects that the payment is in a pending status.
  • the payment switch module 102 verifies the payment against network and financial institution risk thresholds that are created through the limits service module 116 as described above in connection with FIG. 1B .
  • the limits service module 116 and its corresponding thresholds were established by the financial institution 104 A of the sender which may use the risk limit configuration module 114 that is part of the administrative console module 112 .
  • the limits service module 116 may also comprise network thresholds that are established by the payment switch module 102 and more particularly, by the operator of the payment switch module 102 .
  • the network thresholds established by the payment switch module 102 may limit the amount of money that any particular sender may wish to send across the payment switch module 102 .
  • the network thresholds in such an instance would track the aggregate amount being transferred by a particular sender over a specific period of time such as within one business day.
  • the network thresholds may also restrict the amount of money that anyone particular receiver they receive over a specific time. Such as within one business day.
  • One of ordinary skill the art will recognize that other network thresholds are possible and may include any combinations as described above.
  • the limits service module 116 determines if any risk limits imposed by the sender financial institution 104 A, receiver financial institution 104 B, and/or the payment switch module 102 have been exceeded. If the inquiry to decision block 420 is positive, then the “YES” branch is followed to block 502 of FIG. 5 described in further detail below.
  • the payment switch module 102 retrieves a secure party identifier (“SPI”) from the secure party identifier generation module 122 .
  • SPI secure party identifier
  • a secure party identifier generation module 122 produces a unique identifier based on the alias that was matched from the consumer alias registry database 108 A.
  • the secure party identifier generation module 122 is coupled to the consumer alias registry 108 A.
  • the secure party identifier generation module 122 pulls its data from the consumer alias registry 108 A.
  • a secure party identifier may comprise the last four characters of the receiver's last name and the first three characters of the receiver's first name that are listed in the consumer alias registry 108 A.
  • characters for the secure party identifier may be retrieved from e-mail addresses, mobile telephone numbers, mailing addresses, etc.
  • One exemplary intent of the secure party identifier may include allowing the sender to confirm the identity of the intended receiver so that the sender may correct a selection of a wrong receiver.
  • the secure party identifier should contain enough information so that the sender may easily recognize the intended receiver.
  • the payment switch module 102 via the create payment API 106 B 3 forwards the secure party identifier in addition to the payment information such as the payment amount to the sender financial institution 104 A.
  • the sender financial institution 104 A relays the data that includes the secure party identifier and the payment information for display on the portable computing device 101 , such as illustrated in FIG. 15D described below.
  • the portable computing device 101 prompts the sender to select whether or not he or she recognizes the intended receiver based on the secure party identifier.
  • the “NO” branch is followed to block 602 of FIG. 6 . Further details of FIG. 6 will be described below. If the inquiry to block 426 is positive, then the “YES” branch is followed to block 428 in which the sender financial institution 104 A will send a message to the payment switch module 102 of the payment confirmation by the sender. This payment confirmation message will be relayed through the set payment status API 106 B 4 (described above in connection with FIG. 1B ) from the sender's financial institution 104 A to the payment recipient module 102 .
  • the payment switch module 120 updates the entry in the transaction database 108 B to reflect that the pending payment has been confirmed by the sender. This confirmation status by the sender triggers additional processing by the payment switch module 120 .
  • the additional processing includes blocks 432 and 434 .
  • the payment switch module 120 via the process payment status API 106 D 1 described above transmits a message to the sender financial institution 104 A that the payment is now in process.
  • the sender financial institution 104 A in this block 432 may also transmit a message to the portable computing device 101 A of the sender that indicates the payment has been confirmed, such as illustrated in FIG. 15E described below.
  • the payment switch module 120 via the process payment status API 106 D 1 transmits a message to the receiver financial institution 104 B that there is a pending payment for the receiver.
  • the sender's financial institution 104 A pulls from the sender's account corresponding to the payment amount and holds the funds for settlement at the predetermined interval established by the operator of the payment switch module 120 .
  • this predetermined interval comprises a time at the end of a typical business day.
  • the sender's financial institution 104 A will withdraw the funds from the sender's account that corresponds to the payment amount and hold these funds in a general ledger account until the predetermined interval which is usually the end of a typical business day.
  • the sender financial institution 104 A relays a message to the portable computing device 101 of the sender to indicate that the payment is in process whereby the sender's account with the financial institution 104 A has been debited and the payment will be made to the intended receiver shortly.
  • the receiver financial institution 104 B receives that message in decision block 440 and then determines if the receiver has been configured for automatic payment.
  • Automatic payment as an optional feature that may be selected by a receiver such that payments from specific or particular senders may be automatically accepted without confirmation by the receiver.
  • the system 100 is designed such that a receiver must confirm acceptance of a payment before the payment is completely processed. In this way, a receiver may refuse acceptance of payments from senders that he or she does not know.
  • the automatic payment feature allows a receiver to identify specific senders that the receiver will always accept payments from.
  • the automatic payment feature allows a receiver to receive payments from familiar or previous sender's and permits the receiver to receive payments without logging into the system 100 .
  • the “YES” branch is followed to block 442 in which the receiver's financial institution 104 B credits funds into the receiver's account from a general ledger account maintained by the receiver's financial institution 104 B.
  • the receiver's financial institution 104 B creates a message that is transmitted to the payment switch module 102 which indicates that the payment to the receiver has been made/completed. This message created in block 444 is transmitted through the set payment status API 106 B 4 as described above in connection with FIG. 1B .
  • the payment switch module 102 receives the message from block 444 via the payment status API 106 B 4 .
  • the payment switch module 102 then updates the transaction database 108 B to indicate that the sender's financial institution 104 B has completed the payment to the receiver.
  • the payment switch module 102 also creates an entry in a net settlement report to indicate that the payment to the receiver has been made by the receiver's financial institution.
  • This net settlement report may be created for each financial institution 104 .
  • An entry may be created in a net settlement report for the receiver's financial institution 104 B as well as a net settlement report for the sender's financial institution 104 A.
  • the net settlement report may be maintained in the transaction database 108 B by the payment switch module 102 .
  • the payment switch module 102 creates a message for the sender's financial institution 104 A that the receiver's financial institution 104 B has completed the payment to the receiver. This message is transmitted from the payment switch module 102 via the process payment status API 106 D 1 as described above in connection with FIG. 1B .
  • the sender financial institution 104 A receives the payment complete status message from the payment switch module 102 via the process payment API 106 D 1 .
  • the sender financial institution 104 A may create message indicating that the payment has been accepted by the receiver. This message may be transmitted from the sender financial institution 104 A to the PCD 101 of the sender. The method 400 A at this stage may end or terminate.
  • block 454 the receiver's financial institution 104 B generates a message that is transmitted to the portable computing device 101 B of the receiver. This message indicates that a payment is pending for the receiver and that the receiver needs to log into the system 100 and formally accept the payment from the sender.
  • This message from the receiver's financial institution 104 B may be transmitted in an e-mail or a text message.
  • the transmission format is usually dependent upon a preference selected by the receiver when he or she created their account with their financial institution 104 .
  • the message will generally comprise an instruction for the receiver to log in to the system 101 in order to accept the payment from the sender. If the message is sent in either an e-mail or a text message, the message may comprise a hypertext link that allows the receiver to select so that access to the system 101 may be made with little or no effort by the receiver.
  • the portable computing device 101 B of the receiver receives the message from the receiver's financial institution 104 B.
  • the receiver operating the portable computing device 101 B may login to the system 101 at his or her own discretion.
  • the receiver may login to the system 101 within a few minutes or within a few days in order to accept the payment from the sender.
  • the receiver logs into the system 101 and this generates a message that is sent from the portable computing device 101 B of the receiver to the receiver's financial institution 104 B.
  • the receiver's financial institution 104 B upon receiving the log-in message from the portable computing device 101 B, creates a message that instructs the payment switch module 102 to look up and retrieve any pending payments for the alias associated with the receiver who logged into the system 101 .
  • This message in block 456 is transmitted through the process pending payments API 106 D 2 described above in connection with FIG. 1B .
  • the payment switch module 102 upon receipt of the message sent through the process pending payments API 106 D 2 , the payment switch module 102 looks up and retrieves pending payments for the receiver that are listed in the transaction database 108 B.
  • the receiver may have more than one pending payment depending upon the number of payments that may have been sent by other sender's over the course of a period of time.
  • the payment switch module 102 queries the transaction database 108 B for the number of payments pending for the receiver and then creates a message which is transmitted via the process pending payments API 106 D 2 to the receiver's financial institution 104 B.
  • the receiver's financial institution 104 B then relays the pending payments to the portable computing device 101 B of the receiver.
  • decision block 462 the portable computing device 101 B prompts the user with an instruction to either accept or reject the pending payments that were retrieved by the receiver's financial institution 104 B for the receiver. If the inquiry to decision block 462 is negative, then the “NO” branch is followed to block 702 of FIG. 7 . Further details of FIG. 7 will be described below.
  • the “YES” branch is followed to block 464 .
  • the positive inquiry to decision block 462 causes the portable computing device 101 B of the receiver to create a message in transmit the acceptance to the receiver's financial institution 104 B.
  • the receiver's financial institution 104 B may generate a message back to the portable computing device 101 B that includes an option for the receiver to set up the automatic payment configuration so that the receiver does not have to log into the system 101 for this particular sender.
  • the automatic payment configuration option at this stage may also allow the receiver to configure automatic payment for any sender that forwards payment to the receiver.
  • One additional option that may be displayed and selected by the receiver is to identify which account at the receiver's financial institution 104 B should receive the automatic acceptance of payments.
  • Various other auto-pay options may be displayed and available for the receiver to select at this stage as understood by one of ordinary skill the art.
  • decision block 466 the portable computing device 101 B of the receiver may prompt the receiver to decide whether he or she wants to set up the automatic payment configuration described above. If the inquiry to decision block 466 is positive, then the “YES” branch is followed back to block 468 . In this decision block 466 , under a positive inquiry, the receiver may enter and select his or her options for the automatic payment configuration. These options for the automatic payment configuration are routed to the receiver's financial institution 104 B which are then relayed by the receiver's financial institution 104 B through the set auto pay configuration API 106 A 4 as described above in connection with FIG. 1B .
  • the payment switch module 102 receives the automatic payment configuration options selected by the receiver and stores them in the consumer alias registry database 108 A. In block 468 , the payment switch module 102 generates a message to indicate that the automatic payment options have been received and stored in the consumer alias registry database 108 A. This confirmation message is relayed back to the sender's financial institution 104 B via the set auto pay configuration API 106 A 4 . After block 468 , the process returns to block 442 in which the receiver's financial institution 104 B credits funds into the receiver's account corresponding to the payment amount as described above.
  • Block 442 the receiver's financial institution 104 B credits funds into the receiver's account corresponding to the payment amount from the general ledger maintained by the receiver's financial institution 104 B.
  • Block 442 is the same block which was reached from the positive inquiry path at the output of decision block 440 described above.
  • FIG. 5 illustrates a continuation flowchart of the method 400 B of FIGS. 4A-4B for processing a member financial institution customer payor to a member financial institution customer payee.
  • Block 502 is the first step in method 400 B which originates from a positive result or the “YES” branch following decision block 420 in which a risk limit has been exceeded as verified by the limit service module 116 of the payment module 102 .
  • the limits service module 116 identifies what limits have been exceeded with respect to the payment that was ordered by the sender.
  • the limits service module 116 and its corresponding thresholds may be established by the financial institution 104 A of the sender which may use the risk limit configuration module 114 that is part of the administrative console module 112 .
  • the limits service module 116 and its corresponding thresholds may be established by the financial institution 104 B of the receiver which may use the risk limit configuration module 114 that is part of the administrative console module 112 .
  • the limits service module 116 may also comprise network thresholds that are established by the payment switch module 102 and more particularly, by the operator of the payment switch module 102 .
  • the network thresholds established by the payment switch module 102 may limit the amount of money that any particular sender may wish to send or any particular receiver who may receive money across the payment switch module 102 .
  • the network thresholds in such an instance would track the aggregate amount being transferred by a particular sender over a specific period of time such as within one business day.
  • the network thresholds may also restrict the amount of money that anyone particular receiver they receive over a specific time, such as within one business day.
  • One of ordinary skill the art will recognize that other network thresholds are possible and may include any combinations as described above.
  • the limit service module 116 generates a message that identifies the one or more risk limits that have been exceeded by the sender's request to transfer money to the intended receiver. This message created in block 502 is transmitted through the create payment API 106 B 3 and is sent to the sender's financial institution 104 A.
  • the payment switch module 102 stores the risk limit conditions that were exceeded in the transaction database 108 B.
  • the sender's financial institution receives the risk limit exceptions message via the create payment API 106 B 3 and then generates its own message that is relayed to the portal computing device 101 of the sender which states that the payment could not be processed. It is at the discretion of the sender's financial institution 104 A of what level of information about the risk limit exception is conveyed to the sender.
  • the sender's financial institution 104 A will merely state that the transaction could not be processed.
  • the message will usually state that the sender needs to contact the sender's financial institution 104 A to get any additional detail about the rejection of the transaction.
  • the payment switch module 102 may support one or more override features that allow sender and receiver financial institutions 104 to allow for overrides with respect to risk limit exceptions. Therefore, if a sender or a receiver's alias is placed on an override list created by one of the financial institutions 104 , the payment switch module 102 may allow a transaction to occur even if the transaction exceeds a risk limit since the sender or receiver (or both) are present on an override list which allows such individuals to exceed risk limits imposed by financial institutions 104 .
  • FIG. 6 illustrates a continuation flowchart of the method 400 C of FIGS. 4A-4B for processing a member financial institution customer payor to a member financial institution customer payee.
  • Block 602 is the first step in method 400 C which originates from a negative result or the “NO” branch following decision block 426 of FIG. 4 in which a sender cancels a payment because he or she does not recognize the secure party identifier (“SPI”) presented in block 424 of FIG. 4 .
  • SPI secure party identifier
  • the sender's financial institution 104 A receives the message that was created by the portable computing device 101 of the sender which indicates that the sender has decided to cancel the payment transaction.
  • the sender's financial institution 104 A then relays this message through the set payment status API 106 B 4 to the payment switch module 102 .
  • the payment switch module 102 receives the message from the sender's financial institution 104 A via the set payment status API 106 B 4 and then updates the payment status in the transaction database 108 B to indicate that the payment has been canceled by the sender.
  • the transaction database 108 B may be designed such that it tracks all transactions, including ones that have been canceled like the exemplary embodiment illustrated in FIG. 6 , for some period of time. This period of time is usually set by government regulations. Such regulations usually require transaction records to be kept for a time period of at least five years or more.
  • FIG. 7 illustrates a continuation flowchart of the method 400 D of FIGS. 4A-4B for processing a member financial institution customer payor to a member financial institution customer payee.
  • Block 702 is the first step in method 400 D which originates from a negative result or the “NO” branch following decision block 462 of FIG. 4 in which the receiver rejects payment when the receiver logs into his receiver financial institution 104 B to check on what payments have been received from one or more other sender's.
  • This negative condition from block 462 of FIG. 4 is also a result of the receiver not completing or electing to receive payments automatically according to the automatic accepting feature/option that may be selected in previous block 440 of FIG. 4 .
  • the receiver financial institution 104 B upon receiving the message from the portable computing device 101 B operated by the receiver indicating that the receiver has rejected the payment from the sender, the receiver financial institution 104 B closes or cancels this payment transaction and generates a message for relaying this information to the payment switch 102 .
  • the receiver financial institution 104 B relays the rejection payment message via the set payment status API 106 B 4 to the payment switch module 102 .
  • the payment switch module 102 updates the transaction database 108 B to reflect that the payment transaction has been canceled. The payment switch module 102 then creates a message for relaying this information to the sender's financial institution 104 A. In block 708 , the payment switch module 102 via the process payment status API 106 D 1 relays the rejection payment message to the sender's financial institution 104 A.
  • the sender's financial institution 104 A may reverse the prior debit to the sender's account and release funds back into the sender's account that correspond to the amount of the original payment created by the sender.
  • This block 710 is followed to counteract or balance out block 436 of FIG. 4 in which the sender's account was previously debited and the funds were held in the settlement account by the sender's financial institution 104 A.
  • the sender's financial institution 104 A may create a message for relaying to the portable computing device 101 of the sender that indicates that the payment transaction has not been processed. According to one exemplary embodiment, this message may state that the payment was rejected by the receiver. In other exemplary embodiments, a financial institution 104 A may simply state in the message for the sender to contact the financial institution 104 A by telephone or other ways to obtain more details about the rejected transaction.
  • FIG. 8A illustrates a separate flowchart of a method 800 A for checking on payments that have expired for lack of acceptance by a receiver.
  • Method 800 A runs in parallel with respect to Method 400 of FIG. 4 and is generally executed by the payment switch module 102 , and specifically, the expired payments tracking module 124 of the payment switch module 102 .
  • Method 800 A corresponds to a time element with respect to decision block 462 of FIG. 4 in which the receiver has failed to log into his receiver financial institution 104 B within a predetermined amount of time.
  • This predetermined amount of time may be established by the payment switch 102 .
  • Exemplary time limits include, but are not limited to, fourteen calendar days or 10 business days, or the like.
  • Block 802 is the first step of method 800 A.
  • the payment switch module 102 (via its expired payments tracking module 124 ) conducts searches within the transaction database 108 B for expired payments—those payments which have exceeded the time limit established by the payment switch module 102 , and more particularly, the operator of the payment switch module 102 who uses the administrative console module 112 .
  • the expired payments transaction module 124 updates those active payments in the transaction database 108 B that have expired. As described above, payment expiration may occur due to the receiver not logging into his or her account at a respective receiver financial institution 104 B within the predetermined period of time established by the payment switch module 102 .
  • the expired payments transaction module 124 creates an expired payment message for delivery to the sender's financial institution 104 A.
  • the expired payments transaction module 124 relays this expired payment message to the sender's finance will institution 104 A through the process payment status API 106 D 1 that is described above.
  • block 808 the sender's financial institution 104 A upon receiving the expired payment message via the payment status API 106 D 1 , reverses the debit that was made to the sender's account and releases the funds back into the sender's account similar to block 710 of FIG. 7 described above.
  • block 808 to counteracts/cancels-out the debit block 436 of FIG. 4 which was made to correspond with the payment amount in the payment request established by the sender.
  • the sender's financial institution 104 A may create a message for relaying to the portable computing device 101 of the sender that indicates that the payment transaction has not been processed. According to one exemplary embodiment, this message may state that the payment has expired. In other exemplary embodiments, a financial institution 104 A may simply state in the message for the sender to contact the financial institution 104 A by telephone or other ways to obtain more details about the rejected transaction. Method 800 A then ends.
  • FIG. 8B illustrates a separate flowchart of a method 800 B for retrieving payments that have expired for lack of acceptance by a receiver.
  • Method 800 B may be executed by the expired payments tracking module 124 of the payment switch module 102 .
  • Block 812 is the first step of method 800 B.
  • a receiver may use his portable computing device 101 B to log into his receiver financial institution 104 B after the expiration of one or more payment transactions.
  • the receiver may send a message from his portable computing device 101 B to his receiver financial institution 104 B to retrieve any current and pending payment transactions intended for the receiver.
  • the receiver's financial institution 104 B may receive the payment inquiry message from the portable computing device 101 B and then generate its own message containing this inquiry by using the process pending payment API 106 D 2 that is described above in connection with FIG. 1B and then relay this message to the payment switch module 102 .
  • the payment switch module 102 upon receiving the payment inquiry message via the process pending payments API 106 D 2 may execute a query with the transaction database 108 B to identify those payments which are pending for the receiver.
  • expired payments due to timeouts may not be displayed.
  • the payment switch module 102 via the process pending payments 106 D 2 will relay this message to the receiver's financial institution 104 B.
  • the payment switch module 102 may relay a listing of expired payments that cannot be completed to the receiver's financial institution 104 B so that the receiver's financial institution 104 B may relay this information back to the receiver.
  • this message may include that there are no payments pending since all payments have been expired or a message that includes a listing of expired payments that cannot be completed due to the receiver failing to log into the financial institution 104 B within the predetermined periods of time established for a respective payment.
  • Each receiver financial institution 104 B at its discretion may also include a message that tells the receiver the predetermined time period in which he or she needs to log into the financial institution 104 in order to accept a payment or how the receiver may set up the automatic payment/receive option for particular senders. For each expired payment, the receiver will need to request each sender to order or create a new payment transaction. Method 800 B then ends.
  • FIG. 9A illustrates a continuation flowchart of a method 400 E of FIGS. 4A-4B for processing a member financial institution customer payor to a member financial institution customer payee.
  • Block 902 is the first step in method 400 E which originates from a negative result or the “NO” branch following decision block 408 of FIG. 4 in which the receiver is not present in the consumer alias registry database 108 A.
  • Decision block 408 is checking to determine if a receiver identified by the sender exist within the alias registry database 108 A.
  • the payment switch module 102 returns non-velocity type payment options that are available to the sender for a receiver which is not present within the consumer alias registry 108 A.
  • a receiver is not present within the consumer alias registry 108 A, this means that the receiver does not have a financial institution 104 that may receive payments from the payment switch module 102 .
  • the receiver's financial institution 104 B may not be a member or a subscriber of the system 100 that includes the payment switch module 102 .
  • Non-velocity type payment options are those which do not include the person-to-person payment functions supported by the payment switch module 102 .
  • the non-velocity type payment options may include, but are not limited to, ACH transfers, wire transfers, and the sender financial institution 104 A issuing a check on the behalf of the sender to the receiver.
  • the payment switch module 102 creates the list of non-velocity type payment options and places this list in a message which is transmitted to the sender's financial institution 104 A utilizing the identify payee API 106 B 2 that is described above. Upon receiving the message containing the non-velocity type payment options, the sender's financial institution 104 A may relay this message to the portable computing device 101 operated by the sender.
  • the sender may select from the list of non-velocity type payment options that were transmitted by the sender's financial institution 104 A.
  • the portable computing device then relays a message containing the selection of the non-velocity type payment option to the sender's financial institution 104 A.
  • decision block 906 the sender's financial institution 104 A receives the selected payment option and then determines if the payment option should be allowed to proceed.
  • Decision block 906 is like decision block 414 of FIG. 4 , and it may be tied or connected to an internal fraud checking mechanism such as a rules driven antifraud measure. At a minimum, decision block 906 causes the sender's financial institution 104 A to verify that the sender has sufficient funds in his account to make the payment.
  • the sender's financial institution 104 A creates a message which is transmitted through the create payment API 106 B 3 that is described above. This message is relayed to the payment switch module 102 .
  • the payment switch module 102 generates a payment upon receiving the message from the sender's financial institution 104 A via the create payment API 106 B 3 .
  • Block 908 is similar to block 416 of FIG. 4 .
  • the payment switch module 102 creates a payment entry in the transaction database 108 B.
  • the payment entry in the transaction database 108 B reflects that the payment is in a pending status but is going to occur via a non-velocity payment option that was selected by the sender.
  • routine block 910 the payment switch module 102 issues a non velocity payment command to the sender's financial institution 104 A. For example, if the ACH transfer was selected for the non-velocity payment option by the sender, then the payment switch module 102 may issue an ACH transfer command to the sender's financial institution 104 A which can then process the command like routine ACH transfers.
  • Routine block 910 may comprise various steps and may include such steps like blocks 416 - 434 of FIG. 4 described above, but in a non-velocity payment context.
  • the main difference upon the selection of a non-velocity payment option under this method 400 E is that there is no immediate debit of funds from the sender's account such as noted in block 436 of FIG. 4 , like in an ACH transfer scenario.
  • FIG. 9B illustrates a separate flowchart of a method 400 F for processing non-velocity payment options, like an ACH transfer, for a receiver does not have an account with a financial institution 104 B that is part of the system 100 .
  • Method 400 F runs in parallel with respect to Method 400 E of FIG. 9A and is generally executed by the payment switch module 102 and a receiver's financial institution 104 B.
  • Block 914 is the first step of method 400 F.
  • the payment switch module 102 sends a communication to the receiver using the alias provided by the sender which may include, but is not limited to, an e-mail address or a mobile phone number.
  • This communication may include a hypertext link to the registration website 110 as described above in connection with FIG. 1B .
  • the receiver may access the branded registration website 110 that corresponds to the financial institution 104 B at which the receiver may have an account.
  • the receiver may enter into his portable computing device 101 B the account number associated with his financial institution 104 B as well as any routing information associated with account. If the non-velocity option of an ACH transfer was selected by the sender, then the receiver would be prompted in block 918 for the receiver to enter his or her checking account number and routing number associated with the checking account.
  • the registration website 110 would relay this information to the payment switch module 102 .
  • the payment switch module 120 would look up the receiver's financial institution 104 B based on the routing number associated with the account to determine if the receiver financial institution 104 B is part of and/or subscribes to the system 100 .
  • the payment switch module 102 determines if the receiver's account is associated with a financial institution 104 B that is part of and/or subscribes to the system 100 . If the inquiry to decision block 922 is positive, then the “YES” branch is followed to block 932 described below.
  • the payment switch module 902 populates the consumer alias registry 108 A with the receiver's alias (e-mail address and/or mobile phone number) along with the financial institution information.
  • the payment switch module 102 generates a micro deposit ACH batch for sending to the receiver's account of his receiver's financial institution 104 B.
  • the receiver may again access the branded registration website 110 of his financial institution 104 B with his portable computing device 101 B.
  • the receiver may verify the micro deposit made by the payment switch module 102 into his checking account with his receiver financial institution 104 B.
  • the “NO” branch may be followed to block 938 .
  • the receiver's financial institution 104 B would transmit the error condition of the negative consequence for decision block 932 the payment switch module 102 .
  • decision block 932 the portable computing device 101 B of the receiver prompts the receiver to accept the payment from the sender. If the inquiry to decision block 932 is negative, then the “NO” branch is followed to block 938 .
  • the payment switch module 102 updates the payment status in the transaction database 108 B to an accepted status.
  • the payment switch module 102 via the process ACH payment (non-instant payment) API 106 D 3 described above issues a message to the sender's financial institution 104 A to process an ACH payment.
  • the sender's financial institution 104 A upon receipt of the message from the payment switch module 102 via the non-instant payment API 106 D 3 may add the ACH entry to its North American Clearing House (“NACHA”) batch file. Also in block 942 , the sender's financial institution 104 A may generate a message and transmit it using the set payment status API 106 B 4 to the payment switch module 102 . In block 946 , upon receipt of the message from the sender's financial institution 104 A via the set payment status API 106 B 4 , may update the payment status in the transaction database 108 B to complete. And then the method 400 F may end.
  • NACHA North American Clearing House
  • the payment switch module 102 may update the payment status in the transaction database 108 B to rejected.
  • the payment switch module may generate a message for sending to the sender's financial institution 104 B. This message may indicate the rejection or non-acceptance of the payment by the receiver via the process payment status API 106 D 1 .
  • the sender's financial institution 104 A may notify the sender of the non-acceptance of the payment by the receiver by transmitting a message to the portable computing device 101 A of the sender.
  • the method 400 F may end.
  • FIG. 10 illustrates a continuation flowchart of a method 400 G for processing a member financial institution customer payor to a member third-party payment service customer payee.
  • the third-party payment service may comprise a service such as PAY-PALTM known at the time of this writing.
  • This method 400 G shares many of the steps illustrated in FIG. 4 so they will not be repeated here. Specifically, as indicated by block 1002 which lists blocks 402 - 426 as its contents, this block means that blocks 402 through 426 are performed up to this point for this method 400 G.
  • FIG. 10 may share similar reference characters as corresponding blocks in FIG. 4 . Therefore, if a block in FIG. 10 shares in common the same last two digits of a block listed in FIG. 4 , then such blocks in FIG. 10 are identical to those in FIG. 4 and further explanation will not be provided. Only the difference between the blocks in FIG. 4 and FIG. 10 will be described below.
  • block 1028 which is identical to block 428 of FIG. 4 occurs in which a message is created by the sender's financial institution 104 A to indicate that payment has been confirmed by the sender.
  • block 1029 (which is new and unique relative to FIG. 4 ) an internal demand deposit account relative within sender's financial institution 104 A, and which is tied to a dedicated third-party service (i.e. PAY-PALTM) account, is funded in an amount corresponding to the payment selected by the sender with his portable computing device 101 A.
  • PAY-PALTM dedicated third-party service
  • Block 1029 is unique since it addresses the structure of many third-party service payment providers that only permit transfers of funds between accounts which are identical and are only maintained by the third-party service in a provider, such as in PAY-PALTM accounts as of this writing.
  • Each sender's financial institution 104 A will usually establish a third-party service account (i.e. with PAY-PALTM) that is tied to a demand deposit account (“DDA”) or general ledger account that it maintains. In this way, sender's financial institution 104 A can instruct transfers to be made from its third-party service account and this third parties service account will siphon funds are pooled funds from its demand deposit account or general ledger account.
  • a third-party service account i.e. with PAY-PALTM
  • DDA demand deposit account
  • general ledger account general ledger account
  • third-party service accounts do not require funds in order to be maintained by the third-party service provider.
  • these third-party service accounts usually require a link or direct connection to a funding or “source” account at a financial institution or a credit card account.
  • Blocks 1030 - 1038 generally correspond to their counterpart blocks 430 - 438 of FIG. 4 and will not be discussed further here.
  • a payment switch module 102 instead of notifying the receiver's financial institution 104 B of a pending payment, in this block a payment switch module 102 submits a payment request to the third-party API 106 E 1 as described above in connection with FIG. 1B .
  • Blocks 1060 - 1070 are different and new relative to FIG. 4 and will be described as follows.
  • the third-party service provider 118 receives the payment request message via the third-party API 106 E 1 and debits the sender's financial institution third-party service account in an amount corresponding to the payment requested by the sender.
  • the third-party service provider 118 credits the receiver's third-party service account in an amount that corresponds to the debit to the financial institutions third-party service account (which will be the amount of the payment request specified by the sender). Also in this block 1062 , the third-party payment service provider 118 creates a message that indicates the transfer between the financial institutions third-party payment account and the receiver's third-party payment account has occurred.
  • the payment switch module 102 receives the payment complete message from the third-party payment service provider 118 and then updates the payment status in the transactional database 108 B to complete.
  • the payment that was made into the demand deposit account tied to the third-party payment service account is added to the net settlement report also maintained in the transactional database 108 B.
  • the payment switch module 102 generates a message to indicate that the payment has been completed and it transmits this message to the sender's financial institution 104 A.
  • the sender's financial institution 104 receives the payment complete message from the payment switch module 102 and then generates its own payment complete message is relayed to the portable computing device 101 A of the sender. Method 400 G then ends.
  • FIG. 11A illustrates a separate flowchart of a method 1100 A for registering a third party payment service provider account (PAYPALTM, AMAZONTM, etc.) 118 for transferring funds to a financial institution (i.e. a bank) 104 .
  • a financial institution i.e. a bank
  • the financial institution 104 may redirect the customer to a website of the third party payment provider 118 so the customer can log in.
  • a member financial institution 104 may store the parameters for the account of the third party payment service provider 118 as they would any other external financial institution 104 that may also be used for transfers.
  • Block 1103 is the first block of method 1100 B.
  • the financial institution 104 prompts the portable computing device 101 of the customer such that the customer registers his or her account with the third-party payment service provider 118 .
  • the customer through the portable computing device 101 picks or selects the account of his third-party payment service provider 118 in which he wishes to register with the financial institution 104 for periodic transfers from the third-party payment service provider 118 to the financial institution 104 .
  • the portable computing device 101 receives the account information for the third-party payment service provider 118 .
  • This may include the account number, date the account was opened, and/or other similar identifying information.
  • this account information for the third-party payment service provider 118 is transferred back to the financial institution 104 .
  • the financial institution 104 may launch a login webpage for the third-party payment service provider 118 .
  • the third-party payment service provider 118 may display the login website page for the customer to enter his or her account credentials with the third-party financial service provider 118 .
  • the customer may enter his or her login credentials for their account with the third-party payment service provider 118 .
  • the financial institution 104 relays these credentials to the third-party payment service provider 118 .
  • the third-party payment service provider 118 verifies the login credentials from a customer. If the credentials are valid, then in block 1117 , the third-party payment service provider 118 may provide options for the customer to select in order to authorize transfers to the payment switch module 102 . These options are relayed to the portable computing device 101 via the financial institution 104 .
  • the portable computing device 101 may receive authorization from the customer for permitting transfers from the third-party payment service provider 118 to the financial institution 101 .
  • the customer may use his or her portable computing device to logout of the third-party payment service provider's website.
  • the financial institution 104 may store the customer's account information that corresponds to the third-party payment provider account. The process or method 1100 A may then end.
  • FIG. 11B illustrates a separate flowchart of a method 1100 B for automatically transferring funds from a third party payment service account (i.e. like PAYPALTM or AMAZONTM payments) on a recurring basis to a receiver's financial institution 104 B.
  • This method 1100 B may be particularly useful for those receiver's who receive payments through third-party payment service accounts frequently.
  • Block 1102 is the first block of method 1100 B.
  • the receiver's financial institution 104 B may receive the one or more selections that a receiver may choose in order to schedule one or more transfers from his third-party payment service account (i.e. PAYPALTM or AMAZONTM payments account) to his account present in the receiver's financial institution 104 B, including the capability for setting regularly scheduled recurring payments.
  • his third-party payment service account i.e. PAYPALTM or AMAZONTM payments account
  • Block 1102 may further comprise the receiver's financial institution 104 B initiating method 1100 in response to the times and days selected by the receiver via a user interface supplied by the receiver's financial institution 104 B.
  • a message is generated by the receiver's financial institution 104 B in this message is relayed to the payment switch module 102 via the create payment API 106 B 3 that is described above.
  • the payment switch module 102 upon receiving the message via the create payment API 106 B 3 , creates a payment similar to block 416 in FIG. 4A .
  • the payment switch module 102 creates a payment entry in the transaction database 108 B.
  • the payment entry in the transaction database reflects that the payment (technically a transfer) from the third-party payment service account is in a pending status.
  • the create payment API 106 B 3 may still be employed since the transaction is similar to a payment to oneself from the perspective of the receiver's financial institution 104 B.
  • the payment switch module 120 updates the entry in the transaction database 108 B to reflect that the pending payment has been confirmed by the sender. This confirmation status by the sender triggers additional processing by the payment switch module 120 .
  • the additional processing includes block 1108 .
  • the payment switch module 120 via the process payment status API 106 D 1 described above transmits a message to the sender financial institution 104 A that the payment is now in process.
  • a payment switch module 102 submits a payment request to the third-party API 106 E 1 as described above in connection with FIG. 4 .
  • the third-party payment service provider 118 may debit the receiver's third party payment service account according to its current balance or some other amount selected by the receiver.
  • the amount of the debit completed in block 1112 is transferred into the receiver's financial institution third-party payment service account that is maintained by the receiver's financial institution 104 B.
  • the receiver's financial institution 104 B may sweep funds from its third-party payment service account to their internal demand deposit account (“DDA”) in order to offset the credit of funds that is made to the receiver's account made in block 1118 .
  • DDA internal demand deposit account
  • the action performed in block 1116 between the receiver's financial institution 104 B and the third party payment service provider 118 may be customized or tailored for each financial institution 104 based on the agreement it has with the third party payment service provider 118 .
  • block 1118 which originates from block 1108 and which may be performed in parallel with block 1112 , the receiver's financial institution 104 B may credit the receiver's account by the amount/balance found by the payment switch 102 in the receiver's third-party payment service account.
  • the point in time in which block 118 occurs may be adjusted in tailored by each financial institution.
  • block 1108 comprises a message from the payment switch module 102 that a payment request has been made to the third-party payment service provider 118 .
  • the receiver's financial institution 104 B may wait a certain period of time before it issues a credit to the receiver's account which corresponds to the amount or balance that will be transferred by the third-party payment service provider into the account at the third-party payment service provider maintained by the receiver's financial institution 104 B.
  • the third-party payment service provider 118 may generate a payment complete message that is sent through the process payment status API 106 D 1 that is described above in connection with FIG. 1B .
  • the payment switch module 102 may update the transaction database to reflect that the payment has been completed.
  • the payment switch module may generate a message that is sent through the process payment status API 106 D 1 for notifying the receiver's financial institution 104 B that the payment from the third-party service payment account has been completed.
  • the receiver's financial institution 104 B may generate a message for relating to the portable computing device 101 B of the receiver which indicates that the payment or transfer from the third-party payment service account has been completed.
  • This message may be sent through secure e-mail that is internal within the receiver's financial institution 104 B. In this way, when the receiver logs into the receiver's financial institution 104 B, the secure e-mail notifying the receiver of the transferred funds may be waiting for the receiver to review. The method 1100 B then ends.
  • FIG. 12 illustrates a flowchart of a method 1200 for registering a financial account holder for a person-to-person payment supported by the payment switch module 102 .
  • Block 1201 is the first step in method 1200 .
  • a financial institution 104 may prompt one of its customers to register for person-to-person payment process supported by the payment switch module 102 .
  • the financial institution 104 may prompt its customers when they log on to the website of the financial institution 104 during an online banking session or during a mobile banking session with a portable computing device 101 .
  • the customer selects the option for registering for the person-to-person payment process.
  • the financial institution 104 may receive appropriate alias information for the person-to-person payment process.
  • the appropriate alias information that is entered by the customer using a portable computing device 101 may include, but is not limited to, the customers e-mail address, the customers mobile phone number, the customers first name, and the customer's last name.
  • This alias information like first name and last name, may be uncovered and pre-populated or listed for the customer to select from based on existing records present at the financial institution 104 .
  • the financial institution 104 may generate a message that requests the payment switch module 102 to check for existing aliases relative to the alias information provided by the customer under this process 1200 .
  • the financial institution 104 may submit this message through the identify payee API 106 B 2 that is described above in connection with FIG. 1B .
  • the payment switch module 102 may query our search the consumer alias registry database 108 A to check for duplicate alias information. Subsequently, in decision block 1210 , the payment switch module 102 determines if a duplicate alias has been found within the database 108 A.
  • the payment switch module 102 If the inquiry to decision block 1210 is positive, then the “YES” branch is followed to block 1211 in which the method 1200 goes to block 1302 of FIG. 13 described in detail below. If the inquiry to decision block 1210 is negative, then the “NO” branch is followed to block 1212 . If the negative condition is met in block 1210 , the payment switch module 102 generates a message that is sent to the financial institution 104 through the identify payee API 106 B 2 .
  • a financial institution 104 upon receipt of the message from the payment switch module 102 via the identify payee API 106 B 2 advising that no duplicate alias has been found, a financial institution 104 generates a message for sending to a portable computing device 101 that displays available debit accounts that the customer may select from for receiving and sending person-to-person payments.
  • the customer using his portable computing device 101 may select a debit account maintained at defining to institution 104 to be used for the person to person payments.
  • the customer via the portable computing device 101 may be prompted to enter know your customer (“KYC”) data.
  • KYC data may include, but is not limited to, personal information that a financial institution 104 may utilize to verify the identity of the customer.
  • the KYC data may include one or more challenge questions, the password to the online banking account, the customer's home address in years past, and the maiden name of the customer's mother or mother-in-law, etc.
  • Such KYC data may be tracked by the financial institution 104 in order to reduce fraud and/or to comply with certain banking regulations.
  • decision block 1218 the financial institution 104 determines if the customer entering in the KYC data with their portable computing device 101 is accurate. If the inquiry to decision block 1218 is negative, then the “NO” branch is followed to block 1219 in which the customers prompted with an error message and request to contact the help desk of the financial institution 104 .
  • the “YES” branch is followed to block 1220 in which the financial institution 104 retrieves the terms and conditions associated with the agreement for using the person-to-person payment service. In block 1220 , these terms and conditions are relayed by the financial institution to the portable computing device 101 of the customer.
  • decision block 1222 the portable computing device 101 executing the online banking session determines if the customer has accepted the terms and conditions associated with the person-to-person payment service supported by the financial institution 104 . If the inquiry to decision block 1222 is negative, then the “NO” branch is followed back to block 1219 .
  • the “YES” branch is followed to block 1224 in which the financial institution receives the message generated by the portable computing device 101 that indicates the customer has accepted the terms and conditions of the agreement for the person-to-person payment service.
  • the financial institution 104 may generate a message requesting a verification code from the payment switch module 102 .
  • the message may also comprise the alias selected by the customer.
  • This message generated by the financial institution 104 in block 1224 is sent through the register account owner API 106 A 1 described in connection with FIG. 1B .
  • the verification code request comprises requesting the payment switch module 102 to generate a verification code.
  • a verification code typically comprises random alphanumeric characters which may be sent to the customer via e-mail or via a mobile phone number in order to verify that the customer owns the e-mail account or mobile phone number selected for the alias.
  • the payment switch module in block 1246 Upon receipt of a message from the financial institution 104 via the register account owner API 106 A 1 , the payment switch module in block 1246 will add the customer alias to the consumer alias registry database 108 A. However, the entry of the alias will be flagged or noted as in an unverified state.
  • the payment switch module 102 will generate the alias a verification code.
  • the payment switch module 102 will transmit this alias verification code based on the type of alias selected. Therefore, if a customer selected in e-mail alias to associate with the person-to-person payments, then in block 1230 , payment switch module 102 will transmit such an alias using the e-mail address. And vice-versa for the mobile phone number.
  • aliases such as a mobile phone number and an e-mail address
  • separate verification codes may be sent to each of these aliases.
  • the two separate verification codes are usually different from one another.
  • a financial institution 104 may prompt the customer to enter in the verification code into a portable computing device 101 .
  • SMS simple messaging service
  • the financial institution 104 may wait for a predetermined period of time before the verification code is expired by the payment switch module 102 .
  • This predetermined period of time may comprise lengths such as on the order of twenty-four hours to just a few hours that can be set by the payment switch module 102 .
  • the payment switch module 102 may set a standard amount that is greater than any time periods established by a respective financial institution 104 . In other words, each respective financial institution may set its own predetermined time period for expiring verification codes that is less than or equal to the time period specified by the payment switch module 102 .
  • the customer using his portable computing device 101 may enter the verification code that was received with his portable computing device 101 . This information collected from the customer using his portable computing device 101 is relayed to the financial institution in block 1236 .
  • a financial institution 104 may generate a message requesting verification of the code that has been received.
  • the financial institution 104 may send this message via the verify alias API 106 A 4 as described above in connection with FIG. 1B .
  • the payment switch module 102 in decision block 1240 may determine if the supplied code matches the actual code which was sent to the customer. If the inquiry to decision block 1240 is negative, then the “NO” branch may be followed to routine or submethod block 1241 in which the financial institution 104 may track a number of times that a wrong verification code is provided. If the number of times that a wrong verification code is provided exceeds a certain threshold, such as on the order of three or four attempts, the financial institution 104 may cancel the registration process. Further details of routine or submethod block 1241 will be described below in connection with FIG. 14 .
  • the payment switch module 1202 updates the consumer alias registry database 108 A to reflect a new status that the alias has been verified by the customer and is ready for use in the person-to-person payment process. Also in block 1242 , payment switch module 102 may generate a message for relaying to the financial institution 104 via the verify alias API 106 A 4 .
  • the financial institution 104 may generate a message that relays this verified status to the portable computing device 101 of the customer. The process or method 1200 then ends.
  • FIG. 13 illustrates a continuation flowchart of a method 1200 B for registering a financial account holder for a person-to-person payment supported by the payment switch module 102 .
  • Block 1302 is the first step in method 1200 B which originates from a negative result or the “NO” branch following decision block 1210 of FIG. 12 in which the payment switch module 102 discovers a duplicate alias in the consumer alias registry 108 A.
  • a duplicate alias may exist for many customers of the financial institutions 104 .
  • Duplicate aliases may occur when a customer registers for person-to-person payments with two more financial institutions 104 .
  • the payment switch module 102 cannot assume that the identity of a customer is the same when duplicate aliases are found.
  • This method 1200 B comprises a verification that a same customer is registering identical alias when duplicate aliases are found within the alias registry database 108 A.
  • the financial institution 104 generates a message that is relayed to the portable computing device 101 of the customer which indicates that a duplicate alias has been found.
  • the message may comprise language such as the following: “this alias has already been registered. Please verify that you have entered the correct alias. If you have registered this alias that another participating financial institution, please continue with this registration process for the registration with the current financial institution.”
  • a portable computing device 101 determines if a new alias has been entered by the customer. If the inquiry to decision block 1302 is negative, meaning that the customer has confirmed that he or she has correctly entered the alias alphanumeric characters, then the “NO” branch is followed to block 1308 in which the method is directed back to block 1212 of FIG. 12 . As noted previously, in block 1212 of FIG. 12 , a message is generated by the financial institution to display valid debit accounts available to the customer.
  • the “YES” branch is followed to block 1306 .
  • the method is directed back to block 1206 of FIG. 12 .
  • the financial institution 104 generates a request for the payment switch module 102 to conduct another inquiry of the alias registry database 108 A.
  • FIG. 14 illustrates submethod or routine 1241 of method 1200 A, described above, that addresses when the customer has not entered the correct verification code after the financial institution 104 has transmitted the code to the device associated with the alias (i.e.—phone number or e-mail address).
  • Submethod 1241 is part of the verify alias API 106 A 5 described above.
  • Decision Block 1402 is the first step in sub-method 1241 which originates from a negative result or the “NO” branch following decision block 1240 of FIG. 12 in which the payment switch module 102 has determined that the wrong verification code has been entered by the customer.
  • Decision block 1402 dictates or governs the number of attempts the customer is permitted to enter in a valid verification code.
  • the number of attempts may be adjusted by the payment switch module 102 .
  • Exemplary ranges of attempts include, but are not limited to, a range between two attempts to five attempts. However, any number of attempts greater than or less than this range is within the scope of this disclosure as understood by one of ordinary skill in the art.
  • Block 1404 includes the financial institution 104 generating a message that is relayed to the portable computing device 101 of the customer to reenter the verification code.
  • decision block 1406 the financial institution 104 determines if the customer has reentered the verification code. If the inquiry to decision block 1406 is positive, then the “YES” branch is followed back to block 1410 which directs the sub method 1241 to return to block 1238 of FIG. 12 .
  • the “NO” branch is followed to block 1412 in which the financial institution 104 may set a flag or record an entry in the transaction database 108 B for its fraud team to investigate the lack of reentry of the verification code by the customer.
  • the sub method 1241 then ends.
  • the “YES” branch is followed to block 1408 in which the financial institution 104 generates a message that is relayed to the portable computing device 101 of the customer indicating that the wrong verification code has been entered and that the registration process has been terminated.
  • the message may also inform the customer to contact the helpdesk of the financial institution 104 .
  • the submethod 1241 then continues on to block 1412 as described above in which the financial institution 104 may set a flag or record an entry in the transaction database 108 B for its fraud team to investigate the lack of reentry of the verification code by the customer.
  • the submethod 1241 then ends.
  • FIG. 15A is an exemplary screen display 1500 A for a portable computing device 101 that lists person-to-person payment parameters 1502 that may be selected by a sender for a person-to-person payment.
  • the parameters may include a select recipient option 1506 and a payment speed option 1508 .
  • This screen display 1500 A generally corresponds with block 401 of FIG. 4A described above.
  • FIG. 15B is an exemplary screen display 1500 B for a portable computing device 101 that lists receivers (recipients) 1506 B that may be selected by a sender for a person-to-person payment.
  • the exemplary display 1500 B includes a listing 1506 A of instructions for how a sender may select a recipient of a P2P payment with the portable computing device 101 .
  • This screen display 1500 B generally corresponds with block 402 of FIG. 4A described above.
  • FIG. 15C is an exemplary screen display 1500 C for a portable computing device that lists velocity payment options 1508 B that may be selected by a sender in a person-to-person payment.
  • the velocity payment options may include, but are not limited to, instant payment, next day, two day, and select date.
  • the screen display 1500 C may further include a listing 1508 A of instructions on how to select the velocity payment options. This screen display 1500 C generally corresponds with block 410 of FIG. 4A described above.
  • FIG. 15D is an exemplary screen display 1500 D for a portable computing device that lists a secure party identifier 1512 that may be verified by a sender before confirming a payment to a receiver.
  • the screen display 1500 D may further comprise instructions 1510 that advise how a sender may verify the intended receiver with the secure party identifier 1512 .
  • the screen display 1500 D may further comprise a listing 1514 of the payment parameters that were selected by the sender. This screen display 1500 D generally corresponds with block 422 of FIG. 4A described above.
  • FIG. 15E is an exemplary screen display 1500 E for a portable computing device 101 that lists a message 1506 A that payment to a receiver has been confirmed.
  • the screen display 1506 B may list additional options 1506 B that may be selected by the sender to initiate another P2P payment transaction or other banking operations with the portable computing device 101 .
  • This screen display 1500 E generally corresponds with block 432 of FIG. 4A described above.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
US13/462,073 2011-05-03 2012-05-02 Method and system for facilitating person-to-person payments Abandoned US20120284175A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US13/462,073 US20120284175A1 (en) 2011-05-03 2012-05-02 Method and system for facilitating person-to-person payments
US15/977,974 US11748733B2 (en) 2011-05-03 2018-05-11 Method and system for facilitating person-to-person payments

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201161482168P 2011-05-03 2011-05-03
US13/462,073 US20120284175A1 (en) 2011-05-03 2012-05-02 Method and system for facilitating person-to-person payments

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/977,974 Continuation US11748733B2 (en) 2011-05-03 2018-05-11 Method and system for facilitating person-to-person payments

Publications (1)

Publication Number Publication Date
US20120284175A1 true US20120284175A1 (en) 2012-11-08

Family

ID=47090912

Family Applications (2)

Application Number Title Priority Date Filing Date
US13/462,073 Abandoned US20120284175A1 (en) 2011-05-03 2012-05-02 Method and system for facilitating person-to-person payments
US15/977,974 Active 2033-08-20 US11748733B2 (en) 2011-05-03 2018-05-11 Method and system for facilitating person-to-person payments

Family Applications After (1)

Application Number Title Priority Date Filing Date
US15/977,974 Active 2033-08-20 US11748733B2 (en) 2011-05-03 2018-05-11 Method and system for facilitating person-to-person payments

Country Status (4)

Country Link
US (2) US20120284175A1 (fr)
EP (1) EP2705479A4 (fr)
CA (1) CA2832204C (fr)
WO (1) WO2012151251A2 (fr)

Cited By (103)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130144784A1 (en) * 2011-12-02 2013-06-06 Microsoft Corporation Security Component for Electronic Commercial Activity
US20130262213A1 (en) * 2012-04-03 2013-10-03 Prashant Jamkhedkar Systems, Methods, And Computer Program Products Providing Payment With Non-Traditional Sources Of Value
CN103581106A (zh) * 2012-07-19 2014-02-12 深圳市财付通科技有限公司 交互式处理方法和交互式处理系统
US20140172693A1 (en) * 2012-12-19 2014-06-19 Capital One Financial Corporation Systems and methods for effecting application programming interfaces for personal payment transactions
US20140310171A1 (en) * 2013-04-12 2014-10-16 Bank Of America Corporation Certified person-to-person payment system
US20150100637A1 (en) * 2013-10-03 2015-04-09 Tata Consultancy Services Limited Identifying one or more peer devices in a peer-to-peer communication
US20150112866A1 (en) * 2012-03-07 2015-04-23 Clearxchange, Llc System and method for transferring funds
US20150134508A1 (en) * 2013-11-12 2015-05-14 Bank Of America Corporation Expedited person to person payment
US9189778B1 (en) 2014-05-28 2015-11-17 Isys US, Inc. Switch server system interoperable with mobile devices providing secure communications
US20150363778A1 (en) * 2014-06-16 2015-12-17 Bank Of America Corporation Cryptocurrency electronic payment system
US20160034906A1 (en) * 2014-07-30 2016-02-04 Richard Stopic Integrated merchant purchase inquiry and dispute resolution system
US20160071069A1 (en) * 2014-09-05 2016-03-10 Thomas Skala Payment system and method
US20160335637A1 (en) * 2015-05-11 2016-11-17 Mastercard International Incorporated Systems and Methods for Facilitating Transactions to Payment Accounts, Via SMS Messaging
US9626664B2 (en) 2012-03-07 2017-04-18 Clearxchange, Llc System and method for transferring funds
US20170124542A1 (en) * 2015-11-04 2017-05-04 Mastercard International Incorporated Methods and Systems for Dispensing Physical Currency
US20170132615A1 (en) * 2015-11-11 2017-05-11 Bank Of America Corporation Block chain alias for person-to-person payments
US20170214699A1 (en) * 2016-01-26 2017-07-27 Bank Of America Corporation System for conversion of an instrument from a non-secured instrument to a secured instrument in a process data network
CN107077665A (zh) * 2014-07-31 2017-08-18 环球有限责任公司 用于电子交易的方法和系统
US20170244757A1 (en) * 2016-02-22 2017-08-24 Bank Of America Corporation System for external validation of secure process transactions
US20170244721A1 (en) * 2016-02-22 2017-08-24 Bank Of America Corporation System for providing levels of security access to a process data network
US20170331820A1 (en) * 2014-11-14 2017-11-16 Orange Method for connecting a mobile terminal with a server of a service provider via an operator platform
US9825931B2 (en) 2016-01-26 2017-11-21 Bank Of America Corporation System for tracking and validation of an entity in a process data network
WO2018002625A1 (fr) * 2016-06-30 2018-01-04 Ipco 2012 Limited Procédé, appareil et système pour paiements électroniques
US9875468B2 (en) 2014-11-26 2018-01-23 Buy It Mobility Networks Inc. Intelligent authentication process
US10026118B2 (en) 2016-02-22 2018-07-17 Bank Of America Corporation System for allowing external validation of data in a process data network
US10049363B2 (en) * 2014-01-31 2018-08-14 Cubic Corporation Passenger behavior rating for improved risk management in transit systems
US10129238B2 (en) 2016-02-10 2018-11-13 Bank Of America Corporation System for control of secure access and communication with different process data networks with separate security features
WO2018213419A1 (fr) * 2017-05-16 2018-11-22 Apple Inc. Facilitation d'un transfert de fonds entre des comptes d'utilisateur
US10142347B2 (en) 2016-02-10 2018-11-27 Bank Of America Corporation System for centralized control of secure access to process data network
US10142312B2 (en) 2016-02-22 2018-11-27 Bank Of America Corporation System for establishing secure access for users in a process data network
US10140470B2 (en) 2016-02-22 2018-11-27 Bank Of America Corporation System for external validation of distributed resource status
US10163083B2 (en) 2015-04-13 2018-12-25 Bank Of America Corporation Account activity management system
US20190043052A1 (en) * 2015-07-01 2019-02-07 The Clearing House Payments Company, L.L.C. Real-time payment system, method, apparatus, and computer program
US20190108504A1 (en) * 2017-10-09 2019-04-11 Mastercard International Incorporated System and method for performing peer to peer transfers
US10318938B2 (en) 2016-02-22 2019-06-11 Bank Of America Corporation System for routing of process authorization and settlement to a user in process data network based on specified parameters
US20190188652A1 (en) * 2017-06-22 2019-06-20 Jpmorgan Chase Bank, N.A. System and method for implementing an interbank information network
US10387878B2 (en) 2016-02-22 2019-08-20 Bank Of America Corporation System for tracking transfer of resources in a process data network
US10395223B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc System and method for transferring funds
US10395247B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc Systems and methods for facilitating a secure transaction at a non-financial institution system
US10402796B2 (en) 2016-08-29 2019-09-03 Bank Of America Corporation Application life-cycle transition record recreation system
US10440101B2 (en) 2016-02-22 2019-10-08 Bank Of America Corporation System for external validation of private-to-public transition protocols
US10438175B2 (en) 2015-07-21 2019-10-08 Early Warning Services, Llc Secure real-time payment transactions
US10438209B2 (en) 2016-02-10 2019-10-08 Bank Of America Corporation System for secure routing of data to various networks from a process data network
US10475030B2 (en) 2016-02-22 2019-11-12 Bank Of America Corporation System for implementing a distributed ledger across multiple network nodes
US10482449B1 (en) 2014-03-10 2019-11-19 Jpmorgan Chase Bank, N.A. Person to person payment system and method
US10496989B2 (en) 2016-02-22 2019-12-03 Bank Of America Corporation System to enable contactless access to a transaction terminal using a process data network
US10515368B1 (en) 2013-10-01 2019-12-24 Wells Fargo Bank, N.A. Interbank account verification and funds transfer system and method
US10607285B2 (en) 2016-02-22 2020-03-31 Bank Of America Corporation System for managing serializability of resource transfers in a process data network
US10636033B2 (en) 2016-02-22 2020-04-28 Bank Of America Corporation System for routing of process authorizations and settlement to a user in a process data network
US10636018B2 (en) 2004-01-30 2020-04-28 The Clearing House Payments Company L.L.C. Electronic payment clearing and check image exchange systems and methods
US10679215B2 (en) 2016-02-22 2020-06-09 Bank Of America Corporation System for control of device identity and usage in a process data network
WO2020123401A1 (fr) * 2018-12-13 2020-06-18 Jpmorgan Chase Bank, N.A. Systèmes et procédés d'identification et de traitement de paiements de personne à personne
US10748127B2 (en) 2015-03-23 2020-08-18 Early Warning Services, Llc Payment real-time funds availability
US10762504B2 (en) 2016-02-22 2020-09-01 Bank Of America Corporation System for external secure access to process data network
US10769606B2 (en) 2015-03-23 2020-09-08 Early Warning Services, Llc Payment real-time funds availability
US20200322132A1 (en) * 2017-12-15 2020-10-08 nChain Holdings Limited System and method for authenticating off-chain data based on proof verification
US10832246B2 (en) 2015-03-23 2020-11-10 Early Warning Services, Llc Payment real-time funds availability
US10839359B2 (en) 2015-03-23 2020-11-17 Early Warning Services, Llc Payment real-time funds availability
US10846662B2 (en) 2015-03-23 2020-11-24 Early Warning Services, Llc Real-time determination of funds availability for checks and ACH items
US20210012329A1 (en) * 2019-07-12 2021-01-14 Raj Gandhi Privacy protected consumers identity for centralized p2p network services
US10909252B2 (en) 2019-06-11 2021-02-02 Advanced New Technologies Co., Ltd. Blockchain-based relationship binding method, apparatus, and device
US10929545B2 (en) 2018-07-31 2021-02-23 Bank Of America Corporation System for providing access to data stored in a distributed trust computing network
US10956888B2 (en) 2015-07-21 2021-03-23 Early Warning Services, Llc Secure real-time transactions
US10963856B2 (en) 2015-07-21 2021-03-30 Early Warning Services, Llc Secure real-time transactions
US10970688B2 (en) 2012-03-07 2021-04-06 Early Warning Services, Llc System and method for transferring funds
US10970695B2 (en) 2015-07-21 2021-04-06 Early Warning Services, Llc Secure real-time transactions
US20210142328A1 (en) * 2019-11-13 2021-05-13 Early Warning Services, Llc System and method for preventing fraud in real-time payment transactions
US11037121B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11037122B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11062290B2 (en) 2015-07-21 2021-07-13 Early Warning Services, Llc Secure real-time transactions
US11068866B1 (en) * 2015-02-17 2021-07-20 Wells Fargo Bank, N.A. Real-time interbank transactions systems and methods
US20210234848A1 (en) * 2018-01-11 2021-07-29 Visa International Service Association Offline authorization of interactions and controlled tasks
US11102092B2 (en) 2018-11-26 2021-08-24 Bank Of America Corporation Pattern-based examination and detection of malfeasance through dynamic graph network flow analysis
US11144928B2 (en) 2016-09-19 2021-10-12 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
US11151522B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US11151523B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US11157884B2 (en) 2015-07-21 2021-10-26 Early Warning Services, Llc Secure transactions with offline device
US20210350340A1 (en) * 2020-05-05 2021-11-11 Plaid Inc. Secure updating of allocations to user accounts
US20220012722A1 (en) * 2013-09-12 2022-01-13 Paypal, Inc. Electronic wallet fund transfer system
US20220029932A1 (en) * 2020-07-22 2022-01-27 Bank Of America Corporation Electronic system for processing technology resource identifiers and establishing dynamic context-based cross-network communications for resource transfer activities
US11276064B2 (en) 2018-11-26 2022-03-15 Bank Of America Corporation Active malfeasance examination and detection based on dynamic graph network flow analysis
US11295308B1 (en) 2014-10-29 2022-04-05 The Clearing House Payments Company, L.L.C. Secure payment processing
US20220114566A1 (en) * 2020-10-08 2022-04-14 Mastercard International Incorporated Systems and methods for use in facilitating messaging
US11327960B1 (en) 2020-10-16 2022-05-10 Plaid Inc. Systems and methods for data parsing
US11374935B2 (en) 2016-02-11 2022-06-28 Bank Of America Corporation Block chain alias person-to-person resource allocation
US11386410B2 (en) 2015-07-21 2022-07-12 Early Warning Services, Llc Secure transactions with offline device
US11430057B1 (en) 2015-12-28 2022-08-30 Plaid Inc. Parameter-based computer evaluation of user accounts based on user account data stored in one or more databases
US11436577B2 (en) 2018-05-03 2022-09-06 The Clearing House Payments Company L.L.C. Bill pay service with federated directory model support
US11468085B2 (en) 2017-07-22 2022-10-11 Plaid Inc. Browser-based aggregation
US20220343321A1 (en) * 2019-05-02 2022-10-27 Visa International Service Association Masking a primary account number between a party and a service provider
US11503010B2 (en) 2015-09-08 2022-11-15 Plaid Inc. Secure permissioning of access to user accounts, including secure deauthorization of access to user accounts
US11544714B2 (en) * 2020-05-07 2023-01-03 VocaLink Limited Apparatus, computer program and method of tracing events in a communications network
US11580544B2 (en) 2017-07-22 2023-02-14 Plaid Inc. Data verified deposits
US11593800B2 (en) 2012-03-07 2023-02-28 Early Warning Services, Llc System and method for transferring funds
US11631077B2 (en) 2017-01-17 2023-04-18 HashLynx Inc. System for facilitating secure electronic communications between entities and processing resource transfers
US11682070B2 (en) 2016-01-06 2023-06-20 Plaid Inc. Systems and methods for estimating past and prospective attribute values associated with a user account
US11694168B2 (en) 2015-07-01 2023-07-04 The Clearing House Payments Company L.L.C. Real-time payment system, method, apparatus, and computer program
US11720895B2 (en) 2019-10-11 2023-08-08 Mastercard International Incorporated Systems and methods for use in facilitating network messaging
US11770392B2 (en) 2020-01-08 2023-09-26 Bank Of America Corporation Method and system for data communication with anomaly detection
US11798072B1 (en) 2014-05-21 2023-10-24 Plaid Inc. System and method for programmatically accessing data
US11820529B2 (en) 2019-10-29 2023-11-21 Ga Telesis, Llc System and method for monitoring and certifying aircrafts and components of aircrafts
US11888976B2 (en) 2017-12-13 2024-01-30 Nchain Licensing Ag System and method for multi-party generation of blockchain-based smart contract
EP4348552A4 (fr) * 2021-05-27 2024-04-10 Visa Int Service Ass Vérification d'utilisateur à l'aide d'une étiquette numérique

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180089660A1 (en) * 2016-09-23 2018-03-29 Apple Inc. Making anonymous payments
WO2018098590A1 (fr) 2016-12-01 2018-06-07 Royal Bank Of Canada Système et procédé de vérification de destinataire de message
US11315089B2 (en) * 2018-06-01 2022-04-26 Apple Inc. User configurable direct transfer system
US11769132B1 (en) * 2019-05-22 2023-09-26 Wells Fargo Bank, N.A. P2P payments via integrated 3rd party APIs
US11379815B2 (en) 2019-10-07 2022-07-05 Bank Of America Corporation System for secure peer-to-peer interactions with event-based confirmation triggering mechanism
US11836697B1 (en) * 2020-06-30 2023-12-05 United Services Automobile Association (Usaa) Tracking and guidance system for recurring service management
US11699157B1 (en) * 2020-09-30 2023-07-11 Chime Financial, Inc. Dynamic generation of digital messages with unique links for direct-to-merchant payments
US20230069798A1 (en) * 2021-08-27 2023-03-02 Fidelity Information Services, Llc Systems and methods for executing real-time electronic transactions using graphical user interface

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7440915B1 (en) * 2007-11-16 2008-10-21 U.S. Bancorp Licensing, Inc. Method, system, and computer-readable medium for reducing payee fraud
US20080319873A1 (en) * 1999-04-30 2008-12-25 Paypal, Inc., System and method for facilitating value exchanges
US20120209762A1 (en) * 2009-02-03 2012-08-16 Patrick Metaireau Transaction processing system and method
US20130085936A1 (en) * 2010-02-26 2013-04-04 Xtreme Mobility Inc. Secure billing system and method for a mobile device

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20255A (en) 1858-05-18 Improved electric lamp
US8032457B2 (en) * 1999-08-13 2011-10-04 Vladimir Ostrovsky Method and system for transferring electronic funds
US7426492B1 (en) 1999-11-05 2008-09-16 American Express Travel Related Services Company, Inc. Systems and methods for facilitating commercial transactions between parties residing at remote locations
EP2008237A4 (fr) * 2006-03-30 2009-03-18 Obopay Inc Système mobile de paiement de personne à personne
US7848980B2 (en) * 2006-12-26 2010-12-07 Visa U.S.A. Inc. Mobile payment system and method using alias
US8249985B2 (en) * 2007-11-29 2012-08-21 Bank Of America Corporation Sub-account mechanism
US9652761B2 (en) * 2009-01-23 2017-05-16 Boku, Inc. Systems and methods to facilitate electronic payments
US20110046969A1 (en) * 2009-08-24 2011-02-24 Mark Carlson Alias hierarchy and data structure
US8639602B2 (en) * 2010-04-27 2014-01-28 Bindu Rama Rao System for agent assisted mobile funds transfer and mobile banking
US20130018787A1 (en) * 2011-07-14 2013-01-17 Bank Of America Corporation Atm provided payment process
ITRM20110391A1 (it) * 2011-07-22 2013-01-23 Marco Cavaterra Metodo e apparecchiatura per il trasferimento di una somma di denaro con l'utilizzo di un codice immagine bidimensionale
US20140089188A1 (en) * 2011-10-20 2014-03-27 Bindu Rama Rao System for funds transfer using source atm and delivering atm
US8972297B2 (en) * 2011-11-15 2015-03-03 Citibank, N.A. System and method for conducting a transaction at a financial transaction terminal using a mobile device

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080319873A1 (en) * 1999-04-30 2008-12-25 Paypal, Inc., System and method for facilitating value exchanges
US7440915B1 (en) * 2007-11-16 2008-10-21 U.S. Bancorp Licensing, Inc. Method, system, and computer-readable medium for reducing payee fraud
US20120209762A1 (en) * 2009-02-03 2012-08-16 Patrick Metaireau Transaction processing system and method
US20130085936A1 (en) * 2010-02-26 2013-04-04 Xtreme Mobility Inc. Secure billing system and method for a mobile device

Cited By (159)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10643190B2 (en) 2004-01-30 2020-05-05 The Clearing House Payments Company L.L.C. Electronic payment clearing and check image exchange systems and methods
US11301824B2 (en) 2004-01-30 2022-04-12 The Clearing House Payments Company LLC Electronic payment clearing and check image exchange systems and methods
US10685337B2 (en) 2004-01-30 2020-06-16 The Clearing House Payments Company L.L.C. Electronic payment clearing and check image exchange systems and methods
US10636018B2 (en) 2004-01-30 2020-04-28 The Clearing House Payments Company L.L.C. Electronic payment clearing and check image exchange systems and methods
US20130144784A1 (en) * 2011-12-02 2013-06-06 Microsoft Corporation Security Component for Electronic Commercial Activity
US11361290B2 (en) 2012-03-07 2022-06-14 Early Warning Services, Llc System and method for securely registering a recipient to a computer-implemented funds transfer payment network
US10395247B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc Systems and methods for facilitating a secure transaction at a non-financial institution system
US20150112866A1 (en) * 2012-03-07 2015-04-23 Clearxchange, Llc System and method for transferring funds
US11715075B2 (en) 2012-03-07 2023-08-01 Early Warning Services, Llc System and method for transferring funds
US10395223B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc System and method for transferring funds
US11593800B2 (en) 2012-03-07 2023-02-28 Early Warning Services, Llc System and method for transferring funds
US10318936B2 (en) * 2012-03-07 2019-06-11 Early Warning Services, Llc System and method for transferring funds
US11605077B2 (en) 2012-03-07 2023-03-14 Early Warning Services, Llc System and method for transferring funds
US10078821B2 (en) 2012-03-07 2018-09-18 Early Warning Services, Llc System and method for securely registering a recipient to a computer-implemented funds transfer payment network
US11373182B2 (en) 2012-03-07 2022-06-28 Early Warning Services, Llc System and method for transferring funds
US9626664B2 (en) 2012-03-07 2017-04-18 Clearxchange, Llc System and method for transferring funds
US11948148B2 (en) 2012-03-07 2024-04-02 Early Warning Services, Llc System and method for facilitating transferring funds
US11321682B2 (en) 2012-03-07 2022-05-03 Early Warning Services, Llc System and method for transferring funds
US9691056B2 (en) 2012-03-07 2017-06-27 Clearxchange, Llc System and method for transferring funds
US10970688B2 (en) 2012-03-07 2021-04-06 Early Warning Services, Llc System and method for transferring funds
US20130262213A1 (en) * 2012-04-03 2013-10-03 Prashant Jamkhedkar Systems, Methods, And Computer Program Products Providing Payment With Non-Traditional Sources Of Value
CN103581106A (zh) * 2012-07-19 2014-02-12 深圳市财付通科技有限公司 交互式处理方法和交互式处理系统
US20140081873A1 (en) * 2012-07-19 2014-03-20 Tencent Technology (Shenzhen) Company Limited Online payment interactive processing method and online payment interactive processing system
US10565571B2 (en) * 2012-12-19 2020-02-18 Capital One Services, Llc Systems and methods for effecting application programming interfaces for personal payment transactions
US20140172693A1 (en) * 2012-12-19 2014-06-19 Capital One Financial Corporation Systems and methods for effecting application programming interfaces for personal payment transactions
US20140310171A1 (en) * 2013-04-12 2014-10-16 Bank Of America Corporation Certified person-to-person payment system
US20220012722A1 (en) * 2013-09-12 2022-01-13 Paypal, Inc. Electronic wallet fund transfer system
US11568417B1 (en) 2013-10-01 2023-01-31 Wells Fargo Bank, N.A. Interbank account verification and funds transfer system and method
US10949816B1 (en) 2013-10-01 2021-03-16 Wells Fargo Bank, N.A. Interbank account verification and funds transfer system and method
US11151570B1 (en) 2013-10-01 2021-10-19 Wells Fargo Bank, N.A. Interbank account verification and funds transfer system and method
US11854015B1 (en) 2013-10-01 2023-12-26 Wells Fargo Bank, N.A. Interbank account verification and funds transfer system and method
US10515368B1 (en) 2013-10-01 2019-12-24 Wells Fargo Bank, N.A. Interbank account verification and funds transfer system and method
US9635106B2 (en) * 2013-10-03 2017-04-25 Tata Consultancy Services Limited Identifying one or more peer devices in a peer-to-peer communication
US20150100637A1 (en) * 2013-10-03 2015-04-09 Tata Consultancy Services Limited Identifying one or more peer devices in a peer-to-peer communication
US20150134508A1 (en) * 2013-11-12 2015-05-14 Bank Of America Corporation Expedited person to person payment
US10049363B2 (en) * 2014-01-31 2018-08-14 Cubic Corporation Passenger behavior rating for improved risk management in transit systems
US10482449B1 (en) 2014-03-10 2019-11-19 Jpmorgan Chase Bank, N.A. Person to person payment system and method
US11798072B1 (en) 2014-05-21 2023-10-24 Plaid Inc. System and method for programmatically accessing data
US11922492B2 (en) 2014-05-21 2024-03-05 Plaid Inc. System and method for programmatically accessing financial data
US10810573B2 (en) 2014-05-28 2020-10-20 One Global Service For General Trading Llc Switch server system interoperable with mobile devices providing secure communications
WO2015183999A1 (fr) * 2014-05-28 2015-12-03 Isys US, Inc. Système de serveur de commutateur inter-exploitable avec des dispositifs mobiles fournissant des communications sécurisées
US9189778B1 (en) 2014-05-28 2015-11-17 Isys US, Inc. Switch server system interoperable with mobile devices providing secure communications
US20150363778A1 (en) * 2014-06-16 2015-12-17 Bank Of America Corporation Cryptocurrency electronic payment system
US10572880B2 (en) * 2014-07-30 2020-02-25 Visa International Service Association Integrated merchant purchase inquiry and dispute resolution system
US20160034906A1 (en) * 2014-07-30 2016-02-04 Richard Stopic Integrated merchant purchase inquiry and dispute resolution system
CN107077665A (zh) * 2014-07-31 2017-08-18 环球有限责任公司 用于电子交易的方法和系统
US20230046596A1 (en) * 2014-07-31 2023-02-16 Globeone Llc Methods and systems for electronic transactions
US20160071069A1 (en) * 2014-09-05 2016-03-10 Thomas Skala Payment system and method
US10692156B2 (en) * 2014-09-05 2020-06-23 Thomas Skala Payment system and method
US11816666B2 (en) 2014-10-29 2023-11-14 The Clearing House Payments Company L.L.C. Secure payment processing
US11295308B1 (en) 2014-10-29 2022-04-05 The Clearing House Payments Company, L.L.C. Secure payment processing
US20170331820A1 (en) * 2014-11-14 2017-11-16 Orange Method for connecting a mobile terminal with a server of a service provider via an operator platform
US10992661B2 (en) * 2014-11-14 2021-04-27 Orange Method for connecting a mobile terminal with a server of a service provider via an operator platform
US9875468B2 (en) 2014-11-26 2018-01-23 Buy It Mobility Networks Inc. Intelligent authentication process
US11068862B2 (en) 2014-11-26 2021-07-20 Buy It Mobility Networks Inc. Intelligent authentication process
US11972402B1 (en) 2015-02-17 2024-04-30 Wells Fargo Bank, N.A. Real-time interbank transactions systems and methods
US11669813B1 (en) 2015-02-17 2023-06-06 Wells Fargo Bank, N.A. Real-time interbank transactions systems and methods
US11068866B1 (en) * 2015-02-17 2021-07-20 Wells Fargo Bank, N.A. Real-time interbank transactions systems and methods
US11295283B1 (en) * 2015-02-17 2022-04-05 Wells Fargo Bank, N.A. Real-time interbank transactions systems and methods
US10878387B2 (en) 2015-03-23 2020-12-29 Early Warning Services, Llc Real-time determination of funds availability for checks and ACH items
US10846662B2 (en) 2015-03-23 2020-11-24 Early Warning Services, Llc Real-time determination of funds availability for checks and ACH items
US10769606B2 (en) 2015-03-23 2020-09-08 Early Warning Services, Llc Payment real-time funds availability
US10839359B2 (en) 2015-03-23 2020-11-17 Early Warning Services, Llc Payment real-time funds availability
US10832246B2 (en) 2015-03-23 2020-11-10 Early Warning Services, Llc Payment real-time funds availability
US10748127B2 (en) 2015-03-23 2020-08-18 Early Warning Services, Llc Payment real-time funds availability
US10163083B2 (en) 2015-04-13 2018-12-25 Bank Of America Corporation Account activity management system
US20160335637A1 (en) * 2015-05-11 2016-11-17 Mastercard International Incorporated Systems and Methods for Facilitating Transactions to Payment Accounts, Via SMS Messaging
US20190043052A1 (en) * 2015-07-01 2019-02-07 The Clearing House Payments Company, L.L.C. Real-time payment system, method, apparatus, and computer program
US11694168B2 (en) 2015-07-01 2023-07-04 The Clearing House Payments Company L.L.C. Real-time payment system, method, apparatus, and computer program
US11042882B2 (en) 2015-07-01 2021-06-22 The Clearing House Payments Company, L.L.C. Real-time payment system, method, apparatus, and computer program
US10956888B2 (en) 2015-07-21 2021-03-23 Early Warning Services, Llc Secure real-time transactions
US10970695B2 (en) 2015-07-21 2021-04-06 Early Warning Services, Llc Secure real-time transactions
US10762477B2 (en) 2015-07-21 2020-09-01 Early Warning Services, Llc Secure real-time processing of payment transactions
US11922387B2 (en) 2015-07-21 2024-03-05 Early Warning Services, Llc Secure real-time transactions
US11062290B2 (en) 2015-07-21 2021-07-13 Early Warning Services, Llc Secure real-time transactions
US11037122B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11037121B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US10438175B2 (en) 2015-07-21 2019-10-08 Early Warning Services, Llc Secure real-time payment transactions
US10963856B2 (en) 2015-07-21 2021-03-30 Early Warning Services, Llc Secure real-time transactions
US11157884B2 (en) 2015-07-21 2021-10-26 Early Warning Services, Llc Secure transactions with offline device
US11151523B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US11151522B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US11386410B2 (en) 2015-07-21 2022-07-12 Early Warning Services, Llc Secure transactions with offline device
US11503010B2 (en) 2015-09-08 2022-11-15 Plaid Inc. Secure permissioning of access to user accounts, including secure deauthorization of access to user accounts
US11595374B2 (en) 2015-09-08 2023-02-28 Plaid Inc. Secure permissioning of access to user accounts, including secure deauthorization of access to user accounts
US20170124542A1 (en) * 2015-11-04 2017-05-04 Mastercard International Incorporated Methods and Systems for Dispensing Physical Currency
WO2017083565A1 (fr) * 2015-11-11 2017-05-18 Bank Of America Corporation Paiements de personne à personne reposant sur un pseudonyme de chaîne de blocs
US20170132630A1 (en) * 2015-11-11 2017-05-11 Bank Of America Corporation Block chain alias for person-to-person payments
US20170132615A1 (en) * 2015-11-11 2017-05-11 Bank Of America Corporation Block chain alias for person-to-person payments
US11430057B1 (en) 2015-12-28 2022-08-30 Plaid Inc. Parameter-based computer evaluation of user accounts based on user account data stored in one or more databases
US11682070B2 (en) 2016-01-06 2023-06-20 Plaid Inc. Systems and methods for estimating past and prospective attribute values associated with a user account
US9825931B2 (en) 2016-01-26 2017-11-21 Bank Of America Corporation System for tracking and validation of an entity in a process data network
US10116667B2 (en) * 2016-01-26 2018-10-30 Bank Of America Corporation System for conversion of an instrument from a non-secured instrument to a secured instrument in a process data network
US20170214699A1 (en) * 2016-01-26 2017-07-27 Bank Of America Corporation System for conversion of an instrument from a non-secured instrument to a secured instrument in a process data network
US11354672B2 (en) 2016-02-10 2022-06-07 Bank Of America Corporation System for secure routing of data to various networks from a process data network
US10129238B2 (en) 2016-02-10 2018-11-13 Bank Of America Corporation System for control of secure access and communication with different process data networks with separate security features
US10438209B2 (en) 2016-02-10 2019-10-08 Bank Of America Corporation System for secure routing of data to various networks from a process data network
US10142347B2 (en) 2016-02-10 2018-11-27 Bank Of America Corporation System for centralized control of secure access to process data network
US11374935B2 (en) 2016-02-11 2022-06-28 Bank Of America Corporation Block chain alias person-to-person resource allocation
US10614461B2 (en) 2016-02-22 2020-04-07 Bank Of America Corporation System for implementing a distributed ledger across multiple network nodes
US20170244721A1 (en) * 2016-02-22 2017-08-24 Bank Of America Corporation System for providing levels of security access to a process data network
US10142312B2 (en) 2016-02-22 2018-11-27 Bank Of America Corporation System for establishing secure access for users in a process data network
US10496989B2 (en) 2016-02-22 2019-12-03 Bank Of America Corporation System to enable contactless access to a transaction terminal using a process data network
US20170244757A1 (en) * 2016-02-22 2017-08-24 Bank Of America Corporation System for external validation of secure process transactions
US10475030B2 (en) 2016-02-22 2019-11-12 Bank Of America Corporation System for implementing a distributed ledger across multiple network nodes
US10140470B2 (en) 2016-02-22 2018-11-27 Bank Of America Corporation System for external validation of distributed resource status
US10178105B2 (en) * 2016-02-22 2019-01-08 Bank Of America Corporation System for providing levels of security access to a process data network
US10318938B2 (en) 2016-02-22 2019-06-11 Bank Of America Corporation System for routing of process authorization and settlement to a user in process data network based on specified parameters
US10387878B2 (en) 2016-02-22 2019-08-20 Bank Of America Corporation System for tracking transfer of resources in a process data network
US10026118B2 (en) 2016-02-22 2018-07-17 Bank Of America Corporation System for allowing external validation of data in a process data network
US11030621B2 (en) 2016-02-22 2021-06-08 Bank Of America Corporation System to enable contactless access to a transaction terminal using a process data network
US10762504B2 (en) 2016-02-22 2020-09-01 Bank Of America Corporation System for external secure access to process data network
US10135870B2 (en) * 2016-02-22 2018-11-20 Bank Of America Corporation System for external validation of secure process transactions
US10679215B2 (en) 2016-02-22 2020-06-09 Bank Of America Corporation System for control of device identity and usage in a process data network
US10440101B2 (en) 2016-02-22 2019-10-08 Bank Of America Corporation System for external validation of private-to-public transition protocols
US10636033B2 (en) 2016-02-22 2020-04-28 Bank Of America Corporation System for routing of process authorizations and settlement to a user in a process data network
US10607285B2 (en) 2016-02-22 2020-03-31 Bank Of America Corporation System for managing serializability of resource transfers in a process data network
US11102279B2 (en) 2016-02-22 2021-08-24 Bank Of America Corporation System for external validation of private-to-public transition protocols
WO2018002625A1 (fr) * 2016-06-30 2018-01-04 Ipco 2012 Limited Procédé, appareil et système pour paiements électroniques
US11107074B2 (en) * 2016-06-30 2021-08-31 Ipco 2012 Limited Method, apparatus and system for electronic payments
US10402796B2 (en) 2016-08-29 2019-09-03 Bank Of America Corporation Application life-cycle transition record recreation system
US11144928B2 (en) 2016-09-19 2021-10-12 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
US11151566B2 (en) 2016-09-19 2021-10-19 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
US11151567B2 (en) 2016-09-19 2021-10-19 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
US11631077B2 (en) 2017-01-17 2023-04-18 HashLynx Inc. System for facilitating secure electronic communications between entities and processing resource transfers
WO2018213419A1 (fr) * 2017-05-16 2018-11-22 Apple Inc. Facilitation d'un transfert de fonds entre des comptes d'utilisateur
US11687920B2 (en) 2017-05-16 2023-06-27 Apple Inc. Facilitating a fund transfer between user accounts
US11972399B2 (en) * 2017-06-22 2024-04-30 Jpmorgan Chase Bank, N.A. System and method for implementing an interbank information network
US20190188652A1 (en) * 2017-06-22 2019-06-20 Jpmorgan Chase Bank, N.A. System and method for implementing an interbank information network
US11580544B2 (en) 2017-07-22 2023-02-14 Plaid Inc. Data verified deposits
US11468085B2 (en) 2017-07-22 2022-10-11 Plaid Inc. Browser-based aggregation
US20190108504A1 (en) * 2017-10-09 2019-04-11 Mastercard International Incorporated System and method for performing peer to peer transfers
US11978032B2 (en) * 2017-10-09 2024-05-07 Mastercard International Incorporated System and method for performing peer to peer transfers
US11888976B2 (en) 2017-12-13 2024-01-30 Nchain Licensing Ag System and method for multi-party generation of blockchain-based smart contract
US20200322132A1 (en) * 2017-12-15 2020-10-08 nChain Holdings Limited System and method for authenticating off-chain data based on proof verification
US11855971B2 (en) * 2018-01-11 2023-12-26 Visa International Service Association Offline authorization of interactions and controlled tasks
US20210234848A1 (en) * 2018-01-11 2021-07-29 Visa International Service Association Offline authorization of interactions and controlled tasks
US11829967B2 (en) 2018-05-03 2023-11-28 The Clearing House Payments Company L.L.C. Bill pay service with federated directory model support
US11436577B2 (en) 2018-05-03 2022-09-06 The Clearing House Payments Company L.L.C. Bill pay service with federated directory model support
US10929545B2 (en) 2018-07-31 2021-02-23 Bank Of America Corporation System for providing access to data stored in a distributed trust computing network
US11276064B2 (en) 2018-11-26 2022-03-15 Bank Of America Corporation Active malfeasance examination and detection based on dynamic graph network flow analysis
US11102092B2 (en) 2018-11-26 2021-08-24 Bank Of America Corporation Pattern-based examination and detection of malfeasance through dynamic graph network flow analysis
WO2020123401A1 (fr) * 2018-12-13 2020-06-18 Jpmorgan Chase Bank, N.A. Systèmes et procédés d'identification et de traitement de paiements de personne à personne
US20220343321A1 (en) * 2019-05-02 2022-10-27 Visa International Service Association Masking a primary account number between a party and a service provider
US10909252B2 (en) 2019-06-11 2021-02-02 Advanced New Technologies Co., Ltd. Blockchain-based relationship binding method, apparatus, and device
US11687926B2 (en) * 2019-07-12 2023-06-27 Visa International Service Association Privacy protected consumers identity for centralized P2P network services
US20210012329A1 (en) * 2019-07-12 2021-01-14 Raj Gandhi Privacy protected consumers identity for centralized p2p network services
US20230289789A1 (en) * 2019-07-12 2023-09-14 Visa International Service Association Privacy protected consumers identity for centralized p2p network services
US11720895B2 (en) 2019-10-11 2023-08-08 Mastercard International Incorporated Systems and methods for use in facilitating network messaging
US11820529B2 (en) 2019-10-29 2023-11-21 Ga Telesis, Llc System and method for monitoring and certifying aircrafts and components of aircrafts
US20210142328A1 (en) * 2019-11-13 2021-05-13 Early Warning Services, Llc System and method for preventing fraud in real-time payment transactions
US11770392B2 (en) 2020-01-08 2023-09-26 Bank Of America Corporation Method and system for data communication with anomaly detection
US11887069B2 (en) * 2020-05-05 2024-01-30 Plaid Inc. Secure updating of allocations to user accounts
US20210350340A1 (en) * 2020-05-05 2021-11-11 Plaid Inc. Secure updating of allocations to user accounts
US11544714B2 (en) * 2020-05-07 2023-01-03 VocaLink Limited Apparatus, computer program and method of tracing events in a communications network
US20220029932A1 (en) * 2020-07-22 2022-01-27 Bank Of America Corporation Electronic system for processing technology resource identifiers and establishing dynamic context-based cross-network communications for resource transfer activities
US20220114566A1 (en) * 2020-10-08 2022-04-14 Mastercard International Incorporated Systems and methods for use in facilitating messaging
US11327960B1 (en) 2020-10-16 2022-05-10 Plaid Inc. Systems and methods for data parsing
EP4348552A4 (fr) * 2021-05-27 2024-04-10 Visa Int Service Ass Vérification d'utilisateur à l'aide d'une étiquette numérique

Also Published As

Publication number Publication date
US20180336542A1 (en) 2018-11-22
EP2705479A4 (fr) 2014-12-24
CA2832204C (fr) 2019-10-01
WO2012151251A3 (fr) 2013-03-28
WO2012151251A2 (fr) 2012-11-08
US20210049577A9 (en) 2021-02-18
CA2832204A1 (fr) 2012-11-08
EP2705479A2 (fr) 2014-03-12
US11748733B2 (en) 2023-09-05

Similar Documents

Publication Publication Date Title
US11748733B2 (en) Method and system for facilitating person-to-person payments
US10510064B2 (en) Wireless payment method and systems
US10304127B2 (en) Communication device including multi-part alias identifier
KR102634772B1 (ko) 비-금융 기관 시스템에서 안전 거래를 돕기 위한 시스템 및 방법
US10453056B2 (en) Secure account creation
US20070208816A1 (en) System and method for electronically facilitating, recording, and tracking transactions
US20090119209A1 (en) Mobile transaction network
WO2009114876A2 (fr) Système de paiement viral basé sur un réseau
EP2008237A1 (fr) Système mobile de paiement de personne à personne
US20150134509A1 (en) Identification of direct deposit participants
US20230351344A1 (en) Systems and methods for establishing a pull payment relationship
US20200327543A1 (en) Facilitation of real-time payment network transactions
US20230196314A1 (en) Funds transfer service methods and systems for facilitating funds transfers
US20150134520A1 (en) Third party processing of direct deposit enrollment

Legal Events

Date Code Title Description
AS Assignment

Owner name: PANTHER PAYMENTS, LLC, NEW YORK

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SCOTT, DIANE;SPRINGHETTI, ROD;WILSON, MARK;REEL/FRAME:029039/0859

Effective date: 20120625

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION