US 20080040249 A1
A system and method for processing transactions is disclosed. The different processes are integrated by use of a controlling processing engine which contains instructions on how the processes should be treated. The system and method provides an end to end integrated system for processing payments and reporting the transaction results in real time. The system and method allows customers to have access to the transaction data in real time and return any excepted payments in real time.
1. A method of processing transactions, comprising:
capturing data based on one or more transactions;
identifying each of the one or more transactions as unique item;
associating the one or more transactions with one or more customers; and
applying personalized processing of the one or more transactions for each of the one or more customers.
2. The method of
3. The method of
4. The method of
5. The method of
6. The method of
7. The method of
8. The method of
9. The method of
10. The method of
11. The method of
12. The method of
13. A computer readable media comprising code to perform the acts of the method of
14. A system of processing transactions, comprising:
one or more front end locations for capturing data based on one or more transactions;
one or more centralized processing engines for identifying each of the one or more transactions as unique item, associating the one or more transactions with one or more customers, and applying personalized processing of the one or more transactions for each of the one or more customers.
15. The system of
16. The system of
17. The system of
18. The system of
19. The system of
20. The system of
21. The system of
22. The system of
23. The system of
24. The system of
25. The system of
26. A method of processing transactions, comprising:
receiving one or more transactions;
associating the one or more transactions with one or more customers, wherein associating the one or more transactions is based on one or more attributes;
persisting the one or more attributes in one or more data storage systems; and
processing the one or more transactions for each of the one or more customers based on the persisted attributes.
27. A method of processing transactions, comprising:
capturing data based on one or more transactions;
identifying each of the one or more transactions as unique item, wherein each of the one or more transactions is identified as at least one of the following transaction types: credits, deposits, debits, checking, withdrawals, payments, electronic payments, cards, and miscellaneous real-time banking;
associating the one or more transactions with one or more customers, wherein associating the one or more transactions with one or more customers is based on at least one of the following attributes: customer type, customer activity, customer request, transaction value, transaction frequency, transactions volume, date, time, day of week, time of day, market conditions, image quality, currency, geography, and administrator override;
assigning attributes to the one or more transactions; and
applying personalized processing of the one or more transactions for each of the one or more customers, wherein personalized processing is provided in real-time.
The present invention is a continuation-in-part (CIP) of U.S. application Ser. No. 11/400,171, filed Apr. 10, 2006, entitled “Method for Transaction Processing in a Capture and Deposit,” which claims priority to U.S. Provisional Application No. 60/743,157, filed Jan. 20, 2006, both of which are incorporated herein by reference in their entirety.
The present disclosure relates generally to integrating processes related to electronic payment, and is particularly directed to data processing related to data capture and deposit management systems.
The need to make and efficiently track payments is a major concern for business and individuals alike. Generally, there are separate lines of processing for each payment type and particular payment locations may only accept or prefer certain payment types but not others. For instance, a small merchant may not accept a credit card because he does not want to pay the high cost of the credit card payment transaction, just as a large entity may prefer not to accept checks as payment due to the amount of manual labor required to process the payment and the systemic risks. As technology advances, both payees and payors will want faster, more efficient, more secure, and more transparent payment processes across all payment types. Convergence of payment types and changes in security settlement regulations will result in a corresponding convergence in delivery and payment channels. This evolution will require financial institutions to: meet changing regulations; use the most convenient payment instruments; improve productivity; reduce operational, credit, and systemic risks; reduce costs and capital investments; and improve funds availability.
Present payment solutions include Electronic Check Present (ECP), Image Cash Letter Exchange Image Replacement Document (IRD), Automated Clearing House (ACH), and ATM Enhanced Message Structure (EMS), and credit cards. Based on processing cost, funds availability, and credit and systemic risks, each has its respective strengths and weaknesses. Each of the above solutions is generally fixed to a single type of payment and does not integrate processing across different payment types. Also, many of the above solutions are cost prohibitive to all but the largest institutions. In all solutions but ACH, the cost of presenting an electronic check is projected to be more expensive than presenting a traditional paper check. However, some merchants do not like to use ACH as payment mechanism due to the potential payment risks. For example, under ACH a return can occur 45 days after the good has been provided to the consumer
In view of the disadvantages of the present state of the art, it would be desirable to develop an integrated method for end-to-end realtime capture, processing, management and clearing, which increases availability, lower costs, reduce risks, and thus overcomes the above-described inadequacies and shortcomings.
The present subject matter relates to integrating transaction processing. The different payment processes are integrated by use of a controlling processing engine and processing data related to transactions. In one embodiment, the system may comprise:
an integrated distributed capture module for capturing data at payment acceptance locations;
a central processing module, wherein the central processing module accepts multiple payment types;
an electronic quality control module;
an electronic payment type determination module;
a payment processing instruction at the central processing module, wherein the processing instruction includes customer defined rules, processor defined rules, and regulatory defined rules,
a clearing module,
a transaction management module for managing transmissions and reports regarding the transaction in real time;
an inquiry management module for managing inquiries regarding the transaction in real time.
In another embodiment, the method may comprise:
processing payments on a central processing engine that accepts a plurality of payment types, wherein the central processing engine processes the payments based on processing instructions, wherein the processing instructions include at least a customer defined instruction, a processor defined instruction, and a regulatory defined instruction;
capturing data related to a payment at a payment accepting location;
transmitting captured data to the central processing engine;
reviewing the captured data for quality of capture;
recognizing the type of payment from the captured data;
reporting transaction data in real time; and
providing access to the real time transaction data.
In another embodiment the integrated system may comprise capturing data at payment acceptance locations, such as branches, payment centers, cash register, cashiers, payment/receivable processing centers, etc.; a processor to review the quality of the captured data; a payment neutral processing engine that processes exceptions, manages transactions, including reporting to and answering inquiries from customers, creating files; routing images, data and electronic transactions through appropriate payment channels based on customers' and financial institutions' clearing profiles.
Some of the features in the present disclosure include: (1) the ability to convert one type of payment, such as a physical check, into another type of payment, such as a purely electronic transaction; (2) the ability to report or access real-time transaction data; (3) the web-enabled access; (4) the ability to enable payors, payees, processors, their agents or other interested parties to choose appropriate payment channels to clear payments; (5) the ability to detect high risk transactions, which reduces fraud and prevents double posting; and (6) the ability to tailor the system design for changing needs.
In order to facilitate a fuller understanding of the present disclosure, reference is now made to the accompanying drawings. These drawings should not be construed as limiting the present disclosure, but are intended to be exemplary only.
With reference to
The payment acceptance location 3 will capture data related to the payment. For instance, if the payment type is a check, the image of the check can be digitally captured. In another embodiment, the payment type can be a debit or credit card and the data capture can include data obtained from the magnetic stripe or, in the event the debit or credit card is not present, can digitally image a coupon containing the card account information. In other embodiments, other details can be captured on the coupon, such as billing information.
Once the data is captured, the data is transferred at 4 to a processor or group of processors 6 that will review the image for quality and completeness and determine the payment type from the captured data. Payments may be rejected for several reasons, including, but not limited to fraud (e.g., (invalid signature, invalid account), payment risks (e.g., non-sufficient funds, stop checks), unacceptable payment based on client instructions, unacceptably poor image quality, checks do not meet regulatory requirements (post date, stale date, not endorsed, etc.). In the event the data capture does not meet the quality standards, the data can be rejected at 7 and the processor may notify the payment acceptance location 3 in real time that the data is unacceptable and may request for the data to be recaptured. The recognition and quality control processor can be located at the payment acceptance location 3, at a third party transmission site, or within the payment processor's system 5.
After recognition and quality control 6, the captured data can then be sent to the processing engine 9. The engine processes the payments, regardless of type, according to a set of processing instructions. The engine can consist of one processor or a multiple processors and systems. The processing instructions may include rules such as what order the payment types should be processed, whether processing should take place in real time or in batch, the type of reporting to be sent out, and whether incoming payment types should be converted to another payment type for processing. Generally, there are three contributors to the processing instruction. The customer, who may be the payee, the payee's agent or any one who will benefit from the transaction, the payment processor 5, and a regulatory agency, such as the Federal Reserve or NACHA. These parties need not be distinct entities. For example, it is possible that the customer instruction and payment processor instruction are the same. These rules can provide the customer setup and profile management and contain instruction on area such as product usage, deposit positing criteria, availability schedules, deposit/ledger cut-off times, notification criteria, transmission timing, and formats and pricing records, providing clearing recipient set-up and profile management. These rules can help to speed the clearing process, reduce expense, be more efficient, or reflect what ever goal the requesting party needs to be achieved. For example, payee may have a rule that requests all payments be converted into ACH payments because the payor will be credited faster. This would allow any payments to the payee to be processed as ACH, regardless of whether the payment type was a check, debit card or another payment type. However, all the processing instructions must be followed. For example, the regulatory agency may have a rule that prohibits credit card payments from being converted to ACH. That payment will proceed as a credit card transaction unless there is another non-conflicting rule that deals with its processing.
In another embodiment, other parties may contribute to the processing instructions. For, example, the payor drawon 2 may request that all funds drawn from their account happen in real time instead of in batch. A clearinghouse associated with processing the payment may add its own rules.
Moreover, the processing instructions may also include a means for determining a high risk payment. A database or collection of databases with high risk factors can be used to determine if a transaction is high risk. The databases can be internal, external, proprietary or public and risk factors can include low credit scores, previous payee fraud, low account balances, or if the payee has a high return rate. The risk factors can also focus on the data capture such recognizing differences in signatures, improper payment type forms. The amount of risk a payment can have may be set by the rules provided by the relevant parties. If the risk tolerance is exceeded, the processing instructions may require that the payment be denied or noted as an exception. If the payment is too risky, notification may be sent to the payee 6, payor drawon 2 and/or payment accepting location 3 in real time.
After the payment has been processed according to the processing instructions the processing engine 9 may also have a clearing function that processes the transactions 10 related to the payments. For instance, the transaction 10 could consist of debiting and/or crediting the respective accounts. The processing engine 5 can then report information about the transaction to the payee 6, the payor drawon 2, or any other designated party in batch or real-time. The processing instructions may include instructions on what format the reports should take, the content of the reports and who the reports should go to. The reports may include information about the status of the transactions, when credit will be available, when a debit will be taken, provide an alert for an exception, or anything else about the transaction a party wishes to know.
In an embodiment, an interested party, such as the payor 1, the payment acceptance location 3, the payor drawon 2 or the payee 6, or an outside party acting as an agent for an interested party may access the in real time 12, giving the party the ability to inquire about a specific transaction in real-time. For example, this would provide the payee 6 with an increased degree of flexibility. It allows the payee to look proactively for specific information as opposed to just waiting for the report and looking line by line for the desired transaction. This allow the payee to proactively manage its accounts. Real time reporting and party inquiries can be transmitted in a manner known in the art, such as through the Internet, an intranet, email, instant messages, or other transmission means conducive to real time notification or be updated to the client's accounting systems of payment and information, such as receivables, invoice, inventory, banking accounts, brokerage accounts, etc.
The present invention may be used alone or in conjunction with other payment processing solutions such as lockboxes, distributed check capture devices, credit card capture devices, Accounts Receivable and other accounting systems.
With reference to
With reference to
The data capture module 101 may comprise: means for reviewing payments for negotiability and acceptability; means for determining transaction type; an image capture device for capturing images and data of the payments, and spraying an identification number on each item of the captured payments; means for matching the captured data against a stop file; and means for transmitting the captured images and data to a central processing site. The image capture device may comprise a scanner which can capture images and read data, a computer, a storage device, and a device for spraying an identification number. The means for matching the captured data against a stop file may be a computer, a special software, and database, which can determine whether a customer account has been designated not to accept payments, and certain payment types require additional review. The means for transmitting the captured images and data to a central processing site may be a web service such as private network or internet.
With reference to
With reference to
With reference to
With reference to
As the amounts get matched, the payments are reviewed to determine whether the payment is cash-like instrument 324. If the payment is a cash-like instrument, a designated code is assigned to each payment 325. Then an availability code will be assigned to each payment based on account number and branch location 326. If the system requires more detailed availability coding 327, the central processing site will submit the items to the images and electronic transactions clearing module 328. Once a clearing method was determined, the image and electronic transactions clearing module will send that information to the central processing site 329.
A posting file is created hourly for the items processed. This file will not be cumulative. Each hour this file is transmitted from the central processing site to the transaction management module. The images and data associated with each transaction will be included in this transmission 330.
The central data capturing and processing module 102 may comprise: means for receiving transmitted captured images and data from payment acceptance locations; means for receiving lockbox payments and determining transaction type; an image capture device for capturing images and data of lockbox payments; means for identifying payment form types; means for processing payment forms; and means for transmitting posting files of processed items together with images and data to the transaction management module. The means for receiving transmitted captured images and data from branches may comprise computer connected, web service, data storage device, and software. An image capture device for capturing images and data of lockbox payments may comprise scanner, computer, data storage device, device for spraying identification number on each item, and software. The means for identifying payment form types may be form identification software. The means for processing payment forms may be software performing the designated functions. The means for transmitting posting files of processed items together with images and data to the transaction management module may comprise computer, software, and web service.
With reference to
With reference to
Providing transaction processing status function 411 will provide personnel with the status of a transaction in real time. This allows personnel to view all the transactions and their respective processing status. Personnel can see whether a transaction was transmitted successfully to the central processing site. This function will also display the status of processing steps within the transaction management module. Viewing exceptions function 412 will allow personnel to view any exceptions. This facility has two functions. The first is to view the real time same day exceptions. These exceptions could be a check that has a “stop pay” placed on it, or a closed or dormant account, or a bad account number, or had already been posted. They could also be foreign checks, or payments that match stop pay criteria, or payments that do not pass image usability standards and require rescanning, or checks that fail internal processing rules. These exceptions may need to be pulled manually from the work to be reviewed and they would require further disposition. The viewing exceptions function will also allow personnel to view returned checks. Personnel can then contact their customers to inquire whether the returned payments should be re-deposited. A designated security officer can be made as a user administrator 413. This administrator can assign id and roles to both branch and central operation personnel. This application allows only designated personnel to access designated functions.
With reference to
With reference to
The transmission function 404 can be configured to use a number of standard file formats to transmit files on an hourly basis or at any interval. It can also be customized to receive the stop pay file and other special instructions.
The transaction management module provides a number of management reports to perform financial balancing and reconcile details 405. It also provides daily deposits and transaction availability. The function provides a number of management reports on daily processing, exception, return, and other critical processing information by payment acceptance location.
The transaction management module stores both transactions and images in its archive 406. This information is stored for customer service to search and research transactions and retrieve associated images. The archive will track payments clearing methods along with the availability assignment.
With reference to
With reference to
The transaction management module 103 for managing transaction including reporting to and answering inquiries from customers via internet or other communication means, and creating files, comprises: means for customer self-service; means for central control; means for monitoring and control; a transmission facility; means for financial reporting; archive; means for transaction routing; and means for customer profile setup. The transaction management module may comprise web service, enhanced viewer, computer, software, database, and storage device.
Routing both images and electronic transactions through appropriate payment channels based on customers' and financial institutions' clearing profiles 500 provides a single payment management engine for all inbound and outbound electronic payments, and establishes an architecture that can interface with all payment and money movement applications. This method is built on an open infrastructure that provides a web service interface using standard XML messaging as well as the standard check data and image formats. With reference to
With reference to
With reference to
The transaction sorting and routing 504 provides transaction routing and posting control including transaction summary information, adjustments, return items and availability assignment. This function selects the optimum electronic payment channel for each processed item based on risk, cost, clearing rules, and schedules. This function will also perform exception processing on the same day as the transaction is processed. This exception processing includes handling account number editing, stop payment, and closed/dormant accounts.
In addition, payments are matched against transaction database to prevent double posting. The payment images and data will be sent to the payment channels for clearing.
With reference to
and image replacement document (IRD) for imaged checks that cannot be cleared via ECP or ARC 523.
The settlement and reporting function 507 provides deposit and balance reporting data, and customer transaction details. This function also provides reconcilement, proof and control, and adjustment functionality for all system interfaces including delivery channels, facing applications, specific business services and payments channels as well as shared operation support channels like customer service centers, and image and data archive.
The data and transaction clearing module 104 for routing both data and transactions through appropriate payment channels based on customers' and financial institutions' clearing profiles comprises: data and transaction interface; means for customer profile and processing assignment; means for float assignment; means for transaction sorting and routing; warehousing and pending database; payment channels; and means for settlement and reporting. The data and transaction clearing module may comprise web service, computer, software, database, and storage device.
Since many current transactions are processed in batch mode, whenever there is a problem with any one item, the entire group (or batch) is delayed until the one item is corrected or verified thereby resulting in processing inefficiencies. As a result, it should be appreciated that in addition to handling transactions in file/batch mode where groups of transactions are processed together, embodiments of the present disclosure may also handle each transaction as a unique item on an individual basis. Embodiments of the present disclosure may further provide a new architecture for real time processing of transactions as unique discrete items.
During the lifespan of a transaction, for example, a system and method may be provided for assigning specific attributes to each transaction. In one embodiment, a credit may be identified and associated with a customer, e.g., Customer A. The system may recognize that Customer A is a preferred customer with excellent credit history. The system may also recognize that Customer A makes timely payments. The same credit may also be identified and associated with another customer, e.g., Customer B. Although the transactions appear identical, the system may distinguish the transactions based on different customer types. In addition, the system may consider a combination of transaction attributes (e.g., customer type, customer activity, etc.) and may process each transaction in a different personalized manner. Therefore, if Customer B is identified as a delinquent customer, the system may apply various fraud processes against the transaction associated with Customer B by checking for signatures, checking for balances, checking for more recent check activity, and/or other similar fraud-identification processes. In this example, customers may be differentiated on an individual basis so that personalized services may be more easily provided. Furthermore, an automatic trail of transactions may be compiled, which may be useful for searching and/or processing against it. For instance, if a fraud-identification process was run against an account, not only would the process be recognized, but information regarding the process (e.g., results of the fraud check) may also be stored and maintained. Accordingly, a customer service representative who is interacting with a customer whose account was checked (e.g., Customer B) may have access to such information and may be able to detail to Customer B exactly what processes and why they occurred.
It should be appreciated that control software for processing such transactions may be also be centralized. Instead of having separate front-end applications that image the check (or other instrument), embodiments of the present disclosure re-architects the entire flow for the entire banking system so that transaction information may be captured at various front-end systems, such as ATM, branch, lockbox, etc., and processed in a centralized manner.
The one or more front end systems/locations may of the system 700 may capture data based on one or more transactions. In one embodiment, the one or more front end systems may include at least one of an ATM 702, a branch 704, a lockbox 706, a vault (e.g., check safe), or other front end system 708, such as an external customer-created location (e.g., Internet, web browser, etc.). The captured data may include at least one of captured images, scanned paper checks, entered data in computer-based form, or other similar data. Each of the one or more front end systems may also be coupled to the centralized processing engine 710. Other various embodiments may also be provided.
The centralized processing engine 710 may provide centralized processing of the one or more transactions for each of the one or more customers and may perform a variety of centralized processes. The settlement box 720 may be coupled to the centralized processing engine 710 to provide centralized settlement processing for a variety of time frames based on the one or more transactions. Other various embodiments may also be provided.
Although each of the front end systems, centralized processing engine 720, and the settlement box of the system 700 is depicted as a single component in
It should also be appreciated by one of ordinary skill that each of the components in system 700 may include one or more processors (not shown) for processing one or more messages. Data may be processed for storage, indexing, categorizing, and/or settlement by one or more processors of the components of system 700. By storage, indexing, categorizing, and/or settlement, the data/information may be shared by multiple components and/or other external systems. Such use may be sequential or simultaneous. Furthermore, processing the data in this way may also allow the processing logic to of any one of the components of system 700 to cross-reference the various data/information for efficient use by the system. Other various embodiments may also be provided.
In one embodiment, each of the one or more transactions may be identified as at least one of the following transaction types: credits, deposits, debits, checking, withdrawals, or other real-time banking transaction type. It should be appreciated that these may further include, but not limited to, payments, electronic payments, card payments, etc. In another embodiment, the one or more transactions associated with one or more customers may be based on at least one of the following transaction attributes: customer type, customer activity, customer request, transaction value, transaction frequency, transactions volume, and administrator override. In yet another embodiment, the one or more transactions associated with one or more customers may be based on at least one of the following environmental attributes: date, time, day of week, time of day, market conditions, image quality, currency, and geography. It should be appreciated that a currency attribute may include, but not limited to, multi-currency processing, conversion, and exchange. Other various embodiments may also be provided. The central processing engine 710 may also apply personalized processing in real-time.
As discussed above, the centralized processing engine 710 may also include one or more processors and instructions to perform additional features. For example, the centralized processing engine 710 may also assign attributes to the one or more transactions, process transactions by at least one of file processing and batch processing, and/or provide centralized settlement processing for a variety of time frames based on the one or more transactions. For example, in another embodiment, processing transactions by at least one of serial and parallel processing may be provided. In another embodiment, streaming real-time processing in at least the front end systems/applications, the central processing engine 710, the settlement box 720, or other various processing component (e.g., backend system/application) may be provided. Other various embodiments may also be provided.
It should be appreciated that after the one or more front end systems/locations capture data based on one or more transactions 810, the data may be transmitted for at least one of serial and parallel processing. Furthermore, it should be appreciated that while exemplary method 800 depicts four distinct blocks, the method 800 may selectively bypass one or more of the blocks to processing one or more of the transactions. Such a feature may provide a flexible and efficient approach to processing transactions. Additionally, it should be appreciated that once the one or more transactions are associated with one or more customers 830, intelligent routing may be provided from one or more overburdened or offline centralized processing engines to other alternate sites or instances so that network and/or resource utility is maximized.
It should also be appreciated that a state of one or more transactions may be tracked. For example, in one embodiment, one or more transactions may be received for associating with one or more customers. In this example, associating the one or more transactions may be based on one or more attributes (e.g., transaction, environmental, etc.). In addition, the one or more attributes may be persisted in one or more data storage systems to provide a record of transactions and/or full searching capabilities for retrieval, modification, and other processing actions. The one or more transactions for each of the one or more customers may be further processed based on the persisted attributes. As a result, during the entire life cycle of a transaction, the transaction never leaves. Rather, the transaction may change states (e.g., by the various attributes) to ultimately provide a way of processing transactions that is comprehensive and efficient.
Through a centralized system, embodiments of the present disclosure may provide a consistent approach for settlement for the entire system 700, e.g., banking system. Rather than invoking different settlement routines, the centralized system and method may process one or more settlements on a variety of time frames based on the receiving applications. Thus, an intelligent platform may be created where transactions can be recognized by the system and the system identifies how to process the transaction on an individualized manner. Other various benefits and advantages may also be provided.
The present disclosure is not to be limited in scope by the specific embodiments described herein. Indeed, other various embodiments of and modifications to the present disclosure, in addition to those described herein, will be apparent to those of ordinary skill in the art from the foregoing description and accompanying drawings. Thus, such other embodiments and modifications are intended to fall within the scope of the present disclosure. Further, although the present disclosure has been described herein in the context of a particular implementation in a particular environment for a particular purpose, those of ordinary skill in the art will recognize that its usefulness is not limited thereto and that the present disclosure may be beneficially implemented in any number of environments for any number of purposes. Accordingly, the claims set forth below should be construed in view of the full breadth and spirit of the present disclosure as described herein.