Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20080162321 A1
Publication typeApplication
Application numberUS 11/983,032
Publication dateJul 3, 2008
Filing dateNov 6, 2007
Priority dateNov 7, 2006
Also published asUS8112357, US8296223, US8595096, US20080159655, US20080162319, US20080162320, US20080162322, US20140108243
Publication number11983032, 983032, US 2008/0162321 A1, US 2008/162321 A1, US 20080162321 A1, US 20080162321A1, US 2008162321 A1, US 2008162321A1, US-A1-20080162321, US-A1-2008162321, US2008/0162321A1, US2008/162321A1, US20080162321 A1, US20080162321A1, US2008162321 A1, US2008162321A1
InventorsBenjamin T. Breeden, Richard Rodrigues, Steven D. Martin, Timothy Rachek
Original AssigneeBreeden Benjamin T, Richard Rodrigues, Martin Steven D, Timothy Rachek
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
System and method for processing duplicative electronic check return files
US 20080162321 A1
Abstract
Processing duplicate items in image cash letter (“ICL”) return files for efficient handling. A duplicate item processing module can receive ICL return files comprising items representing duplicate electronic checks. The duplicate item processing module can determine whether the processing entity erroneously presented the item more than once. The duplicate item processing module can also determine whether the depositing institution erroneously deposited the item more than once for processing. Based on the determination of the source of the error, the duplicate item processing module can make a correction in its own records and/or forward the ICL return file with the duplicate item to the depositing institution.
Images(5)
Previous page
Next page
Claims(19)
1. A computer-implemented method for processing duplicate electronic checks, comprising the steps of:
receiving a return ICL file comprising a duplicate item;
comparing the duplicate item to a record of items previously presented for payment;
if the duplicate item matches more than one item in the record of items previously presented for payment, suspending the return ICL file for further analysis; and
if the duplicate item does not match more than one item in the record of items previously presented for payment, forwarding the return ICL file to a depositing institution for further processing.
2. The computer-implemented method of claim 1, wherein the step of suspending the return ICL file for further analysis comprises comparing the duplicate item to a record of items previously deposited for processing.
3. The computer-implemented method of claim 2, further comprising the steps of:
if the duplicate item matches more than one item in the record of items previously deposited for processing, forwarding the return ICL file to the depositing institution for further processing; or
if the duplicate item does not match more than one item in the record of items previously deposited for processing, continue suspending the return ICL file for further analysis.
4. The computer-implemented method of claim 1, wherein the return ICL file includes a designation indicating that it comprises at least one duplicate item.
5. The computer-implemented method of claim 1, wherein the return ICL file is received from a receiving institution.
6. The computer-implemented method of claim 5, further comprising the step of notifying the receiving institution of the disposition of the return ICL file.
7. A computer-implemented method for processing duplicate electronic checks, comprising the steps of:
receiving a return ICL file comprising a duplicate item;
comparing the duplicate item to a record of items previously received for processing;
if the duplicate item matches more than one item in the record of items previously deposited for processing, forwarding the return ICL file to a depositing institution; and
if the duplicate item does not match more than one item in the record of items previously deposited for processing, suspending the return ICL file for further analysis.
8. The computer-implemented method of claim 7, wherein the return ICL file includes a designation indicating that it comprises at least one duplicate item.
9. The computer-implemented method of claim 7, wherein the return ICL file is received from a receiving institution.
10. The computer-implemented method of claim 9, further comprising the step of notifying the receiving institution of the disposition of the return ICL file.
11. The computer-implemented method of claim 7, further comprising the step of, after completing the further analysis, forwarding the return ICL file to the depositing institution.
12. A computer-implemented method for processing duplicate electronic checks, comprising the steps of:
receiving a return ICL file comprising a duplicate item;
comparing the duplicate item to a record of items previously presented for payment;
if the duplicate item does not match more than one item in the record of items previously presented for payment, forwarding the return ICL file to a depositing institution;
if the duplicate item matches more than one item in the record of items previously presented for payment, comparing the duplicate item to a record of items previously deposited for processing;
if the duplicate item matches more than one item in the record of items previously deposited for processing, forwarding the return ICL file to the depositing institution; and
if the duplicate item does not match more than one item in the record of items previously deposited for processing, suspending the return ICL file for further analysis.
13. The computer-implemented method of claim 12, wherein the step of suspending the return ICL file for further analysis comprises the steps of:
terminating the return ICL file and adjusting a settlement record for the duplicate item.
14. The computer-implemented method of claim 12, wherein the return ICL file includes a designation indicating that it comprises at least one duplicate item.
15. The computer-implemented method of claim 12, wherein the return ICL file is received from a receiving institution.
16. The method of claim 15, further comprising the step of notifying the receiving institution of the disposition of the return ICL file.
17. A computer-implemented system for processing duplicate electronic checks, comprising:
a check processing system operable for processing items in an ICL file for payment or presentment to a receiving institution, the check processing system comprising a first database of records of items previously presented to the receiving institution and a second database of records of items previously deposited with the check processing system for processing;
a duplicate item processing module operable for receiving from a receiving institution computer a return ICL file comprising a duplicate item and for comparing the duplicate item to the first database of records of items previously presented and the second database of records of items previously deposited with the check processing system for processing.
18. The computer-implemented system of claim 17 wherein the items in the second database of records of items previously deposited with the check processing system for processing were received from a depositing institution computer.
19. The computer-implemented system of claim 17, wherein the duplicate item processing module is further operable for transmitting the return ICL file comprising the duplicate item to a depositing institution computer when the duplicate item matches more than one item in the second database of records of items previously deposited with the check processing system for processing.
Description
RELATED PATENT APPLICATIONS

This patent application claims priority under 35 U.S.C. §119 to U.S. Provisional Patent Application No. 60/857,666, entitled “Check Processing Using Substitute Check Images,” filed Nov. 7, 2006, the complete disclosure of which is hereby fully incorporated herein by reference. This patent application is also related to co-pending U.S. patent application Ser. No. ______ [Attorney Docket No. 08898.105031], entitled “Automated Return Item Re-Clear,” filed Nov. 6, 2007, U.S. patent application Ser. No. ______ [Attorney Docket No. 08898.105034], entitled “Systems and Methods for Preventing Duplicative Check Processing,” filed Nov. 6, 2007, U.S. patent application Ser. No. ______ [Attorney Docket No. 08898.105030], entitled “Prioritizing Checks for Electronic Check Processing,” filed Nov. 6, 2007, and U.S. patent application Ser. No. ______ [Attorney Docket No. 08898.105033], entitled “System and Method for Processing Duplicative Electronic Check Reversal Files,” filed Nov. 6, 2007. The complete disclosure of all of the foregoing related applications is hereby fully incorporated herein by reference.

FIELD OF THE INVENTION

The invention relates generally to processing duplicative electronic checks and more particularly to determining the cause of the duplicative electronic check so that the duplication can be efficiently and properly corrected.

BACKGROUND OF THE INVENTION

Effective Oct. 28, 2004, the Check Clearing for the 21st Century Act (“the Act”) improved the ability of banks to use electronic images of paper checks by, for example, submitting those images, along with associated information, for electronic processing. Under the Act, if a receiving financial institution (“RI”) or its customer requires a paper check, a paper image replacement document (“IRD”), such as a paper “substitute check,” can be created from an electronic check image and associated electronic information. Such a substitute check meeting specified requirements is the legal equivalent of an original paper check, and an RI is required to accept the substitute check for payment. This process enables banks to reduce the costs and inconveniences associated with physically handling and transporting original paper checks.

Under the Act, the substitute check must be essentially an exact copy of the original paper check to be the legal equivalent of the original paper check. In particular, the substitute check must include an exact copy of all of the Magnetic Ink Character Recognition (“MICR”) data provided on the original paper check and all check endorsements.

The terms “substitute check” and “IRD” generally are used interchangeably herein to refer to any electronic or paper document that can be used for electronic payment processing purposes, whether or not the document is the legal equivalent of a paper check negotiable instrument. The terms “bank,” “customer,” “RI,” and “processing entity” generally are used herein to refer to any party performing conventional or electronic check processing at any stage, including depositing and receiving institutions, their non-bank subsidiaries and affiliates, and any non-bank third party agents that provide processing services to banks.

Typically, each electronic check is received for processing in an electronic image cash letter file (hereinafter an “ICL file”), which includes one or more electronic image cash letters (“ICLs”). Each ICL includes one or more bundles of items to be processed. Each bundle includes one or more items. The term “item” is used herein to refer to a check or an IRD or information that represents a check or an IRD. For a particular item, the ICL can include one or more electronic images of the item, the complete MICR data provided on the item, and additional financial data related to the item, such as endorsement information (hereinafter, “addenda data”).

The ICL can further include a series of records related to the items. For example, for each bundle of items in the ICL, the ICL can include a bundle summary control record comprising information about the bundle, such as a bundle identification number, the number of items in the bundle, the value of each of the items in the bundle, and the total value of all the items in the bundle. The ICL also can include an ICL control record comprising information about the origin and destination of the ICL, and a cash letter bundle summary control record comprising a summary of all the bundle summary control records in the ICL. For simplicity, each ICL, bundle, item, image, record, or other component of an ICL file is referred to herein as an “element” of the ICL file.

In the traditional, paper processing arena, each check could be seen and touched throughout processing. Thus, in the traditional, paper processing arena, it was virtually impossible to process the same check twice. However, with electronic check processing, multiple banks are processing the same checks in an electronic environment. Because the banks are producing and processing electronic copies of the checks, the same check may be reproduced and processed two or more times. Thus, a check processor may receive duplicate ICL files and/or ICL file elements. Similarly, a check processor may produce and present duplicate ICL files and/or ICL file elements for payment. To date, banks have been unable to efficiently correct errors resulting from duplicative presentment of ICL files and/or ICL file elements. Thus, a need exists in the art for a system and method to improve the efficiency with which banks and check processors correct duplication errors relating to electronic checks.

SUMMARY OF THE INVENTION

The invention provides systems and methods for processing duplicate items in ICL files. In one embodiment, a receiving institution can transmit a return ICL file containing one or more duplicate items to a check processing entity for processing the duplicate item. The check processing entity can use a check processing system and a duplicate item processing module to attempt to determine the cause of the duplicate item. For example, the duplicate item processing module can compare the duplicate item to a database of records of items previously presented to the receiving institution to determine whether the check processing entity presented the item more than once to the receiving institution. The duplicate item processing module also can compare the duplicate item to a database of records of items the check processing entity previously received from a depositing institution to determine whether the depositing institution deposited the duplicate item with the check processing entity more than once. Once the cause of the duplicate item is determined, the duplicate item can be more efficiently handled and the error associated with the duplication corrected.

In another embodiment, the invention provides a method for handling one or more duplicate items received in a return file. The check processing entity typically receives the return file from a receiving institution. The check processing entity can compare the duplicate item to a database of records of items previously presented to the receiving institution. If the check processing entity does not have a record of presenting the duplicate item to the receiving institution on more than one occasion, then the check processing entity did not cause the duplication error and is unable to correct the duplication. In such a situation, the check processing entity can forward the return file with the duplicate item to the depositing institution for further analysis and processing. On the other hand, if the check processing entity has a record of presenting the duplicate item to the receiving institution, the check processing entity can suspend the duplicate item for further analysis to determine the cause of the duplication.

In yet another embodiment, the invention provides a method for handling one or more duplicate items received in a return file. If the check processing entity has determined that it presented the duplicate item to the receiving institution more than once, the check processing entity can undertake further analysis to determine the cause for the duplication. For example, the check processing entity can compare the duplicate item to a database of records of items received from a depositing institution for processing. If the duplicate item matches more than one of the items received from the depositing institution for processing, then the depositing institution deposited the item with the check processing entity on more than one occasion. In such a situation, the duplication error is the result of the depositing institution depositing the duplicate item more than once and the check processing entity forwards the return ICL file with the duplicate item to the depositing institution for further processing.

These and other aspects, objects, features, and advantages of the invention will become apparent to a person skilled in the art upon consideration of the following detailed description of illustrated exemplary embodiments, which include the best mode of carrying out the invention as presently perceived.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram depicting a system for electronic check processing in accordance with certain exemplary embodiments of the invention.

FIG. 2 is a block diagram depicting a system for electronic check processing in accordance with certain exemplary embodiments of the invention.

FIG. 3 is a flow chart diagram illustrating a method for processing duplicative electronic checks according to certain exemplary embodiments of the invention.

FIG. 4 is a flow chart diagram illustrating a method for processing duplicative electronic checks according to certain exemplary embodiments of the invention.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

The invention is directed to systems and methods for processing checks under the Act. In particular, the invention is directed to monitoring the processing status of electronic image cash letters (“ICLs”) and items in the ICLs (“items” or “ICL items”) during electronic check processing and using information collected during the monitoring process to locate errors where items have been duplicated for payment or presentment more than once.

The invention comprises a computer program that embodies the functions described herein and illustrated in the appended flow charts. However, it should be apparent that there could be many different ways of implementing the invention in computer programming, and the invention should not be construed as limited to any one set of computer program instructions. Further, a skilled programmer would be able to write such a computer program to implement an exemplary embodiment based on the flow charts and associated description in the application text. Therefore, disclosure of a particular set of program code instructions is not considered necessary for an adequate understanding of how to make and use the invention. The inventive functionality of the claimed computer program will be explained in more detail in the following description read in conjunction with the figures illustrating the program flow.

Turning now to the drawings, in which like numerals indicate like elements throughout the figures, exemplary embodiments of the invention are described in detail.

An exemplary system for processing checks will now be described with reference to FIGS. 1-2. FIG. 1 is a block diagram depicting a system 100 for processing checks, according to an exemplary embodiment. FIG. 2 is a block diagram depicting a depositing institution 103 of the system 100, according to an exemplary embodiment.

The system 100 comprises various financial institutions and computer systems involved in check processing. In particular, the system 100 comprises the depositing institution 103, a check processing entity 105, and a receiving institution 125. The depositing institution 103 collects paper checks from a customer. Then, the depositing institution 103 can bundle the paper checks in one or more paper cash letters. Each paper cash letter can comprise one or more bundles of original paper checks and paper image replacement documents, such as substitute checks. The depositing institution 103 forwards the paper checks to the check processing entity 105 via a paper cash letter for electronic processing.

Alternatively, the depositing institution 103 can itself generate an electronic image cash letter based on the paper checks. In this case, the depositing institution 103 can forward the generated ICL to the check processing entity 105 for electronic processing. The ICL can be an electronic file that complies with the American National Standards Institute Specifications for Electronic Exchange of Check and Image Data (ANSI X9.37/X9.100), or other appropriate industry standards, as may change from time to time. The ICL can comprise, for each paper check, one or more electronic images of the check, all of the complete MICR data provided on the check, and additional financial data related to the check.

The ICL can further comprise a series of records related to the checks. For example, for each bundle of checks in the ICL, the ICL can include a bundle summary control record comprising information about the bundle, such as a bundle identification number, the number of items in the bundle, the value of each of the checks in the bundle, and the total value of all the checks in the bundle. The ICL also can comprise an ICL control record comprising information about the origin and destination of the ICL, and a cash letter bundle summary control record comprising a summary of all bundle summary control records in the ICL.

Thus, in alternative embodiments of the invention, the depositing institution 103 can (1) forward received paper checks to the check processing entity 105; or (2) generate an ICL for received checks and forward the ICL to the check processing entity 105.

The following description discusses an exemplary embodiment in which the depositing institution 103 generates an ICL for received checks and forwards the ICL to the check processing entity 105. The depositing institution 103 processes the received paper checks at a sorter 207. The sorter 207 electronically captures information from each paper check. The sorter 207 comprises an image capture device (not shown), such as a scanner or camera, which captures at least one electronic image of each check. For example, the sorter 207 can capture, for each check, an image of the front of the check and an image of the back of the check.

Upon image capture, the sorter 207 forwards each image to a DI data capture module 211 of a DI check processor 209 for further processing. The DI data capture module 211 can store the electronic image(s) in one or more image files, which the DI data capture module 211 maintains in a database 210 of the DI check processor 209. In one exemplary embodiment, the sorter 207 and the DI data capture module 211 can be part of the same physical unit.

The sorter 207 further comprises a MICR reader (not shown) that reads the MICR data financial data from each check. Upon reading the MICR data, the sorter 207 identifies additional financial data related to the check, which is incidental to the processing of the check, and associates that information with the check image(s). For example, the sorter 207 can identify or assign a unique item sequence number, a check processing site identifier, a processing date, a check amount, and/or a routing transit number of the depositing institution 103. The sorter 207 forwards the financial data, including the MICR data and additional financial data, to the DI data capture module 211 for further processing.

The DI data capture module 211 stores a form financial data file with multiple fields. The DI data capture module 211 reads the financial data from the sorter 207 and parses and stores portions of the financial data in each of the data fields. The fields of the financial data file can comprise all of the MICR data from the original paper check. The DI data capture module 211 stores the financial data file in the database 210.

The DI check processor 209 further comprises an addenda data module 212, which generates and/or captures electronic addenda data for each check. For example, the addenda data can comprise a bank endorsement. The addenda data module 212 inputs the addenda data into one or more addenda data files. The addenda data module 212 stores the addenda data file(s) in the database 210.

For each check, the DI data capture module 211 associates the corresponding image file(s), financial data file, and addenda data file(s) for a check with a sequence number, identification number, or other suitable data link that uniquely identifies the check data.

The DI check processor 209 further comprises an ICL module 215, which generates at least one ICL comprising information regarding one or more bundles of checks. Each bundle can comprise one or more checks. For each check, the ICL can include the electronic image(s) from the check's image file(s), the financial data from the check's financial data file, and the addenda data from the check's addenda data file.

The ICL can further comprise a series of records related to the checks. For example, for each bundle of checks in the ICL, the ICL can include a bundle summary control record comprising information about the bundle, such as a bundle identification number, the number of items in the bundle, the value of each of the checks in the bundle, and the total value of all the checks in the bundle. The ICL also can comprise an ICL control record comprising information about the origin and destination of the ICL, and a cash letter bundle summary control record comprising a summary of all bundle summary control records in the ICL. The DI check processor 209 forwards the ICL to a data capture module 111 of a check processor 109 of the check processing entity 105 for further processing. The DI check processor 209 can forward the ICL to the data capture module 111 of the check processing entity 105 via an electronic ICL file. The electronic ICL file can comprise one or more ICLs.

Upon receiving the electronic ICL file, the data capture module 111 instructs a tracking module 131 of the check processor 109 to create an electronic cash letter record file for use in monitoring the processing status of each ICL and item contained in the electronic ICL file. The electronic cash letter record file comprises data fields configured to receive information regarding the electronic ICL file and each ICL and item contained therein. For example, the electronic cash letter record file can comprise a field in which the current processing status of an ICL/item can be stored. The tracking module 131 stores the electronic cash letter record file in a record database 132 of the check processor 109.

The tracking module 131 stores a record of receiving the electronic ICL file in the electronic cash letter record file. For example, the record can identify the electronic ICL file and associate a receipt indicator with the electronic ICL file. The record can identify the electronic ICL file by any identifying means, such as a total dollar amount of the ICLs contained within the electronic ICL file or the name and/or American Bankers Association (“ABA”) routing number of the depositing institution 103 that transmitted the electronic ICL file to the data capture module 111. The receipt indicator can comprise any indicia indicating that the electronic ICL file was received by the data capture module 111. For example, the receipt indicator can comprise a simple, binary indicator. Alternatively, the receipt indicator can comprise the date and/or time at which the electronic ICL file was received by the data capture module 111.

Upon storing the record of receiving the electronic ICL file in the electronic cash letter record file, the tracking module 131 validates the contents and/or format of the electronic ICL file. For example, the tracking module 131 can determine whether each ICL in the electronic ICL file complies with the American National Standards Institute Specifications for Electronic Exchange of Check and Image Data (ANSI X9.37/X9.100), or other appropriate industry standards, as may change from time to time. The tracking module 131 also can evaluate each electronic check image in the ICLs to determine whether it meets particular quality standards. Certain exemplary systems and methods for performing such an evaluation are described in co-pending U.S. patent application Ser. No. 11/079,120, entitled “Assessing Electronic Image Quality,” the disclosure of which is hereby fully incorporated herein by reference.

For example, the tracking module 131 can determine whether to accept or reject the electronic ICL file for processing based on the validation results. Similarly, the tracking module 131 can determine whether to accept or reject each ICL and/or item contained in the electronic ICL file based on the validation results. The tracking module 131 stores a record of the validation in the electronic cash letter record file. For example, the record of the validation can comprise a simple, binary indicator indicating that the validation was completed or failed to complete. Alternatively, the record of the validation can comprise detailed information regarding the validation completion and/or the results of the validation. For example, the record of the validation can comprise the date and/or time at which the validation was started, completed, and/or failed, the reason(s) that the validation failed, the results of the validation, and a reason for each validation result.

Upon validating the electronic ICL file, the check processor 109 separately processes each ICL and item contained in the electronic ICL file. For each ICL in the electronic ICL file, the tracking module 131 assigns a tracking number to the ICL and each of the items contained therein. In an exemplary embodiment, the same tracking number can be assigned to the ICL and each item in the ICL. In an alternative exemplary embodiment, different tracking numbers can be assigned to the ICL and each item in the ICL, with the tracking number for each item also identifying the ICL. The tracking number can be any unique indicia that can be used to identify the ICL and the items. For example, the tracking number can comprise any set of numbers, letters, symbols, or a combination thereof. The tracking module 131 can use the tracking number in monitoring the processing status of the ICL and the items. For example, the tracking module 131 can use the tracking number to identify certain records in the electronic cash letter record file regarding the processing status of the ICL and the items.

The tracking module 131 stores the tracking number in the electronic cash letter record file. For example, for each ICL, the tracking module 131 can store a record identifying the ICL and associating the tracking number with the ICL and the items contained therein. In one exemplary embodiment, the record can comprise a list of the items in the ICL. The record can identify, or otherwise be associated with, the electronic ICL file from which the ICL originated.

The tracking module 131 can further associate an incoming ICL value amount and an outgoing ICL value amount with each ICL. The incoming ICL value amount comprises the total value of the items in the received ICL. The outgoing ICL value amount comprises the total value of the items in the received ICL that have been presented in an outgoing ICL. Because none of the items in the received ICL will have been presented to a receiving institution 125 at the time the tracking module 131 first associates the value amounts with the ICL, the initial value of the outgoing ICL value amount is $0. As each item from the received ICL is presented to a receiving institution 125, the tracking module 131 can update the outgoing ICL value amount. Upon successful presentment of each item in the ICL, the outgoing ICL value amount should equal the incoming ICL value amount. The tracking module 131 can store the incoming ICL value amount and the outgoing ICL value amount in the electronic cash letter record file. Each value amount can be associated with the ICL and/or the ICL's tracking number in the electronic cash letter record file.

The tracking module 131 assigns a sequence number to each item in each ICL. For each item, the sequence number can comprise any unique indicia that can be used to identify the item. For example, the sequence number can comprise any set of numbers, letters, symbols, or a combination thereof. The tracking module 131 can store the sequence number in the electronic cash letter record file. For example, the tracking module 131 can store a record identifying the item and associating the sequence number with the item. The record can identify, or otherwise be associated with, the ICL, and/or the electronic ICL file, from which the item originated.

The tracking module 131 can use an item's sequence number in monitoring the processing status of the item. For example, the tracking module 131 can use the sequence number to identify certain records in the electronic cash letter record file related to the processing status of the item.

For each item in each ICL, the data capture module 111 reads the contents of the item and/or the contents of the ICL corresponding to the item and stores any electronic check image(s) corresponding to the item in one or more image files. The data capture module 111 maintains the image file(s) in an image file database 113 of the check processor 109. The tracking module 131 stores a record of the image file storage in the electronic cash letter record file. For example, the record of the image file storage can comprise a simple, binary indicator indicating that the image file storage was completed or failed to complete. Alternatively, the record of the image file storage can comprise detailed information regarding the image file storage, such as the date and/or time at which the image file storage occurred, the date and/or time at which the image file storage failed, the reason(s) for which the image file storage failed, and the name(s) of the stored image file(s).

For each item in each ICL, the data capture module 111 reads the contents of the item and/or the contents of the ICL corresponding to the item and stores financial data corresponding to the item in a financial data file. The data capture module 111 maintains the financial data file in a financial data file database 114 of the check processor 109. The tracking module 131 stores a record of the financial data file storage in the electronic cash letter record file in the record database 132. For example, the record of the financial data file storage can comprise a simple, binary indicator indicating that the financial data file storage was completed or failed to complete. Alternatively, the record of the financial data file storage can comprise detailed information regarding the financial data file storage, such as the date and/or time at which the financial data file storage occurred, the date and/or time at which the financial data file storage failed, the reason(s) for which the financial data file storage failed, and the name of the stored financial data file.

For each item in each ICL, an addenda data module 112 reads the contents of the item and/or the contents of the ICL corresponding to the item and stores addenda data corresponding to the item in one or more addenda data files. The addenda data module 112 maintains the addenda data file(s) in an addenda data file database 115 of the check processor 109. The tracking module 131 stores a record of the addenda data file storage in the electronic cash letter record file. For example, the record of the addenda data file storage can comprise a simple, binary indicator indicating that the addenda data file storage was completed or failed to complete. Alternatively, the record of the addenda data file storage can comprise detailed information regarding the addenda data file storage, such as the date and/or time at which the addenda data file storage occurred, the date and/or time at which the addenda data file storage failed, the reason(s) for which the addenda data file storage failed, and the name(s) of the stored addenda data file(s).

For each item in each ICL, the data capture module 111 associates the corresponding image file(s), financial data file, and addenda data file(s) for further processing. For example, the data capture module 111 can associate the image file(s), the financial data file, and the addenda data file(s) for the item with the item's sequence number or another suitable data link.

The check processor 109 further comprises a check presentment module 116, which is operable to present each received item to the receiving institution 125 for payment. The check presentment module 116 can generate a substitute check file for each item. In an exemplary embodiment, the substitute check file can comprise the electronic image(s), financial data, and addenda data corresponding to the item. The check presentment module 116 stores the substitute check file in a substitute check database 108 of the check processor 109.

The tracking module 131 stores a record of the substitute check file storage in the electronic cash letter record file. For example, the record of the substitute check file storage can comprise a simple, binary indicator indicating that the substitute check file storage was completed or failed to complete. Alternatively, the record of the substitute check file storage can comprise detailed information regarding the substitute check file storage, such as the date and/or time at which the substitute check file was created, the date and/or time at which the substitute check file storage occurred, the date and/or time at which the substitute check file creation/storage failed, the reason(s) for which the substitute check file creation/storage failed, and the name of the stored substitute check file. The tracking module 131 associates the record with the item in the electronic cash letter record file.

For each receiving institution 125, the check presentment module 116 creates at least one ICL comprising one or more substitute check files. The tracking module 131 stores a record of the ICL creation in the electronic cash letter record file. For example, the record of the ICL creation can comprise a simple, binary indicator indicating that the ICL was created or that the check presentment module 116 failed to create the ICL. Alternatively, the record of the ICL creation can comprise detailed information regarding the ICL creation, such as the date and/or time at which the ICL was created, the date and/or time at which the check presentment module 116 failed to create the ICL, and the reason(s) for which the check presentment module 116 failed to create the ICL. The tracking module 131 associates the record with each item included in the created ICL in the electronic cash letter record file.

The tracking module 131 aggregates the values of the items in the created ICL by tracking number. For each tracking number, the tracking module 131 adds the aggregated value to the outgoing ICL value amount corresponding to the tracking number. Thus, the outgoing ICL value amount will comprise the total value of the items received in the ICL associated with the tracking number that have been processed for presentment in the created, outgoing ICL. For example, the tracking module 131 can determine whether all the items in the ICL processed correctly based or whether the outgoing ICL value amount equals the incoming ICL value amount. If so, then all of the items processed correctly. If not, then at least one of the items has not finished processing or has not been processed correctly.

Depending on the preferences of the receiving institution 125, the check presentment module 116 can present the ICL electronically or via paper. For example, the check presentment module 116 can electronically transmit the ICL via a network (not illustrated) to an RI computer 126 of the receiving institution 125. Upon transmitting the ICL, the tracking module 131 stores a record of the ICL transmission in the electronic cash letter record file. For example, the record of the ICL transmission can comprise a simple, binary indicator indicating that the ICL was transmitted or that the check presentment module 116 failed to transmit the ICL. Alternatively, the record of the ICL transmission can comprise detailed information regarding the ICL transmission, such as the date and/or time at which the ICL was transmitted, the date and/or time at which the ICL failed to transmit, the reason(s) for which the ICL failed to transmit, and the name and/or ABA number of the receiving institution 125. The tracking module 131 associates the record with each item included in the transmitted ICL in the corresponding electronic cash letter record file.

Alternatively, the ICL can be locally or remotely printed for paper delivery. For example, the check presentment module 116 can locally print the ICL on a printer 117 of the check processing entity 105. In another example, the receiving institution 125 can print the ICL on an RI printer 127. In an exemplary embodiment, the check presentment module 116 can prepare a print stream comprising the ICL. Certain exemplary systems and methods for generating such a print stream are described in co-pending U.S. patent application Ser. No. 11/362,344, entitled “Cash Letter Print Streams with Audit Data,” filed on Feb. 22, 2006, the disclosure of which is hereby fully incorporated herein by reference.

In an alternative exemplary embodiment, the tracking module 131 can maintain a single record for each ICL and/or each item in the electronic cash letter record file. The tracking module 131 can continuously update the single record to reflect the current processing status of the ICL/item. Thus, the current processing status of the ICL/item can be determined simply by reading the record in the electronic cash letter record file.

The tracking module 131 can monitor the processing status of each ICL and each item throughout the various stages of electronic check processing. It can read the records stored in the electronic cash letter record file to determine whether each ICL and item processed correctly, and if not, at which processing point it failed. In addition, it can balance each incoming ICL by determining whether each item in the incoming ICL has been presented in a corresponding, outgoing ICL.

For example, for a particular ICL, the tracking module 131 can read the incoming ICL value amount and the outgoing ICL value amount associated with the ICL in the electronic cash letter record file. If the amounts are equal, then all items in the ICL have been processed. If the amounts are not equal, then one or more of the items in the ICL have not been processed, have failed to process, or have been processed multiple times.

The tracking module 131 can determine the processing status of each item in the ICL by reviewing the electronic cash letter record file. For example, if no record corresponding to a particular item in the electronic cash letter record file indicates that a substitute check file corresponding to the item was included in an outgoing ICL file, then the tracking module 131 can determine that the item has not yet been fully processed. In addition, if multiple records corresponding to a particular item indicate that a substitute check file corresponding to the item was included in an outgoing ICL file, then the tracking module 131 can determine that the item has been processed multiple times.

In one exemplary embodiment, the tracking module 131 can generate one or more reports regarding the processing statuses of the ICLs/items. For example, the tracking module 131 can generate a report comprising the processing status of each item in an ICL. Alternatively, the tracking module 131 can generate a report comprising the processing status of each item that has failed to process, remains pending, or has been processed multiple times. For example, the report can comprise a list of each item that has failed to process, remains pending, or has been processed multiple times. The report can further comprise detailed information regarding the processing status of each item, such as the last processing step that the item completed, the date and/or time that the item completed its last processing step, the date and/or time that the item failed to complete a processing step, the reason(s) for which the item failed to complete a processing step, the date and/or time that the item was received (in the electronic ICL file) at the check processor 109, and/or the dollar value of the item.

In one exemplary embodiment, the report can comprise a summary of the processing statuses of all the items in an ICL. For example, the report can comprise a total number of items in the ICL, a total number of items in the ICL that have been processed, a total number of items in the ICL that have failed to process, a total number of items in the ICL that remain pending, and/or a total number of items in the ICL that have been processed multiple times.

The tracking module 131 can output each generated report. For example, the tracking module 131 can display a generated report on a monitor (not shown) or other display device. Alternatively, the tracking module 131 can print the generated report on the printer 117 of the check processing site.

Those skilled in the art will appreciate that exemplary system 100 is merely representative of the components for processing checks. Other embodiments of the invention may not have all of the components identified in FIGS. 1-2 or can include additional components

FIGS. 3 and 4 are flow charts depicting methods 300 and 315 for processing duplicative electronic checks represented as ICL items, according to certain exemplary embodiments of the invention. The exemplary methods 300 and 315 are illustrative and, in alternative embodiments of the invention, certain steps can be performed in a different order, in parallel with one another, or omitted entirely, and/or certain additional steps can be performed without departing from the scope and spirit of the invention. The methods 300 and 315 are described below with reference to FIGS. 1 and 2.

Referring to exemplary method 300 illustrated in FIG. 3, in step 305, a receiving financial institution 125 identifies a duplicate item that has been presented for payment. For example, the receiving institution 125 may have received the duplicate item in different ICL files from one or more check processing entities or the receiving institution 125 may have received the same ICL file twice. The ICL file is an electronic file that includes at least one ICL. For example, each ICL can be an electronic file that complies with the ANSI X9.37/X9.100 standard, or other appropriate industry standards, as may change from time to time. Each ICL includes one or more bundles of items (checks and/or IRDs) to be processed. For a particular item, the ICL can include one or more electronic images of the item, all of the complete MICR data provided on the item, and addenda data of the item.

The ICL also can include a series of records related to the items. For example, for each bundle of items in the ICL, the ICL can include a bundle summary control record including information about the bundle, such as a bundle identification number, the number of items in the bundle, the value of each of the items in the bundle, and the total value of all the items in the bundle. The ICL also can include an ICL control record containing information about the origin and destination of the ICL, and a cash letter bundle summary control record containing a summary of all the bundle summary control records in the ICL.

In certain embodiments of the invention, the ICL file also can include a file header including information identifying the depositing institution 103, such as a name of the depositing institution 103 and/or a bank routing number of the depositing institution 103. The file header also can include information regarding a creation date of the ICL file and information regarding whether each item in the ICL file is associated with a forward transaction or a return transaction.

For example, the depositing institution 103 can submit the ICL file to the check processing entity 105 via a network (not shown). The network can include any wired or wireless telecommunication means by which computerized devices can exchange data, including for example, a local area network (LAN), a wide area network (WAN), an intranet, an Internet, or any combination thereof.

In step 310, the receiving institution 125 places the duplicate item identified in step 305 in a return ICL file and transmits the return ICL file to the check processing entity 105. Typically, the header of the return ICL file will identify its contents as comprising one or more duplicate items. In step 315, the check processing entity 105 receives the return ICL and identifies the return ICL as comprising one or more duplicate items by examining the file's header. When a return ICL comprising one or more duplicate items is identified, the check processing entity 105 forwards the file to the duplicate item processing module 135.

The processing steps that the duplicate item processing module 135 undertakes assist the check processing entity in identifying the reason the item has been identified as a duplicate. The techniques for determining the reason for the duplication can vary. The duplicate item processing module 135 can examine different records maintained at the check processing entity 105 in an attempt to determine the reason the receiving institution 125 received a duplicate item. Examples of techniques for determining the reason for the duplication of the item are illustrated in greater detail in FIG. 4 and will be discussed below in connection with that embodiment.

Determining the reason for the duplication of the item allows the check processing entity 105 to more efficiently correct errors created by the duplication and dispose of the return ICL as illustrated in step 320. For example, if the depositing institution 103 erroneously deposited the item on more than one occasion, the check processing entity 105 can return the duplicate item to the depositing institution 103 for correction. Alternatively, if the check processing entity 105 is the source of the error, the check processing entity 105 can correct its own records, including making any necessary adjustment to settlement records. In connection with step 320, the check processing entity 105 also can notify the receiving institution 125 of its determination and disposition of the return ICL.

Referring to FIG. 4, an exemplary method 315 is illustrated for processing duplicate items to determine the reason for the duplication. The method 315 shown in FIG. 4 is merely one example of a method for processing duplicate items and other methods may be used which fall within the scope of this invention. For example, the method shown in FIG. 4 includes a two-step comparison against the records of items previously presented to the receiving institution and against the records of items previously received from the depositing institution. In alternate embodiments, only one of these comparison steps may be employed to complete the processing. In yet other embodiments of the invention, a comparison against other types of information concerning the ICL items may be used to determine the reason for a duplication.

Turning to exemplary method 315 in FIG. 4, in step 405 the check processing entity 105 can compare the duplicate item received from the receiving institution 125 against a record of items previously presented to the receiving institution 125. The check processing entity 105 can complete this comparison using the duplicate item processing module 135 and the tracking module 131. For example, the duplicate item processing module 135 can communicate with the tracking module 131 to search for records from the record database 132 that match the duplicate item. In step 410, if more than one match for the duplicate item is not identified in the record database 132, this result means the check processing entity 105 did not previously present the duplicate item to the receiving institution 125 more than once. The duplicate item processing module 135 transmits the ICL return file with the duplicate item to the depositing institution 103, in step 415, for further analysis. The depositing institution can analyze its own records in an attempt to determine whether the item has in fact been duplicated and, if so, the cause of the duplication. Alternatively, if in step 410 the duplicate item processing module 135 does not locate any record of the duplicate item in the record database 132, the duplicate item can also be forwarded to the depositing institution 103 in step 415 for further processing.

Referring again to step 410, if the duplicate item processing module 135 identifies more than one match for the duplicate item in the record database 132, the match indicates the check processing entity 105 presented the item to the receiving institution 125 more than once. The reason the item was presented more than once can be that the check processing entity 105 erroneously presented the item on more than one instance or it can be the result of the depositing institution 103 depositing the item with the check processing entity 105 more than once. Duplication errors can also arise from other reasons, such as the activities of other electronic check processing or depositing institutions not illustrated in FIG. 1.

In step 420, the check processing entity 105 compares the duplicate item against a record of the items previously received for deposit from the depositing institution 103. Similar to step 405, this comparison can be accomplished with the duplicate item processing module 135 communicating with the tracking module 131 to compare the duplicate item against the records of deposited items stored in record database 132. If the duplicate item processing module 135 identifies more than one match in the records of deposited items stored in the record database 132, this indicates that the depositing institution is the cause of the error as it deposited the duplicate item with the check processing entity 105 on more than one occasion. When the check processing entity 105 identifies a match, decision step 425 proceeds to step 415 and the duplicate item processing module 135 of the check processing entity 105 forwards the ICL return file with the duplicate item to depositing institution 103.

Referring again to step 425, if there is not more than one match for the duplicate item in the records of items previously deposited stored in the record database 132, this indicates that the duplication is not caused by multiple deposits from the depositing institution 103, but rather, by an erroneous duplicative presentment of the item by the check processing entity 105. Proceeding to steps 430 and 435, the check processing entity 105 terminates the return item and the duplicate item processing module 135 examines the records of presented items stored in the record database 132 to attempt to determine the reason the item was presented more than once to the receiving institution 125. The examination of the records of presented items can also be assisted by manual operations of the check processing entity personnel. After completing the examination of the records, in step 440, the check processing entity 105 can adjust the check processing entity's settlement records relating to the duplicate item. The duplicate item processing module 135 can also notify the receiving institution 125 of the result of the duplicate item processing.

Lastly, in step 445, if there are no other duplicate items for processing, exemplary process 315 returns to step 320 of FIG. 3. If there is another duplicate item for processing, exemplary process 315 proceeds to step 415 where the next duplicate item is selected and the process returns to step 405.

The invention can be used with computer hardware and software that performs the methods and processing functions described above. As will be appreciated by a person skilled in the art, the systems, methods, and procedures described herein can be embodied in a programmable computer, computer executable software, or digital circuitry. The software can be stored on computer readable media. For example, computer readable media can include a floppy disk, RAM, ROM, hard disk, removable media, flash memory, memory stick, optical media, magneto-optical media, CD-ROM, etc. Digital circuitry can include integrated circuits, gate arrays, building block logic, field programmable gate arrays (FPGA), etc.

Although specific embodiments of the invention have been described above in detail, the description is merely for purposes of illustration. It should be appreciated, therefore, that many aspects of the invention were described above by way of example only and are not intended as required or essential elements of the invention unless explicitly stated otherwise. Various modifications of, and equivalent steps corresponding to, the disclosed aspects of the exemplary embodiments, in addition to those described above, can be made by a person skilled in the art without departing from the spirit and scope of the present invention defined in the following claims, the scope of which is to be accorded the broadest interpretation so as to encompass such modifications and equivalent structures.

Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US7594600Feb 22, 2006Sep 29, 2009Federal Reserve Bank Of AtlantaExpanded mass data sets for electronic check processing
US7686209Feb 22, 2006Mar 30, 2010Federal Reserve Bank Of DallasCash letter print streams with audit data
Classifications
U.S. Classification705/35
International ClassificationG06Q40/00
Cooperative ClassificationG06Q20/042, G06Q40/00, G06Q20/108, G06Q20/0425, G06Q20/04
European ClassificationG06Q20/04, G06Q20/042, G06Q40/00
Legal Events
DateCodeEventDescription
Mar 12, 2008ASAssignment
Owner name: FEDERAL RESERVE BANK OF CHICAGO, ILLINOIS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:RODRIGUES, RICHARD;REEL/FRAME:020642/0371
Effective date: 20080208
Owner name: FEDERAL RESERVE BANK OF CLEVELAND, OHIO
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MARTIN, STEVEN D.;RACHEK, TIMOTHY;REEL/FRAME:020642/0417
Effective date: 20080207
Owner name: FEDERAL RESERVE BANK OF RICHMOND, VIRGINIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BREEDEN, BENJAMIN T., JR.;REEL/FRAME:020642/0342
Effective date: 20080306