Abstract:
A system and method for processing financial transactions includes an input receptive of cash and a plurality of images of physical items of the transaction, wherein the images contain a visual record of the transaction data such as an amount of monetary value. A front, counter transaction processor processes the cash and a first item image and generates front counter transaction data. A back counter transaction processor processes item images of the transaction and generates back counter transaction data. A match module matches back counter transaction data to front counter transaction data. An output is adapted to transmit front counter transaction data and back counter transaction data to at least one of form fields and a temporary transaction datastore.

Description:
FIELD OF THE INVENTION  
       [0001]     The present invention generally relates to financial transaction systems, methods, and devices, and particularly to systems and methods of transactions at point presentment utilizing a front counter-back counter workflow integration.  
       BACKGROUND OF THE INVENTION  
       [0002]     Financial institutions typically interact with parties to transactions, such as individuals, partnerships, companies, and corporations, by providing points of presentment at locations that are convenient to the parties to the transactions. Points of presentment include, for example, front counters of bank branches, cash vaults, merchant back offices, and automatic teller machines (ATMs) providing deposit automation. Parties to transactions present physical items embodying a transaction at these points of presentment, and these items typically include checks, cash, withdrawal slips, deposit slips, loan payment slips, and/or remittance slips.  
         [0003]     While tellers often assist parties to transactions at some points of presentment, these tellers are typically required to spend excessive amounts of time and attention to data entry and transaction balancing. Furthermore, the tellers typically have no way of ensuring that all items of a transaction are valid. In addition, points of presentment affording no teller assistance rely entirely on the party to the transaction to ensure that the transaction is balanced. Thus, the teller&#39;s focus is on the transaction and not the customer.  
         [0004]     Often, financial institution branches will assemble and process the transaction long after the party to the transaction has departed the point of presentment. As a result, unbalanced and/or invalid transactions are discovered late, without affording the party to the transaction or teller at the point of presentment an opportunity to correct or otherwise balance the transaction.  
         [0005]     The need remains, therefore, for a system and method of processing a transaction at a point of presentment that improves quality control of transactions while reducing time and labor requirements at a point of presentment. The present invention fulfills this need.  
       SUMMARY OF THE INVENTION  
       [0006]     In accordance with the present invention, a system and method for processing financial transactions includes an input receptive of cash and a plurality of images of physical items of the transaction, wherein the images contain a visual record of data associated with the transaction. A front counter transaction processor processes the cash and a first item image and generates front counter transaction data. A back counter transaction processor processes item images of the transaction and generates back counter transaction data. A match module matches back counter transaction data to front counter transaction data. An output is adapted to transmit front counter transaction data and back counter transaction data to either form fields or a temporary transaction datastore.  
         [0007]     Further areas of applicability of the present invention will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples, while indicating the preferred embodiment of the invention, are intended for purposes of illustration only and are not intended to limit the scope of the invention. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0008]     The present invention will become more fully understood from the detailed description and the accompanying drawings; wherein:  
         [0009]      FIG. 1  is a an entity relationship diagram illustrating a financial transaction system implemented at a point of presentment according to the present invention;  
         [0010]      FIG. 2  is a functional block diagram illustrating an image-enabled, transaction processing system including a front counter back counter workflow for use at a point of presentment according to the present invention;  
         [0011]      FIG. 3  is a functional block diagram illustrating a front counter transaction processing system in accordance with the present invention; and  
         [0012]      FIG. 4  is a functional block diagram illustrating a back counter transaction processing system in accordance with the present invention.  
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT  
       [0013]     The following description of the preferred embodiment is merely exemplary in nature and is in no way intended to limit the invention, its application, or uses. For purposes of clarity, the same reference numbers will be used in the drawings to identify similar elements.  
         [0014]      FIG. 1  illustrates a point of presentment  10  implementing a front counter back counter integration method with an image-enabled, financial transaction processing system in accordance with the present invention. It is envisioned that a financial institution according to the present invention has a central location  12  with a central transaction datastore  14  and centralized business rules  16 . The central location  12  promulgates central business rules  16  by periodically transmitting business rules data  16 A over a communications network  18 , such as the Internet, to plural points of presentment. In turn, point of presentment  10  daily receives rules data  16 B via data input  17  and stores it in local rules datastore  20 .  
         [0015]     Local rules datastore  20  may store validation characteristics for authenticating identity of parties and/or items. Validation characteristics may include routing numbers for financial institutions, account numbers for parties to transactions, one or more signatures or other biometric characteristics of individuals, and/or encryption keys, hash functions, and similar code features relating to digital watermarks, holograms, and other item features. Business rules  16 B of local datastore  20  also define how to identify a type of document item based on image features and/or codeline data, how to extract, recognize, and utilize features from different types of documents, and how to validate and balance different types of transactions.  
         [0016]     In operation, an operator at the point of presentment  10 , such as a teller assisting the party to the transaction or a customer of an ATM, initiates a transaction by selecting an electronic form  22  designated for performing the transaction from a visual screen  24  by providing input  26  to an input device  28 . Input device  28  may be one of a keyboard, mouse, touchscreen, microphone with speech recognition capability, and/or other input mechanisms. If the operator selects to perform a deposit, the operator selects the deposit form and takes items  30 , which may include a completed credit slip, checks and cash from the party to the transaction at the point of presentment  10 . If the operator selects to process the complete transaction in a front counter mode while the party to the transaction is present, the cash is processed and each received check and credit slip is scanned using imaging and scanning mechanism  32 . It is envisioned that scanning mechanisms that read magnetic ink image items, and sort items may be employed to validate and/or count a non-cash portion of the transaction. The complete transaction is then processed by transaction processor  34 .  
         [0017]     In accordance with the present invention, the operator also has the option of deferring the time consuming functions of transaction processor  34 , such as capturing and validating each check, in a back counter mode as will be described in more detail below. Once transaction processor  34  has completed balancing the validated transaction, filled form  36  and item images  38  are stored in local transaction datastore  40 . A receipt  42  for the party to the transaction is generated using printing device  44 . The operator has the option of posting the complete transaction by communicating the transaction  46 A and  46 B stored in local transaction datastore  40  of point of presentment  10  to central transaction data store  14  of central location  12  via data output  48  and communications network  18 .  
         [0018]     The transaction processor  34  generally performs the tasks of assigning a unique identification number (DIN) to each item image, recognizing and extracting relevant data from item images, validating each image according to validation characteristics of business rules  16  and filling fields of electronic form  22  with validated extracted data. Corrections to field contents may be made by the operator interfacing with the application or an operator at a remote location using an input device  28  and/or scanning mechanism  32 . Specifically, the transaction may be corrected by manual input or re-processing the item through the scanner to recognize and extract data. Transaction processor  34  balances the complete cash and/or check transaction and sends a validation decision along with the electronic from filling results back to the operator via visual screen  24 . Transaction processor  34  posts data stored in temporary transaction datastore  40  to central transaction data store  14  upon receipt of input  26  command to post.  
         [0019]      FIG. 2  illustrates a method for integrating front counter and back counter processing within transaction processor  34  at a point of presentment  10 . The method captures work done in the front counter mode, where the application interfaces with the teller while the party to the transaction is present and the back counter mode where the application provides the ability to capture work in a standalone mode. Data input  52  is receptive of transaction items  30  such as credit slips, cash, checks, operator input  26  and business rules  20 . Front counter transaction processor  50  inputs data  52  and provides the operator with the ability to capture items  30  of the transaction, to determine a conditional balance of the transaction and to conditionally complete a transaction including a conditional tag to local transaction data store  40  via data output  54 . Data output  56  is receptive of front counter transaction processor data. Such data is used to generate a conditional receipt  42  for the party to the transaction and allow the operator to view filled forms and/or images  22  of the transaction.  
         [0020]     Back counter transaction processor  58  inputs data  52  and provides the operator the ability to reprocess items  26  of the transaction according to business rules from local rules datastore  20  and match the transaction to data from the partially processed front counter transaction data via data input  60 . Data output  62  is receptive of the back counter transaction processor data and is stored in the local transaction datastore  40 . Filled forms, reports and images of back counter transaction processor are viewable via data output  64 . Posting module  66  of transaction processor  34  allows the completed transaction data accessible from local transaction datastore  40  via data input  68  to be posted via data output  70  to central transaction datastore  14  of central location  12 .  
         [0021]      FIG. 3  illustrates the function of front counter transaction processor  50  in more detail. Data input  52 A is receptive of scanned credit slip image  72  and business rules  16 B. Credit module  76  receives input  52 A and extracts and validates recognized fields of the credit image  74  according to business rules  16 B. A transaction number is created and stored in local transaction datastore  40  along with extracted data via data output  54 . A document identification number is assigned to the credit slip image. Data input  52 B is receptive of cash ticket information  80  that is electronically entered after the cash portion of the transaction is tallied. Cash Module.  82  receives cash ticket information  80  and creates and stores a substitute cash ticket image with a document identification number in local transaction datastore  40  via data output  54 . Data input  52 C is receptive of an electronic entry for the total amount of the checks  84  in the transaction. Provisional check processor  86  inputs check total  84  and stores check total  84  with a conditional tag in local transaction datastore  40  via data output  54 . Front counter transaction processor allows the operator to complete and balance the transaction without actually capturing and validating each check in the transaction. Conditional receipt module  88  inputs data from cash module  76 , credit module  82 , and provisional check module  86 . Conditional receipt module  88  determines a conditional balance from the cash amount and check total and generates conditional receipt data  90  via data output  56 A for a conditional receipt  42  that is given to the party of the transaction. Data output  56 B outputs credit module data, cash module data, and provisional check module data that is used to populate viewable forms  92 .  
         [0022]      FIG. 4  illustrates the function of back counter transaction processor  58  in more detail. Data input  52 D is receptive of credit image  72  and business rules  16  which are used to match the back counter transaction to a front counter transaction. Match module  92  receives credit image  72  and business rules  16  and extracts and validates recognized matching parameters of the credit image  72  according to business rules  16 B. It is envisioned that matching parameters may be configurable and can be any of credit codeline data, cash-in and cash-out amounts and/or assigned transaction number. Match module  94  matches the parameters with data stored in local transaction datastore  40 . The matched front counter transaction images and forms are input to match module via data input  60 . The matching forms are displayed from form data  92  via data output  64 A. Match module  94  provides the capability to create and output report data  96  via data output  64 A containing a list of transactions captured at the front counter and not reprocessed at the back counter or any transactions at the back counter that does not have a corresponding front counter transaction.  
         [0023]     Data input  52 E is receptive of check images  98  and business rules  16 B. Recognition module  100  and validation module  102  receive check images and business rules data  16 B via data input  52 E. Recognition module  100  performs feature analysis, extracts image details, and recognizes image content for form fields according to business rules  16 B. Recognized image content is stored in local transaction datastore  40  via data output  62 . Validation module  102  compares check images  98  and recognized image content to validation characteristics of business rules  16 B. Validation module ensures that items of the transaction are complete, correct, and authentic.  
         [0024]     Recognized form fields, flawed images, and a valdiation decision for each item are communicated from recognition module  100  and validation module  102  to balancing module  104 . Balancing module  104  receives input from local transaction datastore  40 , balances the transaction and communicates a balance decision  106 , form filling results  108 , one or more validation decisions  112  and/or flawed images  112  to an operator via output  64 C. Data input  52 G receives additions and/or corrections input  114  from the operator and an operator command to post the transaction  116 . It is envisioned that an option to enter a post transaction command  116  may be withheld from the operator until the transaction is in balance. If the transaction is in balance, a post transaction command  116  is sent to posting module  66 . Upon receiving the post transaction command  116  via data output  120 , posting module  66  assembles item images together with substitute cash tickets and filled electronic forms of the transaction from local transaction datastore  40  and transmits the resulting transaction to central transaction datastore  14  of central location  12 .  
         [0025]     It is envisioned that transaction processor  34  may allow an operator to chose to complete both front counter transactions and back counter transaction at the front counter via input command  26 . Further, it is envisioned that an operator may begin back counter transaction but not complete the transaction and have to defer back counter transaction processing for a later time. In such a case, match module  94  provides the capability to match front counter transaction and partially processed back counter transaction to the final back counter transaction without requiring the already processed back counter transaction to be performed again. Recognition module  100  prevents storing duplicate item images by recognizing that the item image has already been scanned and assigned a DIN.  
         [0026]     Those skilled in the art can now appreciate from the foregoing description that the broad teachings of the present invention can be implemented in a variety of forms. Therefore, while this invention has been described in connection with particular examples thereof, the true scope of the invention should not be so limited since other modifications will become apparent to the. skilled practitioner upon a study of the drawings, the specification and the following claims.