Patent Grant
11694168
Example aspects herein relate generally to electronic transactions and, more specifically, to electronic real-time payment transactions.
The average banking customer interacts with his or her bank or financial institution at least twice a day for payment-related matters, such as buying a financial product, checking on a payment, or paying a bill. These interactions represent more than 80 percent of customer interactions with banks, making payments a superb platform, or beachhead, for cross-selling other financial services. Indeed, payment revenue is increasingly targeted by non-banks, and, missing out on these fees could detrimentally impact the capture of all possible banking related revenue.
However, the competition for the beachhead is intensifying, particularly in the area of mobile payments and digital payments.
Financial transfers today take place more quickly than before, but consumers are still burdened with needing to review their accounts to identify unauthorized or false transactions, and disputing such transactions with their financial institutions. Faster payment capabilities, along with robust consumer protections against fraud, unauthorized transactions, and erroneous debits, can help to alleviate these limitations at least somewhat.
Indeed, the Federal Reserve itself has developed a roadmap for a “near real time” payments system, and has noted that the financial services industry has a sense of urgency in pursuing this objective. The Federal Reserve has created task forces charged with advisory roles focused on defining faster payments capabilities, and payment security.
Various countries (e.g., Singapore, South Africa, Sweden, Switzerland, and the United Kingdom (UK)) offer a real-time credit push and a debit capability not in real-time (i.e., a transaction cleared on deferred basis). A so-called Fast Payment service exists in the United Kingdom (UK), as does a FAST service in Singapore. Both follow a typical model for providing immediate funds availability. For example, 97% of payment transactions are made available to a recipient within 60 seconds of receipt. For transactions not posted within 60 seconds, the payer is informed that transaction is under review.
To meet this standard, a receiving financial institution (FI) must have real-time screening for suspected fraud, AML, and sanctions (
Swish and PayM mobile P2P in Sweden and the UK purportedly provide immediate notification and credit, ClearXchange and PopMoney in the U.S. purportedly provide immediate notification with deferred credit, and Venmo and Square Cash purportedly provide immediate notification and immediate/or deferred credit. However, none of those services actually provide a service with a real-time crediting and settlement capability (i.e., posting of funds immediately to a creditor's account).
Instead, settlement often occurs within hours of a payment initiation. The UK Faster Payments service moved to full cash pre-funding of net settlement liabilities in November of 2014, effectively using a central bank balance as a net debit cap (i.e., a defaulter pays). Prior to that date, a multilateral debit cap was employed.
In a credit push scenario, a sending FI can verify and secure good funds. By not having debits, the risk of a reversal due to fraudulent and/or unauthorized debits is removed.
The Clearing House Interbank Payments System (CHIPS) addresses the risk of unsettled debit positions for wholesale wire transfers by requiring participants to prefund a settlement pool, while using an algorithm that continuously nets positions to reduce a funding requirement.
Also, currently, in the case of a payment error, existing processes for returning funds are manual, costly, and unsatisfying for consumers. PayM purportedly has features to reduce sending errors. For example, a payer can enter payment instructions and an alias account, and PayM looks up payee information in a database of registered users based on an account alias provided. Payer confirms the name of the payee presented by PayM prior to executing a transaction. Also, PopMoney services enable users to send funds using an email address. PayM and Swish in Sweden enable users to send payments to registered payees by providing a telephone number.
Typical real-time payment systems are designed to be a ubiquitous, industry-scaled solution that allow financial institutions to meet the real-time payment and contextual commerce needs of consumers and businesses. As the number of participants in a real-time payment system network increases, however, increasing ubiquity and efficient, faster payments across the payment network becomes technically challenging.
There exists a need, therefore, to support a greater number of participants that are transacting in a real-time payment system network, such as ACH network 130. One technical problem with supporting a greater number of participants transacting involves liquidity efficiency. Obtaining liquidity efficiency is not merely a scaling problem in which more processor power could be incorporated into the system, but rather an issue related to aggregate optimization. Aggregating multiple transactions for multiple institutions would reduce the liquidity requirements of each individual participant.
There presently does not exist a technical mechanism that enables a real-time payment system to manage and aggregate the liquidity of individual participants to back up the positions of the various individual participants based on a larger pool of transactions. Nor does there exist a technical mechanism enables the reduction of the liquidity requirements of individual participants based on the larger pool of transactions for which liquidity is being provided.
In view of the foregoing, there is a need to develop and implement an actual real-time payment system with real-time settlement to better meet consumers' and businesses' expectations in an increasingly digital economy, while minimizing or substantially reducing fraudulent or unauthorized transactions and the like, and streamlining processes for returning funds and correcting errors. There is also a need to develop and implement a mechanism for tracking account positions in the real-time payments system.
The example embodiments discussed herein address the challenges in the art discussed above, by providing methods, and systems, apparatuses, computer-readable media, and computer programs that operate in accordance with the methods for tracking account positions in a real-time payments system.
In one embodiment a method for tracking account positions in a real-time payments system performs the steps of: linking each of a plurality of participants to a funding agent account via an ACH network, thereby creating a plurality of linked participants; providing each of the plurality of linked participants access to a current prefunded position of the funding agent through the ACH network; comparing an unsettled financial position of each of the plurality of participants to the current prefunded position of the funding agent; determining whether to perform a financial settlement for a corresponding one of the plurality of participants based on a result of the comparing; and performing the financial settlement for the corresponding participant when it is determined that the unsettled financial position of the corresponding participant is not greater than the current prefunded position of the funding agent.
In some embodiments, the method includes updating the current prefunded position of the funding agent, by: debiting from the current prefunded position each successful transaction sent by a participant, and crediting the current prefunded position of the funding agent for each successful transaction received by the funding agent; and tracking the position of each of the plurality of participants against the current prefunded position of the funding agent.
In some embodiments, at least one of the plurality of participants is a non-funding participant.
In some embodiments, calculating the current prefunded position of the funding agent includes: determining an opening prefunded position; determining a net position; determining a supplemental funding amount; determining a plurality of disbursements; and calculating the current prefunded position according to: opening prefunded position+net position+supplemental funding+disbursements.
In some embodiments, the method further comprises calculating the net position by summing of all credit transfers sent and accepted or accepted without posting and all credit transfers received and accepted or accepted without posting by a participant.
In some embodiments the method further includes calculating an individual tracking position for each of the plurality of participants.
In yet other embodiments, the method further includes receiving, from the ACH network, a prefunded balance change notification system notification message (SNM) from the funding agent indicating a change in the tracking position of a participant; and communicating, to the participant, an SNM notifying the participant that the tracking position of the participant has changed.
In another embodiment there is provided a computer-readable medium storing instructions which, when executed by a computer processor, cause the computer processor to perform the methods disclosed herein.
In another embodiment a system for conducting financial settlement is provided. The system includes at least one memory for storing instructions and one or more computer processors arranged to execute the instructions to perform: linking each of a plurality of participants to a funding agent account via an ACH network, thereby creating a plurality of linked participants; providing each of the plurality of linked participants access to a current prefunded position of the funding agent through the ACH network; comparing an unsettled financial position of each of the plurality of participants to the current prefunded position of the funding agent; determining whether to perform a financial settlement for a corresponding one of the plurality of participants based on a result of the comparing; and performing the financial settlement for the corresponding participant when it is determined that the unsettled financial position of the corresponding participant is not greater than the current prefunded position of the funding agent.
In some embodiments, the one or more computer processors arranged to execute the instructions to further perform: updating the current prefunded position of the funding agent, by: debiting from the current prefunded position each successful transaction sent by a participant, and crediting the current prefunded position of the funding agent for each successful transaction received by the funding agent; tracking the position of each of the plurality of participants against the current prefunded position of the funding agent.
In some embodiments, at least one of the plurality of participants is a non-funding participant.
In some embodiments, calculating the current prefunded position of the funding agent includes: determining an opening prefunded position; determining a net position; determining a supplemental funding amount; determining a plurality of disbursements; and calculating the current prefunded position according to: opening prefunded position+net position+supplemental funding+disbursements.
In some embodiments, the one or more computer processors arranged to execute the instructions to further perform: calculating the net position by summing of all credit transfers sent and accepted or accepted without posting and all credit transfers received and accepted or accepted without posting by a participant.
In some embodiments, the one or more computer processors arranged to execute the instructions to further perform: calculating an individual tracking position for each of the plurality of participants.
In some embodiments, the one or more computer processors arranged to execute the instructions to further perform: receiving, from the ACH network, a prefunded balance change notification system notification message (SNM) from the funding agent indicating a change in the tracking position of a participant; and communicating, to the participant, an SNM notifying the participant that the tracking position of the participant has changed.
The real-time payments system herein is a safe, sustainable, standards-based retail real-time payment system that has an ability to reach financial institutions and position them to be pre-eminent providers of innovative payment services to their customers, by providing a fully featured product platform with extensible messaging and robust security.
Further features and advantages, as well as the structure and operation, of various example embodiments are described in detail below with reference to the accompanying drawings.
The features and advantages of the example embodiments presented herein will become more apparent from the detailed description set forth below when taken in conjunction with the drawings. Like reference numbers between two or more drawings can denote identical or functionally similar elements unless the description indicates otherwise.
Again, identical portions of the various figures have been identified with the same reference numerals in order to simplify the descriptions thereof, and a detailed description may not be provided with respect to each figure.
System 100 also includes financial institutions (FIs) 111 and 120. In an example embodiment, a user associated with station 110 can receive banking services (e.g., account services such as access to demand deposit accounts and savings accounts, brokerage services, and electronic bill payment and present services and the like) from FI 111. Similarly, a user associated with station 121 receives banking services from FI 120. Accordingly, FI 111 can be referred to as a “debtor FI,” and FI 120 can be referred to as a “creditor FI.” Each FI includes one or more computers and/or servers, such as, for example, the system of
Debtor station 110 is connected to (e.g., can electronically communicate with) debtor FI 111. Accordingly, the debtor may use station 110 to access banking services provided by FI 111 through, for example, an online banking portal available through a web browser running on station 110, banking software loaded on to station 110, or any other banking service provided by FI 111 on station 110. Similarly, creditor station 121 is connected to creditor FI 120. Station 110 and 121 also may connect to other elements as well, such as other elements of system 100.
Debtor FI 111 and creditor FI 120 are connected to each other by an Automated Clearinghouse (ACH) network 130 (e.g., such as, without limitation, one or more of the Electronic Payments Network (EPN) and the FedACH). ACH network 130 can route (e.g., receive and transmit) electronic transactions and various types of messages between FIs via message interfaces 112 and 114, as described hereinbelow. ACH network 130 can include one or more computers and/or servers (such as, for example, the system shown in
Each connection (as indicated by a dual-headed arrow) illustrated in
In one example embodiment, stations 110 and 121 can be connected by a secure communication channel (as indicated by the dashed arrow) on which communications may proceed after a single sign-on (SSO) procedure is performed in which a member using station 110 logs in to an online banking service provided by FI 111, although this example is neither limiting nor exclusive. In such a procedure, debtor FI 111 can be configured as a SAML identity provider, and station 121 can be configured as a SAML service provider. Accordingly, through communication between FI 111 (as the SAML identity provider) and station 121 (as the SAML service provider), a secure communication channel between station 110 and 121 can be established. In one example embodiment, such a secure communication channel is provided by way of network 130, which enables the SSO procedure to be effected.
Network 130 also includes a core processing system 131, an administrative system 132, a settlement system 133. Network 130 also can include one or more databases. Generally, core processing system 131 performs processes such as payment processing, message validation, duplicate message checking, transaction state management, acknowledgements, non-payment processing, administrative message processing, and system message processing. The core processing system 131 also performs processes such as message routing, transaction routing, routing to a value added service system (to be described below), and end-point fraud management. The system 131 also performs processes such as system security processes, authorization and authentication, user access management, and fraud detection.
The administrative system 132 performs administrative processes such as operations processing, participant onboarding, helpdesk and customer service, control room system monitoring, data management, conducting inquiries and investigations, and bank administration. Additionally, system 132 performs reporting processes such as dashboard processing, operations reporting, statistics reporting, performance reporting, pricing and billing, regulatory reporting, and internal audit reporting. System 132 also performs government and rules management processing, maintains business rules, effects change management, participant management, audits, and risk management. The settlement service system 133 performs settlement processing to enable financial transactions to be settled, manages multilateral net settlement positions, settlement notifications, and transmits/receives data to/from at least one settlement facility 134. That facility 134 also can communicate with the FIs 111 and 120 by way of gateways 115 and interfaces 114.
The system 100 also can include a value added service system 138 connected to (or within) the network 130 and the FIs 111 and 120. The system 138 performs various valued-added services such as, for example, directory services and maintenance, fraud management, analysis, and reporting, and token services. The system 100 can include one or more computers and/or servers, such as, for example, the system shown in
System 100 further can include third party service providers 142 which can be, for example, payment service providers, a biller or a clearinghouse. In the system 100, the third party can receive bills and payments from FIs and send them to other FIs 111. Third party 142 can include one or more computers and/or servers, such as, for example, the system shown in
In the illustrated example, the systems 138 and 134 are represented as being separate from ACH network 130, and at least some parts of the below description is made in the context of that example embodiment. However, it should be understood that the scope of the invention is not limited to that example only. For example, it is also within the scope of the invention for the systems 138 and 134 to be included in, operated by, or otherwise be a part of ACH network 130, and one skilled in the art would understand in view of this description how to adapt the functionalities described herein where needed to accommodate such an embodiment.
Elements of system 100 can be configured to perform one or more of the steps or functions associated with any of the processes discussed herein, including those illustrated in the flow diagrams shown in the Figures and those discussed in connection therewith.
Example Computer Systems
The system of
Processor 1802 can communicate with the other components of the computer system through bus 1801. Storage device 1804 includes one or more computer-readable media. Storage device 1804 can be configured to read and write data including program instructions that may be executed by processor 1802 and operating systems (e.g., a general-purpose operating system, such as Microsoft Windows and UNIX, or a custom operating system) that allow processor 1802 to control the operation of the other components. Communications device 1805 can be configured to enable processor 1802 to communicate with, for example, a network and the internet. User interface(s) 1806 can include input devices (e.g., keyboards, mice, joysticks, trackpads, stylus tablets, microphones, and cameras), output devices (e.g., video displays, printers, and speakers), and input/output devices (e.g., touch screens). User interface(s) 1806 can form at least part of any of the devices, components, and/or systems discussed herein.
Processor 1802 is configured to perform part (or all) of any of the processes described herein, depending on which component(s) of
Example Real-Time Payment Procedures
An example real-time payments procedure according to an example embodiment herein will now be described. Referring now to
If any of the determinations (i), (ii), and (iii) results in a determination of “No” (“No” in step 205), then control passes to step 207, where the user of station 110 may elect to make the payment via another payment alternative, and then the method ends (step 215). On the other hand, if each of the determinations (i), (ii), and (iii) results in a determination of “yes” (“Yes” in step 205), then control passes to step 206, where a payment transaction message (e.g., a pacs.008 message) is generated by the debtor FI 111. The payment transaction message includes, for example, a transaction identifier (e.g., a UT-ID generated by an algorithm), a biller's or creditor's name, the biller's account number at the biller's FI (e.g., FI 120), the routing number of the biller's FI (e.g., FI 120), the consumer's name, the payment amount, and a biller remittance identifier (i.e., consumer's account number with the biller) so that the biller can associate the payment with the consumer for posting purposes. Payments made for bills obtained by the consumer may be initiated, where the FI 111 can initiate a payment transaction message for each payment, enabling the consumer to pay bills such as, for example and without limitation, bills for debts owed by the consumer (e.g., user of station 110) to the debtor (e.g., associated with station 121).
In traditional (i.e., non-pseudo-identifier) payment transactions, biller routing numbers are used to determine which biller FI should receive a payment transaction message, and billers' account numbers are used to determine which biller's account at the biller FI should receive the payment, and those numbers, in one example, can be obtained by correlating an identifier of the biller to those numbers maintained in a directory (steps 208, 231). The directory may be included in the ACH network 130 (or value added services 138), in one example embodiment, or in another example, it can be included elsewhere in the system 100, such as at a third party or another element.
As an alternative to traditional payment transactions, the ACH network 130 enables a biller to use a bank account number pseudo-code (BANPC) and a bank routing number pseudo-code (BRNPC) as described below, for an added level of security. Similar functionality also is described in U.S. Pat. Nos. 6,173,272 and 6,317,745, both to Thomas et al. These two patents are hereby incorporated by reference in their entireties, as if set forth fully herein. In the example embodiments herein, the BANPC can be used in effecting credit-only transactions, or both credit and debit transactions.
A BRNPC is an alias for a biller FI's routing number which indicates to the ACH network that a BANPC transaction is present. A BANPC is an account identifier alias for a biller's account number at its biller FI (e.g., FI 120). Each alias also is referred to herein as a “token”. For a BANPC transaction, when an electronic payment is specified to be made by a consumer by way of its FI (e.g., FI 111), instead of using the biller's actual account number and a biller FI's actual routing number (whether obtained in the payment authorization message or obtained from the directory), a BANPC identifier corresponding to that account number and a BRNPC are obtained and inserted by the FI (e.g., FI 111) in the payment transaction message, in step 206 (see also steps 208 and 209). As such, “tokenization” is thereby performed. For security, in one example embodiment, FIs such as FI 111 are provided with BRNPCs and corresponding BANPCs, but not with the biller's actual account and routing numbers. The BANPC and BRNPC collectively protect the biller's banking information and mitigate the opportunity for fraud.
In one example embodiment herein, the BANPC identifier and BRNPC are obtained by the FI 111 by accessing the directory to correlate information identifying the biller (creditor) included in the payment authorization to a corresponding BANPC identifier and BRNPC included in the directory (step 208, 209). (In one example embodiment herein, the information identifying the creditor can be any suitable type of identifier, such as, for example, a name, email address, phone number, or the like). As pointed out above, the directory may be included in the ACH network 130, in one example embodiment, or in another example, it can be included elsewhere in the system 100, such as at a third party or another element.
After step 206 is performed, control passes to step 210 where, in one example embodiment, the network 130 receives the payment transaction from the debtor FI 111 (e.g., in a pacs.008 credit transfer message) and determines whether the transaction is correctly formatted. For example, the network 130 checks the message type of the transaction, and validates the format, syntax, and/or structure of the message. That step can be performed in accordance with any suitable techniques. If it is determined that the message is not properly formatted (“No” in step 211), then control passes to step 216′ which will be described below. If it is determined that the message is properly formatted (“Yes” in step 211), then control passes to step 212 where the network 130 checks to determine whether the message is duplicative of one already received, based on, for example, whether a UT-ID included in the message was already received. If it is determined that the message is duplicative (“Yes” in step 213), then control passes to step 216′, which will be described below. If, on the other hand, the message is determined to not be duplicative (“No” in step 213), then control passes to step 214 where the network 130 checks the message to determine whether it includes valid account and routing numbers (e.g., whether tokens or actual account and routing numbers). If not (“No” in step 215), then control passes to step 216′ which is performed in a manner to be described below. If “Yes” in step 215, then in step 216 the network 130 makes a determination as to whether the debtor FI 111 is enabled for sending payment transactions, and whether the creditor FI 120 is enabled to receive payment transactions. For example, this step can include the network 130 checking a look-up table to determine whether information in the table indicates that those FIs have such respective capabilities.
If the FIs are determined not to be enabled (No” in step 217), then control passes to step 216′ which will be described below. If, on the other hand, the FIs are determined to be enabled (“Yes” in step 217), then the network 130 makes a determination as to whether the debtor FI 111 or creditor FI 120 have been suspended to participate in electronic payment transactions (step 218). If either of those FIs are determined to be suspended (and thus the check is determined not to be successful (“No” in step 219)), then control passes to step 216′. That step 216′ will now be described. In step 216′, the network 130 generates an exception message (e.g., a pacs.002 message) and forwards it to the debtor FI 111, and then, in step 220 the debtor FI 111 responds by processing the exception, whereafter the method then ends in step 215.
If, on the other hand, either of the FIs 111 or 120 is determined not to be suspended (and thus the check is determined to be successful (“Yes” in step 219)), then control passes to step 221 where the network 130 performs various business validations. As an example, the validations can include determining whether the payment amount of the payment transaction is less than a predetermined individual transaction limit of the system 100. If the validation(s) performed in step 221 are determined not to be successful (“No” in step 222), then control passes to step 216′ which is performed in the manner described above.
If the validation(s) performed in step 221 are determined to be successful (“Yes” in step 222), then control passes to step 223 where the network 130 updates a multilateral net settlement position for at least one of the debtor FI 111 and the creditor FI 120. Then, in step 224 the network 130 checks to determine whether a token service is being employed in the payment transaction (i.e., the network 130 detects whether a BANPC transaction or a traditional transaction is present). The presence of a BANPC transaction is detected based on the ACH network comparing the BRNPC of the consumer's payment request to a list of routing numbers designated by the ACH network for BANPC transactions. If no match exists (“No” in step 225), then traditional processing proceeds where the network 130 sends the payment transaction to the creditor FI 120 (step 226) to attempt effecting a payment based on the routing number and account number included in the payment transaction message (a pacs.008 message), whereafter the creditor FI 120 begins processing the payment transaction (step 227). That FI 120 determines whether to accept or reject the payment (step 243) based on predetermined criteria, or whether the payment is pending (e.g., perhaps owing to an anti-fraud, AML, or OFAC investigation, etc.). In the case where the payment is rejected (e.g., perhaps a relevant account is closed, a token is not recognized, etc.), the FI 120 assigns a reason for rejecting the payment (step 244) and then sends a status “RJCT” negative ACK (e.g., a pacs.002 message) to the network 110 in step 245. Control then passes to step 230 which performs a tokenizing procedure, and then control passes to step 231′ which will be described below. In the case where the FI 120 determines that the payment is pending in step 243, then in step 246 the FI 120 sends a status “PDNG” (e.g., a pacs.002 message) to the network 110. The pending status message may also be, in one embodiment, an accepted without posting message. Control then passes to step 230 which performs a tokenizing procedure, and control then passes to step 236 which will be described below. In the case where the FI 120 determines that the payment is accepted in step 243, then in step 247 the FI 120 sends a status “ACSP” positive ACK message (e.g., a pacs.002 message) to the network 110. Control then passes to step 230 which performs a tokenizing procedure, and control then passes to step 236 which will be described below. In one example embodiment, the FI 120 also can notify the station 121 of the status of the payment (e.g., via text message, email, an online message or other form of communication) (see step 226′ of
Referring back again to step 225, a case where token services are determined to have been used in the payment transaction will now be described. If a match is determined to exist in step 225 (i.e., if the routing number is a BRNPC in the list), and thus token services are determined to have been used in the transaction (i.e., “Yes” in step 225), then a BANPC transaction is deemed present and the ACH network 130 in step 228 (and involving step 229) performs a detokenization procedure. In this particular example, the detokenization procedure includes a reversal of the tokenization procedure performed in step 206, and thus includes a translation from the BANPC included in the payment transaction to (1) a biller's account number at their biller FI (e.g., FI 120) and (2) a routing number for the biller's FI (e.g., FI 120). To perform this translation, the ACH network 130 and/or value added services 138, maintains a BANPC database that associates each biller's BANPC with that biller's account number at their FI (e.g., FI 120) and the routing number to the biller's FI (e.g., FI 120). Using the directory (also referred to as a BANPC database, which may be maintained by the ACH network 130 or value added service 138 or another element) and the BANPC included in the payment transaction, the ACH network 130 correlates the BANPC included in the transaction to a corresponding BANPC included in the directory, and to that latter BANPC's associated biller account number and routing number of the biller's FI (e.g., FI 120), in the directory (step 229).
The BANPC's associated biller account number and routing number of the biller's FI (e.g., FI 120) are inserted into the payment transaction, and the BANPC and BRNPC are removed from the transaction. Then the ACH network 130 routes the payment transaction, including the inserted account number and routing number, to the biller's FI (e.g., FI 120) based on the inserted routing number, in step 226. Control then passes to step 227 where the process proceeds in the above described manner. It is noted that, when a payment is accepted (in step 243), the biller FI (e.g., FI 120) posts the credit to the biller's account (corresponding to the biller account number) to complete payment.
In accordance with another example embodiment herein, the above translation (de-tokenization) is performed by a FI, such as FI 111, for at least some payment transactions, instead of by the ACH network 130.
Referring now to step 250, in that step the creditor FI 120 awaits an acknowledgement from the creditor station 121 that it has received the payment (see step 250, and “No” in step 249). In response to receive such an acknowledgement from the creditor station 121 (“Yes” in step 249), the creditor FI 120 forwards a payment acknowledgement message towards the debtor FI 111 and/or the debtor station 110 in step 248, via the network 130. Control then passes to step 230, which tokenizes that message, and control then passes to step 240 which will be described below.
Step 231′ will now be described. In step 231′ the network 130 validates the payment message with reason for rejection to determine that it is in a correct format (e.g., in accordance with pacs.002 schema). Then, in step 232, the network 130 conducts a reversal of the update to the multilateral net settlement position of the debtor FI 111 and/or creditor FI 120 (i.e., a reversal of step 223), and then in step 233 the network 130 updates the status of the payment transaction to indicate that the payment has been rejected. In step 234 the network 130 sends a payment reject message (e.g., pacs.002) to the debtor FI 111, including the reason for the rejection, the message is provided from the FI 111 to the station 110, and then the method then terminates (step 215).
Step 236 will now be described. In step 236, the network 130 validates the (a pacs.002 message) from step 246 or 247 to determine that it is in a correct format (e.g., in accordance with pacs.002 schema). Then, in step 238, the network 130 updates the status of the payment transaction as successful (in the case of step 247) or pending (in the case of step 246). In step 239 the network 130 sends a payment status message (e.g., pacs.002) to the debtor FI 111, indicating that the payment was successful or pending, and control then passes to step 235 where the FI 111 sends a message (e.g., a text message, email, online message or other form of communication) to the user station 110 indicating that the payment was successful or pending. Then the method ends at step 215.
Step 240 will now be described. In one example embodiment, in step 240 the network 130 determines whether a payment acknowledgement (e.g., an ACK message) received by the network 130 from the creditor FI 120 is correctly formatted. For example, the network 130 checks the message type of the transaction, and validates the format, syntax, and/or structure of the ACK message. That step can be performed in accordance with any suitable techniques. Then, in step 241 the network 130 forwards the ACK message to the debtor FI 111, which then responds in step 242 by providing a message to the station 110 indicating that the creditor FI 120 has acknowledged receipt of the payment. The method then ends in step 215.
Time Out and Status Reporting
The system 100 also can perform time out and status report processing. Referring now to
According to another example aspect of the present application, a party, such as, for example, a creditor, can request a payment from another party. Referring now to
In step 400 the creditor station 121 sends a request to the creditor FI 120, requesting that payment be made to a creditor associated with the station 121, from another party, such as a party associated with debtor station 110. The creditor FI 120 then generates a request for payment message in step 401. Thereafter, step 402 is performed is the same manner as step 206 of
After step 402, step 403 is performed wherein, in one example embodiment, the network 130 receives the payment request message from the creditor FI 120 (e.g., in a pain.013 message) and determines whether the message is correctly formatted. For example, the network 130 checks the message type, and validates the format, syntax, and/or structure of the message. That step can be performed in accordance with any suitable techniques. If it is determined that the message is not properly formatted (“No” in step 404), then control passes to step 411 which will be described below. If it is determined that the message is properly formatted (“Yes” in step 404), then control passes to step 405 where the network 130 checks to determine whether the message is duplicative of one already received, based on, for example, whether a UT-ID included in the message was already received in a previous message. If it is determined that the message is duplicative (“Yes” in step 406), then control passes to step 411, which will be described below. If, on the other hand, the message is determined to not be duplicative (“No” in step 406), then control passes to step 407 where the network 130 checks the message to determine whether it includes valid account and routing numbers for the debtor FI 111, or a valid alias (token). If not (“No” in step 408), then control passes to step 411 which is performed in a manner to be described below. If “Yes” in step 408, then in step 409 the network 130 makes a determination as to whether the debtor FI 111 is enabled for sending payment transactions, and whether the creditor FI 120 is enabled for sending a request for payment. For example, this step can include the network 130 checking a look-up table to determine whether information in the table indicates that those FIs have such respective capabilities.
If the FIs are determined not to be enabled (No” in step 410), then control passes to step 411 which will be described below. If, on the other hand, the FIs are determined to be enabled (“Yes” in step 410), then the network 130 makes a determination as to whether a token service is being employed by the debtor FI 111 (e.g., in one embodiment by checking a look-up table that includes such information) (step 412). In one example embodiment herein that step can be performed like step 224 of
Referring back to step 411, that step includes the network 103 generating an exception message (e.g., a pain.014 message) and providing it to the creditor FI 120. Then, in step 414, the creditor FI 120 receives that message and notifies the creditor station 121 of the message, and then the method ends in step 415′.
Referring back again to step 412, a case where token services are determined to be employed by the debtor FI 111 will now be described. In such a case (“Yes” in step 413), control passes to step 416 where the payment request message is de-tokenized. For example, the ACH network 130 (and/or value added services 138) performs a translation from the BANPC included in the request to (1) a debtor's account number with their debtor FI (e.g., FI 111) and (2) a routing number for the debtor's FI (e.g., FI 111). To perform this translation, the ACH network 130 and/or value added services 138, maintains the BANPC database that associates each debtor's BANPC with that debtor's account number at their FI (e.g., FI 111) and the routing number to the debtor's FI (e.g., FI 111). Using the directory and the BANPC included in the payment request, the BANPC included in the transaction is correlated to a corresponding BANPC included in the directory, and to that latter BANPC's associated account number and routing number of the debtor's FI (e.g., FI 111), in the directory (step 417).
The BANPC's associated account number and routing number of the debtor's FI (e.g., FI 111) are inserted into the payment request, and the BANPC and BRNPC are removed from the request. Then the payment request, including the inserted account number and routing number, is routed to the debtor's FI (e.g., FI 111) based on the inserted routing number, in step 415.
After step 415 the payment request is validated in step 418 to confirm that it is in the correct format (step 418). In the case where the validation is not successful (“No” in step 419), then in step 421 the debtor FI 111 sends a “request for payment rejected” message to the ACH network 130 and control passes to step 422 which will be described below. In the case where the validation performed in step 419 is successful (“Yes” in step 419), then the debtor FI 111 determines whether the debtor associated with the debtor station 110 (or the station itself 110) accepts request for payment messages (step 420). If not (“No” in step 420), then control passes to step 421 which is performed in the above-described manner. If step 420 results in a determination of “Yes” (“Yes” in step 420, then control passes to step 423 where the debtor FI 111 forwards a request for payment message to the debtor station 110, where a decision is made (step 424) to accept or ignore the request for payment message. If it is decided the ignore the message, the method ends in step 425. On the other hand, if the message is accepted (“Yes” in step 424), then the station 110 sends a payment transaction message to the debtor FI 111 requesting that the payment be made. The debtor FI 111 then receives the message (step 426) and adds to the message an indication that the payment transaction is in response to a request for payment message (step 427) (e.g., the indication is added to the UT-ID). Then, in step 428 the debtor FI 111 checks the account of the party associated with the debtor station 110 to determine whether it holds sufficient funds for being able to cover the payment transaction amount indicated in the payment message. Where there are sufficient funds, then in step 429 the FI 111 determines whether the payment can be executed in real time (e.g., whether the receiving institution, such as creditor FI 120, has subscribed to the real time payments service). If it is determined that the payment cannot be executed in real time (“No” in step 430), then the payment can be effected using an alternate routing method (step 431), and the method ends in step 432. If it is determined that the payment can be executed in real time (“Yes” in step 430), then the payment transaction message is sent (e.g., in a pacs.003 message) to the ACH network 130.
Referring now to step 422, the step includes tokenizing the account/routing numbers of the creditor in a similar manner as tokenization is performed in step 206 of
On the other hand, after step 422 for the case where the “request for payment rejected” message is received from debtor FI 111 in step 421 and processed in step 422, control passes to step 434 where, in one example embodiment, the network 130 determines whether the message received from the debtor FI 111 is correctly formatted. For example, the network 130 checks the message type of the transaction, and validates the format, syntax, and/or structure of the message. That step can be performed in accordance with any suitable techniques. Then, in step 435 the network 130 forwards a reject message to the creditor FI 120 and updates a record of the network 130 to indicate that the request for payment message has been rejected. In step 436 the creditor FI 120 receives the reject message and notifies the creditor station 121 that the request for payment has been rejected. The method then ends in step 415′.
Return of Funds
The method herein provides certainty for receivers. For example, funds are not permitted to be taken back from the receiver. In the case of error, a payer can ability request a return of funds (although in some embodiments there is no obligation to reverse/revoke transaction). This enables parties to complete transactions that would be too risky if payment could be reversed. In one example embodiment, requests for a return of funds refund can require a new transaction to return the funds to the requester, although this example is not limiting.
In example embodiments herein, between a payer and payee, once funds are sent by sender, funds cannot be pulled back without receiver's permission. Between a payer and payer's FI and between a payer's FI and payee's FI, once a payment message is transmitted to the network operator by the sending FI, the message cannot be cancelled or amended. Between a payer's FI and payee's FI, once the payment message is transmitted to the network operator by the sending FI, the sending FI has an obligation to settle the payment (unless receiving FI rejects the payment), and, once settled, the sending FI has no ability to pull back funds, although the receiving FI can reject payment and return funds.
In a credit push scenario, a consumer initiates payment, and, as such, there are no unauthorized debits. Bank are required by regulations to resolve errors related to thefts of account funds, subject to a consumer's responsibility to report the loss or theft of an access device. With respect to errors such as input errors (e.g., transposed account digits), these can be addressed by a process to request the funds from the counterparty and the development of payment features to reduce sending errors.
As an example of a process to request the return of funds sent in error, in one example embodiment, a return can be requested only for a sender error. For example, a receiver may recognize that a payment was made in error, sends a message to the payer that the payment is being returned, the payment is returned to the payer, which recognizes that the payment was made in error. The payer can send a message to the payee indicating that the payment was made in error. The receiver receives the message and can agree to return the funds to the payer. If the receiver does not agree to do so, or otherwise does not send a response, then the payer sends a message via the payer's FI to the receiver's FI asking for the return of funds. All messages reference the universal transaction Id of the original payment.
An example aspect of the present application will now be described, with reference to
If, on the other hand, the message is determined in step 508 to not be duplicative (“No” in step 508), then control passes to step 509 where the network 130 checks the message to determine whether it includes valid account and routing numbers. If not (“No” in step 510), then control passes to step 506 which is performed in the manner described above. If “Yes” in step 510, then in step 511 the network 130 forwards a request for return of funds message to the creditor FI 120, which then validates the message to check that it is correctly formatted (step 512). If the validation is not successful (“No” in step 513), then a message (e.g., a camt.029 message) indicating that result is provided to ACH network 130 and processing continues in step 517 where, in one example embodiment, the network 130 can notify the debtor FI 111 thereof (which can the notify the station 110 of the same). Additional procedures then can be performed as will be further described with respect to
If, on the other hand, the validation in step 513 is successful, then the creditor FI 120 investigates the situation regarding whether or not the funds should be returned (step 514). If it is decided to respond to the request for return of funds (“Yes” in step 515), then control passes to step 517 where, in one example embodiment, the network 130 can notify the debtor FI 111 of the result of the investigation or that one is being undertaken (the FI 11 also can notify the station 110 of the same). The notification also can provide a message returning the amount requested in the request for return of funds message. Additional procedures can then be performed as will be further described with respect to
After step 606 is performed, control passes to step 610 where, in one example embodiment, the network 130 receives the message generated in step 606 from the debtor FI 111 (e.g., in a camt.029 message) and determines whether the transaction is correctly formatted. For example, the network 130 checks the message type of the transaction, and validates the format, syntax, and/or structure of the message. That step can be performed in accordance with any suitable techniques. If it is determined that the message is not properly formatted (“No” in step 611), then control passes to step 616 which is performed to generate an exception message like in step 506 of
Requests for Information
In one example embodiment herein, for tokenization a BANPC identifier and BRNPC are obtained by the FI 120 and included in the message. For example, the FI 120 can access a directory to correlate information (e.g., a bank account and routing number) included in the message to a corresponding BANPC identifier and BRNPC included in the directory (step 209). The directory may be included in the FI 120, ACH network 130, or in another part of the system 100, such as at a third party or another element.
After step 704 is performed, control passes to step 705 where, in one example embodiment, the network 130 receives the message generated in step 704 from the creditor FI 120 (e.g., in a camt.027 message) and determines whether the transaction is correctly formatted. For example, the network 130 checks the message type of the transaction, and validates the format, syntax, and/or structure of the message. That step can be performed in accordance with any suitable techniques. If it is determined that the message is not properly formatted (“No” in step 706), then control passes to step 711 where the ACH network 130 generates an exception message and provides it to the creditor FI 120, which then processes the message and notifies (step 712) the creditor station 121 of the exception message (step 713). The method ends in step 714.
Referring again to steps 705 and 706, if it is determined that the message from step 704 is properly formatted (“Yes” in step 706), then control passes to step 707 where the network 130 checks to determine whether the message is duplicative of one already received, based on, for example, whether a UT-ID included in the message was already received. If it is determined that the message is duplicative (“Yes” in step 708), then control passes to step 711, which is performed as described above. If, on the other hand, the message is determined to not be duplicative (“No” in step 708), then control passes to step 709 where the network 130 checks the message to determine whether it includes valid account and routing numbers. If not (“No” in step 710), then control passes to step 711, which is performed as described above. If “Yes” in step 710, then in step 715 the network 130 sends a request for information message to the debtor FI 111, which then processes the message (step 716) and validates it against predetermined criteria (step 717). The message is then forwarded to the debtor station 110 in step 718, and the debtor station 110 and/or party associated therewith can decide how to address the request for information (step 721). If it is decided to ignore the request, then the method ends in step 722. In the event were the debtor station 110 provides a respond to the request for information, then the debtor FI 111 receives that response (step 719), adds a reference to the message in step 720 to indicate that it is associated with the original request for information message received in step 716, and then control passes through step 723 to
Also, in one example embodiment herein, tokenization is performed wherein a BANPC identifier and BRNPC are obtained by the FI 111 by accessing a directory to correlate information included in the response message (e.g., information identifying the requestor of the request for information) to a corresponding BANPC identifier and BRNPC included in the directory (step 209). The directory may be included in the ACH network 130, in one example embodiment, or in another example, it can be included elsewhere in the system 100, such as at FI 111, a third party, or another element. The obtained BANPC and BRNPC are included in the response message generated in step 806.
After step 806 is performed, control passes to step 810 where, in one example embodiment, the network 130 receives the message generated in step 806 from the debtor FI 111 (e.g., in a camt.028 message) and determines whether the transaction is correctly formatted. For example, the network 130 checks the message type of the transaction, and validates the format, syntax, and/or structure of the message. That step can be performed in accordance with any suitable techniques. If it is determined that the message is not properly formatted (“No” in step 811), then control passes to step 816 where the ACH network 130 generates an exception message and provides it to the debtor FI 111, which then processes the message and notifies (step 820) the debtor station 110 of the exception message. The method ends in step 815.
If performance of step 810 results in a determination that the message is properly formatted (“Yes” in step 811), then control passes to step 812 where the network 130 checks to determine whether the message is duplicative of one already received, based on, for example, whether a UT-ID included in the message was already received. If it is determined that the message is duplicative (“Yes” in step 813), then control passes to step 816, which will be described below. If, on the other hand, the message is determined to not be duplicative (“No” in step 813), then control passes to step 814 where the network 130 checks the message to determine whether it includes valid account and routing numbers. If not (“No” in step 815), then control passes to step 816, which is performed in a manner to be described below. If “Yes” in step 815, then in step 817 the network 130 sends a response to request for return of funds message to the creditor FI 120, which then validates that response against predetermined criteria (step 818) and provides it to the creditor station 121 (step 819). The method ends in step 820.
Providing Remittance Advice
In one example embodiment herein, a BANPC identifier and BRNPC are obtained by the FI 111 by accessing a directory to correlate information included in the remittance advice (e.g., information associated with station 121 and/or FI 120) to a corresponding BANPC identifier and BRNPC included in the directory (step 903, 208, 209). The directory may be included in the ACH network 130, in one example embodiment, or in another example, it can be included elsewhere in the system 100, such as at the FI 111, a third party or another element. The obtained identifiers are included in the remittance advice message, as is an assigned UT-ID. Step 903 can be performed like step 206 of
After step 903 is performed, control passes to step 904 where, in one example embodiment, the network 130 receives the message generated in step 904 from the debtor FI 111 (e.g., in a remt.001 message) and determines whether the message is correctly formatted. For example, the network 130 checks the message type, and validates the format, syntax, and/or structure of the message. That step can be performed in accordance with any suitable techniques. If it is determined that the message is not properly formatted (“No” in step 905), then control passes to step 916 which will be described below. If it is determined that the message is properly formatted (“Yes” in step 905), then control passes to step 907 where the network 130 checks to determine whether the message is duplicative of one already received, based on, for example, whether a UT-ID included in the message was already received. If it is determined that the message is duplicative (“Yes” in step 908), then control passes to step 916, which will be described below. If, on the other hand, the message is determined to not be duplicative (“No” in step 908), then control passes to step 909 where the network 130 checks the message to determine whether it includes valid account and routing numbers. If not (“No” in step 910), then control passes to step 916, which is performed in a manner to be described below. If “Yes” in step 910, then in step 911 the network 130 determines whether the debtor FI 111 identified in the message has a capability to receive real time payments (i.e., is “real time enabled”) (step 911). If not (“No” in step 912), then control passes to step 916 which is performed in the manner described below. If “Yes” in step 912,
then the network 130 makes a determination as to whether the debtor FI 111 or creditor FI 120 have been suspended to participate in electronic payment transactions (step 913). If either of those FIs are determined to be suspended (and thus the check is determined to not be successful) (“No” in step 914), then control passes to step 916. That step 916 will now be described. In step 916, the network 130 generates an exception message (e.g., a NACK message) and forwards it to the debtor FI 111, and then, in step 929 the debtor FI 111 responds by sending the exception message to the debtor station 110 (step 929), whereafter the method then ends in step 930.
If, on the other hand, either of the FIs 111 or 120 is determined not to be suspended (and thus the check is determined to be successful) (“Yes” in step 914), then control passes to step 915 where the network 130 determines whether token services are being employed by the creditor FI 120. If that determination results in a “Yes” decision (“Yes” in step 917), then in step 919 the tokens obtained in step 903 that are aliases of the creditor account and routing numbers are removed from the remittance advice message received from the FI 111 and replaced with their corresponding account and routing numbers (step 919). That step, which can be performed by the value added services 138, in one example embodiment herein, can be performed by invoking a directory (step 920) that may be included in the ACH network 130 or elsewhere in the system 100.
Referring again to steps 915 and 917, if the determination results in a “No” decision (“No” in step 917), then in step 918 the network 130 sends a remittance advice message (e.g., remt.001) to the creditor FI 120, which then processes and validates the message (step 921).
If that message is determined to be valid (“Yes” in step 922) then the remittance advice message is provided to the creditor station 121 (step 923), and then the method ends in step 924. If step 922 results in a determination of “Yes” decision (“Yes” in step 922), then a message indicative thereof (and, in one example, including the remittance advice) is provided by the FI 120 to the value added services 138, and, in step 925 tokenization can be performed by the services 138 to include tokens in the message, corresponding to the debtor FI 111. The inclusion of tokens can be performed in a similar manner as that described above for, by example, step 230 of
Payment States
In one example embodiment herein, a payee receives notification of a payment immediately after a payer initiates a transaction, and the payer can receive timely feedback as to the disposition of the payment. This can be useful because it enables the payee to know when a payment has been initiated, and provides an immediate customer experience, even if settlement is done later. Positive notification may serve as proof of payment.
In one example, embodiment, notification can be provided according to a predetermined standard (e.g., always notify a mobile device if available), or the customer can select the method of being notified. Also, the payer can receive immediate notification as to whether the payment was able to be completed immediately, was delayed for review, or was unsuccessful. Notifications preferably include a Universal Transaction Id. Examples of methods of communication with a customer include a text messages, E-mails, online banking website, telephone (e.g., auto dial), etc.
Step 1013 will now be described. In step 1013 the network 130 responds to a timeout by performing step 1014 where the network 130 records a status of the payment as having a creditor timeout status and notifies the debtor FI 111 of the same. That FI 111 then records the status of the payment to timeout with a rejection and reason therefor (step 1015).
Exception Message Processing
As described above, the system 100 generates various types of exception messages in the event that an exception type of message is detected.
Message Types
In an example embodiment herein, robust messaging capability is provided. The payment system supports multiple financial and non-financial message types which can be used to create a variety of transaction flows in support of disparate use cases, and flexible and extensible message formats are employed that are able to adapt to changing needs. This enables payment system flexibility for future needs, provides a platform for product development and innovation, and allows the system to become backward compatible with a network such as the ACH network 130. Messages may be overlaid to provide end-to-end solutions for specific use cases. Extensible messaging includes both financial and non-financial messages, asymmetric products (framework allows FIs to create products independently for senders and receivers), and, within messages there can be fields of data, external links, etc. Messages employed herein also can comply with existing global standard formats (e.g., ISO 20022, ISO 8583, etc.), and have international compatibility (e.g., multi-currency). Related messages can include a Universal Transaction Id which is unique within the payment system for every payment, as well as an identifier of a sending party (if applicable). Example messages include FI to FI messages such as acknowledgements by a receiver, and payment messages. Example FI to end user messages include receiver notification messages, sender notification messages, payment successful messages, sender notification payment rejected messages, and sender notification payment under review messages. Example end user to end user messages include requests for payment (e.g., invoice or message), receipt acknowledged by receiver messages, request for return of funds messages, and agree to return funds messages. Example third party messages include universal transaction IDs, links to external sources, and contingency payment rule messages. Non-payment messages preferably support value-added services and administration. Related messages can be linked into complex transactions. Messages can carry remittance data and references to external data and processes for extended functionality.
ISO 20022 is a harmonized set of XML messaging standards across major financial services domains (Funds Transfer, Cash, Securities, Trade, Card and Foreign Exchange) based on a shared data dictionary and business process model. Messages are available for the complete end-to-end payments chain; i.e., customer to bank, bank to bank, and reporting. Data definitions can be used as the basis for internal communication needs, and the standard can support real-time messaging (e.g., Denmark NETS).
ISO 8583 is a common interface by which financial transaction card originated messages may be interchanged between acquirers and card issuers. Messages in the standard typically contain information about the value of a transaction, where it originated, the card account number, and bank sort code. Message data fields can be customized, and the standard can support real-time messaging. The standard is used by retail banks, and for almost all credit and debit card transactions, including ATMs.
As described above, and referring now to
In one example embodiment herein, at least some of the various types of messages employed in the system include at least some of the following types of information:
Payment instruction messages can include, for example, remittance fields, and 140 characters, although these examples are not limiting. Administrative Messages
Non-payment administrative messages can include, by example, the following: management messages:
At least one or more of the following messaging features, types, contents, functions, and characteristics can be employed in the system 100 herein:
In an example embodiment herein, bulk messages can be employed. By example, low value, urgent payments can be aggregated and sent together for convenience and efficiency (e.g., this can be useful in scenarios such as payments of temporary employee wages, emergency disbursements, etc.). The bulking functionality can be performed at a FI level at the network 130, or in other elements of the system 100.
Payment Scenario Contexts
The methods and system described herein can be employed to conduct real-time payments in many different scenarios. By example, they can be employed in a business to person context, such as, for example, to pay employee wages, emergency payroll, urgent business to consumer contexts (e.g., disaster relief). Other examples may involve high value ad hoc payments such as large, one-time payments (e.g., insurance claims, legal settlements, etc.), or low value ad hoc payments (e.g., small one-time payments (e.g., temporary employee wages, emergency payroll, etc.)). Payments can be made available within a predetermined amount of time (e.g., within minutes, hours, etc.).
As another example, the methods and system described herein can be employed to conduct real-time payments in a person to person context. By example only, they can be employed to effect non-commerce payments (e.g., rent payments to a roommate, emergency funds for a family member, etc.), to perform urgent Account-to-Account transfers (e.g., to fund investments or purchases), to pay for informal services (e.g., babysitting, lawn care, etc.), and the like. Payments can be made available within a predetermined amount of time (e.g., within seconds, minutes, etc.).
As another example, the methods and system described herein can be employed to conduct real-time payments in a person to business context. By example only, they can be employed to conduct immediate bill payments with acknowledgments or receipts, to perform e-commerce purchases, and the like. Payments in this context may be time critical, such as, for example, stock purchases, emergency bill payments, etc. Payments can be made available within a predetermined amount of time (e.g., within seconds, minutes, or hours, etc.).
In still a further example, the methods and system described herein can be employed to conduct real-time payments in a business to business context. By example only, they can be employed to effect just in time payments to suppliers, to perform immediate bill payments with acknowledgments of receipt, and the like. Payments in this context may be time critical one time payments between businesses, such as, for example, just-in-time supplier payments, emergency bill payments, etc. Payments can be made available within a predetermined amount of time (e.g., within minutes).
The system has many additional capabilities, such as those described herein above and others as well. For example, the system 100 herein also can employ anti-spam measures to prevent the sender from broadcasting a massive number of requests to dupe receivers into sending funds. For example, this can be accomplished by charging a fee for all requests for payments. Also, in one example embodiment herein, a sending or receiving FI can be made liable for information in remittance data that may indicate illegal activity (e.g., the remittance data mentions a sanctioned individual or company). Provided that the payment is not being sent or received by a person or entity on an OFAC list, the FI would not be required to block or reject the transaction under OFAC requirements, in one example. The FI may, however, be required to file a suspicious activity report within 30 days if the content of a message indicates a potential relationship to illicit activity.
As another example capability of the system 100, as described above, in one example embodiment it has a capability for returning funds that were paid. Referring to
Also, as described above in connection with various flow diagrams, duplicate transactions are detected so they are prevented from being fully processed.
Also as described above in connection with various flow diagrams, invalid tokens are detected.
Fraud Detection
Still another capability of the system herein is fraud detection.
Thus, fraud detection can be performed at a central facility, such as at the system (network) 130, which is in a unique position within the overall system 100 to be able to detect activity between sending and receiving points. For example, the system 130 can evaluate transactions passing therethrough to detect predetermined patterns indicative of possible fraud, in real-time, and can then notify the FIs about the possible fraud so that they can take this into account when, for example, running their own fraud algorithms. The determination can involve a heuristic model, in one example embodiment herein, although other models may be used instead. As an example of a fraud detection, the system 130 can recognize that a single recipient is being sent payment transactions from multiple senders, and that a single sender is sending payment transactions to multiple recipients. If those activities are recognized by the system 130 as being indicative of possible fraudulent activity, then the system 130 can take action such as suspending the transaction and notifying FIs in real-time in the above-described manner.
Real-Time Payments are Useful to Customers
The system 100 is convenient in that it can enable consumers to pay each other directly from their existing accounts using online or mobile banking platforms. The system maintains account data privacy and is easy to use. For example, the system can route payments based on tokens that, in one example, are not used to debit accounts, so that senders and receivers will not need to provide complex, sensitive bank account details to other parties. The system also provides cost savings in that it provides a less costly alternative to costly funds transfers, check cashing services and last-minute bill payments. Additionally, the system provides certainty in that senders and receivers can be provided with immediate notifications of payment, and risks of returned payments are reduced because sending financial institutions can immediately verify sufficient funds. The system also is safe in that sending and receiving financial institutions, which have existing relationships with their customers, are responsible for authentication, in one example embodiment herein. Moreover, the system provides for effective cash management in that is has the ability to send and receive payments immediately, giving customers more control over cash flow, which can be useful for cash-constrained small businesses and consumers.
The system herein also supports superior and safer P2P payments, and provides comprehensive digital payment capability. In the system herein, customers can use their existing bank accounts to send and receive payments, whereas other types of non-bank MSP providers typically require customers to establish new accounts, which can be inconvenient during enrollment. Customers of the system herein can fund directly from their bank accounts, without requiring the sharing of sensitive data to payment recipients and recipient banks. For customers of typical non-bank MSP providers, on the other hand, customers must provide banking credentials, and MSP verification must be effected via, for example, a bank website or payment system. With regard to initiating payments, customers can use their existing bank login information, and bank verification/identification are employed for security, according to one example embodiment herein. For typical non-bank MSP providers, on the other hand, a customer must establish a separate login for MSP payment initiation. As for clearing and settlement, in one example embodiment of the system herein, immediate debit and push credit with real time availability to the payment receiver are provided, essentially in all cases. For typical non-bank MSP providers, on the other hand, a debit card or use of an ACH network may be required to effect external payments. Also, no cash outs are required in the system herein, since funds are transferred directly and immediately to a customer's bank account, whereas in typical MSP systems, customers must pull funds from the MSP account into their bank account, which can take a day or longer to be effected.
Sample Business Requirements
In one example embodiment herein, the system complies with predetermined business requirements. For example, with respect to credit transfers, in one example embodiment all payments originated by a payer are not permitted to be taken back from the receiver, and instead the payer can request the return of a payment made in error. This provides payment certainty for receivers.
The real time payment system herein can provide for 24/7 payments, provides real time access to payment status information for both senders and receivers, and immediate availability of funds for receivers. In one example embodiment herein, one of the business rules is that receiving FIs must be able to accept or reject most payments in seconds, and to resolve exceptions flagged for risk management and compliance review within a reasonable time (e.g., 2 hours). Also, receivers are to have access to funds for accepted payments substantially immediately (i.e., no holds).
Other example business requirements are that there is real time exchange of financial and non-financial messages that support a variety of use cases (i.e., messages are in real time), alias routing (e.g., tokens) is preferably employed (although not necessarily required) to initiate payments instead of account numbers. Also, ISO standard formats and internationally consistent transaction flows preferably are employed, to provide global compatibility, and messages must include all relevant data for risk management and compliance. This supports anti-fraud, anti-money laundering and OFAC/sanctions compliance processes.
For safety, additional business requirements can be employed. For example, in one example there is a system-wide limit on transaction sizes, and sending FIs can set lower limits. A settlement approach that mitigates material risk of loss can be employed. Intra-day net settlement and the use of position limits and pre-funding reduce settlement risk. Additionally, as described above, tokenization of bank account numbers protects account data. FIs that cannot meet a threshold for initiating payments may be able to participate as “receive-only” FIs. Thus, in one example a minimum threshold of security and privacy protection can be required of participating FIs.
In one example embodiment herein, there are certain payment system requirements for participants. For example, participating FIs should have functionality supported by the IT infrastructure of the payment system, and there can be certain operating rules and procedures as well. For example, requirements can be placed on participants in the real-time payment system that are not directly implemented by the IT infrastructure of the payment system. This can be in the form of policies, rules, standards, and service level agreements implemented through payment system governance.
In one example herein, FIs can be required to operate on a 24/7/365 basis, to accept and reject payments automatically on that basis, and to have the ability to perform necessary risk management and compliance functions, such as customer authentication, authorization, regulatory compliance screening, and anti-fraud screening 24/7 (which may be automated or outsourced). FIs also can be required to provide real-time access to payment status information for senders and receivers, so that senders and receivers can have complete, timely information about the status of real-time payments.
FIs also can be required to accept or reject a majority of payments (e.g., 95%+) within seconds, and all payments in a reasonable time, and to make immediate notification of payment to senders and receivers, or provide a channel for senders and receivers to inquire about payment status and receive an immediate response. FIs can be required to integrate accurate real-time payment status inquiry, notification, and feedback into online and mobile banking services.
Receiving FIs can be required to provide immediate availability of funds to recipients on a 24/7/365 basis, or at least make funds available to receivers within seconds for any accepted payment. Payments can be rejected for risk management, or an inability to post or legal compliance. Payments may be held for review for a reasonable time only when necessary for risk management and legal compliance purposes, and after review FIs must accept or reject payments, not withhold availability, in one example requirement.
FIs also can be required to employ limits on transaction value, which can be updated periodically based on objective criteria. Policies and processes can be provided to set sender FI value limits for transactions and to apply them to payment origination, and risk management policies and processes can be employed to accept payments up to a system-wide transaction value limit. FIs can be required to have an ability to identify potential structuring of transactions to avoid transaction limits.
Sending FIs can be required to have policies and processes for handling customer claims for unauthorized transfers and funds sent in error, and receiving FI can be required to have policies and processes for responding to requests to reclaim funds sent in error, and FIs can be required to have processes to request a return of erroneous payments, and an inter-FI process including electronic messaging to support requests for return of funds sent in error.
FIs can be required to create and operate a token vault or outsource it to a third party, integrate tokenization into products and services, and educate customers on tokenization. FIs can be required to have an ability to initiate payments based on an alias instead of an account numbers, and enable senders to initiate payments using an alias for the receiver such as a telephone number or email address, or the like.
FIs can be required to have an approach that mitigates material risk of loss, and a settlement process and legal framework that reduce or eliminate potential for settlement failure. FIs can be required to monitor, manage, and fund settlement pools or net settlement across all settlement windows, develop a process to respond to situations where settlement exposure has reached its limit, use tokens to protect account data, such as a unique code in lieu of an account number that cannot be used to debit the account.
For participating FIs, most security and data protection requirements apply across channels and products, not to a specific payment system, in one example embodiment herein. FIs also can be required to support risk management and regulatory compliance, and to support anti-fraud, anti-money laundering, and OFAC/sanctions compliance processes.
There also may be certain requirements placed on FIs such as, for example, practices and procedures for financial institutions participating in the real-time payment system that are not dictated by payment system requirements and operating rules.
Also in one example embodiment herein, there may be certain operator requirements placed on an operator of the core payments system, above and beyond day to day operation and maintenance of the IT infrastructure of the payment system, such as operator policies and procedures. An operator can be, for example, an entity responsible for operating the system 100, a subset thereof, or the network 100.
An operator can be required to establish limits on the value of transactions cleared through the payment system 100, and rules for a process for revising the transaction value limits (sending FIs can set lower value limits for their customers, and receiving FIs cannot set a transaction limit lower than the system-wide limit, in one example. In one example, there is a $25,000 per transaction initial limit, which can be raised over time.
An operator also can be required to provide data collection and reporting to support future value limit revisions, provide rules and procedures establishing a legal basis for payment finality (e.g., rules do not provide a basis for sending FIs to reclaim funds from receiving FIs for unauthorized payments (only sending FI has obligation to verify payment authorization, in one example)).
An operator can be required to support FI processes that prevent errors in sending payments, and for the transmission of messages requesting a return of funds and responses to such requests. An operator can be required to provide utilities to reduce sending errors (e.g., duplicate checking), operate inter-FI settlement, and establish and manage exposure limits for participating FIs.
An operator also can be required to act as a token services provider (TSP), and support third-party token vaults and FIs acting as their own token vaults, or work with a third party service to do so. An operator can be required also to provide centralized fraud and AML monitoring to complement processes at participating FIs. Additionally, an operator can be required to coordinate with international standards groups and payment system operators in other countries to ensure compatibility with the system 100, and to provide immediate transmission of payment status messages, and real-time access to payment status information to FIs. An operator also can be required to provide centralized fraud and AML monitoring to support receiving FI decision-making.
The network 130 also can have various capabilities, in example embodiments herein. For example, the system can support for frequent intraday net settlement, including evening and weekend settlement, and have an ability to apply limits on settlement exposure on an individual FI basis, including the ability to reject or suspend payments submitted by FIs that have reached their limit, and notify FIs that are approaching limits.
The network 130 also can have an ability to administer a pre-funded settlement pool, an ability to process and route tokenized payments and other messages, and an ability to route payments based on either alias or RT/Account Number. The network 130 also in one example can support any type of character-based alias (not just a telephone number of email address), and have an ability to accommodate an alias registry, registry maintenance, and unambiguous routing for multi-owner accounts and multi-account owners.
The network 130, in one example, also meets standards for data security and privacy protection appropriate for a retail payment market utility, has an ability to reject transactions that exceed a system-wide limit on the value of transactions, an ability to change the value limit, and an ability to establish different limits by type of payment.
Moreover, the network 130 can employ message formats that carry all data required for regulatory compliance, and employ tokenization in a manner that does not obscure data required for risk management and compliance such as anti-fraud, anti-money laundering, and OFAC/sanctions compliance. Message formats and processes can be globally compatible, and in one example are in accordance ISO 20022 message formats. The network 130 also can support real-time delivery of payment status information to and from FIs, including payment messages, and ACK/NAC and disposition messages (success, fail or pending).
Also, various elements of the system 100 may be required, in one example herein, to comply with certain business rules for real-time exchange of financial and non-financial messages that support a variety of use cases. For example, sending FIs can be required to adhere to standard formats and usage rules for payment and non-payment messages, receiving FIs can be required to make all relevant information from payment and non-payment messages available to receivers, and receiving FIs can be required to act on administrative messages. FIs also can be required to create products, services and processes to create, deliver, and respond to payment, non-payment, and administrative messages.
Security
The system herein has robust security capability that limits the ability to initiate payments, non-payment messages, and access to data to only authorized persons or applications. This reduces exposure to fraud or data breaches, and prevents incidents that undermine trust in the payments system. Security can be multi-factor, multi-layered security for immediate payments, and any participating FI should meet minimum access standards based on industry standard security principles.
Preferably, the system herein has mechanisms that limit the ability of unauthorized persons or applications to initiate payments, non-payment messages, and access data, so as to reduce exposure to fraud or data breaches. This can prevent incidents that undermine trust in the payments system. In one example embodiment herein, multi-factor, multi-layered security is provided to protect immediate payments, participating FIs meet minimum access standards based on industry standard security principles. Authentication and payment authorization can be provided. Authentication verifies that a payer is an actual authentic payer and has access to account. Payment authorization verifies that authenticated payer is making a true payment, and provides non-repudiation protection for FIs. Existing authentication standards can be employed, such as, for example, FFIEC guidelines, OCC guidelines, NIST CyberSecurity Framework and various standards, or FISMA. Assessments and certifications also can be employed, such as, for example, SOC1/SOC2 assessments, shared assessment SIG & AUP, ISO27001 certifications, SSAE16 certifications, penetration tests and 3rd party attestations. Authorization ensures that sending financial institutions have taken adequate measures to ensure that every payment submitted to the real-time payment system is duly authorized by an authenticated customer. Authentication provides verification that a payer is whom they claim to be and should have access to an account, and can include multi-factor authentication with secure tokens, or other automated fraud management.
Threats and countermeasures are constantly evolving. As such, it is possible that a static standard may become obsolete. Thus, security involves more than just payments initiation. For example, in a credit push system, the sender's financial institution may be required to verify the identity of the sender. Typically, a sender's FI (particularly in a credit push scenario) is in the best position to verify a sender's identity because of the existing relationship therebetween and “know your customer” obligations. A sending FI generally bears possible liability for unauthorized transactions and therefore has an incentive to employ effective online and mobile banking security.
According to an example embodiment herein, participating FIs should meet a minimum level of security and privacy protection appropriate for a retail payment market utility. The payment system may include FIs that receive but do not send payments.
The system also can have certain operating rules and procedures, such as, for example, rules that reference external security and privacy standards, rules requiring that all FIs meet data protection standards, and that sending FIs meet rigorous standards for sender authentication and payment authorization. Compliance with security and privacy standards preferably is auditable and audited. Security standards do not unnecessarily restrict usability.
With respect to operator requirements, an operator may be required to administer compliance with security and privacy requirements, and, with regard to financial institutions, security and data protection requirements may apply across channels and products, not to a specific payment system.
Tiered Approach to Minimum Requirements Based on Participation
Not all financial initiations may wish to participate in real-time payments at the same level (i.e., some will send and receive real-time payments, while others will only receive). Some institutions will carry greater inherent risk due to participation and volume of payments. In one example embodiment herein, a tiered approach is employed that matches minimum level of requirements with potential for risk within the system. For example, a Tier 2 involves large financial institutions with substantial volume and participating as a sender, and a tier 1 involves small and midsize financial institutions with low to moderate volume and participating as a sender. All Participants in the system may not be sending real-time payments, but may have the capability to receive payments. Tier 2 has a higher level of security, tier 1 has a next, lesser level of security, and the remaining participants may have a lesser level of security.
Minimum requirements for risk control will be associated with the activities that a financial institution is offering and be additive in nature for each increasing level of potential risk. The centralized utility analyzes network level data to identify and report potential fraudulent behavior (e.g., detect anomalous send/receive activity; excessive complaints, etc.). Participating financial institutions should comply with FFIEC guidelines as applied through prudential regulator examination, and to report fraudulent behavior to the operator of the network 130 and/or the sending financial institutions. Participating institutions also should be able to react to alerts from the centralized activity monitoring utility. Participating financial institutions that also send payments also should comply with requirements for all participating financial institutions, have at least a two factor authentication, require registration of customers sending payments, and be able to perform real-time fraud and risk screening for payments being originated. Participating financial institutions that allow customers to make requests for payment should comply with requirements for all participating sending and receiving financial institutions, make warranties and representations that requests for payment are for legitimate purposes, screen and monitor requests for payment initiators, with the ability to identify abusive or fraudulent use, and take corrective actions including suspension of initiator access to the network. Such institutions also should be able to respond to network reports of abuse of requests for payment.
Participating financial institutions that allow for third party payments should comply with requirements for all participating sending and receiving financial institutions that allow customers to initiate requests for payment, make warranties and representations that the third party is abiding by rules for payment origination, apply the same requirements to third party payment services that are applied to financial institutions that send real-time payments and allow requests for payment. Such institutions also should follow FFIEC guidelines regarding third party relationships. The network 130 has an ability to enforce rules against FIs and third parties, including an ability to levy fines and suspend activity on the network. FIs should not allow third parties to originate volume greater than their financial resources can support in the case of third party failure.
Minimum Requirements for all Participating Financial Institutions
Any institution that participates in the system may comply with the following requirements:
In addition to the requirements for all participants in the system, any Tier 1 participants also can be required to meet the following incremental requirements:
In addition to the requirements for all participants in the system and Tier 1 requirements, any Tier 2 participants can be required to meet the following incremental requirements:
In one example herein, support for anti-fraud, anti-money laundering and OFAC/sanctions compliance process is provided. For example, payment system requirements may be such that a message format carry all data required for regulatory compliance, and tokenization may be required to not obscure data required for risk management and compliance such as anti-fraud, anti-money laundering and OFAC/sanctions compliance process. Operating rules and procedures may require that a sending FI provide data required for regulatory compliance by a receiving FI, and operator requirements may provide centralized fraud and AML monitoring to complement processes at participating FIs.
Moreover, financial institutions may be required to establish policies and processes to obtain data required for regulatory compliance in the payment initiation process, and automated anti-fraud screening may be required to meet expectation to accept or reject payments in seconds or minutes.
Fraud Prevention and Mitigation
Various types of fraud may happen in a credit push system, such as, for example, an account take over, money mule operations, fraudulently inserted payments, fraudulent solicitations (e.g., spam, phishing, credential stealing malware etc.), or other types of fraud. Fraud detection can be provided at the ACH network, financial institutions, and/or third party processors, and can occur in flight/real time, by post hock analysis and detection, or by holding transaction/message records for analysis.
In one example embodiment herein, anti-fraud functions are performed centrally, such as at the ACH network 130. The network 130 can process data that is central in the system, versus at end points (sending and receiving financial institutions). Patterns of activity that are not apparent at an end point (e.g., money mule operations, network fraud schemes, etc.), can be detected. The network 130 also can be a centralized utility that provides offerings for financial institutions that choose not to perform complete anti-fraud in house, and can perform analytics/business intelligence to support fraud prevention.
Security and Fraud Mitigation
Security and risk management requirements are associated with specific real-time payment activities, such as receiving real-time payments, sending real-time payments, allowing customers to send request for payment messages, providing access to third party payment service providers to send real-time payment, and providing a real-time payment directory service. With the exception of receiving real-time payment, there is no existing framework that can be utilized to define all security requirements for financial institutions offering that service. As such, there is a need to establish a governance process for creating, maintaining, updating, monitoring, and enforcing security requirements.
Example embodiments described herein can mitigate fraud by employing a centralized utility (e.g., ACH network 130) that can analyze network level data to identify and report potential fraudulent behavior to origination and receive points, and enable the exchange of information between financial institutions regarding fraudulent activity. Also, in one example herein, a tiered approach is taken to address threats, based on participation. For example, financial institutions may not participate in real-time payments at the same level (e.g., some may participate at a level where by both can send and receive real-time payments, while others will only receive such payments, and some institutions may carry great inherent risk owing to participation level and volume of payments covered). As such, risk control may be associated with the activities that a financial institution is offering and be additive in nature based on level of participation.
Preferably, the centralized utility (e.g., network 130) that analyzes network level data to identify and report potential fraudulent behavior can detect anomalous sending and receiving activity with alerts to the financial institutions that are impacted, perform velocity checks on origination, receive, and request for payment volumes, and be able to detect patterns that indicate potential network fraud or money mule activity. To address fraud mitigation needs of a real-time system, the centralized utility can analyze network level data to identify and report potential fraudulent behavior to origination and receive points, and serve as a platform to allow for the exchange of information between financial institutions regarding fraudulent activity.
Preferably, the utility also can provide alerts with reason codes upon the detection of anomalous activity for impacted financial institutions, provide access to network data to augment financial institution fraud detection and risk management, and perform fraud analytics to provide regular fraud reporting to participating financial institutions. Also, preferably the utility can track complaints of excessive abuse of request for real time payments and send notification to a receiver's FI, can support the exchange of reported fraud incidents among financial institutions, and can provide payment data elements to support receiving FI risk management, such as by providing data on origination channel and device ID, and accommodating geolocation data for a sender. The utility preferably also can provide data to support sending FI risk management, such as, for example, data specifying an age of receiving accounts.
Participating financial institutions may be required to comply with FFIEC guidelines as applied through a regulator examination, report fraudulent behavior to an entity responsible for the ACH network 130 and/or to sending financial institutions, and react to alerts from a centralized activity monitoring utility.
Participating financial institutions that also send payments also may be required to comply with requirements for all participating financial institutions, have a minimum of two factor authentication (as defined through a real-time payments governance process), require registration of customers sending payments, conduct real-time fraud screening for payments being originated thereby, have a capability to assign risk based sending value limits to customers, and avoid the use of including active hyperlinks (as defined by a real-time payments governance process) in payment and non-payment messages.
Also in one example herein, participating financial institutions that allow customers to make requests for payment must comply with requirements for all participating sending and receiving financial institutions, make warranties and representations that requests for payment are for legitimate purposes, comply with requirements similar to those for origination of ACH debits (determined through a governance process), and financial institutions must be able to respond to network reports of abuse of requests for payment, and have the ability to suspend users' access to the network.
Participating financial institutions that allow for third party payments may be required to comply with requirements for all participating sending and receiving financial institutions that allow customers to initiate requests for payment, provide warranties and representations that the third party is abiding by rules for payment origination, apply the same requirements to third party payment services that are applied to financial institutions that send real-time payments and allow requests for payment (as applicable), and follow FFIEC guidelines regarding third party relationships. Additionally, such financial institutions also should have a capability to enforce rules against FIs and third parties, including an ability to levy fines and suspend activities on the network. The financial institutions also should not allow third parties to originate volumes greater than their financial resources can support in the case of third party failures.
Security measures also can be taken regarding requirements for directory services. As an example, it may be required that a directory service cannot store account information (i.e., it should store tokens only), and have a robust entry maintenance process to ensure that entries are reliable and updated on a timely basis. Ideally, directory services have the ability to allow customers to change their alias affiliation through their registrars, aliases can be registered only in the directory through a financial institution or third party sponsored by a financial institution, and the registrar is responsible for maintaining aliases by providing a process to verify the identity of an alias owner, and by providing warranties and representations that aliases are associated with correct accounts. Preferably, directory access is restricted to financial institutions for the purposes of routing payments (i.e., no direct third party is permitted access to the directory), and industry standard data protection is complied with as it applies to financial institution data processors. Other requirements may include that the directory service must be able to provide the name and address of the receiver to the sending FI to support error prevention, risk management and regulatory compliance (e.g., OFAC screening, AML), and must have a robust entry maintenance process to ensure that entries are reliable and updated on a timely basis.
The payment system herein is useful in that, in one example embodiment herein, it processes credits only versus debits, and thus privacy protection is maintained. A transaction is generated and sent through the ACH network 130 from a sending institution upon that institution receiving instructions from a payer, and only if the payer has sufficient funds available to cover the transaction value and has been duly authenticated (e.g., at the sending financial institution).
The use of a credit “push only” model addresses funds availability and risk management concerns (e.g., insufficient funds, payment authorization, multi-party authentication, PCI, etc.), and offers transparency and control for end users. Any case can be addressed by credit push, such as, for example, a business to person application, a person to person application, a person to business application, and a business to business application. In one, non-limiting example embodiment herein, debits are not employed in the method herein because current debit and credit card payment systems work well for existing debit use cases, and requests for payments followed by credit transfer might be a superior form of debit. A credit transfer system is inherently safer than a payment system that allows a payee to debit a payer. Even if hacked, the amount vulnerable is limited to merely the amount of funds in each account.
In the system herein, a debit capability can be emulated using a request to pay from a payee to a payer, wherein the payee initiates a request for payment from the payer, the payer receives a notification of the request for payment and authorizes a credit transfer to the payee. This approach gives the payer a level of control over the payment process. A credit push only model addresses funds availability and risk management concerns. For example, for a sending institution, there is a risk that a fraudulent transaction is attempted to be initiated by a fraudster. The sending bank can verify that there are sufficient funds available to cover the transaction, and that the payer has authenticated itself. In a debit pull situation, on the other hand, a bank initiating a transaction for a payee does not necessarily know the payer, or whether the payer has funds sufficient to cover a transaction. Also in a debit pull situation, advanced fraud protection mechanisms typically cannot be employed (e.g., transaction analytics, pattern recognition, etc.). Funds also are not made immediately available.
As described above, in one example embodiment the system has the ability to send or receive payments on a 24/7 basis, provides immediate notification to senders and receivers, immediate fund availability to recipients on a 24/7 basis, and employs an extensive set of payment and non-payment messages. The system provides payment certainty for receivers, a process to request the return of erroneous payments, and, in one example embodiment, also employs value limits on transactions updated periodically based on predetermined criteria. Settlement is performed in a manner that mitigates material risk of loss, and preferably tokenization of all account data is employed such that payments can be initiated using an alias accounting/routing number. A threshold level of security can be required to provide privacy protection of all participating financial institutions.
Real-Time Payments—Immediate Availability of Funds for Receivers
In one example embodiment herein, a receiving FI can be required to make payments available immediately to the extent possible, and to comply with all applicable laws (e.g., AML, OFAC) and necessary risk management processes (fraud monitoring). For example, funds can be made available immediately, within seconds, minutes, hours, multiple times daily, at the end of the day, and can be tied to settlement, in some embodiments. Availability exceptions are a small fraction of total payments. This provides consistent expectations for payees and payers, allows for an expanded number of use cases, and limits confusion for payers and payees. Pre-screening transactions at the network level can minimize exceptions (e.g. AML, OFAC, fraud suspects), and notifications can be provided to payees for transactions that cannot be immediately screened.
Transaction Value Limits
In one example embodiment, payment value limits are employed to mitigate risk. For example, a pre-determined value limit on transactions is employed to limit exposure to credit or liquidity risk between sending and receiving banks. This has the advantage of limiting the amount of credit, settlement, and/or liquidity risk, and reduces potential risk from fraud events.
System-wide transaction value limits (e.g., $25,000) can be employed based on risk tolerances of institutions and research into use cases. Sending FIs also may impose limits (e.g., lower limits) per day or per transaction or on some other predetermined basis. In one example, a receiving FI cannot impose a lower limit on its receivers, and there is a process for updating limits based on objective criteria, such as, for example, periodic evaluations (e.g., analyzing transaction data, model settlement risk, survey unmet needs, etc.), and automatic triggers are employed when limits are exceeded (e.g., transaction thresholds, loss rates, or the like). In example embodiments herein, payment transactions can be evaluated at a sending and/or receiving FI, at the ACH network 130, and/or at another element of the system 100, to determine whether a payment amount specified in the transaction equals or exceeds the limit. If the limit is equaled or exceeded, then the evaluating element can provide an alert indicative thereof to the sending and/or receiving FI or another element of the system 100, and, in one example embodiment herein, the transaction is discontinued/not effected.
FIs also may manage sending limits based on, for example, customer segments and use cases, structuring of multiple transactions to circumvent limits, and overall customer activity. In certain countries, certain value limits are employed. For example, Poland employs a limit at $27,500 or 100,000 zt, in Japan transactions over $842,500 or ¥100 million are diverted to real time gross settlement, and in South Africa there is a limit of $430,000 or ZAR 5 Million until 16:00 hr, and $21,500 or ZAR 250,000 during non-business hours. In the UK there is a limit of $155,00 or £100,0001.
Setting a payments limit mitigates exposure to fraud, credit, and liquidity risk while still enabling customers to benefit from real-time payments. A limit on transactions can help prevent minor errors and challenges associated with new systems. A limit also can mitigate credit/liquidity risk for banks and reduce fraud risk. An initial limit of, for example, $25,000 allows most customers to benefit from real-time payments as follows:
Limits can be raised incrementally where deemed appropriate.
Settlement and Settlement Risk Mitigation
Effective settlement risk management mechanism(s) ensure that a payer has funds available to settle a transaction/credit to a payee (e.g., pre-funding or funds not available to payee until after settlement). Such management is useful because it provides improved customer experience in the event of a FI failure, fraud, etc. Such a mechanism decreases a receiving financial institution's risk, and insures overall integrity and trust of the payment system. Settlement cycles can be at predetermined time, such as, e.g., the end of day, multiple times/day, in real-time, etc. Interbank settlement should effectively eliminate material risk to receiving FIs that sending FIs will not meet their obligation to settle. For net settlement systems, there should be reduction of risk associated with unsettled debit positions. Settling more frequently can limit the build up of large unsettled debit positions.
According to an example aspect herein, FI settlement accounts are pre-funded. Prefunding of settlement pools mitigates the risk of unsettled positions. Also, different settlement mechanisms can be employed for large credit worthy FIs versus smaller and non-credit worthy FIs.
There are several models for settlement management that can be considered while balancing funds availability needs. For example, in a PIN/Debit system, funds in a payer's account are captured immediately, and may become available in a payee account in 2-3 days. Settlement typically occurs one time per day. In Japan, real-time funds availability is provided, as is end of day settlement for non-RTGS payments (over maximum value). In Korea there is immediate fund availability, and deferred net settlement (next day). In India there is real-time funds availability, and end of day net settlement. In China there is funds availability within 20 seconds, and deferred net settlement. Each of those is a daily settlement model.
Multiple per day settlement models also exist. For example, with respect to funds availability, in Chile a receiving bank must respond within 10 seconds, and there are settlements two times per day through RTGS. In Sweden there is near real-time (within 15 seconds) funds availability, and multiple deferred central bank settlements per day. In South Africa funds availability is within 60 seconds, and there is deferred net settlement (hourly during the business day). In Denmark, funds availability is in near real-time (1-10 seconds), and there is Net, intraday settlement. Singapore has near real-time (seconds) funds availability, and deferred settlement 2 times per day (with intention of increasing cycles as system matures). In the United Kingdom for funds availability there is 15 second confirmation, posting within 2 hours, and deferred net settlement, 3 times per day.
Real Time settlement management systems also exist. For example, in Brazil 97% of funds are released in less than one minute, and there is continuous net settlement. In Switzerland there is purported real-time funds availability and real-time settlement. In Mexico funds availability occurs within a maximum of one minute and 5 seconds, end-to-end. Poland has near real-time (seconds) funds availability, and immediate settlement.
In one example embodiment herein, the real-time payment system employs pre-funding of accounts and net settlement, with multiple settlements per day to mitigate the build-up of unsettled positions, although this example is not limiting. Indeed, other types of settlement can be employed, such as, without limitation, any of the types represented in
As pointed out above, settlement herein can employ a hybrid approach to mitigate risk of default, including a pre-funded account and allowance for qualified FIs to carry an unfunded net debit position. Regarding prefunding, financial institutions (e.g., 111 and 120) can deposit a full or partial settlement obligation amount in cash into one or more settlement accounts prior to a clearing, and the pre-funded balance is used to settle net positions at scheduled times. The account(s) can be maintained by, for example, a settlement facility such as facility 134 or service 133, or at another location. With respect to a multilateral net debit cap, in one example herein there is a limit on the net unfunded settlement position for participating FIs across all counterparties, and the net unfunded settlement position is the amount by which the net debit position exceeds an FI's balance in the pre-funded settlement account. Clearing can be suspended when the net unfunded debit position reaches the net debit cap. Also, in one example herein the limit is based on credit risk criteria pre-established through, for example, a governance process. It may happen that an FI may have a zero net debit cap, which means that the FI must pre-fund its entire settlement position. Conversely, if an FI has a zero balance in the pre-funded settlement account, its multilateral net debit cap represents its entire settlement capacity. FIs can deposit funds into the pre-funded settlement account to initiate payments that exceed their net debit cap. Loss-sharing agreements can be employed wherein remaining participants cover losses in the event of a settlement default; for example, a loss sharing formula established through governance process.
Thus, as can be understood in view hereof, and referring to
Also, in accordance with an example embodiment herein, in the case of multiple settlements, the frequency thereof can be determined to avoid a predetermined level of unsettled net debit positions on the part of FIs, and to prevent large unfunded positions. For example, the settlement service 133 and/or settlement facility 134 can evaluate whether the unsettled positions of all participating FIs, or a subset thereof, exceeds a predetermined threshold (e.g., 10% of the FIs have unsettled debit positions exceeding a predetermined threshold amount). If the threshold is exceeded, then the service 133 and/or facility 134 can increase the frequency at which settlements occur and/or schedule and conduct one or more additional settlements that were not previously scheduled. In the event losses occur owing to one or more FIs not funding their unfunded positions in time, then the losses can be shared (funded) between multiple FIs, based on predetermined criteria.
Funding Agent
When a transaction between two participants is placed onto the Automated Clearinghouse (ACH) network 130 to effect a real-time payment, a position for each of the participants is recorded by the settlement services system 133. Upon the transaction clearing, one participant is debited and the other is credited. At that point the transaction has settled. A participant that is funding the prefunded balance account with a balance is referred to herein as a funding participant. To back up the settlement of the transaction the participant's funding agent is required to deposit monies in a joint account owned jointly by one or more funding agents and one or more funding participants. In some embodiments, a funding participant is a participant that has become a party to the prefunded balance account agreement with a bank that holds the prefunded balance account and that (i) requests and receives disbursements from the prefunded balance account, as permitted by operating rules, to its account and (ii) if the participant is a sending participant, prefunds for itself in accordance with the applicable participation rules and/or operating rules.
A funding agent is a depository institution that (i) has become a party to a prefunded balance account agreement and (ii) serves as an agent to one or more non-funding participants to (A) provide the prefunded requirement and supplemental funding on behalf of such non-funding participant and (B) request disbursements as permitted by operating rules for each of its non-funding participants. More generally, a funding agent funds and manages a participant's positions in the real-time payments network, e.g., ACH network 130, on behalf of the participant (e.g., adding liquidity or subtracting liquidity).
Settlement in a real-time payment system network such as ACH network 130 is effectuated through entries on a ledger and fully backed by the balance in a prefunded balance account, thereby making settlement the practical equivalent of settlement in central bank money. Participants can fund ledger positions and receive disbursement of excess network liquidity through, e.g., FedWire® funds transfers. The FedWire® funds transfer system is a real-time gross settlement system of central bank money used by Federal Reserve banks to transfer funds electronically between member participants. While the prefunded balance account is with, e.g., a Federal Reserve bank, the positions are held on the ACH network 130 (e.g., in settlement services system 133). In addition, the transfer of funds is ultimately controlled by the settlement services system 133 component of the ACH network 130.
Each participant has a position on the ACH network 130. However, participants have the need to manage their positions on the ACH network 130 and their prefunded balance. Some participants may not have the ability to effectively manage their own position on the ACH network 130 or their prefunded balance because the balance is constantly changing, making their accounts difficult to maintain, track and administer their positions.
According to some embodiments, a funding agent facilitates the liquidity of the participation of members in network 130.
Prior to processing each credit transfer made by a participant, settlement services system 133 checks the position of each participant and determines if the participant has sufficient liquidity to make a payment. If the participant does not have sufficient liquidity to make the payment it can increase its position. A participant can only increase its position by either receiving credit transfers or providing initial or supplemental funding into the prefunded balance account, such as via a FedWire® system. It should be understood that other mechanisms for one FI to move liquidity to another FI can be used and still be within the scope of the invention, such as Payments Clearing and Settlement (PACS) which is an XML messages used between banks that is defined in the ISO 20022 standard (e.g., via PACS.009 messaging). In an example implementation, each initial or supplemental funding wire communication includes an identifier of the participant referred to as a participant identifier (ID). The participant ID is a prestored identifier that is used to ensure the supplemental funding wire is applied properly. As described above, under the funding manager model 4602, the funding manager (i.e., funding agent) must provide sufficient prefunded balance to cover the funding position of each non-funding participant.
A tracking position is a position associated with a linked participant that is checked upon every transaction to ensure that the linked participant has sufficient access to liquidity to cover a transaction amount. More details as to how a determination is performed on each transaction between participants to determine if the linked participant has sufficient liquidity to cover a transaction amount are described in more detail below.
Under the funding provider model 4604, also referred to as a full funding agent solution, each participant, participant 1, participant 2, . . . , participant n, will still have its own position (position 1, position 2, . . . , position n, correspondingly). However, the settlement services system 133 can distinctly maintain and track multiple positions of participants against one current prefunded position owned by the funding agent and representative of the liquidity of the funding agent.
Current Prefunded Position=Opening Prefunded Position+Net Position+supplemental funding+disbursements, (1)
where the net position is the sum of all credit transfers sent and accepted or accepted without posting and all credit transfers received and accepted or accepted without posting by a funding participant or a linked participant. As described above, a linked participant is a non-funding participant that is linked to a funding agent through the settlement services system 133 such that the participant can leverage a current prefunded position of the funding agent.
Generally, a current prefunded position (CPP) of the funding agent is obtained and checked. The CPP position is affected by a) the opening prefunded position/balance of funding agent, b) activities of the funding agent (e.g., supplemental funding and disbursements made by the funding agent), and c) net position. The settlement services system 133 will make a determination whether the CPP of the funding agent is greater than a transaction amount. If the CPP of the funding agent is not greater than the transaction amount, then it will reject the transaction. If the CPP of the funding agent is greater than the transaction amount then it will approve the transaction if the transaction would otherwise be approved.
Referring still to
The funding agent will have its own current prefunded position, minimum prefunded requirement, and watermarks, similar to how a self-funded position of a participant is managed and tracked.
In turn, a determination is made at step 4616 whether the funding agent CPP is greater than or equal to a transaction amount of the transaction determined to be initiated at step 4612. If a determination is made at step 4616 that the funding agent CPP is less than the transaction amount the transaction is rejected. If a determination is made at step 4616 that the funding agent CPP is greater than or equal to the transaction amount then at step 4617 a determination is made whether executing the amount of the transaction would cause the participant to exceed its tracking position limit (TPL). If a determination is made at step 4617 that executing the amount of the transaction would not cause the tracking position of the participant to exceed the tracking position limit of the participant, the transaction is approved. If a determination is made at step 4617 that executing the amount of the transaction would cause the tracking position of the participant to exceed the tracking position limit of the participant, then the transaction is rejected. It should be understood that steps 4616 and 4617 can be performed in reverse order and still be within the scope of the invention. The transaction must be within the funding agent CPP and the non-funding participant TPL. If a determination is made that the transaction is within the funding agent CPP and non-funding participant TPL (as per steps 4616 and 4617) then the transaction (e.g., credit transfer sent by a linked participant to another participant) will be approved by the settlement services system 133 if the transaction would otherwise be approved, as shown in step 4618. The positions are updated for both a funding agent prefunded position and the individual positions of the non-funding participant(s), as shown in step 4619.
The added functionality that the full funding agent mechanism of the settlement services system 133 brings is that each linked participant will have its individual position, (i.e., the “tracking position” of the participant) tracked against the overall current prefunded position of that funding agent.
The performance of the one or more actions enables enhanced and automated tracking of the current prefunded position of a funding agent and the individual positions of the linked participants which increases the capacity of the available funds to participants and has the added effect of stabilizing the network by reducing, for example, the number of communication transmissions required to notify the various operators of rejections because such rejections will be minimized. Moreover, fewer transactions will fail because there is less demand on liquidity as a result of the improved ACH network 130, particularly by use of the a settlement system 133 to manage the positions of participants. This means that the other data which is used to check against the positions of the participants according to the processes described herein are of enhanced relevance and are received, output and stored at significantly improved rates with fewer rejections. In other words, aspects of the embodiments described herein provide throughput and processing of data and speed of data selection in the ACH network 130 that is significantly enhanced. The data which is automatically received, processed and output according to the processes described herein can thus be pre-emptively obtained and stored within a computer, or transmitted to the computer, such that the selected data is immediately accessible and relevant to a local user of the computer.
In some embodiments, funding agents have the ability to manage access by each participant to the current prefunded position of the funding agent. In addition, the funding agent can set (and update at any time) a tracking position limit for each linked participant. Referring again to
Funding Agent Setup
In an example implementation, a funding agent can be created or managed through a management portal either through a web browser running on a station connected to the network of the funding agent or settlement services system 133 via ACH network 130 or other software loaded onto a station that is in communication with the funding agent network or settlement services system 133 via ACH network). The funding agent that has been created can be edited and managed through the management portal as well. Funding agent attributes, include but not limited to:
In some embodiments, the watermark format and values for a funding agent have no impact or restriction on the watermark format or values for a linked participant.
Once a funding agent is entered into the settlement services system 133 via the Automated Clearinghouse (ACH) network 130 (e.g., by, for example, an operator of the ACH network 130), it will have a default current prefunded position, for example, of $0. In some embodiments, the funding agent can create watermarks and set the TPL thereafter.
Funding In and Out of an Account
Each funding agent has the ability to optionally indicate a single participant for which a supplemental funding is being submitted, as shown in step 4664. If a participant is indicated, at step 4665 the participant ID is sent from the FWI to the settlement services system 133 via the real-time payments system 130 so that the position of the participant in the settlement services system 133 can be incremented by the amount of the initial or supplemental funding.
The update to the tracking position (TP) for a linked participant is depicted in step 4666. In addition to the update (step 4666) to the tracking position of the linked participant, the current prefunded position of the funding agent is increased by the amount of the request. Following successful completion of the initial or supplemental funding request, real-time payments system 130 will send a prefunded balance change notification SNM (e.g., via ACH network 130) to the funding agent, as shown in step 4667.
The linked participant will also receive a prefunded balance change notification SNM (e.g., via ACH network 130) in this case to notify the linked participant that its tracking position has been updated, as shown in step 4668.
A funding agent can also issue a disbursement through the settlement services system 133, as shown in step 4669. A funding agent has the ability to withdraw funds from its current prefunded position up to the value of the minimum prefunded requirement of the funding agent. A funding agent user with the proper permissions can request a disbursement through a management portal of the real-time payments system 130 in the same way a disbursement request is handled for a participant. A disbursement request causes the settlement services system 133 to perform checks on the positions of the funding agent and the participant associated with the disbursement, as shown in step 4674. The funding agent account ID and beneficiary account ID are passed in the disbursement request to the FWI. Settlement services system 133 will receive the disbursement status as shown in step 4670. Following successful completion of a disbursement request, real-time payments system 130 will send a prefunded balance change notification SNM to the funding agent, as indicated by step 4673C.
Each funding agent has the ability to optionally indicate a single participant for which a disbursement is being executed. If a participant is indicated, the participant ID is sent to FWI for inclusion in the wire to the participant. In addition to the current prefunded position of the funding agent being decremented, upon successful completion of the disbursement request, the participant tracking position is decremented by the amount of the disbursement request (applicable to each participant). Following successful completion of the disbursement request, settlement services system 133 (via real-time payments system 130) sends a prefunded balance change notification SNM to the funding agent as indicated by step 4673C. The linked participant receives an SNM in this case to notify the linked participant that its tracking position has been updated, as indicated by step 4673B or 4673A as the case may be.
Each disbursement will update both the tracking position of the linked participant and the current prefunded position of the funding agent automatically, as shown in step 4672.
A system operator with the appropriate permissions can execute a drawdown on behalf of a funding agent. This functionality is available for a participant as well.
A system operator with the appropriate permissions can perform a manual adjustment for a current prefunded position of a funding agent. This functionality is available for a participant's position as well.
Funding Agent—Transaction Processing
A funding agent can have a current prefunded position according to equation 1 described above, where net position is the sum of the net positions of the linked participants of the funding agent. For clarity, all supplemental funding and disbursements performed by the funding agent, whether or not a participant ID of a linked participant is included, will impact the current prefunded position of the funding agent.
Each transaction sent or receive by any linked participant will update the net position of the funding agent. For transactions sent between linked participants using the same funding agent, the net position will not change. Each participant using a funding agent (linked participant) will have a tracking position which is the net position (sum of transactions sent and ACTC (AcceptedTechnicalValidation: Authentication and syntactical and semantical validation are successful) or ACWP (Accepted without Posting: Payment instruction included in the credit transfer is accepted without being posted to the creditor customer's account) and transactions received and ACTC or ACWP) of the individual participant for the current reconciliation window plus any initial or supplemental funding and disbursement requests.
For each transaction sent/received and accepted or accepted without posting by any participant using a funding agent, the tracking position of the participant is decremented/incremented accordingly and recorded in the settlement services system 133. Each transaction will also result in the current prefunded position of the funding agent increasing/decreasing in the same amount as the tracking position of the linked participant, unless the transaction is between two linked participants using the same funding agent.
Each credit transfer will update both the tracking position of the linked participant and the current prefunded position of the funding agent automatically. Information or updated information on the settlement services system is made available to these updates by the corresponding participants and funding agent (e.g., in the form of a notification or providing access to the information stored in the settlement services system 133). If either of these updates fails, the credit transfer will not be completed by the system. Such a scenario will generate an alert indicating that describes the specific failure condition whether the tracking position could not be updated or the current prefunded position could not be updated. For a participant using a funding agent, transaction processing logic must be updated such that the system permits a payment to be sent to a creditor FI if: 1. the funding agent of the debtor FI has sufficient funds in its current prefunded position to cover the amount of the payment; and 2. The tracking position of the debtor FI will not breach the FA configured tracking position limit for the participant.
If for any given transaction, the current prefunded position of the funding agent is not sufficient to cover the transaction, real-time payments system 130 will reject the message with a reason code indicating that the funding agent did not have funds to cover the transaction (also referred to as a “new reason code”).
If for any given transaction, the tracking position of the participant would breach the tracking position limit for the participant, real-time payments system 130 will reject the message with a reason code indicating that the participant did not have funds to cover the transaction (also referred to as an “existing reason code”).
In some embodiments, the funding agent will receive an SNM notifying the funding agent of the reject due to their insufficient liquidity. In some embodiments, an SNM will be sent to both the participant and the funding agent to notify the relevant parties of the failure.
Funding agent can obtain its current prefunded position in near real-time. This can be achieved in multiple ways. For example, 1. the funding agent will have access to a funding agent dashboard that includes information regarding the opening balance of the funding agent, the current prefunded position of the funding agent, and the net position of the funding agent. Additionally, a list of liquidity related alerts of the linked participant (e.g. low watermark breach warning, available prefunded balance warning, etc.) and summary information on the current day's credit transfer activity will be displayed on the FA dashboard; and 2. funding agent will have access to a near-real time feed of transaction information for transactions performed by linked participants.
In some embodiments, application programming interfaces (APIs) can be used to allow the funding agent to obtain real time balances machine to machine instead of having to log on to a console or rely solely on alerts.
If a transaction causes the current prefunded position of the funding agent to fall below its low watermark, real-time payments system 130 can send a watermark notification to the funding agent to notify the funding agent of the event.
If a transaction causes the current prefunded position of the funding agent to rise above its high watermark following a low watermark breach, real-time payments system 130 sends a watermark notification to the funding agent to notify the funding agent of the event.
If a transaction causes a tracking position of a participant to fall below the low watermark of the participant, real-time payments system 130 sends a watermark notification to the participant and the funding agent. If a transaction causes a tracking position of the participant to rise above the high watermark of the participant following a low watermark breach of the participant, real-time payments system 130 sends a watermark notification to the participant and the funding agent.
Funding Agent Access to Participant Information and Controls for Participant Position
In some embodiments, a funding agent has the ability to view the tracking position of each linked participant at any given point in time. A funding agent also has the ability to extract and download a file (and/or use an API call) that includes each tracking position of each linked participant at any point in time.
A funding agent also has the ability to configure the tracking position of each linked participant to reset to zero at the beginning of each reconciliation window or to remain at the closing tracking position from the previous reconciliation window.
Funding Agent Management of Participant
In some embodiments, the tracking position of individual participants linked to a funding agent cannot be manually adjusted by the funding agent. This tracking position will only be impacted by sending/receiving transactions; when a funding agent initiates a disbursement request or supplemental funding that indicates a specific participant to which the request applies; or at the beginning of a reconciliation window if the participant is in “reset” tracking mode.
A funding agent also has the ability to set a tracking position limit for each linked participant. The tracking position limit will serve as a limit to how much below zero a single participant's tracking position can fall before transactions are rejected. In an example implementation, the tracking position limit of each participant will be set, as a default, at $25,000. A funding agent may change the tracking position limit at any time to any value greater than or equal to $0. A funding agent cannot set the tracking position limit such that the linked participant is required to hold a positive tracking position in the system.
In some embodiments, the sum of all of the tracking position limits of the linked participants of a funding agent divided by the minimum prefunded requirement of the funding agent will not exceed the tracking position limit multiple of a funding agent.
In some embodiments, a funding agent is not permitted to extend a tracking position limit of a participant to an amount that would put the funding agent out of compliance with this rule.
In an example implementation, when a system operator updates a tracking position limit multiple of a funding agent, real-time payments system 130 notifies the funding agent by transmitting an SNM. For example, the funding agent will receive notification (via an SNM) if a change is made to the STL or SITL.
Reconciliation and Reporting
At the end of each reconciliation window, the tracking position of each linked participant will be reset to zero (unless otherwise indicated by the funding agent). In some embodiments, the funding agent can evaluate each of current tracking position limit of its participant and adjust each tracking position limit accordingly.
At the end of each reconciliation window, the funding agent will receive an SNM with a summary of the information for its current prefunded position during the previous reconciliation window. Volumes and values in the report are the sum of all transactions sent and received by all linked participants. In some embodiments, each linked participant will receive an SNM related to its tracking position as per existing functionality.
In some embodiments, the funding agent will receive standard reconciliation reports (e.g. detailed reconciliation report) and daily reports (e.g., volume and value report, reject report, etc.) related to each linked participant and also to the current prefunded position as a whole of the funding agent.
In addition, a funding agent can receive a summary level report (looks like participant reconciliation report, but with multiple entries, one per linked participant) that shows the funding agent's opening and closing positions, all successful supplemental funding and disbursement requests, and the net position, supplemental funding and disbursement requests associated with each linked participant.
Funding Agent Account Reconciliation Report—Details for all Participant Activity and Funding Activity
In some embodiments, a funding agent can receive a new report (called the tracking position summary report) at the end of each reconciliation window that includes a row for each linked participant and the following information:
In some embodiments, a system operator with the proper privileges can be authorized to manually adjust a tracking position of a participant similarly to how the system operator can adjust a current prefunded position of the participant. In some embodiments, preferably, any manual adjustment to a tracking position of a participant must not also update the current prefunded position of a funding agent.
In some embodiments, a system operator has the ability to manually adjust the current prefunded position of a funding agent similarly to how a system operator can adjust a current prefunded position of a participant.
In some embodiments a system operator has the ability to create/manage users of the real-time payments system 130 management portal for the funding agent.
A system operator has the ability to set a tracking position limit (TPL) multiple on each funding agent. The TPL multiple limits the overall TPL that the funding agent can set for all of its participants. The TPL multiple is compared to the sum of the TPL of the linked participant divided by the minimum prefunded requirement of the funding agent. Preferably the sum of the tracking position limits of the participants tracking position limits divided by the minimum prefunded requirement of the funding agent should not exceed the TPL multiple. Also, in some embodiments, preferably a funding agent is not be permitted to set a TPL to an amount that would allow the funding agent to be out of compliance with this rule. If the TPL multiple is adjusted downward such that the funding agent is out of compliance with an applicable rule, the funding agent is required to adjust its linked participant's TPLs to come back into compliance with the rule. An alert is communicated to the system operator which can be cleared when the funding agent comes back into compliance with the TPL multiple rule. Transaction processing should continue as normal while the funding agent is out of compliance with the TPL multiple rule.
Tokenization
Regarding tokenization, that involves use of a unique code that can only be used to post transactions to an account. It can be useful because a payer does not receive a payee's account data, there is no need for a PCI-type of security for a payer. Tokens are safe even if exposed in a cyber attack. Also, mass payment fraud is more difficult to execute.
Tokenization can be provided in a dynamic versus static manner. Tokenization is a preferred approach to secure mobile and e-commerce payments using credit and debit cards. Tokenization substitutes a limited-use random number (secure digital token) for a customer's account number so that the sensitive information remains safe. Even if compromised, the token is of limited or no use to cybercriminals. Tokenization as used in the example embodiments herein can involve various aspects. For example, one is a dynamic token, in which the token for each transaction is unique rendering the token itself unusable for any other transaction. Another is a static token, wherein the same token is used for multiple transactions, but may be restricted to prevent unauthorized use (e.g., credit only, single merchant). Still another is a domain restriction, that provides further fraud reduction by limiting token use to a certain digital wallet, merchant, channel (e.g., e-commerce), amount, transaction type (e.g. credit or debit) or expiration date. For a token vault, bank (or multi-bank) vaults create tokens, perform customer authentication and provision tokens to digital wallets or directories.
Regarding directory services, by virtue of the directory and use of tokens, senders can initiate payments using an alias (e.g., a phone number, email, or other code, etc.) which is used to retrieve bank routing information from a database. As such, receivers do not need to provide account numbers to senders, and senders do not assume a risk of holding receivers account numbers.
Optional Travel Rule Requirements
Various elements of the system 100 may be required, in one example herein, to comply with certain travel-related rules. For example, a financial institution can be required to include in a transmittal order for any funds for a transfer of $3,000 or more, the following:
A transmittor's financial institution can receive with the transmittal order (from the transmittor):
It also generally applies to bill payments initiated by a business. Such rules can be subject to certain exceptions, such as an “electronic funds transfer” governed by Regulation E (i.e., a transfer that a consumer initiates from his or her account), and situations where both the transmitter and the recipient (i.e., the beneficial recipient of the funds) are any of the following:
The real-time payment system herein is a platform for financial institutions to develop novel, compelling, and commercially viable products and services for their customers. The system is adaptable to meet the changing needs associated with market expectations and risk environments that are prone to change over time. The system supports robust, flexible data models and message types and has an architecture that supports modular service integration. In one example embodiment herein, the system has global compatibility, and, consistent with domestic U.S. requirements, the system adheres to widely used global standards (e.g., ISO 20022) and the processes/conventions used by real-time payment systems in other countries to facility future interoperability, and to ease the implementation burden for multi-national banks and companies.
As described above, the real-time system 100 herein, in one example embodiment, employs “Credit Push” payments where customers can send payments directly from their existing accounts, providing greater customer engagement and transparency than alternative payment services. The system 100 also, in one example, employs standard but extensible message formats, and supports independent product development by financial institutions through powerful, flexible standards while ensuring that the overall end-to-end process is consistent and reliable. Real-time messaging also is provided with “bank-grade” security, in that is provided financial institutions with tools to create a superior customer experience in applications such as mobile banking, P2P transfers, bill payments, just-in-time B2B transactions, etc. The system 100 also uses integrated tokenization and directory services to eliminate need for customers to share sensitive account information or know routing details of recipients. The system 100 thus is fundamentally safer, more-convenient, and more-capable than existing payment systems.
In the foregoing description, example aspects are described with reference to several example embodiments. Accordingly, the specification should be regarded as illustrative, rather than restrictive. Similarly, the figures illustrated in the drawings, which highlight the functionality and advantages of the example embodiments, are presented for example purposes only. The architecture of the example embodiments is sufficiently flexible and configurable, such that it may be utilized (and navigated) in ways other than those shown in the accompanying figures.
Software embodiments may be provided as a sequence of instructions, or software, which may be stored on an article of manufacture, e.g., a computer-readable medium having instructions. The instructions on the computer-readable medium may be used to program a computer system or other electronic device. The computer-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks or other types of media suitable for storing electronic instructions.
The techniques described herein, when performed using a computer system, are not limited to any particular software configuration. They may find applicability in any computing or processing environment. The terms “computer-readable medium” and “memory” refer to any medium that is capable of storing, encoding, or transmitting a sequence of instructions for execution by a computer system and that causes the computer system to perform any technique described herein. Furthermore, it is common in the art to speak of software, in one form or another (e.g., program, procedure, process, application, logic, and so on) as taking an action or causing a result. Such expressions are merely a shorthand way of stating that the execution of the software by a computer system causes the processor to perform an action to produce a result. In other embodiments, functions performed by software can instead be performed by hardcoded modules, and thus the example embodiments herein are not limited only for use with stored software programs. In addition, it is not necessary that processes described herein be performed with a computer system, and instead they can be performed, in whole or in part, by a human operator.
It should be noted that, although described in the context of a healthcare billing and payment environment, the scope of the invention is not limited for use in that environment only, and also can be used for transactions involving other environments as well, including, for example and without limitation, any suitable type of environment involving bill presentment and payment.
Although example aspects have been described in certain specific embodiments, many additional modifications and variations would be apparent to those skilled in the art. It thus should be understood that the example embodiments may be practiced in ways other than those specifically described. Again, the present example embodiments should be considered in all respects as illustrative and not restrictive.
The present application is a continuation-in-part of U.S. patent application Ser. No. 15/200,340, filed Jul. 1, 2016, entitled REAL-TIME PAYMENT SYSTEM, METHOD, APPARATUS, AND COMPUTER PROGRAM, which application claims priority to U.S. Provisional Patent Application No. 62/187,406, filed Jul. 1, 2015, and U.S. Provisional Patent Application No. 62/286,738, filed Jan. 25, 2016, the contents of each of which are incorporated by reference herein in their entireties, as if set forth fully herein.
| Number | Name | Date | Kind |
|---|---|---|---|
| 3852571 | Hal et al. | Dec 1974 | A |
| 4201978 | Nally | May 1980 | A |
| 4205780 | Burns et al. | Jun 1980 | A |
| 4264808 | Owens et al. | Apr 1981 | A |
| 4268715 | Atalla | May 1981 | A |
| 4270042 | Case | May 1981 | A |
| 4321672 | Braun et al. | Mar 1982 | A |
| 4326258 | de la Guardia | Apr 1982 | A |
| 4404649 | Nunley et al. | Sep 1983 | A |
| 4417136 | Rushby et al. | Nov 1983 | A |
| 4457015 | Nally et al. | Jun 1984 | A |
| 4491725 | Pritchard | Jan 1985 | A |
| 4500750 | Elander et al. | Feb 1985 | A |
| 4523330 | Cain | Jun 1985 | A |
| 4555617 | Brooks et al. | Nov 1985 | A |
| 4578530 | Zeidler | Mar 1986 | A |
| 4602936 | Topfl et al. | Jul 1986 | A |
| 4617457 | Granzow et al. | Oct 1986 | A |
| 4652990 | Pailen et al. | Mar 1987 | A |
| 4672377 | Murphy et al. | Jun 1987 | A |
| 4673802 | Ohmae et al. | Jun 1987 | A |
| 4675815 | Kuroki et al. | Jun 1987 | A |
| 4680803 | Dilella | Jul 1987 | A |
| 4694147 | Amemiya et al. | Sep 1987 | A |
| 4723283 | Nagasawa et al. | Feb 1988 | A |
| 4745267 | Davis et al. | May 1988 | A |
| 4747058 | Ho | May 1988 | A |
| 4748557 | Tamada et al. | May 1988 | A |
| 4750201 | Hodgson et al. | Jun 1988 | A |
| 4755940 | Brachtl et al. | Jul 1988 | A |
| 4757543 | Tamada et al. | Jul 1988 | A |
| 4758530 | Schubert | Jul 1988 | A |
| 4771460 | Tamada et al. | Sep 1988 | A |
| 4799156 | Shavit et al. | Jan 1989 | A |
| 4810866 | Lord, Jr. | Mar 1989 | A |
| 4823264 | Deming | Apr 1989 | A |
| 4843220 | Haun | Jun 1989 | A |
| 4858121 | Barber et al. | Aug 1989 | A |
| 4882779 | Ralitgen | Nov 1989 | A |
| 4888812 | Dinan et al. | Dec 1989 | A |
| 4910774 | Barakat | Mar 1990 | A |
| 4912762 | Lee et al. | Mar 1990 | A |
| 4922503 | Leone | May 1990 | A |
| 4926325 | Benton et al. | May 1990 | A |
| 4941125 | Boyne | Jul 1990 | A |
| 4960981 | Benton et al. | Oct 1990 | A |
| 4961142 | Elliott et al. | Oct 1990 | A |
| 4962531 | Sipman et al. | Oct 1990 | A |
| 4977595 | Ohta et al. | Dec 1990 | A |
| 4985921 | Schwartz | Jan 1991 | A |
| 5003594 | Shinagawa | Mar 1991 | A |
| 5014311 | Schrenk | May 1991 | A |
| 5016277 | Hamilton | May 1991 | A |
| 5053607 | Carlson et al. | Oct 1991 | A |
| 5054096 | Beizer | Oct 1991 | A |
| 5081680 | Bennett | Jan 1992 | A |
| 5091968 | Higgins | Feb 1992 | A |
| 5093787 | Simmons | Mar 1992 | A |
| 5095480 | Fenner | Mar 1992 | A |
| 5111395 | Smith et al. | May 1992 | A |
| 5122950 | Benton et al. | Jun 1992 | A |
| 5123047 | Rosenow | Jun 1992 | A |
| 5144115 | Yoshida | Sep 1992 | A |
| 5159548 | Caslavka | Oct 1992 | A |
| 5159592 | Perkins | Oct 1992 | A |
| 5163098 | Dahbura | Nov 1992 | A |
| 5168444 | Cukor | Dec 1992 | A |
| 5170466 | Rogan et al. | Dec 1992 | A |
| 5173594 | McClure | Dec 1992 | A |
| 5175682 | Higashiyama | Dec 1992 | A |
| 5175766 | Hamilton | Dec 1992 | A |
| 5185798 | Hamada et al. | Feb 1993 | A |
| 5187750 | Behera | Feb 1993 | A |
| 5195133 | Kapp et al. | Mar 1993 | A |
| 5198975 | Barker et al. | Mar 1993 | A |
| 5200993 | Wheeler et al. | Apr 1993 | A |
| 5204811 | Bednar et al. | Apr 1993 | A |
| 5214697 | Saito | May 1993 | A |
| 5220501 | Lawlor et al. | Jun 1993 | A |
| 5231569 | Myatt et al. | Jul 1993 | A |
| 5233547 | Kapp et al. | Aug 1993 | A |
| 5233656 | Langrand et al. | Aug 1993 | A |
| 5235433 | Clarkson et al. | Aug 1993 | A |
| 5237158 | Kern et al. | Aug 1993 | A |
| 5237159 | Stephens et al. | Aug 1993 | A |
| 5237620 | Deaton et al. | Aug 1993 | A |
| 5241600 | Hillis | Aug 1993 | A |
| 5256863 | Ferguson et al. | Oct 1993 | A |
| 5259025 | Monroe et al. | Nov 1993 | A |
| 5262942 | Earle | Nov 1993 | A |
| 5265007 | Barnhard, Jr. et al. | Nov 1993 | A |
| 5274567 | Kallin et al. | Dec 1993 | A |
| 5283829 | Anderson | Feb 1994 | A |
| 5287497 | Behera | Feb 1994 | A |
| 5317637 | Pichlmaier et al. | May 1994 | A |
| 5321238 | Kamata et al. | Jun 1994 | A |
| 5321751 | Ray et al. | Jun 1994 | A |
| 5321816 | Rogan et al. | Jun 1994 | A |
| 5326959 | Perazza | Jul 1994 | A |
| 5329589 | Fraser et al. | Jul 1994 | A |
| 5337358 | Axelrod et al. | Aug 1994 | A |
| 5341428 | Schatz | Aug 1994 | A |
| 5343529 | Goldfine et al. | Aug 1994 | A |
| 5345090 | Hludzinski | Sep 1994 | A |
| 5373550 | Campbell et al. | Dec 1994 | A |
| 5383113 | Kight et al. | Jan 1995 | A |
| 5396558 | Ishiguro et al. | Mar 1995 | A |
| 5408531 | Nakajima | Apr 1995 | A |
| 5412190 | Josephson et al. | May 1995 | A |
| 5426281 | Abecassis | Jun 1995 | A |
| 5434928 | Wagner et al. | Jul 1995 | A |
| 5436970 | Ray et al. | Jul 1995 | A |
| 5440634 | Jones et al. | Aug 1995 | A |
| 5444794 | Uhland, Sr. | Aug 1995 | A |
| 5446796 | Ishiguro et al. | Aug 1995 | A |
| 5453601 | Rosen | Sep 1995 | A |
| 5454575 | Del Buono | Oct 1995 | A |
| 5455407 | Rosen | Oct 1995 | A |
| 5457747 | Drexler et al. | Oct 1995 | A |
| 5465206 | Hilt et al. | Nov 1995 | A |
| 5473143 | Vak et al. | Dec 1995 | A |
| 5479510 | Olsen et al. | Dec 1995 | A |
| 5484988 | Hilts et al. | Jan 1996 | A |
| 5502765 | Ishiguro et al. | Mar 1996 | A |
| 5506691 | Bednar et al. | Apr 1996 | A |
| 5523167 | Hunt et al. | Jun 1996 | A |
| 5524073 | Stambler | Jun 1996 | A |
| 5528705 | Reasoner, Jr. et al. | Jun 1996 | A |
| 5532464 | Josephson et al. | Jul 1996 | A |
| 5539822 | Lett | Jul 1996 | A |
| 5539825 | Akiyama et al. | Jul 1996 | A |
| 5544043 | Miki et al. | Aug 1996 | A |
| 5544255 | Smithies et al. | Aug 1996 | A |
| 5557518 | Rosen | Sep 1996 | A |
| 5577121 | Davis et al. | Nov 1996 | A |
| 5590038 | Pitroda | Dec 1996 | A |
| 5594226 | Steger | Jan 1997 | A |
| 5596642 | Davis et al. | Jan 1997 | A |
| 5602933 | Blackwell et al. | Feb 1997 | A |
| 5602936 | Green et al. | Feb 1997 | A |
| 5604640 | Zipf et al. | Feb 1997 | A |
| 5604802 | Holloway | Feb 1997 | A |
| 5608800 | Hoffmann et al. | Mar 1997 | A |
| 5613001 | Bakhoutn | Mar 1997 | A |
| 5615269 | Micali | Mar 1997 | A |
| 5621796 | Davis et al. | Apr 1997 | A |
| 5621797 | Rosen | Apr 1997 | A |
| 5623547 | Jones et al. | Apr 1997 | A |
| 5625694 | Lee et al. | Apr 1997 | A |
| 5629981 | Nerlikar | May 1997 | A |
| 5633930 | Davis et al. | May 1997 | A |
| 5642419 | Rosen | Jun 1997 | A |
| 5647017 | Smithies et al. | Jul 1997 | A |
| 5649116 | McCoy et al. | Jul 1997 | A |
| 5649117 | Landry | Jul 1997 | A |
| 5652786 | Rogers | Jul 1997 | A |
| 5657389 | Houvener | Aug 1997 | A |
| 5657396 | Rudolph et al. | Aug 1997 | A |
| 5659616 | Sudia | Aug 1997 | A |
| 5668897 | Stolfo | Sep 1997 | A |
| 5673333 | Johnston | Sep 1997 | A |
| 5677955 | Doggett et al. | Oct 1997 | A |
| 5682549 | Tanaka et al. | Oct 1997 | A |
| 5684965 | Pickering | Nov 1997 | A |
| 5691524 | Josephson | Nov 1997 | A |
| 5699528 | Hogan | Dec 1997 | A |
| 5703344 | Bezy et al. | Dec 1997 | A |
| 5708810 | Kern et al. | Jan 1998 | A |
| 5710887 | Chelliah et al. | Jan 1998 | A |
| 5715298 | Rogers | Feb 1998 | A |
| 5717868 | James | Feb 1998 | A |
| 5732400 | Mandler et al. | Mar 1998 | A |
| 5742668 | Pepe et al. | Apr 1998 | A |
| 5742888 | Fuchiwaki et al. | Apr 1998 | A |
| 5751842 | Riach et al. | May 1998 | A |
| 5754673 | Brooks et al. | May 1998 | A |
| 5760916 | Dellert et al. | Jun 1998 | A |
| 5778178 | Arunachalam | Jul 1998 | A |
| 5781654 | Carney | Jul 1998 | A |
| 5783808 | Josephson | Jul 1998 | A |
| 5784503 | Bleecker, III et al. | Jul 1998 | A |
| 5784610 | Copeland, III et al. | Jul 1998 | A |
| 5787403 | Randle | Jul 1998 | A |
| 5790260 | Myers | Aug 1998 | A |
| 5790790 | Smith et al. | Aug 1998 | A |
| 5793869 | Claflin, Jr. | Aug 1998 | A |
| 5832460 | Bednar et al. | Nov 1998 | A |
| 5832463 | Funk | Nov 1998 | A |
| 5832464 | Houvener et al. | Nov 1998 | A |
| 5848400 | Chang | Dec 1998 | A |
| 5857034 | Tsuchiya et al. | Jan 1999 | A |
| 5870456 | Rogers | Feb 1999 | A |
| 5870724 | Lawlor et al. | Feb 1999 | A |
| 5870725 | Bellinger et al. | Feb 1999 | A |
| 5873072 | Kight et al. | Feb 1999 | A |
| 5884271 | Pitroda | Mar 1999 | A |
| 5893080 | McGurl et al. | Apr 1999 | A |
| 5903874 | Leonard et al. | May 1999 | A |
| 5903880 | Biffar | May 1999 | A |
| 5903881 | Schrader et al. | May 1999 | A |
| 5910988 | Ballard | Jun 1999 | A |
| 5915023 | Bernstein | Jun 1999 | A |
| 5917965 | Cahill et al. | Jun 1999 | A |
| 5920847 | Kolling et al. | Jul 1999 | A |
| 5925865 | Steger | Jul 1999 | A |
| 5926288 | Dellert et al. | Jul 1999 | A |
| 5930778 | Geer | Jul 1999 | A |
| 5937396 | Konya | Aug 1999 | A |
| 5940844 | Cahill et al. | Aug 1999 | A |
| 5956700 | Landry | Sep 1999 | A |
| 5963647 | Downing et al. | Oct 1999 | A |
| 5963925 | Kolling et al. | Oct 1999 | A |
| 5973731 | Schwab | Oct 1999 | A |
| 5978780 | Watson | Nov 1999 | A |
| 5987500 | Amuachalam | Nov 1999 | A |
| 5999625 | Bellare et al. | Dec 1999 | A |
| 6006208 | Forst et al. | Dec 1999 | A |
| 6021202 | Anderson et al. | Feb 2000 | A |
| 6029150 | Ktavitz | Feb 2000 | A |
| 6029151 | Nikander | Feb 2000 | A |
| 6032133 | Hilt et al. | Feb 2000 | A |
| 6032137 | Ballard | Feb 2000 | A |
| 6036344 | Goldenberg | Mar 2000 | A |
| 6047051 | Ginzboorg et al. | Apr 2000 | A |
| 6049785 | Gifford | Apr 2000 | A |
| 6049786 | Smorodinsky | Apr 2000 | A |
| 6055567 | Ganesan et al. | Apr 2000 | A |
| 6058382 | Kasai | May 2000 | A |
| 6069896 | Borgstahl et al. | May 2000 | A |
| 6070150 | Remington et al. | May 2000 | A |
| 6076068 | DeLapa et al. | Jun 2000 | A |
| 6076074 | Cotton et al. | Jun 2000 | A |
| 6108104 | Tesavis | Aug 2000 | A |
| 6115509 | Yeskel | Sep 2000 | A |
| 6138107 | Elgamal | Oct 2000 | A |
| 6145738 | Stinson et al. | Nov 2000 | A |
| 6173272 | Thomas et al. | Jan 2001 | B1 |
| 6181837 | Cahill et al. | Jan 2001 | B1 |
| 6189785 | Lowery | Feb 2001 | B1 |
| 6192142 | Pare, Jr. et al. | Feb 2001 | B1 |
| 6192407 | Smith et al. | Feb 2001 | B1 |
| 6199077 | Inala et al. | Mar 2001 | B1 |
| 6202054 | Lawlor et al. | Mar 2001 | B1 |
| 6209095 | Anderson et al. | Mar 2001 | B1 |
| 6212556 | Arunachalam | Apr 2001 | B1 |
| 6223168 | McGurl et al. | Apr 2001 | B1 |
| 6230148 | Pare, Jr. et al. | May 2001 | B1 |
| 6243689 | Norton | Jun 2001 | B1 |
| 6260024 | Shkedy | Jul 2001 | B1 |
| 6269348 | Pare, Jr. et al. | Jul 2001 | B1 |
| 6278993 | Kumar et al. | Aug 2001 | B1 |
| 6282523 | Tedesco et al. | Aug 2001 | B1 |
| 6283366 | Hills et al. | Sep 2001 | B1 |
| 6285991 | Powar | Sep 2001 | B1 |
| 6289322 | Kitchen et al. | Sep 2001 | B1 |
| 6292789 | Schutzer | Sep 2001 | B1 |
| 6301379 | Thompson et al. | Oct 2001 | B1 |
| 6304857 | Heindei et al. | Oct 2001 | B1 |
| 6317745 | Thomas et al. | Nov 2001 | B1 |
| 6317783 | Freishtat et al. | Nov 2001 | B1 |
| 6324526 | D'Agostino | Nov 2001 | B1 |
| 6327577 | Garrison et al. | Dec 2001 | B1 |
| 6330544 | Walker et al. | Dec 2001 | B1 |
| 6334116 | Ganesan et al. | Dec 2001 | B1 |
| 6338050 | Conklin et al. | Jan 2002 | B1 |
| 6351553 | Hayosh | Feb 2002 | B1 |
| 6353811 | Weissman | Mar 2002 | B1 |
| 6363362 | Burfield et al. | Mar 2002 | B1 |
| 6385595 | Kolling et al. | May 2002 | B1 |
| 6385652 | Brown et al. | May 2002 | B1 |
| 6405245 | Burson et al. | Jun 2002 | B1 |
| 6408284 | Hilt et al. | Jun 2002 | B1 |
| 6411939 | Parsons | Jun 2002 | B1 |
| 6412073 | Rangan | Jun 2002 | B1 |
| 6438527 | Powar | Aug 2002 | B1 |
| 6442590 | Inala et al. | Aug 2002 | B1 |
| 6477565 | Daswani et al. | Nov 2002 | B1 |
| 6493685 | Ensel et al. | Dec 2002 | B1 |
| 6510451 | Wu et al. | Jan 2003 | B2 |
| 6517587 | Satyavolu et al. | Feb 2003 | B2 |
| 6553346 | Walker et al. | Apr 2003 | B1 |
| 6567850 | Freishtat et al. | May 2003 | B1 |
| 6574377 | Cahill et al. | Jun 2003 | B1 |
| 6578015 | Haseltine et al. | Jun 2003 | B1 |
| 6594647 | Randle et al. | Jul 2003 | B1 |
| 6594766 | Rangan et al. | Jul 2003 | B2 |
| 6633910 | Rajan et al. | Oct 2003 | B1 |
| 6647376 | Farrar et al. | Nov 2003 | B1 |
| 6678664 | Ganesan | Jan 2004 | B1 |
| 6694300 | Walker et al. | Feb 2004 | B1 |
| 6725425 | Rajan et al. | Apr 2004 | B1 |
| 6738804 | Lo | May 2004 | B1 |
| 6748367 | Lee | Jun 2004 | B1 |
| 6802042 | Rangan et al. | Oct 2004 | B2 |
| 6826545 | Kawashima et al. | Nov 2004 | B2 |
| 6842782 | Malik et al. | Jan 2005 | B1 |
| 6856974 | Ganesan et al. | Feb 2005 | B1 |
| 6856975 | Inglis | Feb 2005 | B1 |
| 6859212 | Kumar et al. | Feb 2005 | B2 |
| 6863214 | Garner, IV et al. | Mar 2005 | B2 |
| 6865680 | Wu et al. | Mar 2005 | B1 |
| 6871220 | Rajan et al. | Mar 2005 | B1 |
| 6910023 | Schibi | Jun 2005 | B1 |
| 6932268 | McCoy et al. | Aug 2005 | B1 |
| 6934691 | Simpson et al. | Aug 2005 | B1 |
| 6945453 | Schwarz, Jr. | Sep 2005 | B1 |
| 6948063 | Ganesan et al. | Sep 2005 | B1 |
| 6968319 | Remington et al. | Nov 2005 | B1 |
| 6980973 | Karpenko | Dec 2005 | B1 |
| 6996542 | Landry | Feb 2006 | B1 |
| 7004382 | Sandru | Feb 2006 | B2 |
| 7013310 | Messing et al. | Mar 2006 | B2 |
| 7028008 | Powar | Apr 2006 | B2 |
| 7028886 | Maloney | Apr 2006 | B1 |
| 7039656 | Tsai et al. | May 2006 | B1 |
| 7076458 | Lawlor et al. | Jul 2006 | B2 |
| 7085997 | Wu et al. | Aug 2006 | B1 |
| 7089208 | Levchin et al. | Aug 2006 | B1 |
| 7099845 | Higgins et al. | Aug 2006 | B2 |
| 7107244 | Kight et al. | Sep 2006 | B2 |
| 7110969 | Bennett et al. | Sep 2006 | B1 |
| 7110993 | Soulanille et al. | Sep 2006 | B2 |
| 7120602 | Kitchen et al. | Oct 2006 | B2 |
| 7146338 | Kight et al. | Dec 2006 | B2 |
| 7155508 | Sankuratripati et al. | Dec 2006 | B2 |
| 7158955 | Diveley et al. | Jan 2007 | B2 |
| 7165052 | Diveley et al. | Jan 2007 | B2 |
| 7165723 | McGlamery et al. | Jan 2007 | B2 |
| 7167711 | Dennis | Jan 2007 | B1 |
| 7175074 | Mejias et al. | Feb 2007 | B2 |
| 7177846 | Moenickheim et al. | Feb 2007 | B2 |
| 7178096 | Rangan et al. | Feb 2007 | B2 |
| 7181430 | Buchanan et al. | Feb 2007 | B1 |
| 7191150 | Shao et al. | Mar 2007 | B1 |
| 7191151 | Nosek | Mar 2007 | B1 |
| 7200551 | Senez | Apr 2007 | B1 |
| 7200804 | Khavati et al. | Apr 2007 | B1 |
| 7203845 | Sokolic et al. | Apr 2007 | B2 |
| 7213003 | Kight et al. | May 2007 | B1 |
| 7225156 | Fisher et al. | May 2007 | B2 |
| 7225464 | Satyavolu et al. | May 2007 | B2 |
| 7236950 | Savage et al. | Jun 2007 | B2 |
| 7240031 | Kight et al. | Jul 2007 | B1 |
| 7249080 | Hoffman et al. | Jul 2007 | B1 |
| 7249094 | Levchin et al. | Jul 2007 | B2 |
| 7251656 | Keown et al. | Jul 2007 | B2 |
| 7263548 | Daswani et al. | Aug 2007 | B2 |
| 7296004 | Garrison | Nov 2007 | B1 |
| 7302408 | Engdahl et al. | Nov 2007 | B2 |
| 7302411 | Ganesan et al. | Nov 2007 | B2 |
| 7308426 | Pitroda | Dec 2007 | B1 |
| 7313813 | Rangan et al. | Dec 2007 | B2 |
| 7321874 | Dilip et al. | Jan 2008 | B2 |
| 7321875 | Dilip et al. | Jan 2008 | B2 |
| 7330831 | Biondi et al. | Feb 2008 | B2 |
| 7334128 | Ganesan et al. | Feb 2008 | B2 |
| 7356502 | LaBadie et al. | Apr 2008 | B1 |
| 7366696 | Ganesan et al. | Apr 2008 | B1 |
| 7366697 | Kitchen et al. | Apr 2008 | B2 |
| 7370014 | Vasavada et al. | May 2008 | B1 |
| 7383223 | Dilip et al. | Jun 2008 | B1 |
| 7383226 | Kight et al. | Jun 2008 | B2 |
| 7392223 | Ganesan et al. | Jun 2008 | B1 |
| 7395319 | Harris et al. | Jul 2008 | B2 |
| 7415610 | Ganesan et al. | Aug 2008 | B2 |
| 7424520 | Daswani et al. | Sep 2008 | B2 |
| 7426638 | Ganesan et al. | Sep 2008 | B2 |
| 7447347 | Weber | Nov 2008 | B2 |
| 7474779 | Duncan | Jan 2009 | B2 |
| 7490063 | Garrison et al. | Feb 2009 | B2 |
| 7502749 | Ganesan et al. | Mar 2009 | B2 |
| 7505937 | Dilip et al. | Mar 2009 | B2 |
| 7526448 | Zielke et al. | Apr 2009 | B2 |
| 7533058 | Kulakowski | May 2009 | B2 |
| 7536340 | Dheer et al. | May 2009 | B2 |
| 7558795 | Malik et al. | Jul 2009 | B2 |
| 7606752 | Hazlehurst et al. | Oct 2009 | B2 |
| 7606787 | Keown et al. | Oct 2009 | B2 |
| 7610245 | Dent et al. | Oct 2009 | B2 |
| 7636686 | Pierdinock et al. | Dec 2009 | B2 |
| 7636688 | Kitchen et al. | Dec 2009 | B2 |
| 7640197 | Gentry et al. | Dec 2009 | B1 |
| 7644023 | Kumar et al. | Jan 2010 | B2 |
| 7644036 | McCoy et al. | Jan 2010 | B2 |
| 7653598 | Hamilton et al. | Jan 2010 | B1 |
| 7657484 | Ganesan et al. | Feb 2010 | B2 |
| 7660766 | Lawson et al. | Feb 2010 | B1 |
| 7672879 | Kumar et al. | Mar 2010 | B1 |
| 7685525 | Kumar et al. | Mar 2010 | B2 |
| 7693790 | Lawlor et al. | Apr 2010 | B2 |
| 7702583 | Hamilton et al. | Apr 2010 | B1 |
| 7702585 | Lyda et al. | Apr 2010 | B2 |
| 7711626 | Nanjundamoorthy et al. | May 2010 | B2 |
| 7711690 | Garrison et al. | May 2010 | B1 |
| 7725389 | D'Aquisto et al. | May 2010 | B1 |
| 7729283 | Ferguson et al. | Jun 2010 | B2 |
| 7729969 | Smith, III et al. | Jun 2010 | B1 |
| 7729996 | Zito | Jun 2010 | B2 |
| 7734541 | Kumar et al. | Jun 2010 | B2 |
| 7752130 | Byrd et al. | Jul 2010 | B2 |
| 7752535 | Satyavolu | Jul 2010 | B2 |
| 7778901 | Ganesan et al. | Aug 2010 | B2 |
| 7788172 | Kight et al. | Aug 2010 | B2 |
| 7792749 | Ganesan | Sep 2010 | B2 |
| 7886156 | Franchi | Feb 2011 | B2 |
| 7979348 | Thomas et al. | Jul 2011 | B2 |
| 8032932 | Speyer et al. | Oct 2011 | B2 |
| 8073772 | Bishop et al. | Dec 2011 | B2 |
| 8327429 | Speyer et al. | Dec 2012 | B2 |
| 8369601 | Lugg | Feb 2013 | B2 |
| 8423453 | Elliott | Apr 2013 | B1 |
| 8688580 | Guenther et al. | Apr 2014 | B1 |
| 8725607 | Dunn et al. | May 2014 | B2 |
| 8725609 | Pawelczyk et al. | May 2014 | B2 |
| 9135620 | Chen et al. | Sep 2015 | B2 |
| 9195984 | Spector et al. | Nov 2015 | B1 |
| 9264902 | Ward et al. | Feb 2016 | B1 |
| 9600817 | Bondesen et al. | Mar 2017 | B2 |
| 9693234 | Cook | Jun 2017 | B2 |
| 9741037 | Garlick et al. | Aug 2017 | B2 |
| 9799011 | Dunn et al. | Oct 2017 | B2 |
| 10262306 | Pawelczyk et al. | Apr 2019 | B2 |
| 20010000537 | Inala et al. | Apr 2001 | A1 |
| 20010016034 | Singh et al. | Aug 2001 | A1 |
| 20010023414 | Kumar et al. | Sep 2001 | A1 |
| 20010024157 | Hansmann et al. | Sep 2001 | A1 |
| 20010032182 | Kumar et al. | Oct 2001 | A1 |
| 20010032183 | Landry | Oct 2001 | A1 |
| 20010051907 | Kumar et al. | Dec 2001 | A1 |
| 20020002536 | Braco | Jan 2002 | A1 |
| 20020007323 | Tamatsu | Jan 2002 | A1 |
| 20020010612 | Smith et al. | Jan 2002 | A1 |
| 20020010677 | Kitchen et al. | Jan 2002 | A1 |
| 20020015480 | Daswani et al. | Feb 2002 | A1 |
| 20020019808 | Sharma | Feb 2002 | A1 |
| 20020019809 | Kitchen et al. | Feb 2002 | A1 |
| 20020023108 | Daswani et al. | Feb 2002 | A1 |
| 20020046167 | Kitchen et al. | Apr 2002 | A1 |
| 20020046168 | Kitchen et al. | Apr 2002 | A1 |
| 20020049671 | Trende et al. | Apr 2002 | A1 |
| 20020049672 | Kitchen et al. | Apr 2002 | A1 |
| 20020052840 | Kitchen et al. | May 2002 | A1 |
| 20020059139 | Evans | May 2002 | A1 |
| 20020059369 | Kern et al. | May 2002 | A1 |
| 20020062282 | Kight et al. | May 2002 | A1 |
| 20020065773 | Kight et al. | May 2002 | A1 |
| 20020069161 | Eckert et al. | Jun 2002 | A1 |
| 20020077952 | Eckert et al. | Jun 2002 | A1 |
| 20020077961 | Eckert et al. | Jun 2002 | A1 |
| 20020077978 | O'Leary et al. | Jun 2002 | A1 |
| 20020087454 | Calo et al. | Jul 2002 | A1 |
| 20020087455 | Tsagarakis et al. | Jul 2002 | A1 |
| 20020087461 | Ganesan et al. | Jul 2002 | A1 |
| 20020087465 | Ganesan et al. | Jul 2002 | A1 |
| 20020091635 | Dilip et al. | Jul 2002 | A1 |
| 20020111886 | Chenevich et al. | Aug 2002 | A1 |
| 20020128964 | Baker et al. | Sep 2002 | A1 |
| 20020128968 | Kitchen et al. | Sep 2002 | A1 |
| 20020143655 | Elston et al. | Oct 2002 | A1 |
| 20020174048 | Dheer et al. | Nov 2002 | A1 |
| 20020184144 | Byrd et al. | Dec 2002 | A1 |
| 20020194137 | Park et al. | Dec 2002 | A1 |
| 20030014489 | Inala et al. | Jan 2003 | A1 |
| 20030018571 | Eckert et al. | Jan 2003 | A1 |
| 20030023552 | Kight et al. | Jan 2003 | A1 |
| 20030037002 | Higgins et al. | Feb 2003 | A1 |
| 20030089768 | Page | May 2003 | A1 |
| 20030120774 | Satyavolu et al. | Jun 2003 | A1 |
| 20030126075 | Mascavage, III et al. | Jul 2003 | A1 |
| 20030158811 | Sanders et al. | Aug 2003 | A1 |
| 20030182206 | Hendrix et al. | Sep 2003 | A1 |
| 20030187925 | Inala et al. | Oct 2003 | A1 |
| 20030191701 | Haseltine et al. | Oct 2003 | A1 |
| 20030191711 | Jamison et al. | Oct 2003 | A1 |
| 20030191832 | Satyavolu et al. | Oct 2003 | A1 |
| 20030195844 | Hogan | Oct 2003 | A1 |
| 20030208421 | Vicknair et al. | Nov 2003 | A1 |
| 20030208441 | Poplawski et al. | Nov 2003 | A1 |
| 20030225705 | Park et al. | Dec 2003 | A1 |
| 20030236728 | Sunderji et al. | Dec 2003 | A1 |
| 20040034594 | Thomas et al. | Feb 2004 | A1 |
| 20040039701 | Nakamura et al. | Feb 2004 | A1 |
| 20040059671 | Nozaki et al. | Mar 2004 | A1 |
| 20040059672 | Baig et al. | Mar 2004 | A1 |
| 20040059673 | Kitchen et al. | Mar 2004 | A1 |
| 20040064407 | Kight et al. | Apr 2004 | A1 |
| 20040064408 | Kight et al. | Apr 2004 | A1 |
| 20040064409 | Kight et al. | Apr 2004 | A1 |
| 20040064410 | Kight et al. | Apr 2004 | A1 |
| 20040071333 | Douglas et al. | Apr 2004 | A1 |
| 20040078423 | Satyavolu et al. | Apr 2004 | A1 |
| 20040078464 | Rajan et al. | Apr 2004 | A1 |
| 20040083167 | Kight et al. | Apr 2004 | A1 |
| 20040083171 | Kight et al. | Apr 2004 | A1 |
| 20040088235 | Ziekle et al. | May 2004 | A1 |
| 20040093305 | Kight et al. | May 2004 | A1 |
| 20040133515 | McCoy et al. | Jul 2004 | A1 |
| 20040139005 | Ganesan | Jul 2004 | A1 |
| 20040139009 | Kozee et al. | Jul 2004 | A1 |
| 20040139010 | McMichael et al. | Jul 2004 | A1 |
| 20040139011 | Kozee et al. | Jul 2004 | A1 |
| 20040143552 | Weichert et al. | Jul 2004 | A1 |
| 20040148235 | Craig et al. | Jul 2004 | A1 |
| 20040148252 | Fleishman | Jul 2004 | A1 |
| 20040215543 | Betz et al. | Oct 2004 | A1 |
| 20040225609 | Greene | Nov 2004 | A1 |
| 20040236653 | Sokolic et al. | Nov 2004 | A1 |
| 20040236681 | Modigliani et al. | Nov 2004 | A1 |
| 20050010483 | Ling | Jan 2005 | A1 |
| 20050010523 | Myklebust et al. | Jan 2005 | A1 |
| 20050086136 | Love et al. | Apr 2005 | A1 |
| 20050086165 | Pawelczyk et al. | Apr 2005 | A1 |
| 20050119971 | Zito | Jun 2005 | A1 |
| 20050137960 | Brann et al. | Jun 2005 | A1 |
| 20050137978 | Ganesan et al. | Jun 2005 | A1 |
| 20050015492 | Lok et al. | Jul 2005 | A1 |
| 20050149439 | Suisa | Jul 2005 | A1 |
| 20050171899 | Dunn et al. | Aug 2005 | A1 |
| 20050171900 | Onneken | Aug 2005 | A1 |
| 20050177505 | Keeling et al. | Aug 2005 | A1 |
| 20050182720 | Willard et al. | Aug 2005 | A1 |
| 20050187867 | Sokolic et al. | Aug 2005 | A1 |
| 20050192901 | McCoy et al. | Sep 2005 | A1 |
| 20050198377 | Ferguson et al. | Sep 2005 | A1 |
| 20050203835 | Nhaissi et al. | Sep 2005 | A1 |
| 20050203844 | Ferguson et al. | Sep 2005 | A1 |
| 20050210297 | Wu et al. | Sep 2005 | A1 |
| 20050222954 | Keown et al. | Oct 2005 | A1 |
| 20060047724 | Messing et al. | Mar 2006 | A1 |
| 20060106717 | Randle et al. | May 2006 | A1 |
| 20060136595 | Satyavolu | Jun 2006 | A1 |
| 20060184451 | Ganesan et al. | Aug 2006 | A1 |
| 20060195398 | Dheer et al. | Aug 2006 | A1 |
| 20060230343 | Amiandpour et al. | Oct 2006 | A1 |
| 20060253340 | Levchin et al. | Nov 2006 | A1 |
| 20060253463 | Wu et al. | Nov 2006 | A1 |
| 20060282381 | Ritchie | Dec 2006 | A1 |
| 20070011090 | Baker et al. | Jan 2007 | A1 |
| 20070067239 | Dheer et al. | Mar 2007 | A1 |
| 20070088821 | Sankuratripati et al. | Apr 2007 | A1 |
| 20070094151 | Moenickheim et al. | Apr 2007 | A1 |
| 20070100748 | Dheer et al. | May 2007 | A1 |
| 20070106612 | O'Brien et al. | May 2007 | A1 |
| 20070121840 | Ganesan et al. | May 2007 | A1 |
| 20070125840 | Law et al. | Jun 2007 | A1 |
| 20070130347 | Rangan et al. | Jun 2007 | A1 |
| 20070131758 | Mejias et al. | Jun 2007 | A1 |
| 20070162769 | Sokolic et al. | Jul 2007 | A1 |
| 20070179885 | Bird et al. | Aug 2007 | A1 |
| 20070180380 | Khavari et al. | Aug 2007 | A1 |
| 20070208645 | Hoffman et al. | Sep 2007 | A1 |
| 20070230371 | Tumminaro | Oct 2007 | A1 |
| 20070233615 | Tumminaro | Oct 2007 | A1 |
| 20070239601 | Ganesan et al. | Oct 2007 | A1 |
| 20070244811 | Tumminaro | Oct 2007 | A1 |
| 20070255620 | Tumminaro et al. | Nov 2007 | A1 |
| 20070255652 | Tumminaro et al. | Nov 2007 | A1 |
| 20070255653 | Tumminaro et al. | Nov 2007 | A1 |
| 20070255662 | Tumminaro | Nov 2007 | A1 |
| 20080015982 | Sokolic et al. | Jan 2008 | A1 |
| 20080032741 | Tumminaro | Feb 2008 | A1 |
| 20080033878 | Krikorian et al. | Feb 2008 | A1 |
| 20080052226 | Agarwal et al. | Feb 2008 | A1 |
| 20080082454 | Dilip et al. | Apr 2008 | A1 |
| 20080086403 | Dilip et al. | Apr 2008 | A1 |
| 20080086426 | Dilip et al. | Apr 2008 | A1 |
| 20080091663 | Inala et al. | Apr 2008 | A1 |
| 20080097899 | Jackson et al. | Apr 2008 | A1 |
| 20080133407 | Guillory et al. | Jun 2008 | A1 |
| 20080263069 | Harris et al. | Oct 2008 | A1 |
| 20080275816 | Hazlehurst | Nov 2008 | A1 |
| 20080288376 | Panthaki et al. | Nov 2008 | A1 |
| 20080288400 | Panthaki et al. | Nov 2008 | A1 |
| 20080301022 | Patel et al. | Dec 2008 | A1 |
| 20080301023 | Patel et al. | Dec 2008 | A1 |
| 20080306846 | Ferguson | Dec 2008 | A1 |
| 20080319880 | D'Aquisto et al. | Dec 2008 | A1 |
| 20090006205 | Bixler et al. | Jan 2009 | A1 |
| 20090006582 | Daswani et al. | Jan 2009 | A1 |
| 20090024505 | Patel et al. | Jan 2009 | A1 |
| 20090063197 | Lisle | Mar 2009 | A1 |
| 20090076950 | Chang et al. | Mar 2009 | A1 |
| 20090119190 | Realini | May 2009 | A1 |
| 20090125446 | Saunders et al. | May 2009 | A1 |
| 20090132289 | Stenman et al. | May 2009 | A1 |
| 20090138394 | Garrison et al. | May 2009 | A1 |
| 20090222369 | Zoldi | Sep 2009 | A1 |
| 20090265241 | Bishop et al. | Oct 2009 | A1 |
| 20090265774 | Malik et al. | Oct 2009 | A1 |
| 20090271854 | Hazlehurst et al. | Oct 2009 | A1 |
| 20090287601 | Tumminaro et al. | Nov 2009 | A1 |
| 20090287613 | Pierdinock et al. | Nov 2009 | A1 |
| 20090319410 | Kight et al. | Dec 2009 | A1 |
| 20090319425 | Tumminaro et al. | Dec 2009 | A1 |
| 20100004990 | Hazlehurst et al. | Jan 2010 | A1 |
| 20100005025 | Kumar et al. | Jan 2010 | A1 |
| 20100017332 | Kight et al. | Jan 2010 | A1 |
| 20100030687 | Panthaki et al. | Feb 2010 | A1 |
| 20100100462 | Lyda et al. | Apr 2010 | A1 |
| 20100100466 | Garrison et al. | Apr 2010 | A1 |
| 20100100467 | McCoy et al. | Apr 2010 | A1 |
| 20100138243 | Carroll | Jun 2010 | A1 |
| 20100198645 | Heiss et al. | Aug 2010 | A1 |
| 20110119190 | Mina | May 2011 | A1 |
| 20110125613 | Franchi | May 2011 | A1 |
| 20110202415 | Casares et al. | Aug 2011 | A1 |
| 20110295746 | Thomas et al. | Dec 2011 | A1 |
| 20120284175 | Wilson et al. | Nov 2012 | A1 |
| 20130262296 | Thomas et al. | Oct 2013 | A1 |
| 20130268839 | Lefebvre et al. | Oct 2013 | A1 |
| 20130293363 | Plymouth et al. | Nov 2013 | A1 |
| 20130297501 | Monk et al. | Nov 2013 | A1 |
| 20140067677 | Ali et al. | Mar 2014 | A1 |
| 20140089182 | Short et al. | Mar 2014 | A1 |
| 20140164246 | Thomas et al. | Jun 2014 | A1 |
| 20140188728 | Dheer et al. | Jul 2014 | A1 |
| 20140289106 | Pawelczyk et al. | Sep 2014 | A1 |
| 20150046319 | Thomas et al. | Feb 2015 | A1 |
| 20150161597 | Subramanian et al. | Jun 2015 | A1 |
| 20150254665 | Bondesen | Sep 2015 | A1 |
| 20150324801 | Thomas et al. | Nov 2015 | A1 |
| 20160019536 | Ortiz et al. | Jan 2016 | A1 |
| 20160092872 | Prakash et al. | Mar 2016 | A1 |
| 20160358163 | Kumar et al. | Dec 2016 | A1 |
| 20160359829 | Gulledge | Dec 2016 | A1 |
| 20170221066 | Ledford | Aug 2017 | A1 |
| 20170344960 | Garlick et al. | Nov 2017 | A1 |
| 20170344964 | Garlick et al. | Nov 2017 | A1 |
| 20170353420 | Garlick et al. | Dec 2017 | A1 |
| 20170372319 | Garlick et al. | Dec 2017 | A1 |
| 20180012199 | Dunn et al. | Jan 2018 | A1 |
| 20180012200 | Dunn et al. | Jan 2018 | A1 |
| 20180012201 | Dunn et al. | Jan 2018 | A1 |
| 20180174140 | Garlick et al. | Jan 2018 | A1 |
| 20190043052 | Ledford et al. | Feb 2019 | A1 |
| 20200327515 | McCarley | Oct 2020 | A1 |
| Number | Date | Country |
|---|---|---|
| 2131667 | Jun 1995 | CA |
| 0 029 733 | Jun 1981 | EP |
| 0 593 209 | Apr 1994 | EP |
| 0 661 654 | Jul 1995 | EP |
| 2 328 310 | Feb 1999 | GB |
| 2533379 | Jun 2016 | GB |
| 2533380 | Jun 2016 | GB |
| 2533432 | Jun 2016 | GB |
| 2533562 | Jun 2016 | GB |
| 2537087 | Oct 2016 | GB |
| 9004837 | May 1990 | WO |
| 9106058 | May 1991 | WO |
| 9302424 | Feb 1993 | WO |
| 9512859 | May 1995 | WO |
| 9707468 | Feb 1997 | WO |
| 9722060 | Jun 1997 | WO |
| 9818095 | Apr 1998 | WO |
| 9847100 | Oct 1998 | WO |
| 9858356 | Dec 1998 | WO |
| 9956219 | Nov 1999 | WO |
| 0217196 | Feb 2002 | WO |
| 03060749 | Jul 2003 | WO |
| 2007053123 | May 2007 | WO |
| 2007056274 | May 2007 | WO |
| 2008027620 | Mar 2008 | WO |
| 2008027621 | Mar 2008 | WO |
| 2008060725 | May 2008 | WO |
| 2009114876 | Sep 2009 | WO |
| 2009152184 | Dec 2009 | WO |
| 2016097672 | Jun 2016 | WO |
| 2016097673 | Jun 2016 | WO |
| 2016097674 | Jun 2016 | WO |
| 2016097675 | Jun 2016 | WO |
| Entry |
|---|
| “Authentication in an Internet Banking Environment,” Federal Financial Institutions Examination Council, http://www.ffiec.gov/pdf/authentication_guidance.pdf, pp. 1-14, published 2005. |
| “Supplement to Authentication in an Internet Banking Environment,” Federal Financial Institutions Examination Council, http://www.ffiec.gov/pdflauth-its-final%206-22- 11%20(ffiec%20formated).pdf, pp. 1-12, published 2011. |
| “Suspicious Activity Monitoring—Anti-Money Laundering Solutions,” NICE-Actimize, www.niceactimize com, 4 pages, Mar. 15, 2014. |
| “ACI Proactive Risk Manager™ for Enterprise Risk—Product Flyer,” ACI Universal Payments, www aciworldwide.com, 4 pages, 2016. |
| “Guardian Analytics FraudDESK,” Guardian Analytics, www.guardiananalytics.com, 2 pages, 2016. |
| “SAS® Fraud Management—Real-time scoring of all transactions for fast, accurate fraud detection,” Product Brief, SAS, www.sas.com, 6 pages, 2015. |
| “Payment Trends in the Healthcare Industry,” A Survey of Healthcare Providers, pp. 5-38, Fall 2010. |
| The Clearing House, “Mayo Clinic Interview,” Healthcare EFT Enrollment, NACHA—The Electronic Payments Association, Healthcare EFT Enrollment, pp. 1-6, Mar. 14, 2011. |
| The Clearing House, “Healthcare EFT Enrollment, Mar. 25, 2011 Stakeholder Meeting Minutes & Wrap-Up,” NACHA—The Electronic Payments Association, pp. 1-22, Apr. 20, 2011. |
| The Clearing House, “Healthcare EFT Enrollment, Stakeholder Meeting Materials,” NACHA—The Electronic Payments Association, pp. 1-43, Mar. 25, 2011. |
| “A Primer on HIPAA and the ACH Network,” Banking Industry HIPAA Task Force, pp. 1-34. |
| Irfan Ahmad, “Payments Processor Perspective on EFT Enrollment,” Hearing 2—Section 10109 of the Affordable Care Act Provider Enrollment Forms, National Committee of Vital and Health Statistics (NCVHS) Subcommittee on Standards, pp. 1-5, Nov. 18, 2011. |
| Irfan Ahmad, “Payments Processor Perspective on EFT Enrollment,” Hearing 2—Section 10109 of the Affordable Care Act Provider Enrollment Forms, National Committee of Vital and Health Statistics (NCVHS) Subcommittee on Standards, pp. 1-6, Nov. 15, 2010. |
| Russ Waterhouse, “Administrative Simplification under the Patient Protection and Affordable Care Act Standards and Operating Rules for Electronic Funds Transfer (EFT) and Remittance Advice (RA),” National Committee of Vital and Health Statistics (NCVHS) Subcommittee on Standards, pp. 1-11, Dec. 3, 2010. |
| J.P. Morgan, “Addressing the Administrative Cost Trajectory in a New Environment,” Post-Reform Opportunities for Healthcare Payments, pp. 1-14, Apr. 27, 2010. |
| Matthew Smith and Victoria Terekhova, “Electronic Payments in Healthcare: Overcoming the Challenges,” pp. 1-25, Apr. 3-6, 2011. |
| Gwendolyn Lohse et al., “Federal Operating Rules for Healthcare Administrative Simplification,” 2011 Payments, NACHA—The Electronic Payments Association, pp. 1-32, Apr. 3-6, 2011. |
| Matt Brodis et al., “Best Practices for Migrating Healthcare Payments to ACH,” pp. 1-39, Apr. 3-6, 2011. |
| “Healthcare in the Electronic Environment, Payment, Information and Communication Within the Revenue Cycle,” Alacriti Clearwave, 2011 Payments, pp. 1-30, Apr. 3-6, 2011. |
| B. Arnold et al., “Increasing eBilling in the Healthcare Industry Without Running Afoul of Privacy Laws,” 2011 Payments, pp. 1-29, Apr. 3-6, 2011. |
| Russ Waterhouse et al., “The Healthcare Payments Solution: What's In It for the Banking Industry,” NACHA Payments 2011, pp. 1-17, Apr. 5, 2011. |
| “CAQH Committee on Operating Rules for Information Exchange (CORE), Phase III Core ETF & ERA Operating Rule Set,” pp. 1-138, Jun. 2012. |
| Russ Waterhouse, “National Committee on Vital and Health Statistics (NCVHS) Subcommittee on Standards, Administrative Simplification Under the Patient Protection and Affordable Care Act, Standards and Operating Rules for Electronic Funds Transfer (ETF) and Remittances Advice (RA),” The Clearing House, pp. 1-5, Dec. 3, 2010. |
| Robert Hunter, “Letter Re: CMS-0024-IFC, Adoption of Standards for Health Care ETFs and Remittance Advice,” pp. 1-10, Mar. 12, 2012. |
| Department of Health and Human Services, Federal Register, vol. 77, No. 6, pp. 1556-1590, Jan. 10, 2012. |
| J. Steven Stone et al., “Healthcare Reform: What Does It Really Mean for Banks?,” NACHA, pp. 1-37, 2011. |
| Henry Ijams et al., “Evaluating ePayables Opportunities to Improve A/P Efficiencies,” pp. 1-28, Jun. 22, 2011. |
| J. Estep, “Ninth National Medical Banking Institute, The Growing Collaboration of eHealth and Medical Banking, Banks Engaging in Healthcare Reform,” pp. 1-20, Feb. 21, 2011. |
| “Ninth National Medical Banking Institute, The Growing Collaboration of eHealth and Medical Banking, HIMSS G7 Operating Rules in Healthcare,” pp. 1-11, Feb. 15, 2011. |
| Richard D. Marks, “Ninth National Medical Banking Institute, The Growing Collaboration of eHealth and Medical Banking, Health Record Banking: Changing the Game for Healthcare Information Technology, An Analysis of Checking Accounts for Health Information,” pp. 1-13, Feb. 10, 2011. |
| Jim St. Clair et al., “Ninth National Medical Banking Institute, The Growing Collaboration of eHealth and Medical Banking, Banking Platforms: Creating Programs to Speed Innovation in Healthcare,” pp. 1-28, Feb. 11, 2011. |
| The Clearing House, “Healthcare ETF Enrollment, Stakeholder Meeting: Pre-read Materials,” NACHA—The Electronic Payments Association, pp. 1-21, Mar. 25, 2011. |
| “820 Payment Order/Remittance Advice” Version: X12-4010, pp. 1-61, Sep. 2005. |
| “835 Health Care Claim Payment/Advice” Version: 1.0 Final, pp. 1-70, Jul. 20, 2011. |
| Priya Malhotra, “Clearing House Enumerates e-Payment Ills,” American Banker, Aug. 13, 2002. |
| “Simplify Reconciliation Using Trace Reassociation Number (TRN) Segment,” Emdeon; Jun. 15, 2012. This reference was previously provided under U.S. Appl. No. 14/166,423. |
| “Proposal to Faster Payments Task Force,” Faster Payments Qiat, The Clearing House and FIS, Feb. 21, 2017, 170 pages. |
| U.S. Office Action for U.S. Appl. No. 15/488,848 dated Aug. 7, 2019. |
| “TCH Real-Time Payments BAFT/ABA Global Payments Symposium,” The ClearingHouse, Jul. 14, 2016, 6 pgs. |
| Davey, Peter, “Real-Time Payments: Addressing Decades-Old Chalenges Facing Treasury Professionals,” The ClearingHouse, Mar. 2017, 28 pgs. |
| “Information Interchange 2016—Hit it Out of the Park with Payments!”, EastPay, Mar. 2, 2016, 6 pgs. |
| “TCH Real-Time Payments,” The ClearingHouse, Mar. 9, 2016, 18 pgs. |
| “TCH Real-Time Payments,” The ClearingHouse, Feb. 17, 2016, 12 pgs. |
| “TCH Real-Time Payments Briefing for the OCC,” The ClearingHouse, Mar. 18, 2016, 6 pgs. |
| “TCH Real-Time Payments,” The ClearingHouse, Oct. 7, 2016, 13 pgs. |
| Ledford, Steve, “Real-time Payments Overview,” The ClearingHouse, Oct. 3, 2016, 9 pgs. |
| “Real-Time Payments Operations Playbook, Version 1.01,” The ClearingHouse, May 2016, 48 pgs. |
| “Appendix: Payment Opportunities Detail,” The ClearingHouse, Real-time Payments Stockholder Engagement Session, New York, Jun. 14-15, 2016, 46 pgs. |
| “U.S. Real-Time Payments Business Playbook, Version 1.03,” The ClearingHouse, Mar. 2016, 45 pgs. |
| “U.S. Real-Time Payments Technology Playbook, Version 1.0,” The ClearingHouse, Nov. 2016, 35 pgs. |
| “TCH Real-Time Payments,” The ClearingHouse, Aug. 19, 2016, 17 pgs. |
| 250 U.S. Banks to Use NCR, Cincinnati Bell Financial Systems, AT&T News Release, http://www.att.com/news/0593/930504.ncd.html, 2 pages (May 4, 1993). |
| “3174 Configuration,” http://www.commercecomputer.com/3174.html, Commerce Computer Corporation, 3 pages (Downloaded Oct. 7, 2002). |
| 3174 Network Processor, Specification Sheet, http://ecc400.com/ibm/controllers/31.prod.htm, Downloaded Oct. 7, 2002. |
| 7780 Mid-Range Item Processing—Product Overview, NCR Corporation, http://www.ncr.com/products/hardware/hw_7780_ts_product.htm, 4 pages (Downloaded Nov. 15, 2002). |
| 7780 Mid-Range Item Processing—Technical Specifications, NCR Corporation, http//www.ncr.com/products/hardware/hw__7780__ts__product.htm, 1 page (Downloaded Nov. 15, 2002). |
| 7780—The Robust, Reliable Solution . . . for Processing Varying Volumes in any Environment, NCR Corporation, 8 pages (1998). |
| About FSTC, Financial Services Technology Consortium, http://www.fstc.org/about/history.cfm, 2 pages (Downloaded Feb. 27, 2003). |
| Addink et al., “AS/400 ImagePlus Svstem View,” IBM Systems Journal, vol. 29, No. 3, pp. 451-466 (1990). |
| “American National Standard For Financial Image Interchange: Architecture, Overview and System Design Specification,” American Bankers Association, American National Standards Institute, Inc., pp. 1-202 (1994). |
| Anderson, Re: Electronic Check and Check Law, Letter to Robert Ballen, 2 pages (Apr. 8, 1996). |
| Anderson et al., “ImagePlus Workstation Program,” IBM Systems Journal, vol. 29, No. 3, pp. 398-407 (1990). |
| “ANSI/ABA X9.46-1995. Draft version 0.13, American National Standard For Financial Image Interchange: Architecture, Overview and System Design Specification,” American Bankers Association, American National Standards Institute, Inc., 229 pages (1995). |
| “ANSI/ABA X9.46-1997, American National Standard For Financial Image Interchange: Architecture, Overview and System Design Specification,” American Banker Association, American National Standards Institute. Inc., 245 pages (Jan. 21, 1997). |
| AT&T Global Offers One-Step Imaging. (AT&T Global Information Solutions) (Brief Article), American Banker, vol. 159. No. 39. p. 14A(1), 1 page (Feb. 28, 1994). |
| AT&T Partners with Fiserv to Form Single Source Provider for Leading Image Item Processing Solutions, PR Newswire, p. 913C1011, 2 pages (Sep. 13, 1995). |
| Atzel, Article Order, Email to Marshall J. Hambro, 1 page (Oct. 9, 2001). |
| Avers et al., “ImagePlus as a Model for Application Solution Development,” IBM Systems Journal, vol. 29, No. 3, pp. 356-370 {1990}. |
| Baby Boomers, Generation X are Both Addicted to the ATM, AT&T News Release, http://www.att.com/news/0295/950228.nca.html. 3 pages (Feb. 28, 1995). |
| Banctec Inc. has Received Another Order for Its Image Statement Processing Product. (First National Bank of Chicago Orders ImageFirst). Financial Services Report, vol. 8, No. 22, p. 5(2) (Nov. 13, 1991). |
| Banet, Document Image Processing, 1991: The Imaging Edge, Seybold Report on Publishing Systems, vol. 20. No. 19, p. 22(8), 10 pages (Jun. 24, 1991). |
| Bank Automation News, Phillips Business Information, vol. 9, Issue 6, 2 pages (Apr. 2, 1997). |
| Banks to Check Out Imaging (Solutions), Communicationsweek International, No. 093, p. 46, 2 pages (Oct. 19, 1992). |
| Barhel, “NCR and Unisys Exchange Check Images in a Pivotal Test. (Computer Makers Test Compatibility of Check Imaging Svstems),” American Banker. vol. 158, No. 67, p. 3(1), 2 pages (Apr. 8, 1993). |
| Barthel, “Unisys, Banctec Offer PC-based Imaging: High-tech Check Statements Produced; Community Banks are Market, (Banctec Systems Inc.),” American Banker, vol. 157, No. 195, p. 3(1) (Oct. 8, 1992). |
| Bartholomew, “More Checks On Checks—Bank of America Plans to Convert to an IBM Imaging System that Screens Checks Faster and More Thoroughly (Spotlight),” Informationweek, No. 504, p. 32 (Dec. 5, 1994). |
| Bartimo et al., “Fine Tuning the Terminal Picture,” ComputerWorld, Special Report, vol. XVII, No. 35, 48 pages (Aug. 29, 1983). |
| Beckett, P., “Credit-card Firms Get Into Web Game,” Asian Wall Street Journal, p. NI, 1 page (Apr. 3, 2001). |
| Behnke, “NSSDC's Mass Storage System Evolves,” NSSDC, http://nssdc.gsfc.gov/nssdc_news/march95/09_j_behuke_0395.html, 2 pages (Mar. 1995). |
| Bill Processing: US West Re-engineers with $7.2 Million Unisys Image-based Remittance Processing Solution, EDGE, On & About AT&T, vol. 10, No. 378, 3 pages (Oct. 23, 1995). |
| Blankenhorn, “Cincinnati Bell and Unisys Go Into Bank Imaging, (Cincinnati Bell Information Systems, Inc.)”, Newsbytes, p. NEW10240020, 1 page (Oct. 24, 1990). |
| Block, USAA Federal Gets Imaging System, (USAA Federal Savings Bank. Cincinatti Bell Information Systems Inc.) (Brief Article), American Banker, vol. 159, No. 49, p. 6A(I), page (Mar. 14, 1994). |
| Booker, “Bank to Test Scalable NCR Imaging for Check Processing,” Computerworld, p. 66, 2 pages (Dec. 14, 1992). |
| Broadway & Seymour Announces Client/Server Product for Item and Image Processing, Business Wire, p. 03201186, 2 pages (Mar. 20, 1995). |
| Broadwav & Seymore Announces New VISUALIMPACT Release, Business Wire, p. 3291274 2 pages (Mar. 29, 1996). |
| Broadway & Seymour to Invest in Two Strategic Initiatives, Business Wire, p. 03151248, 2 pages (Mar. 15, 1995). |
| Brooks, A., “Still Waiting for the E-Mail and Faxes to Start Coming In?”, The New York Times. (East Coast Late Edition), New York, NY, Dec. 19, 1996, p. C7, 2 pages. |
| Brown, “Imaging May Dramatically Alter Bank Data Networks,” Network World, vol. 6, No. 19, p. 6(2), 1 page (May 15, 1989). |
| Brown, R.J., ANSI X9.46, Data Structure Reference, IBM Corporations, 16 pages (Jul. 31, 1995). |
| Brown. R.J., “FSTC Image Interchange Project: Pilot Phase-1A Preliminary Architecture and Project Plan,” 34 pages (Jun. 30, 1995). |
| Buchok, “OCR Gets Processing Credit,” Computing Canada, vol. 19, No. 26, p. 30(1), 1 page (Dec. 20, 1993). |
| “By-law No. 7 Resvecting the Large Value Transfer System,” Canada Gazette, Part I, vol. 132, No. 16 (Canadian Government Publishing, online: Archive 1998, Part I http://canadagazette.gc.ca/part1/1998/19980418/pdf/g1-13216.pdf Apr. 18, 1998, 71 pages. |
| Cahill, T.P., “Image Processing Applications at the Chase Manhattan Bank,” 2 pages (date unknown). |
| Cantwell, Data Compression Over Frame Relay Implementation Agreement FRF.9, Frame Relay Forum Technical Committee, 38 pages (Jan. 22, 1996). |
| Carey, T.W., “Quicken versus Money,” PC World, vol. 14, No. 4, p. 162(6), 8 pages (Apr. 1996). |
| Casey et al., “Intelligent Forms Processing,” IBM Systems Journal, vol. 29, No. 3, pp. 435-450 (1990). |
| CashFlex Selects NCR Item Processing Systems for Lockbox, AT&T News Release, http://www.att.com/news/0793/930712.ncd.html, 2 pages (Jul. 12, 1993). |
| Chase's New Image (Chase Manhattan Awards 12-yrs Image-processing Contract to Flserv; Contract Could Generate $40 mil/yr in Revenue for Flserv), Information Week, No. 517, p. 14, 1 page (Mar. 6, 1995). |
| “Check Adjustment Quick Reference Guide,” Federal Reserve System, 10 pages (Jul. 1996). |
| Check Adjustment Request Federal Reserve Bank, Form FRBADJ, 1 page (Sep. 1993). |
| “Check Clearing forthe 21st Century Act: Frequently Asked Questions about Check 21,” http://www.federalreserve.gov/paymentsystems/truncation/faqs.htm. The Federal Reserve Board, 2 pages (Jan. 27, 2005). |
| Check Image Exchange Project—Project Participants, FSTC Projects, FSTC, http://www.fstc.org/projects/imaging/participants.cfm, 1 page (Downloaded Oct. 30, 2002). |
| Check-Image Interchange Inches Closer (New York Clearing House, Chase Manhattan Bank and Federal Reserve Bank of Boston All Launch Check-image Interchange Program), Bank Technology News, vol. 10, No. 1, p. 19+, 2 pages (Jan. 1997). |
| “Check Image Processing Archive and Retrieval System Proposal: Technical Volume—Total System Solution Overview,” BancTec, Incorporated, 128 pages (Jul. 8, 1994). |
| Check Image Processing Delivers Truncation Benefits Today, NCR Reports—Financial Sendees Trends & Technologies, NCR Corporation, vol. 1, Iss. 8, 13 pages (1997). |
| Check Technology Case Stays in Texas, IP Law Bulletin, 4 pages (Oct. 13, 2005). |
| Checks & Checking: Check Imaging at the Teller Station, Bank Technology News, vol. 9, No. 10, p. 37 (Oct. 1996). |
| Chemical Chooses IBM Check Imaging (Chemical Banking Corp to Install IBM's ImagePlus High Performance Transaction System to Process 9 Mil Checks Daily), Bank Technology News, vol. 8, No. 9, p. 11 (Sep. 1995). |
| Cincinnati Bell: CBIS & Unisys in Major Imaging Agreement, EDGE, On & About AT&T, vol. 5, No. 118, 1 page (Oct. 29, 1990). |
| Cincinnati Bell Information Systems (Integrator Briefs), Computer Reseller News, No. 534, p. 129 (Jul. 12, 1993). |
| Cisco Partners with AT&T CMS on Network Switch Manufacturing, Lucent Technologies, http://www.lucent.com/press/0995/950926.mma.html, 2 pages (Sep. 26, 1995). |
| Citibank, New Castle Installation, one page (no date available). |
| Cooney. “*Frame* *Relay* Comes to Computerm Extenders,” Network World, p. 14, 2 pages (Jun. 28, 1993). |
| Company Background and Product Guide, MagTek, 42 pages (no date available). |
| Computerm Announces Remote Check Imaging Support for VMC 8200 High-speed Channel Extension System, PR Newswire, p. 408LAM012, 2 pages (Apr. 8, 1996). |
| Computerm Earns MCI “Level 1” Approval; Computerm's Industry Exclusive Native *Frame * *Relay* Interface Passes Test for Interoperability with MCI's *Frame* *Relay* Services, Business Wire, p. 4121139, 2 pages (Apr. 12, 1995). |
| Computerm Eases Remote Imaging, (Introduces Remote Image Solution) Brief Article, American Banker, vol. 158, No. 156, p. 13A(1), 1 page (Aug. 16, 1993). |
| Computerm Enables Boatmen's Bancshares to Execute Remote Check Imaging, PR Newswire, p. 408LAM013 (Apr. 8, 1996). |
| Cortese, “Image Yields Interest at Banks, Collaboration Results in Imaging System to Automate Check Processing”, Computerworld, p. 6, 2 pages (Mar. 19, 1990). |
| Costanzo, “As Banks Cling To The Conventional, Check-imaging Struts Its Stuff,” Bank Technology News, p. 1, 5 pages (Mar. 1994). |
| Crockett, Systematics to Use Deposited-check Imaging; Installation at Firm's N.J. Center Would Be The First By An Outsourcer, Systematics Financial Services Inc., Unisys Corp., American Banker, vol. 158, No. 95, p. 3(1), 2 pages (May 19, 1993). |
| Crone, Reducing Data Processing Costs with a Remote Item Processing System, Bank Administration, vol. 62, No. 10, pp. 44-46 (Oct. 1986). |
| Cummings, S., “Home Banking with Quicken,” New York: MIS Press, 15 pages (1996). |
| Current Check Flow, PowerPoint Presentation, Check[1].ppt, pp. 1-4. |
| “Declaration of Richard Jesmajian,” In re Claudio R. Ballard for Remote Image Capture with Centralized Processing and Storage, 3 pages (Nov. 18, 2005). |
| Depompa, “IBM Adds Image-based Processing,” MIS Week, vol. 11, No. 12, p. 12(1), 2 pages (Mar. 19, 1990). |
| Dinan et al., “ImagePlus High Performance Transaction System,” IBM Systems Journal, vol. 29, No. 3, pp. 421-434 (1990). |
| Dowdell, “Security,” Email to fstc-imagE, 2 pages (Apr. 27, 1996). |
| ECheck: Homepage, http://www.echeck.org. Downloaded Feb. 27, 2003, 1 page. |
| “Electronic Check Adjustments: Are You Using FedLine?”, The Federal Reserve Bank of St. Louis, http://www.stlouisfed.com/publications/pq/1998/a/pq1998a5.html, 3 pages (Spring 1998). |
| “Electronic Imaging '88—International Electronic Imaging Exposition & Conference,” (Advance Printing of Paper Summaries), Anaheim, California, Mar. 28-31, 1988, 26 pages. |
| Electronic Payment Systems Support/Check Processing Control System: Program Reference and Operations Manual, IBM Corporation, 6 pages (Jun. 1986). |
| Encryption and Digital Signature Explained, Northern Telecom Inc., 4 pages (no date available). |
| European Search Repot for Application No. 03728532.7 dated Feb. 15, 2008, 3 pages. |
| Evans, “The End of Paper Wait: Document Imaging, (includes related articles on successful document imaging implementations at Borgess Medical Center, the Huntington Internal Medicine Group, the University of Alabama Health Services Foundation and Quest Diagnostics)(Indusuy Trend or Event),” Health Management Technology, vol. 18, No. 2, p. 16(5), 7 pages (Feb. 1997). |
| Fassett, “Impact of Imaging,” Bank Management, vol. 67, No. 11, p. 56, 1 page (Nov. 1991). |
| “Financial EDI over the Internet, A pilot conducted bv BankAmerica and Lawrence Livermore National Laboratory,” Bank of America, 1996. http://www.bofa.com/batoday/edi_briefing.html, 7 pages (Copyright 1996). |
| “Financial Services Technology Consortium—Interbank Check Imaging Project—White Paper (Draft),” FSTC, pp. 1-29 (Jun. 20, 1994). |
| Fisher, “IBM, Customers Continue Work on Document Image Processor,” Datamation, vol. 34, No. 19, 3 pages (Oct. 1, 1988). |
| Fitch, “Check Image Capture Speeds Up Positive Pay Reconcilement,” Corporate Cashflow, pp. 7 & 11 (Feb. 1995). |
| Fitch, “Digital Image Systems Speed Return Items, Exceptions,” Corporate Cashflow, pp. 8 & 10 (May 1996). |
| Frequently Asked Questions on Drive Space Issues, Drive Space FAQ, 1 page (date unknown). |
| Fricke, “PACES Paperless Automated Check Exchange & Settlement Next Steps,” Chase Manhattan Bank, 10 pages (Aug. 12, 1997). |
| Frost National Bank Selects NCR Over Old Mainframe Environment, AT&T News Release, http://www.aft.com/news/0493/930428.nca.html, 2 pages (Apr. 28, 1993). |
| “FSTC Check Image Interchange Project—Archive Storage and Retrieval Component Decomposition,” 20 pages (May 25, 1995). |
| FSTC Demonstrates Interbank Check Image Pilot; Multi-vendor System Speeds Check Clearing, Cuts Fraud, FSTC Projects—Check Image Exchange Project, Press Release, http//www.fstc.orq/projects/imaging/public/information.cfm, 2 pages (Dec. 12, 1995). |
| FSTC Financial Services Technology Consortium, PowerPoint Presentation, Ansi6v4[1].ppt, pp. 1-27 (no date available). |
| FSTC Interbank Check Imaging Unisys Monthly Status Report, pp. 1-7 (Jun. 26, 1996). |
| FSTC Interbank Check Imaging Unisys Monthly Status Report, pp. 1-9 (Jul. 22, 1996). |
| FSTC Projects, Check Image Exchange Project (a.k.a Interbank Check Imaging Project), Financial Services Technology Consortium, http://www.fstc.org/projects/imaging/index.cfm, 6 pages (Downloaded Oct. 30, 2002). |
| Garvey, “Check Processing Goes Digital—Chase Manhattan Batik to Store Checks Electronically, Saving Time and Money,” Informationweek, No. 648, p. 20, 1 page (Sep. 15, 1997). |
| Gawen, “PC Based Document Image Processing and Signature Verification,” OIS IMC91 Document Imaging, Proceedings of the Information & Image Management Conference, London, pp. 389-391 (Jul. 1991). |
| Glooal Concepts—Payment Systems Consulting, Global Concepts, Inc., http://www.global-concepts.com/image_archive.htm, 1 page (Downloaded Nov. 20, 2002). |
| Graf, R.F., “Modern Dictionary of Electronics,” 6th Edition, 5 pages (1997). |
| Gullo, “NCR, Unisys Plan Check Imaging for IBM Systems,” American Banker, vol. 156, No. 249, p. 1(2). 2 pages (Dec. 30, 1991). |
| Hakeda, “The Image Object Content Architecture,” IBM Systems Journal, vol. 29, No. 3, pp. 333-342 (1990). |
| Hanna, FSTC Image Exchange, POS Image Capture Pilot—Reader-Scanner Study, RDM Corp, 1 page (May 21, 1996). |
| Harding et al., “Object Storage Hierarchy Management” IBM Systems Journal, vol. 29, No. 3, pp. 384-397 (1990). |
| Helm, “Banks Check Into Image Processing,” Computers in Banking, vol. 7, No. 3, p. 25(7), 8 pages (Mar. 1990). |
| Helm, “Who's Doing What in Image Processing, (includes definition of image processing),” ABA Banking Journal, vol. 83, No. 1, p. 31(3), 6 pages (Jan. 1991). |
| Helms, “Introductionto Image Technology,” IBM Systems Journal, vol. 29, No. 3, pp. 313-332 (1990). |
| High-Volume Data Capture Sans the Paper, Bank Svstems & Technology, p. 35 (May 1996). |
| Horine, “AT&T and Fiserv Team to Offer Imaging Solutions,” AT&T News Release, http://www.att.com/news/0995/9509I3.nca.html, 2 pages (Sep. 13, 1995). |
| Huntington Bancshares in the Forefront of Technology with Purchase of Unisys Check Imaging Svstem, PR Newswire, p. 1 (Oct. 11, 1989). |
| IBM 3898 Image Processor, Product Announcement, IBM, 3 pages (Mar. 19, 1990). |
| “IBM 3995 Optical Library Dataserver—Economical, high-capacity, removable optical storage,” IBM Corporation, 4 pages (1991). |
| “IBM Proposal for FRB Phase Four: Image Archive System,” IBM Financial Document Processing, IBM, 175 pages (Nov. 7, 1991). |
| “IBM ImagePlus Fact Sheet,” IBM Corporation, 2 pages (1991). |
| “IBM's ImagePlus eases transformation of the Worker's Compensation Board,” IBM Corporation, 2 pages (1991). |
| “IBM's ImagePlus key to improving Royal Trust's customer service,” IBM Corporation, 2 pages (1991). |
| “IBM's ImagePlus: Making USAA's ‘Impossible Dream’ a reality,” IBM Corporation, 3 pages (1991). |
| IBM X9.46 Pilot Status—Summary, 3 pages (no date available). |
| “Ibnamed, A Load Balancing Name Server Written in Perl,” http://www.standford. edu/-schemers/docs/Ibnamed/lbnamed.html, 5 pages (Sep. 17, 1995). |
| “ICI Project Security Work Session, Agenda,” 3 pages (May 10, 1996). |
| IdeaCopTM OpenOpposition Prior Art Report for U.S. Pat. No. 5,910,988 by PatenTrakkerTM, Email regarding USPTO Reexam. C.N. 90/007,829, Requested Date: Nov. 25, 2005, from “PT” <admnin@patentrakker.com>, pp. 1-13 (May 10, 2006). |
| “Image Archive Forum—Payments Systems Task Force—Economic Framework,” 33 pages (Jan. 27, 1998). |
| “Image Archive Forum—Payments System Task Force—Introduction,” 52 pages (1998). |
| Image Can Be . . . Everything!, At Your Service, A Newsletter from the Federal Reserve Bank of Kansas City, pp. 1-6 (Special Edition—Summer 1995). |
| Image Processing Survival Guide. vol. II—Sure-Fire Strategies for Imolementing Image-Remittance, Phillips Business Information Inc., 40 pages (1996). |
| “Image systems gamer NOAC spotlight (American Bankers' Association's National Operations and Automation Conference),” Computer in Banking, vol. 6, No. 7, p. 8(4), 9 pages (Jul. 1989). |
| “Image Quality Functional Requirements,” FSTC, Chase Manhattan Bank, 19 pages (Jul. 26, 1995). |
| Imaging Products, United States Banker, vol. 100, No. 8, p. 23(3), 6 pages (Aug. 1990). |
| Imaging Technology: Generating New Bank Revenues in the Age of the Consumer, NCR Reports—Financial Services Trends & Technologies, NCR Corporation, Issue 1, 4 pages (Jan. 1997). |
| Imaging Vendors Shape Processing, Banking Management, vol. 69, No. 4, p. 29, 1 page (Apr. 1993). |
| Implementing Imaging Payment Systems: Managing Change to Achieve Results, NCR Reports—Financial Services Trends & Technologies, NCR Corporation, Issue 2, 3 pages (Feb. 1997). |
| Implementing National Electronic Payment System in Emerging Economies. NCR Reports—Financial Services Trends & Technologies, NCR Corporation, vol. 1, Issue 7, 12 pages (1997). |
| “Industry Security Leader Racal Supports Visa/Mastercard Proposal for Internet,” PR Newswire, 2 pages (Apr. 17, 1996). |
| Information Technology Outsourcing: Sharpening Management Focus in Financial Institutions, NCR Reports—Financial Services Trends & Technologies, NCR Corporation, Issue 5, 6 pages (1997). |
| Integrated, Customer-Focused Banking Architecture: Tomorrow's Competitive Edge, NCR Reports—Financial Services Trends & Technologies, NCR Coiporation, Issue 3, 6 pages (Mar. 1997). |
| Interbank Check Image Project, FSTC, PowerPoint Presentation, No. 1016V4[1]ppt, 18 pages (no date available). |
| Interbank Check Imaging, FSTC General Meeting—Orlando, Florida, 5 pages (Apr. 17, 1997). |
| International Search Report for Application No. PCT/US00/33010 dated Jun. 21, 2002, 4 pages. |
| Introducing the Age of Document-Image Processing, FileNetTM Brochure, FileNet Corporation, 13 pages (1984). |
| Item Processing Leaps Ahead with VisualImpact and Windows NT. (Sponsored Supplement: Unlock Your Back Office with Microsoft BackOffice), US Banker, vol. 105, No. 6, p. S4(3), 4 pages (Jun. 1995). |
| Janusky, FSTC Interbank Check Imaging, 6 pages (Apr. 29, 1996). |
| Janusky, FSTC Interbank Check Imaging, 7 pages (May 22, 1996). |
| Joint Marketing & Referral Agreement Between ACS Image Solutions, Inc. and JPMorgan Chase Bank, 27 pages (Mar. 15, 2002). |
| JPMorgan Chase and DataTreasury Settle Patent Dispute, Company Announcement, DataTreasury Corporation, http://wvww.finextra.com/fullpr.asp?pf=y&id-4989, 1 page (Jul. 6, 2005). |
| Kingman III et al., “Operational Image Systems: A New Opportunity,” IBM Systems Journal, vol. 29, No. 3, pp. 304-312 (1990). |
| Kingson et al., “E-Processing by Banks: Idea Gains Ground,” American Banker, 2 pages (Apr. 26, 2001). |
| Kniskern, “Engineering A Visionary Solution,” Datamation, vol. 36, No. 8, pp. 1-3 (Apr. 15, 1990). |
| Kniskern, J.M., “Strategic Rethinking,” 6 pages (date unknown). |
| Kutler, “AT&T, IBM and Unisys Join Bank Resrearch Group. (Financial Services Technology Consortium),” American Banker, vol. 159, No. 124, p. 14(1), 3 pages (Jun. 29, 1994). |
| Lee et al., NOVAHID: A Novel Architecture for Asvachronous Hierarchical. International, Distributed, Real-Time Payments Processing, IEEE Journal on Selected Areas in Communications, vol. 12, No. 6, pp. 1072-1087 (Aug. 1994). |
| MagTek Adds Enhanced Reading To MICRImageTM—New Reading Capability Supports Check Conversion with Higher Reliability, MagTek Press Release, 3 pages (Jan. 9, 2003). |
| MagTek Unveils Excella, a Dual-side Scanner for Check 21 Applications, 1 page (May 10, 2004). |
| MagTek Upgrades Its MICRImageTM Check Reader/Scanner—V.34 Modem Supports High-Speed Image Archiving for Check Conversion, MagTek Press Release, 3 pages (Jun. 12, 2002). |
| MagTek's MICRImage Transmits Check Images at Speed of Ethernet, MagTek Press Release, 2 pages (Feb. 14, 2002). |
| Mantel, “Notes Gets In The Picture,” Datamation, pp. 87 & 88 (Jul. 15, 1992). |
| Marjanovic, “Home Loan Bank to Offer Check-image Statements to Members' Customers. (Federal Home Loan Bank of Pittsburgh)(Brief Article),” American Banker, vol. 159, No. 248, p. 14(1), 2 pages (Dec. 29, 1994). |
| Marjanovic, “Mich. National Streamlines Imaging with IBM System, (check imaging),” American Banker, vol. 160, No. 176, pp. 1-2 (Sep. 13, 1995). |
| Marjanovic, “Payment Groups Square Off Over Electronic Check Plan,” American Banker, 1 page (May 8, 1996). |
| McGinn, “IBM ImagePlus High Performance Transaction System. (IBM Harnesses Image Processing to Make its 389x/XP Cheque Processors More Efficient)(Product Announcement),” Computergram International, No. 1389, p. CG103210008, 2 pages(Mar. 21, 1990). |
| Messmer, “Hurdles Stand in Way of Electronic Checking,” Network World, p. 33, 1 page (Sep. 4, 1995). |
| Messmer, E., “Banks Turn to Web for Check Processing,” Network World, Framingham, vol. 17, Issue 25, 3 pages (Jun. 19, 2000). |
| Methodology and Value, Image Archive Forum, 20 pages (Sep. 19, 1997). |
| Meyerson, “PACES Redeposit Processing,” pp. 1-60 (no date available). |
| MICR Technology' Helps Eliminate POS Check Fraud, Chain Store Age Executive, p. 79 (Sep. 1991). |
| “Microsoft Introduces SNA Server Version 3.0, Begins Beta Testing,” Microsoft Press Release, http://www. microsoft.com/presspass/press/1996/jun96/sna30pr.mspx, 4 pages (Jun. 17, 1996). |
| Minoli, D., “Imaging in Corporate Environments Techmnology and Communication,” McGraw-Hill, Inc., 315 pages (1994). |
| Moore, “IBM, Unisys Test Check Systems for Fed Reserve,” Federal Computer Week, vol. 6, No. 21. p. 6(2), 1 page (Jul. 27. 1992). |
| Moreau, “Payment by Authenticated Facsimile Transmission A Check Replacement Technology for Small and Medium Enterprises—Payment Processing Overview,” CONNOTECH, http://connotech.com/PAYPROC.HTM, 23 pages (Downloaded Nov. 25, 2006). |
| Morris et al., “Image System Communications,” IBM Systems Journal, vol. 29, No. 3, pp. 371-383 (1990). |
| Morton, W., “E-Commerce (A Special Report): A Consumer's Guide—Payments—Check It Out: The Web is suddenly crowded with online-payment services; Here's how they compare,” The Wall Street Journal, New York, NY, p. R13, 4 pages (Dec. 10, 2001). |
| Murphy, POD Check Imaging Faces New Challenges (In 1995 vs 1996, banks raised investment in check imaging by 9% from $198 mil and $215 mil; new low cost POD technology keeps it down), Bank Technology News, vol. 10, No. 3, p. 2.3, 3 pages (Mar. 1997). |
| National City, NCR Form Strategic Imaging Partnership, AT&T News Release. http://www.att.com/news/1192/921109.nca.hlml, 3 pages (Nov. 9, 1992). |
| NCR, CKI to Market Image-based Credit Card Chargeback System, AT&T News Release, http://www.att.com/news/0193/930106.ncb.html, 2 pages (Jan. 6, 1993). |
| NCR and Arkansas Systems Announce Strategic Alliance, AT&T News Release, http://www.att.com/news/0793/930712.ncb.html, 2 pages (Jul. 12, 1993). |
| NCR and Cincinnati Bell Offer Image Processing Service, AT&T News Release, http://www.att.com/news/0194/940111.nca.html, 2 pages (Jan. 11, 1994). |
| NCR and NYCH to Develop Image-based Check Notification System, AT&T News Release, http://www.att.com/news/0892/920824.ncb.html, 2 pages (Aug. 14, 1992). |
| NCR and Signet Banking to Provide Item Processing Services, AT&T News Release, http://www.att.com/news/0793/930713.ncb.html, 2 pages (Jul. 13, 1993). |
| NCR Demonstrates Full Line of Retail Products at NFR Conference, AT&T News Release, http://www.att.com/news/0193/930118.ncd.html, 3 pages (Jan. 18, 1993). |
| NCR Demonstrates Systems for Insurance and Accounting Industry, AT&T News Release, http://www.att.com/news/0592/920531.nca.html, 3 pages (May 31, 1992). |
| NCR Deposit Processing Technology Speeds Banking Operations, AT&T News Release, http://www.att.com/news/1292/921207.ncc.html, 3 pages (Dec. 7, 1992). |
| NCR Document Management System Includes Kodak, Ricoh Products, AT&T News Release, http://www.att.com/news/0493/930406.ncc.html, 3 pages (Apr. 6, 1993). |
| NCR Introduces Scalable Image Item Processing Solution, AT&T News Release, http://www.att.com/news/0196/960119.nca.html, 3 pages (Jan. 19, 1996). |
| NCR Offers New Image-Based Document Management System, AT&T News Release, http://www.att.com/news/0692/920623.ncb.html 3 pages (Jun. 23, 1992). |
| NCR Reports—Financial Services Trends & Technologies, NCR Corporation, Issue 4, 6 pages (1997). |
| NCR Signs DSI Alliance for Imaging Statement Processing, AT&T News Release, http//www.att.com/news/0792/920720.nca.htl, 2 pages (Jul. 20, 1992). |
| NCR Unveils Client-Server Check Imaging (NCR introduced NCR Scalable Image Item Processing Solution, a client-server based systemfot image-based check processing), Bank Technology News, vol. 9, No. 3, p. 23, 1 page (Mar. 1996). |
| New ATM from At&T GIS Features Automated Document Processing, AT&T News Release, http://www.att.com/news/1194/941129.ucb.html 4 pages (Nov. 29, 1994). |
| New Mexico Uses NCR Imaging Systems for Tax, Revenue Processing, AT&T News Release, http://www.att.com/news/0793/930712.ncc.html, 2 pages (Jul. 12, 1993). |
| “New Universal Payment Identification Code Will Become Industry Standard for I-Enabled Payments,” The Clearing House Press Release, 2 pages (Apr. 24, 2001). |
| “New York Clearing House—A Proposal for an Image-based Return Item Processing System,” Unisys, Document No. PDC 1010-16, 126 pages (Jun. 1991). |
| News Release, Retail Banking Solution Enhanced, AT&T News Release, http.//www.att.com/news/0590/900521.nca.html, 2 pages (May 21, 1990). |
| Nixdorf Computer Introduces DCPA Image—A Sophisticated Document Image Processing System with Unglue Capabilities, PR Newswire, 3 pages (Aug. 15, 1989). |
| Nixon, “Is Check Imaging For You? (automation in banking) related articles),” Savings & Community Banker, vol. 2, No. 10, p. 28(6), 6 pages (Oct. 1993). |
| Norwest Bank Selects NCR Image-based Processing Systems, AT&T News Release, http://www.att.com/news/0893/930802.nca.html, 3 pages (Aug. 2, 1993). |
| Nugent, W.R., “Specifications for a Stack Droid: Robotics Required For Large Libraries of Digitized Images on Optical Disk,” 1 page (date unknown). |
| “NYCH Project Shows Promise for Facilitating E-Payments,” AFP Pulse, The News Source for Financial Professionals, 2 pages (Mar. 2002). |
| O'Heney, Prepare for The Image Revolution. (Bankers and Vendors)(image processing; includes related article listing image processing products)(buyers guide), Computers in Banking, vol. 6, No. 10, p. 24(6), 8 pages (Oct. 1989). |
| On The ImagingTechnology Front (Unisys Corp is in an accord to Remarket Broadway & Seymore Inc's VisualImpact software, a midrange check-imaging system), American Banker, vol. CLXI, No. 68, p. 26, 1 page (Apr. 10, 1996). |
| “PACES—Paperless Automated Check Exchange & Settlement—Business Requirements,” FSTC, PACESBusReq3[1].doc, 7 pages (Apr. 3, 1998). |
| PACES—Paperless Automated Check Exchange & Settlement—Project Proposal, FSTC, PACESPRO[1].doc, 25 pages (Apr. 23, 1998). |
| PACES—Paperless Automated Check Exchange & Settlement—Requirements Document, FSTC, PACESRequirements[1].doc, 25 pages (Apr. 3, 1998). |
| Padgett, T., “Melville, N. Y.—Based DataTreasurv Fights J.P. Morgan Chase over Patent,” Newsday, 4 pages (Oct. 22, 2003). |
| Paperless Automated Check Exchange and Settlement (PACES), FSTC Projects, http://www.fstc.org/projects/paces/projstatus.cfm, 2 pages (Jun. 22, 2000). |
| Perry et al., “Experience Gained in Implementing ImagePlus,” IBM Systems Journal, vol. 29, No. 3, pp. 467-488 (1990). |
| Plesums et al., “Large-Scale Image Systems: USAA Case Study,” IBM Systems Journal, vol. 29, No. 3, pp. 343-355 (1990). |
| “Real-Time Gross Settlement Systems,” Bank for International Settlements, 66 pages (Mar. 1997). |
| Regions Bank Selects ImageSoft to Provide Imaging Solution, Business Wire, p. 9161220, 2 pages (Sep. 16, 1997). |
| “Request for Proposal for Check Image Processing and Archival and Retrieval Systems for the Federal Reserve,” Federal Reserve Bank of Boston, Version 1.0, 246 pages (Apr. 21. 1994). |
| Rivest et al., “A Method for Obtaining Digital Signatures and Public-Key Cryptosystems,” 15 pages (Feb. 1978). |
| Roldan, Jr., “Image Quality White Paper,” FSTC PACES Project Document, Chase Manhattan Bank, pp. 1-18 (Feb. 18, 1999). |
| Roldan, PACES—Paces Models—FSTC Project, Chase Manhattan Bank, 19 pages (Jul. 17, 1997). |
| Roldan, “Project Overview—PACES Planning Meeting”, New York City, FSTC, PacesOverview40[1].ppt, 28 pages (Dec. 19, 1997). |
| Roth, A., “Banks Fund B2B Payment System Effort,” American Banker, 1 page (Apr. 24, 2001). |
| Ryman, “Personal Systems Image Application Architecture: Lessons Leaned from the ImagEdit Proaram,” IBM Systems Journal, vol. 29, No. 3, pp. 408-420 (1990). |
| Scheschuk, B., “Pay it on the Net,” CMA Management, vol. 75, Issue 4, pp. 30-34, 4 pages (Jun. 2001). |
| Schwartz, “Banks to Test Imaging for Clearing Checks,” CommunicationsWeek, p. 35, 2 pages (Sep. 14, 1992). |
| Signet Bank Processes Over 2,500 Documents/Hour in Unisys Check Imaging Tests, PR Newswire, p. 0409P8428, 2 pages (Apr. 9, 1991). |
| Softchec Licenses ‘Envision’ Image Solution to West Suburban Bank, PR Newswire, p. 116SETU002, 2 pages (Jan. 16, 1996). |
| Spencer, “Scanning Goes Vertical: A Big Future for Specialized Check Scanning, Check Scanning Technology,” Advanced Imaging, pp. 42-44 (Oct. 1997). |
| Stanley, P., “Pilot Overview,” 8 pages (Apr. 3, 1995). |
| “SurePOS ACE Electronic Payment Support PRPQ for 4690 OS User's Guide,” Version 1, Release 5, IBM, 281 pages (Mar. 2002). |
| Technical Volume—Check Image Processing Archive and Retrieval System—Proposal, BancTec, Inc., 469 pages (Jul. 8, 1994). |
| Ten Dyke, R.P., “Books,” IBM Svstems Journal, vol. 29, No. 1, pp. 489-490, 2 pages (1990). |
| Terminal Data to Supolv NCR with Document Microfiimers, AT&T News Release, http://www.att.com/news/1093/931013.nca.html 2 pages (Oct. 13, 1993). |
| “The Bank Internet Payment System (BIPS): Leading the Way to Electronic Commerce,” FSTC, http://www.fstc.org/projects/bips/index.cfm, 3 pages (Downloaded Feb. 27, 2003). |
| The Check Information Age, Vision Executive Summary Image Archive Forum, Payment System Task Force, 10 pages (Jan. 27, 1998). |
| The New Era of Check Scanning Technology—Introducing Excella, Specifically Designed to Meet the Processing Reauirements of Check21, MagTek. Inc., 22 pages (2005). |
| “The Remaining Barriers to ePayments and Straight-through Processing,” Research Conducted Oct. 2001-Mar. 2002 by The Clearing House, The Clearing House, 24 pages. |
| The Wachovia Story, RDM Corporation, 1 page (Oct. 1993). |
| Tracey, “IBM Unveils First Stage of Image-check System (product announcement),” Computers in Banking, vol. 7, No. 4, p. 13(3), 3 pages (Apr. 1990). |
| Tucker, “Broadway Rolls Out Check Imaging System for Community Banks (Broadway & Seymour Inc.),” American Banker, vol. 160, No. 61, p. 14(1), 2 pages (Mar. 30, 1995). |
| Understanding EDI, 2 pages (Mar. 2, 1996). |
| Unisys Acauires VisualImpact Solution for Check Processing, Archive & Image Delivery, Business Wire, p. 9181204, 3 pages (Sep. 19, 1997). |
| Unisys Enhances Check Imager (Unisys Corp. Makes Effort to Appeal to Wider Range of Financial Institutions), American Baker, vol. CLIX, No. 205, p. 15A, 1 page (Oct. 24, 1994). |
| Unisys Enters Image Processing Market with Two New Products and Major Financial and Industrial Customers. (product announcement), PR Newswire, p. 1011PH009, 3 pages (Oct. 11, 1989). |
| Unisys Integrates Retail/Wholesale Lockbox Solution for Remittance Processors, Business Wire, p. 03251075, 4 pages (Mar. 25, 1997). |
| Unisys Provides Services to Bank of the West to Support Retail Banking, Business Wire, p. 9180098, 2 pages (Sep. 19, 1995). |
| Unisys Solution will Support Check Processing at Vermont Federal, Business Wire, p. 5201185, 3 pages (May 20, 1996). |
| Unisys Wins Contract to Supply Imaging Solution to Chase Manhattan/FISERV Check Processing Alliance, Business Wire, p. 6121175, 2 pages (Jun. 12, 1995). |
| Unix-based Imge Statement Software (Cincinnati Bell Information Systems Inc. introduces ImageBanc II computer sollware)(Brief Article), ABA Banking Journal, vol. 85, No. 2, p. 80(1), 1 page (Feb. 1993). |
| Universal Card Purchases BancTec ImageFIRST System, AT&T News Release, http://www.att.com/news/1292/921222.uca.html, 2 pages (Dec. 22, 1992). |
| U.S. Appl. No. 14/926,112, filed Oct. 29, 2015 entitled “Secure Payment Processing”. |
| U.S. Appl. No. 15/970,058, filed May 3, 2018 entitled “Bill Pay Service With Federated Directory Model Support”. |
| Verifone Soilware Links PCs to the Point of Sale (Brief Article), American Banker, vol. 158, No. 156, p. 13A(1), 2 pages (Aug. 16, 1993). |
| Vermeire, D.R., “Prosecution of Check Image Patent,” letter to Peter Hanna, 1 page (Jul. 11, 1997). |
| Wachovia Tests NCR's New Imaging Item Processing Svstem, AT&T News Release, http://www.att.com/news/1091/911015.nca.html, 2 pages (Oct. 15, 1991). |
| Wagner, “Banc One Checks Out Web,” Computerworld, vol. 30, No. 35, p. 69, 2 pages (Aug. 26, 1996). |
| Walter, G. “Making Optical Disk Based Systems Pay,” Electronic Imaging '88—Advanced Printing of Paper Summaries, vol. 1, Oct. 3-6, 1988, Boston, MA, 11 pages. |
| Western Bank Purchases NCR's Document Managing System, AT&T News Release, http://www.att.com/news/0893/930831.nca.html, 3 pages (Aug. 31, 1993). |
| What Is A Financial Transaction Switch?, NCR Reports—Financial Services Trends & Technologies, NCR Corporation, vol. 1, Issue 6, 6 pages (1997). |
| Winig. E., “Cracking the Code,” Washington Business Journal, vol. 20. No. 11, 2 pages (Jul. 20-26, 2001). |
| Wong et al., FSTC Check Image Quality Subproject Status and Project Plan Update, 6 pages (May 22, 1996). |
| You Have Requested Data From 32 Answers—Continue? Y/(N): Y, Inspec, pp. 175-198 (2001). |
| Number | Date | Country | |
|---|---|---|---|
| 20210073750 A1 | Mar 2021 | US |
| Number | Date | Country | |
|---|---|---|---|
| 62187406 | Jul 2015 | US | |
| 62286738 | Jan 2016 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15200340 | Jul 2016 | US |
| Child | 17099609 | US |
