US20110258111A1

US20110258111A1 - Alias management and off-us dda processing

Info

Publication number: US20110258111A1
Application number: US13/089,134
Authority: US
Inventors: Thanigaivel Ashwin Raj; Jacob Saul Fuentes; John Tullis; Vishwanath Shastry
Original assignee: Visa International Service Association
Current assignee: Visa International Service Association
Priority date: 2010-04-19
Filing date: 2011-04-18
Publication date: 2011-10-20
Also published as: US8336088B2; US20130179335A1; US10417619B2; US20110258686A1; US20190370764A1; WO2011133594A3; WO2011133594A2; US11126979B2

Abstract

An alias management and off-us demand deposit account processing system is disclosed. A sending entity initiates a value transfer with a payment processing network indicating a value transfer providing issuer which will conduct the value transfer and a demand deposit account issuer which hosts the demand deposit account that funds the value transfer. The sending entity is able to conduct a value transfer via a value transfer providing issuer using funds from an account with another issuer.

Description

CROSS-REFERENCES TO RELATED APPLICATIONS

The present non-provisional application claims the benefit under 35 U.S.C. §119(e) of U.S. Provisional Patent Application No. 61/325,809, entitled “ALIAS MANAGEMENT FOR VALUE TRANSFER,” filed Apr. 19, 2010, of U.S. Provisional Patent Application No. 61/349,473, entitled “VALUE TRANSFER DEVELOPMENT KIT,” filed May 28, 2010, and of U.S. Provisional Patent Application No. 61/348,524, entitled “VALUE TRANSFER CLAIM SYSTEM AND METHOD,” filed May 26, 2010, the entire disclosure of each of the referenced applications is incorporated herein by reference in their entirety for all purposes.

BACKGROUND

Value transfers enable a sending entity to transfer value to a recipient entity. Traditionally, such value transfers originate from financial institutions, e.g., issuers, which both support value transfer functionality and are associated with the account that funds the value transfer. However, sending entities, such as consumers, often have accounts with more than one issuer, and not all such issuers may have adopted value transfer capability. Thus, sending entities may not have the ability to send value transfers using funds from any of their accounts.
Issuers adopting value transfer functionality also monetize only value transfers from accounts they host, and cannot earn money for providing value transfer functionality to other issuers or entities. Without a method to share money transfer functionality, the large scale adoption of value transfer may be limited.
Thus, there is a need in the art for an alias management and off-us DDA (“demand deposit account”) processing system that addresses the above concerns. Embodiments of the invention address these and other problems, individually and collectively.

BRIEF SUMMARY

Embodiments of the invention disclosed herein include systems, technical architecture of the systems, and methods for an alias management and off-us DDA processing system. An alias management and off-us DDA processing system can be implemented using one or more computer apparatuses and databases.
One embodiment of the invention is directed to a method for sending a debit instruction message to a first financial institution to withdrawal at least a transfer amount from a second financial institution, wherein the withdrawal request message comprises a demand deposit account identifier associated with the second financial institution, receiving a withdrawal response message from the first financial institution confirming the withdrawal of at least the transfer amount from the second financial institution, and initiating the sending of the transfer amount to a recipient entity account associated with the third financial institution.
In a further embodiment the invention is directed to a method for sending an authorization request message to a third party authenticator, querying if at least the transfer amount is available from a demand deposit account, and receiving an authorization response message from the third party authenticator indicating that at least the transfer amount is available from the demand deposit account.
In a further embodiment the invention is directed to a method wherein the debit instruction message further comprises an authorization response indicator indicating that at least the transfer amount exists in the demand deposit account.
In a further embodiment the invention is directed to a method wherein initiating the sending of the transfer amount to the third financial institution comprises sending a credit message to the third financial institution wherein the credit message comprises a bank identification number (BIN) of the acquiring first financial institution and the personal account number (PAN) of a recipient entity having an account at the third financial institution.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an alias management and off-us DDA processing system, according to an example embodiment.

FIG. 2 is a process flow of an off-us DDA value transfer, according to an example embodiment.

FIG. 3 is an alternative process flow of an off-us DDA value transfer, according to an example embodiment.

FIG. 4 is a diagram of a computer apparatus, according to an example embodiment.

DETAILED DESCRIPTION

Embodiments of the invention are directed to systems, architectures of the systems, and methods for conducting alias management and off-us DDA processing.
In certain embodiments, an alias management and off-us DDA processing system enables a sending entity to send a value transfer to a recipient entity using the value transfer system of a value transfer providing issuer, where the value transfer is funded by a demand deposit account (“DDA”) of the sending entity associated with a demand deposit issuer that is not the value transfer providing issuer. The value may be sent to a recipient entity associated with a recipient entity issuer.
In other embodiments, the alias management and off-us DDA processing system enables the sending entity to send a debit instruction message to a first financial institution, instructing the first financial institution to withdraw a transfer amount from a second financial institution, for a subsequent transfer of funds in the transfer amount to a third financial institution, wherein the debit instruction message comprises a demand deposit account identifier associated with the second financial institution and may further comprise a recipient entity account identifier associated with the third financial institution. In a further embodiment, the first financial institution may be a value transfer providing issuer, the second financial institution may be a demand deposit account issuer, and the third financial institution may be the recipient entity issuer. In an example embodiment, the demand deposit account identifier is associated with a demand deposit account issuer and a demand deposit account. In a further embodiment, the recipient entity account identifier is associated with a recipient entity issuer and a recipient entity account.
The transactions processed by the alias management and off-us DDA processing system may transfer various types of value. Value may comprise of types such as traditional currencies, e.g., US Dollar (USD), Renminbi (RMB), but may also include other units of value, such as cell phone minutes, online currencies, digital points, and other digital micro-credits. For example, the system may process value in the form of Facebook™ Coins or Zynga™ Cash or Coins.
As used herein, a “demand deposit account” may be a bank account, demand deposit account as commonly known in the art, mobile phone account, credit or debit card account, pre-paid account, online value storage account, an account associated with a portable consumer device, or other account from which money or units of value may be transferred to and be withdrawn from. The same type of accounts that could comprise of a demand deposit account may also be a “recipient entity account.” A recipient entity account may be the account associated with the third financial institution, such as a recipient entity issuer. The demand deposit account may be associated with a financial institution such as an issuer, that does not provide the value transfer functionality for the value transfer.
As used herein, a “portable consumer device” may be a credit card, a debit card, a mobile phone, a pre-paid card, a mobile application, a payment instrument, a specialized application, or any portable device or software application capable of transferring funds. Such devices may include contact or contactless smart cards, ordinary credit or debit cards (with a magnetic strip and without an embedded microprocessor), keychain devices (such as the Speedpass™ commercially available from Exxon-Mobil Corp.), etc. Other examples of portable consumer devices include cellular phones, personal digital assistants (PDAs), pagers, payment cards, security cards, access cards, smart media, transponders, and the like, where such devices may include an embedded or incorporated contactless chip or similar element. In an example embodiment, a value transfer transfers funds from one account associated with a portable consumer device to another account associated with another portable consumer device. For example, a value transfer may transfer funds from one credit card account to another credit card account.
The alias management and off-us DDA processing system may facilitate value transfers without exposing sensitive information by using an alias, also referred to as a customer identity alias. As used herein, an “alias” may be an alpha-numeric value, such as a username, and may be static or dynamic. An alias may also comprise of Unicode characters or other CJK (Chinese, Japanese, Korean) characters. An alias may be used to identify a sending entity instead of sharing sensitive information, to preserve privacy and reduce the likelihood of fraud. An alias may be associated with one or more portable consumer devices or value accounts.
In a further embodiment, an alias may be a verifiable value, such as a phone number or an email address. The alias is verifiable if the alias value may be used to contact a user the alias represents. The user may be contacted for verification purposes. For example, a phone number and an email are verifiable aliases because the alias value indicates a method to contact a user, such as by SMS or email. For example, in a value transfer transaction, the sending entity may send money from the alias “ted@ted.com” rather than by presenting a credit card number.
The alias management and off-us DDA processing system may operatively communicate with various issuers to effectuate a value transfer between accounts hosted by the various issuers. For example, the alias management and off-us DDA processing system may communicate with a first issuer to withdraw funds from a second issuer, and to later deposit those funds into a recipient entity account associated with a third issuer.
The alias management and off-us DDA processing system may support value transfer functions through web exposed value transfer application programming interfaces (“APIs”) and other network interfaces such as a payment processing network. The various value transfer supporting functions may be called by an issuer, an originating institution, or other entity via the APIs. In an example embodiment, a sending entity may visit the website of an originating institution, such as a merchant website, and may initiate a value transfer from that website. The originating institution website may have embedded commands to call the alias management and off-us DDA processing system APIs to conduct the value transfer. In an example embodiment, the value transfer APIs may be called from any platform or device with Internet access.
The alias management and off-us DDA processing system may also provide various value transfer supporting functionality, such as anti-money laundering, account management, foreign exchange calculation, and fee calculation services, among others. In an example embodiment, the alias management and off-us DDA processing system may also calculate fees and surcharges levied by the payment processing network and the value transfer providing issuer, which may be added to the transfer amount and debited from the demand deposit account.
The sending entity may initiate a value transfer by sending a value transfer initiation message to a payment processing network. The value transfer initiation message may comprise of a primary account number (“PAN”) or a recipient entity alias to identify the recipient entity. The sending entity may identify himself or herself by providing a PAN, an alias, an identifier, or otherwise authenticating with the payment processing network. The sending entity may also identify a demand deposit account, through a demand deposit account identifier, from which funds will be debited to fund the value transfer and a transfer amount. The demand deposit account identifier may also identify the demand deposit account issuer. The sending entity many also identify the value transfer providing entity. In an example embodiment, the sending entity may have defined a default value transfer providing issuer with the payment processing network. The sending entity may provide the value transfer initiation message directly to a payment processing network or indirectly to the payment processing network through an originating institution, such as a bank, a merchant, etc.
In an example embodiment, the payment processing network, after receiving the value transfer initiation message, may ensure that the demand deposit account has sufficient funds for the value transfer by communicating with a third party authorizer. The third party authorizer may be instructed to communicate with the demand deposit account issuer to query whether sufficient funds exist. The demand deposit account issuer may reply to the third party authorizer, which in turn may communicate the reply to the payment processing network. The third party authorizer may be an electronic clearing house.
The payment processing network may instruct the value transfer providing issuer to withdraw at least the transfer amount from the demand deposit account. The payment processing network may include the demand deposit account issuer reply/authorization message to the third party authorizer in the communications with the value transfer providing issuer. The exact process and protocol used to transfer the funds from the demand deposit account issuer to the value transfer providing issuer may be varied, and may not be known by the payment processing network. The alias management and off-us DDA processing system may operate regardless of which process is used to transfer funds between the demand deposit account issuer and the value transfer providing issuer. The transfer between the demand deposit account issuer and the value transfer providing issuer may be conducted by an automated clearinghouse network, via a direct transfer, via a value transfer, via an account funding transaction, or other methods for transferring value.
After the value transfer providing issuer has successfully withdrawn at least the transfer amount from the demand deposit account issuer, the value transfer providing issuer sends a withdrawal confirmation message to the payment processing network. The payment processing network then sends a credit message to the recipient entity issuer to credit at least the transfer amount to the recipient entity account. After the credit message is confirmed, a confirmation message is sent to both the payment processing network and the sending entity.

I. Systems

FIG. 1 is an alias management and off-us DDA processing system 100, according to an example embodiment. The alias management and off-us DDA processing system 100 comprises a sending entity 102, a payment processing network 104, a value transfer providing issuer 106, third party authorizer 107, a demand deposit account issuer 108, and a recipient entity issuer 110. Although only one sending entity 102, one payment processing network 104, one value transfer providing issuer 106, one third party authorizer 107, one demand deposit account issuer 108, and one recipient entity issuer 110 are shown, there may be any suitable number of any of these entities in the alias management and off-us DDA processing system 100. Each of the entities shown in FIG. 1 may operate on or more computer apparatuses to accomplish the functions described herein.
The “sending entity” 102 may be a consumer that initiates a value transfer. The sending entity 102 may be an individual, an agent, or an organization, such as a business, that is capable of initiating a value transfer. The sending entity 102 may identify a demand deposit account as the funding source of the value transfer. The sending entity 102 may also identify the recipient entity as the recipient of the value transfer. The sending entity 102 may also identify the value transfer providing issuer 106 and the transfer amount, along with other data, such as the confirmation of terms and conditions.
The payment processing network 104 can refer to a network of suitable entities that have information related to an account associated with the portable consumer device. This information includes data associated with the account on the portable consumer device such as profile information, data, aliases, value transfer history, metadata, and other suitable information.
The payment processing network 104 may have or operate a server computer and may include a database. The database may include any hardware, software, firmware, or combination of the preceding for storing and facilitating retrieval of information. Also, the database may use any of a variety of data structures, arrangements, and compilations to store and facilitate retrieval of information. The database may store information such a user profile, transfer history, and other value transfer related data. The server computer may be coupled to the database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. The server computer may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers. The payment processing network 104 may also provide risk management and anti-money laundering services.
The payment processing network 104 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network 104 may include VisaNet™. Networks that include VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, includes a VIP system (Visa Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services. The payment processing network 104 may use any suitable wired or wireless network, including the Internet.
The “value transfer providing issuer” 106 may be any suitable entity that may provide value transfer functionality to the sending entity 102. The value transfer providing issuer 106 may have issued, may host, or may manage a portable consumer device of the sending entity 102. The value transfer providing issuer 106 may be a bank, a business entity such as a retail store, or a governmental entity. The value transfer providing issuer 106 may communicate with a third party authorizer 107 to authorize a value transfer with a demand deposit account issuer 108. The value transfer providing issuer 106 may also communicate with the demand deposit account issuer 108 to withdraw funds for a value transfer.
The “third party authorizer” 107 may be an entity that may authorize a value transfer with an issuer. For example, a third party authorizer 107 may query a demand deposit account issuer 108 to see if an identified demand deposit account has enough funds or can support a proposed value transfer. The third party authorizer 107 may receive the demand deposit account issuer's response. The response may then be sent to a payment processing network 104 in order to authenticate the value transfer. In addition, the response may also be sent to the value transfer providing issuer 106. In an example embodiment, the third party authorizer 107 may be an electronic clearinghouse such as a tier 1 multi-platform payment processing service such as offered by ECHO, Inc.
The “demand deposit account issuer” 108 may be any suitable entity that may maintain or manage the funds of the sending entity 102. The demand deposit account issuer 108 may have issued, may host, or may manage the portable consumer device or the demand deposit account of the sending entity 102 used in the value transfer. In an example embodiment, the demand deposit account issuer 108 is the issuing bank of the portable consumer device being used to fund the value transfer. The demand deposit account issuer 108 may be a bank, a business entity such as a retail store, or a governmental entity. The demand deposit account issuer 108 may provide value transfer services and may host the demand deposit account.
The “recipient entity issuer” 110 may be any suitable entity that may maintain or manage the funds of the recipient entity. The recipient entity issuer 110 may have issued, may host, or may manage the portable consumer device or an account of the recipient entity. In an example embodiment, the recipient entity issuer 110 is the issuing bank of the portable consumer device receiving the funds from the value transfer. For example, the recipient entity issuer 110 may have issued the credit card receiving the funds of the value transfer. The recipient entity issuer 110 may be a bank, a business entity such as a retail store, or a governmental entity. The recipient entity issuer 110 may provide value transfer services. The recipient entity issuer 110 may be capable of transferring funds to the value transfer providing issuer 106.
The sending entity 102 may be in operative communication with the payment processing network 104. The sending entity 102 may communicate with the payment processing network 104 to provide information in order to initiate and conduct a value transfer. The value transfer may be an off-us DDA transfer. In an example embodiment, an off-us DDA transfer is transfer where the issuer that issued the portable consumer device is not the issuer that is used by the value transfer issuer. In a further example embodiment, an off-us DDA transfer is a transaction where the issuer is different than the acquirer. The sending entity 102 may provide information such as a transfer amount, a recipient entity alias or PAN, a demand deposit account identifier, and other information to complete a value transfer. The sending entity 102 may also identify the value transfer providing issuer 106. The sending entity 102 may also self identify to the payment processing network 104 by providing a sending entity alias, PAN, identifier, or by authenticating with the payment processing network 104, such as by logging in or providing a password or other authentication data. The payment processing network 104 may respond to the sending entity's requests and may prompt the sending entity 102 for more data.
Similarly, the sending entity 102 may be in operative communication with the value transfer providing issuer 106. The sending entity 102 may communicate with the value transfer providing issuer 106 to provide information in order to conduct a value transfer. The sending entity 102 may provide information such as a transfer amount, a recipient entity alias or PAN, a demand deposit account identifier, and other information to complete a value transfer. The sending entity 102 may also identify the payment processing network 104. The sending entity 102 may also self identify to the value transfer providing issuer 106 by providing a sending entity alias, PAN, identifier, or by authenticating with the originating institution 103, such as by logging in or providing a password or other authentication data.
The value transfer providing issuer 106 may also be in operative communication with the payment processing network 104. In an example embodiment, the value transfer providing issuer 106 communicates with the payment processing network 104 to conduct a value transfer as requested by the sending entity 102. The value transfer providing issuer 106 may also receive instructions form a payment processing network 104 to authorize a value transfer by communicating with a third party authorizer 107.
The payment processing network 104 and the value transfer providing issuer 106 may also be in operative communication with a third party authorizer 107. The third party authorizer 107 may receive requests to determine if a proposed value transfer is allowable, such as from the payment processing network 104 or the value transfer providing issuer 106, and query the demand deposit account issuer 108. The third party authorizer 107 may be in operative communication with the demand deposit account issuer 108. The third party authorizer 107 may communicate the reply of the query to the demand deposit account issuer 108 to the payment processing network 104 and the value transfer providing issuer 106. For example, the third party authorizer 107 may receive from the demand deposit account issuer 108 that sufficient of insufficient funds exist in the demand deposit account for the value transfer.
The value transfer providing issuer 106 may operatively communicate with the demand deposit account issuer 108 to effectuate a value transfer. The value transfer providing issuer 106 may communicate to the demand deposit account issuer 108 a debit message to debit the value transfer funds from the demand deposit account of the sending entity 102. In an example embodiment, the debit message is an account funding transaction. An account funding transaction may be a transaction that results in the debit of the sending entity's account.
The payment processing network 104 may communicate a credit message to the recipient entity issuer 110 to deposit the value transfer funds into the account of the recipient entity. In an example embodiment, the credit message is a original credit transaction. An original credit transaction may be a transaction that results in a credit to a recipient entity's account.
An account funding transaction message and original credit transaction message may be modified to contain specific information to support the value transfer, such as alias and issuer information. In an example embodiment, if the value transfer fails, an AFT reversal message may be sent to unwind the value transfer. In an example embodiment, an original credit transaction message or an account funding transaction message may comprise of a processing code, a transaction code, a transaction code qualifier, a business application identifier, and a merchant category code. The processing code may be a 26 bit code containing payment processing network 104 data. The transaction may be a 6 bit code describing a BASE II transaction. The business application identifier may be two bits, and describe either a merchant initiated or bank initiated original credit transaction.
Communications between entities in the alias management and off-us DDA processing system 100 may be conducted via any combination of the Internet, a mobile network, an intranet, SMS/IVR, a plain old telephone system, email, USSD-2, APIs, tailored messages, a specialized application, or a communications network. For example, the sending entity 102 may initiate a value transfer with the payment processing network 104 via SMS and the payment processing network 104 may communicate with the issuers via the web.

II. Method

FIG. 2 is a process flow of an off-us DDA value transfer, according to an example embodiment. At operation 1, the sending entity 102 sends a value transfer initiation message to the payment processing network 104. The value transfer initiation message may comprise of a transfer amount, a value transfer providing issuer identifier, a demand deposit account identifier, and a recipient entity account identifier. For example, the sending entity 102 may send a message indicating that it wishes to send $30 USD, to “ted@ted.com,” through the value transfer functionality of CitiBank. The listed identifiers may be PANs, aliases, or other identifying values. The value transfer initiation message may also comprise of additional information, such as a schedule in which to make the value transfer, whether such transfer are one-time or reoccurring, or other supplemental terms. For example, the sending entity 102 may detail that it wishes to send the value transfer next Tuesday, or every Tuesday until October 29. The value transfer initiation message may indicate that the sending entity 102 wishes to initiate an “off-us” DDA value transfer. The value transfer initiation message may include an identifier or value that indicates to the payment processing network 104 that the sending entity 102 wishes to execute an off-us DDA transaction. Illustratively, a customer wishing to send money to his friend may send a value transfer initiation message to a payment processing network 104 identifying his friend, identifying his value transfer supporting bank, and identifying the bank account from which he or she intends to send the money from. In an example embodiment, the sending entity 102 may instruct the payment processing network 104 to create a reoccurring or scheduled value transfer. A reoccurring value transfer may repeat for a certain time frame, such as every Monday or every two weeks. A scheduled value transfer may be submitted now, but may not be processed, or funds may not be transferred, until the scheduled date arrives.
After the payment processing network 104 receives the value transfer initiation message, at operation 2, the payment processing network 104 may then send an authorization request message to the third party authorizer 107 requesting that the third party authorizer 107 authorize the value transfer with the demand deposit account issuer 108. The authorization request message may include the transfer amount, the demand deposit account identifier, the value transfer providing issuer identifier, and the recipient entity account identifier. The authorization request may also include charges or fees, such as those charged by the value transfer providing issuer 106. The payment processing network 104 may communicate with the third party authorizer 107 as a precautionary measure to ensure that the identified demand deposit account has sufficient funds for the value transfer. In an example embodiment, the payment processing network 104 does not communicate with the third party authorizer 107 during the value transfer process.
In an example embodiment, the payment processing network 104 may analyze the value transfer initiation message and look up the sending entity identifier to see if it exists in a table identifying entities which are eligible to receive “fast funds,” or real time transfers. A sending entity 102 may be eligible for “fast funds” transfer, or real time transfers, such as value transfers, if it is enabled to send real time value transfers. In an example embodiment, a real time value transfer is enable for a sending entity 102 when an issuer associated with the portable consumer device associated with the sending entity 102 agrees to honor all real time value transfers, such that if a recipient entity issuer 110 receives a credit transaction, that the sending entity issuer agrees to honor the corresponding debit action, so that the recipient entity issuer 110 may make available the credited funds in real time.
The third party authorizer 107 receives the authorization request message from the payment processing network 104, and at operation 3, sends a query message to the demand deposit account issuer 108. The query message may comprise a demand deposit account identifier and the transfer amount. The query message may ask the demand deposit account issuer 108 if the demand deposit account identified by the demand deposit account identifier has sufficient funds to support the value transfer. In an example embodiment, the query may be an account balance query. In a further embodiment, the demand deposit account issuer 108 may be derived from the demand deposit account identifier. For example, the third party authorizer 107 may be an electronic clearinghouse that will query the demand deposit account issuer 108. At operation 4, the demand deposit account issuer 108 sends a response message to the query to the third party authorizer 107. The response message may indicate that the demand deposit account contains sufficient funds and that the value transfer is authorized, or that the demand deposit account does not contain sufficient funds and that the value transfer is not authorized.
The third party authorizer 107 receives the response message from the demand deposit account issuer 108, and at operation 5, sends the response to the payment processing network 104. If the response message indicates that the funds in the demand deposit account are insufficient, then the value transfer is canceled and notification is sent to the sending entity 102. If the response message indicates that sufficient funds exist in the demand deposit account, then upon receiving the message from the third party authorizer 107, the payment processing network 104, at operation 6, then sends a debit instruction message to the value transfer providing issuer 106. The debit instruction message may comprise of a transfer amount, a demand deposit account identifier, and the authorization from the third party authorizer 107. The debit instruction message may instruct the value transfer providing issuer 106 to withdraw or debit at least the transfer amount from the demand deposit account associated with the demand deposit account identifier.
After receiving the debit instruction message from the payment processing network 104, at operation 7, the value transfer providing issuer 106 and the demand deposit account issuer 108 operatively communicate in a variable process in order to transfer at least the transfer amount from the demand deposit account to the value transfer providing issuer 106. The process used to transfer the value may be variable and unknown by the payment processing network 104. Such a process between the value transfer providing issuer 106 and the demand deposit account issuer 108 may be an account funding transaction, an automated clearinghouse transaction, via wire transfer (e.g., Check21, FedWire, or other real time gross settlement systems). The value transferred from the demand deposit account may be held in an escrow account associated with the value transfer supporting issuer 106 or held in an account of the sending entity 102 associated with the value transfer providing issuer 106 and debited from the account when a confirmation is sent to the payment processing network 104 or when a schedule value transfer occurs. In an example embodiment, the value is withdrawn from the demand deposit account but not deposited in an account with the value transfer providing issuer 106.
After the value transfer providing issuer 106 receives at least the transfer amount from the demand deposit account issuer 108, the value transfer providing issuer 106 at operation 8 sends a confirmation message to the payment processing network 104. The confirmation message may confirm that the value transfer providing issuer 106 successfully debited at least the transfer amount from the demand deposit account issuer 108. In an example embodiment, the confirmation message confirms a successful wire transfer or account funding transaction.
After the payment processing network 104 receives the confirmation message from the value transfer providing issuer 106, the payment processing network 104 then sends, at operation 9, a credit message to the recipient entity issuer 110. In an example embodiment, the credit message is an original credit transaction. The credit message may instruct the recipient entity issuer 110 to deposit the transfer amount into the recipient entity's account. In an example embodiment, the credit message may be structured to indicate that the value originated from the value transfer providing issuer 106, rather than the demand deposit account issuer 108. For example, the credit message may include the value transfer providing issuer 106 bank identification number (BIN) and the recipient entity PAN.
In some embodiments, the recipient entity issuer 110 may be eligible for a “fast funds” transfer. In order to determine whether the recipient entity issuer 110 is eligible for a fast funds transfer, the payment processing network 104 may consult one or more routing tables to determine whether the recipient entity issuer 110 participates in fast funds. If the recipient entity issuer 110 participates in fast funds, then the transfer amount may be credited to the recipient entity account within 30 minutes of approval of the credit message by the recipient entity issuer 110. If the recipient entity issuer 110 does not participate in fast funds, the transfer amount may be credited to the recipient entity account within 2-3 business days.
After receiving the credit message, the recipient entity issuer 110 may credit the transfer amount into the recipient entity account of the recipient entity and at operation 10 may send a confirmation message to the payment processing network 104. The confirmation message may confirm that the credit to the recipient entity account was successful. If the credit was not successful, the recipient entity issuer 110 may send a failure message to the payment processing network 104 and the prior transfer between the value transfer providing issuer 106 and the demand deposit account issuer 108 may be unwound.
After receiving the confirmation message from the recipient entity issuer 110, the payment processing network 104, at operation 11, may send a confirmation message to the sending entity 102. The confirmation message may confirm that the off-us dda value transfer was successful. The confirmation message may be sent via SMS, email, voice mail, or other means.
In an example embodiment, the value transfer settlement occurs in real time, such as with AFT/OCT transactions. In a further example, the value transfer settlement may occur as a part of a periodic batch processing, such as through traditional bank wire transfers.
FIG. 3 is an alternative process flow of an off-us DDA value transfer, according to an example embodiment. The flow in FIG. 3 is identical to that of FIG. 2, except that at operation 2 a, the payment processing network 104 sends the authorization request message to the money transfer providing issuer 106 which then queries the third party authorizer in operation 3 a. The third party authorizer 107 communicates with the demand deposit account issuer 108 and receives the response message and communicates that to the money transfer providing issuer 106 in operation 4 a. The money transfer providing issuer 106 then communicates the response message to the payment processing network 104 in operation 5 a. The value transfer providing issuer 106 may communicate with the third party authorizer 107, rather than the payment processing network 104, as in FIG. 2. The descriptions of the other process steps in FIG. 2 are herein incorporated by reference.
FIG. 4 is a diagram of a computer apparatus, according to an example embodiment. The various participants and elements in the previously described system diagrams (e.g., the third party authorizer, payment processing network, the issuers, etc. in FIGS. 1, 2, 3) may use any suitable number of subsystems in the computer apparatus to facilitate the functions described herein. Examples of such subsystems or components are shown in FIG. 4. The subsystems shown in FIG. 4 are interconnected via a system bus 775. Additional subsystems such as a printer 774, keyboard 778, fixed disk 779 (or other memory comprising computer-readable media), monitor 776, which is coupled to display adapter 782, and others are shown. Peripherals and input/output (I/O) devices, which couple to I/O controller 771, can be connected to the computer system by any number of means known in the art, such as serial port 777. For example, serial port 777 or external interface 781 can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus allows the central processor 773 to communicate with each subsystem and to control the execution of instructions from system memory 772 or the fixed disk 779, as well as the exchange of information between subsystems. The system memory 772 and/or the fixed disk 779 may embody a computer-readable medium.
The software components or functions described in this application may be implemented as software code to be executed by one or more processors using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer-readable medium may also reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.
The present invention can be implemented in the form of control logic in software or hardware or a combination of both. The control logic may be stored in an information storage medium as a plurality of instructions adapted to direct an information processing device to perform a set of steps disclosed in embodiments of the present invention. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the present invention.
In an example embodiment the money transfer providing entity receives a debit instruction message comprising a transfer amount and a demand deposit account identifier, sends a debit message to a demand deposit account issuer to debit at least the transfer amount from a demand deposit account, wherein the demand deposit account issuer and the demand deposit account are identified using the demand deposit account identifier, receives from the demand deposit account issuer confirmation that that at least the transfer amount was debited from the demand deposit account, and sends a confirmation message confirming that at least the transfer amount has been debited from the demand deposit account to a payment processing network.
In a further embodiment, the demand deposit account issuer receives a debit message from a money transfer providing issuer comprising a demand deposit account identifier and a transfer amount, debits at least the transfer amount from the demand deposit account identified by the demand deposit account identifier, and sends a confirmation message to the payment processing network 104, wherein the payment processing network 104 then sends a credit message to the recipient entity issuer 110 to credit the recipient entity account at least the transfer amount.
In embodiments, any of the entities described herein may be embodied by a computer that performs any or all of the functions and steps disclosed.
Any recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary.
The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.
Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules (e.g., code embodied on a machine-readable medium or in a transmission signal) or hardware modules. A hardware module is tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.
In various embodiments, a hardware module may be implemented mechanically or electronically. For example, a hardware module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
Accordingly, the term “hardware module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired) or temporarily configured (e.g., programmed) to operate in a certain manner and/or to perform certain operations described herein. Considering embodiments in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where the hardware modules comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different hardware modules at different times. Software may accordingly configure a processor, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.
Hardware modules can provide information to, and receive information from, other hardware modules. Accordingly, the described hardware modules may be regarded as being communicatively coupled. Where multiple of such hardware modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the hardware modules. In embodiments in which multiple hardware modules are configured or instantiated at different times, communications between such hardware modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware modules have access. For example, one hardware module may perform an operation, and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware module may then, at a later time, access the memory device to retrieve and process the stored output. Hardware modules may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).
The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules.
Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or processors or processor-implemented modules. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor or processors may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other embodiments the processors may be distributed across a number of locations.
The one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., Application Program Interfaces (APIs).)
Embodiments of the alias management and off-us DDA processing system may provide several advantages over existing systems. The alias management and off-us DDA processing system allows the sending entity to send value from accounts associated with financial institutions that do not directly support value transfer. The alias management and off-us DDA processing system also allows the value transfer providing issuer to monetize their value transfer platform by providing services to other financial institutions and issuers. The alias management and off-us DDA processing system may also increase the spread of value transfer functionality by increasing the use of the value transfer services. It also allows a sending entity to send funds from a demand deposit account issuer that is not in communication with the payment processing network, and thus allows the anti money laundering and risk management functions of the payment processing network to be applied to funds from the demand deposit account issuer.

Claims

1. A method comprising:

sending, by a payment processing network server computer, a debit instruction message to a first financial institution to withdrawal at least a transfer amount from a second financial institution, the withdrawal request message comprising a demand deposit account identifier associated with the second financial institution, wherein the withdrawn funds are to be subsequently transferred to a third financial institution;

receiving, by the payment processing network computer, a withdrawal response message from the first financial institution confirming the withdrawal of at least the transfer amount from the second financial institution; and

initiating, by the payment processing network server computer, the sending of the transfer amount to a recipient entity account associated with the third financial institution.

2. The method of claim 1, further comprising sending, by the payment processing network server computer, an authorization request message to a third party authenticator, querying if at least the transfer amount is available from a demand deposit account, and receiving an authorization response message from the third party authenticator indicating that at least the transfer amount is available from the demand deposit account.

3. The method of claim 2, wherein the debit instruction message further comprises an authorization response indicator indicating that at least the transfer amount exists in the demand deposit account.

4. The method of claim 1, wherein initiating the sending of the transfer amount to the third financial institution comprises sending a credit message to the third financial institution, wherein the credit message comprises a BIN associated with the first financial institution and a personal account number (PAN) associated with the recipient entity account.

5. The method of claim 4, wherein the credit message is an original credit transaction.

6. The method of claim 1, wherein the demand deposit account and the recipient entity account at the third financial institution are payment card accounts.

7. The method of claim 1, wherein the recipient entity account is identified via a recipient entity alias, the first financial institution is a value transfer providing issuer, the second financial institution is a demand deposit account issuer, and the third financial institution is a recipient entity issuer.

8. The method of claim 1, further comprising receiving a confirmation message from a recipient entity issuer indicating that at least the transfer amount was credited to the recipient entity account.

9. The method of claim 1, further comprising receiving a value transfer initiation message from a sending entity comprising a transfer amount, a money transfer providing issuer identifier, a demand deposit account identifier, and a recipient entity identifier.

10. The method of claim 9, wherein the recipient entity identifier is a verifiable alias.

11. A non-transitory computer readable medium comprising code that when executed by a processor performs the method of claim 1.

12. A method comprising

receiving, by a value transfer providing issuer server computer, a debit instruction message comprising a transfer amount and a demand deposit account identifier;

sending, by the value transfer providing issuer server computer, a debit message to a demand deposit account issuer to debit at least the transfer amount from a demand deposit account, wherein the demand deposit account issuer and the demand deposit account are identified using the demand deposit account identifier;

receiving, by the value transfer providing issuer server computer, from the demand deposit account issuer confirmation that that at least the transfer amount was debited from the demand deposit account; and

sending, by the value transfer providing issuer server computer, a confirmation message confirming that at least the transfer amount has been debited from the demand deposit account to a payment processing network server computer.

13. The method of claim 12, further comprising receiving a authorization response message from the payment processing network server computer indicating that at least the transfer amount is available from the demand deposit account.

14. A non-transitory computer readable medium comprising code that when executed by a processor performs the method of claim 12.

15. A system comprising

a processor; and

a computer-readable medium coupled to the processor, the computer readable medium comprising code executable by the processor for implementing a method comprising:

sending a debit instruction message to a first financial institution to withdrawal at least a transfer amount from a second financial institution, wherein the withdrawal request message comprises a demand deposit account identifier associated with the second financial institution;

receiving a withdrawal response message from the first financial institution confirming the withdrawal of at least the transfer amount from the second financial institution; and

initiating the sending of the transfer amount to a recipient entity account associated with the third financial institution.

16. The method of claim 15, further comprising sending an authorization request message to a third party authorizer, querying if at least the transfer amount is available from a demand deposit account, and receiving an authorization response message from the third party authenticator indicating that at least the transfer amount is available from the demand deposit account.

17. The method of claim 15, wherein the debit instruction message further comprises an authorization response indicator indicating that at least the transfer amount exists in the demand deposit account.

18. The method of claim 15, wherein initiating the sending of the transfer amount to the third financial institution comprises sending a credit message to the third financial institution wherein the credit message comprises a first financial institution acquiring BIN and the third financial institution PAN.