FRONT COUNTER AND BACK COUNTER WORKFLOW INTEGRATION

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 of 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'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] Figure 1 is a an entity relationship diagram illustrating a financial transaction system implemented at a point of presentment according to the present invention;

[0010] Figure 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] Figure 3 is a functional block diagram illustrating a front counter transaction processing system in accordance with the present invention; and

[0012] Figure 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] Figure 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 16A over a communications network 18, such as the Internet, to plural points of presentment. In turn, point of presentment 10 daily receives rules data 16B 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 16B 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 46A and 46B 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] Figure 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] Figure 3 illustrates the function of front counter transaction processor 50 in more detail. Data input 52A is receptive of scanned credit slip

image 72 and business rules 16B. Credit module 76 receives input 52A and extracts and validates recognized fields of the credit image 74 according to business rules 16B. 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 52B 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 52C 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 56A for a conditional receipt 42 that is given to the party of the transaction. Data output 56B outputs credit module data, cash module data, and provisional check module data that is used to populate viewable forms 92.

[0022] Figure 4 illustrates the function of back counter transaction processor 58 in more detail. Data input 52D 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 16B. 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 64A. Match module 94 provides the capability to create and output report data 96 via data output 64A 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 52E is receptive of check images 98 and business rules 16B. Recognition module 100 and validation module 102 receive check images and business rules data 16B via data input 52E. Recognition module 100 performs feature analysis, extracts image details, and recognizes image content for form fields according to business rules 16B. 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 16B. 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 64C. Data input 52G 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.