SYSTEM AND METHOD FOR PROCESSING CHECKS AND CHECK TRANSACTIONS
A method of processing paper checks that divides into two independent paths the processing of a data file representing a check and the digital image of the check. The data files and image files are separated both in time and in space, with the data files being used to promptly initiate the transfer of funds to and from appropriate accounts, while the paper checks, at a remote location and typically lagging in time, are scanned to create digital image files and deposited as an image or substitute check if deemed ACH ineligible. The method provides for the comparison of data files to image files, based on MICR information, to find any unmatching or mismatched items for exception processing and a process to manage ACH-ineligible items as an image or substitute check.
Latest SOLUTRAN Patents:
- Data Transmission Filtering Through a Customized Filter List
- Server-Based Product Substantiation with Local Filtering System and Method
- Server-based product substantiation with local filtering system and method
- Server-based product substantiation with local filtering system and method
- Dual Redemption Path with Shared Benefits System and Method
This application is a continuation of prior U.S. patent application Ser. No. 11/699,776 filed Jan. 30, 2007 (U.S. Pat. No. 8,311,945), which in turn claims the benefit of U.S. Provisional Patent Application No. 60/763,417, filed Jan. 30, 2006, both of which are hereby incorporated by reference in their entireties.
FIELD OF THE INVENTIONThe present invention relates generally to a system and method of processing checks and check transactions, and more particularly to capturing data from a check at point of sale and later and remotely capturing the image of the check for later matching of the check image with the check data.
BACKGROUND OF THE INVENTION A. Paper Checks—Functions Served by Paper Checks and How Paper Checks Were Physically Processed HistoricallyConceptually, a paper check is a vehicle for two things: 1) the data pertinent to the financial transaction; and 2) evidence of the authorization given by the check writer (the “payer”) to transfer funds from the payer's account to the designated payee and evidence that the financial information was accurately extracted and recorded from the check.
Historically, the processing of paper check transactions was slow and labor-intensive. When one entity (“payer”) paid another entity (“payee”) with a paper check, the payee would physically transport the paper check to its own bank, i.e. a bank with which the payee had an account. The payee's bank would process the check, by reading and recording pertinent information about the transaction represented by the check. The payee's bank would sort by payers' bank all of the checks it received within a given period and physically transport those checks to the payers' banks. The payer bank would then read and record the pertinent information about the transaction contained on the check and make the appropriate debit entry to the payer's account. The payer bank would then transfer funds to the payee's bank. Finally, the payee's bank would make the appropriate credit entry to the payee's account.
The physical transport and handling of the paper checks was highly inefficient. Further, both the payer and payee banks had to process the check to collect and record pertinent information, with such double processing is time-consuming and prone to error.
B. Electronic Processing of Check TransactionThe digital age has ushered in a new approach to processing checks. Over the past decade, there has been an industry transition to the electronic processing of checks. Electronic processing involves the recordation of the data (hereafter “transaction information”) presented by the check into a digital format which can then be transferred electronically, via the internet or other connection between computer networks, between and amongst independent entities (such as banks and third party processors) without the need to physically transfer the paper check. Transaction information includes:
-
- the amount of the check;
- the routing number of the bank holding the account on which the check is written;
- the account number of the payer;
- the check number; and
- the date of the check.
By converting the transaction information described by the check into digital form that can be electronically transmitted, it is not always necessary to physically move the paper check from one entity to another to accomplish the proper debiting and crediting of the financial transaction. Electronic transfers of funds from a payer to a payee (or, more precisely, from the account of the payer to the account of the payee) are facilitated by the Automated Clearing House Network (ACH).
There remain, however, a number of functions served by the paper check that are not served by the digital file of the transaction data. For example, the paper check can be used as evidence that the transaction was authorized by the check writer, or conversely that the check was forged. The paper check can be used as proof that there was an error in the capture of transaction information. An endorsement and appropriate stamp(s) on the paper check provides proof that the transaction was paid, thereby acting as a receipt. Further, when a check bounces due to insufficient funds, the paper check can be returned and is proof that the payer owes the payee the designated amount and that the amount has not been paid.
C. Check 21—Image Exchange and Substitute ChecksTo accommodate the two competing ideals of getting rid of the burdens of handling paper checks and maintaining a paper document that can be used as proof when necessary, the U.S. federal government recently has passed legislation (“Check Clearing for the 21st Century Act”; hereafter “Check 21”) that creates a negotiable instrument called a “substitute check”. The substitute check is a paper reproduction that is generated from a stored digital image of the original check. The original check can be scanned and its digital image stored for later use in generating the substitute check. The original check can then be safely destroyed or disposed of.
If a substitute check meets the requirement of the Act, then it is the equivalent of an original paper check. A substitute check has the following physical characteristics:
-
- contains an image of the front and back of the original check;
- bears a MICR (Magnetic Ink Character Recognition) line containing all the information appearing on the MICR line of the original check;
- conforms, in paper stock, dimension, and otherwise, with generally applicable industry standards; and
- is suitable for automated processing in the same manner as the original check.
The National Automated Clearing House Association (NACHA) develops operating rules and business practices for the Automated Clearing House (ACH) Network and for electronic payments in the areas of Internet commerce, electronic bill and invoice presentment and payment (EBPP, EIPP), e-checks, financial electronic data interchange (EDI), international payments, and electronic benefits transfer (EBT). NACHA's rules have, since 2000, provided for merchants to convert checks to an ACH debit at the point of purchase (“POP conversion”). NACHA's POP conversion rules required merchants to obtain the explicit authorization (i.e. signature) of the consumer to debit their account. The merchant then returns the check to the consumer along with a receipt as required by the NACHA POP rules and regulations. At their option, merchants may keep an image of the check, though POP conversion rules do not require that the merchant keep an image of the check.
E. Back Office Conversion and New NACHA RulesAn alternative method of handling checks has been proposed by NACHA for “back office conversion” (BOC), by which merchants scan their checks in a back office, typically at the end of a day. The scanners capture an image of the check and store the image with the MICR data from the check. A file containing this information is then transferred to a bank or third party payment processor.
NACHA has passed this rule, to accommodate back office conversion, which goes into effect on Mar. 16, 2007. These rules require that a digital image of the front of the check be retained for two years, a notice provided to the consumer at point-of-sale prior to the acceptance of the check of payment, and a receipt provided to the consumer with language as depicted by NACHA and the Federal Reserve under Regulation E.
SUMMARY OF THE INVENTIONThe present invention provides a system and method for converting checks to debit entries by which data from the checks is captured at the point of purchase and this data is used to promptly process a deposit to the merchant's account via a third party payment processor (TPPP). Meanwhile, the paper checks collected by the merchant are physically transported from the merchant's place of business to another location for scanning and image capture. Each check image is stored in association with its MICR (Magnetic Ink Character Recognition) line and indexed for future retrieval purposes. The TPPP receives data files from the merchant with the MICR and amount information; the TPPP receives the physical items for scanning and imaging. The TPPP executes a matching operation between the image files and the data files, matching image files with data files based on the MICR, amount, and auxiliary information. Routines are provided for handling image files with no matching data file, data files with no matching image files, and image and data files that find a MICR match but include some discrepancy in their data (e.g. amounts do not match). The non-ACH items that find a successful match, are rendered via image exchange for settlement.
With this system and method of processing checks, the data file is used to promptly process the transaction (and send a credit to the merchant's account) through a third party payment processor. In other words, the third party payment processor can initiate the credit to the merchant's account before the image of the check is matched up to the data file, or perhaps even before the image of the check is made for ACH eligible items (i.e. first-party consumer checks and business checks that do not contain an auxiliary on-us field). In this manner, the third party payment processor can provide the merchant with improved funds availability, while still providing for the storage of the image of the check, and destruction, as required by rules and regulations governing check processing.
This system and method allows for the storage and use (e.g. reporting) of a variety of data regarding each check that may be captured at the point of sale. Such data includes MICR line (routing number, account number, check number), dollar amount, store identifier, lane/cashier identifier, point-of-sale date, and other merchant defined auxiliary information.
The system and method offers the further advantage that merchant's are relieved of the task, cost, and risk of scanning and destroying the paper checks themselves, relying instead on a secure, high-volume scanning operation to obtain digital images of the checks. This method further provides for the digital archiving of check images for prescribed periods of time.
In typical practice, many merchants have more than one location, and the system and method provide for service to more than one location of a merchant. Further, the system and method provide for service to more than one merchant. The system and method for processing check transactions is generally automated to allow processing of a high volume of check transactions from a number of merchants and to accommodate multiple locations of the merchant(s).
A method for processing paper checks according to this system including the steps of: at the merchant's point of purchase, capturing the amount of the transaction and associating that amount in a data file with MICR information for each paper check, or batch of paper checks; sending a batch of said data files representing said batch of checks to a third party payment processor without an image file; physically transporting said batch of checks to a location remote from said merchant; scanning said batch of checks thereby creating a digital image of the checks and, for each said check, associating said image with said check's MICR information; and comparing said image files with said data files to find matches.
An exemplary version of the check processing system and method is shown in the figures wherein like reference numerals refer to equivalent structure throughout, and wherein:
Periodically (typically daily), the merchant sends a data file 36 to a third party payment processor 38, reflecting a batch of such check transactions that have occurred during the period. More specifically, the merchant computer or server transfers the POS data file 36 to a TPPP computer or server over a computer network via a pre-defined file transfer protocol. The data file 36 contains at least the following information about each transaction: the MICR information (routing number, account number, and check number) and the amount. The data file 36 also includes an identifier for the merchant, location identifier, and a transaction identifier, with at least one of these identifiers being unique or with some combination of these identifiers being unique across the system that typically involves multiple merchants, each with multiple locations and with multiple transactions being processed within the reporting period.
The TPPP decisions the received data files, determining which are eligible for processing through the Automated Clearing House (ACH) 40, and which are not. ACH transactions are passed through the ACH network for processing and appropriate debiting of the consumer's account 42 and the crediting the merchant's account 44, respectively. More specifically, the TPPP computer sends data files reflecting the ACH transactions into the ACH network (i.e. the computers or servers on which the ACH network operates) via pre-defined file transfer protocol.
The merchant 34 periodically physically transfers a batch 50 of its paper checks to a secure courier (e.g. Brinks, UPS or U.S. postal service) 52 for physical delivery to a secure, high-volume scanning operation 54. This scanning service might be provided by the TPPP or may be provided by an independent company, typically in accord with a contractual relationship with the TPPP. The scanning operation 54 scans the checks, creating digital images of the checks that are stored in a digital file in association with their MICR information on the imager's server or computer. Physical checks are securely stored until they are destroyed, based on client specification.
Finally, the image files of the checks are matched to the data files representing the checks using the MICR line, thereby linking the images to the data files. This is achieved by assigning a unique number to each data record, and upon a successful match, indexing the data and image with the unique number for future access in retrieval needs. The MICR line, including the dollar amount, of a check is typically unique and this affords a one-to-one matching based on the MICR line.
This matching operation may be performed on a computer or server operated by the TPPP 38 or by the scanner 54 or by some other entity affiliated with or associated with the TPPP. This matching step is performed to identify any discrepancies between the data files and the image files which represent the checks so that these can be investigated. It will be appreciated that before the matching operation takes place, the matching computer must have access to both the POS data file and the image files created by the imager. When the matching step is performed by the TPPP, the imager transfers the image files from the imager computer to the TPPP computer over a computer network via a pre-defined file transfer protocol. When, alternatively, the matching step is performed by the imager, the TPPP transfers the POS data files from the TPPP computer to the imager computer over a computer network via a pre-defined file transfer protocol. When, as yet another alternative, the matching step is performed by a third party, the TPPP transfers its POS data files and the imager transfers its imager files to the matcher's computer over a computer network via a pre-defined file transfer protocol.
-
- Record type: a predefined indicator indicating that the record following, until file trailer indication, is a file record
- Version: predefined identifier, identifying a file format version
- Filename: assigned by a merchant
- Account Number: an identifier unique to the merchant, assigned by the TPPP
- Merchant's Bank ID: a prescribed identifier for the merchant's bank
- File items: a count of the number of detail records in this file transmission
-
- Record type: a predefined indicator indicating that the record following, until batch trailer indication, is a batch record
- Location: identifier for a store location
- Sale Date: date of sale
- ACH Company Name: Name of merchant company that will appear on consumer's bank statement (assigned by merchant)
- ACH CED: An optional additional field for a merchant description that may appear on consumer's bank statement (assigned by the merchant)
- ACH CDD: An optional additional field for merchant's discretionary data (assigned by merchant)
-
- Record type: a predefined indicator indicating that the record following, until detail record trailer indicator or batch trailer record, is a detail record
- Item type: indicates the type of document or transaction (e.g. business check, merchant payroll, non-standard check such as WIC, traveler's check, gift certificate check), personal check or Canadian
- Amount: Numeric dollar/cents amount of transaction
- Raw MICR: MICR line, consisting of digits, spaces and TOAD delimiters)
- Parsed RT: Parsed Routing Number, an optional field used when merchant's MICR reader parses the MICR to identify the routing number
- Parsed ACCT: Parsed Account Number, an optional field used when merchant's MICR reader parses the MICR to identify the consumer's account number
- Parsed CHECK: Parsed Check Number, an optional field used when merchant's MICR reader parses the MICR to identify the check number
-
- Record type: a predefined indicator indicating a batch trailer record
- Batch Items: number of data records in this batch
- Total Amount: total dollar/cents amount of all detail records in this batch
-
- Record type: a predefined indicator indicating a file trailer record
This data file is sent via data connection, such as from one computer networked, one way or another, to another computer, via a predefined secure socket layer (SSL) file transfer protocol (FTP) As shown in
For each transaction record, the payment processor makes a determination as to whether the transaction is eligible for ACH processing or not (150). ACH eligible items include first party consumer checks and small-size corporate checks. (Corporate checks come in two sizes: a “small” size that is approximately the same size as a consumer check, and a larger size.) ACH ineligible items include money orders, WIC checks, travelers checks, large-size corporate checks, government checks, and others as identified under the NACHA rules and regulations. For those records that are ACH eligible, the payment processor creates an ACH file that includes the merchant's name, company entry description, ACH tracer identifier, the MICR line, and the amount of the transaction according to NACHA rules and regulations for ACH BOC processing and various other information. (160).
The payment processor, in typical commercial practice, will provide payment processing services to a number of merchants. On a periodic basis, typically daily, the processor will batch the records of the ACH eligible items by merchant (170), and will submit the batched records in an ACH file to the ACH Network for settlement (180). Thereafter, settlement to the merchant's bank account is made, followed by balance reporting, a confirmation file and a BAI file, typically on the next business day (190).
As noted above, the physical transaction documents that customers present at a point of sale follow a path (200) that is independent of the path (110) of the data reflecting the transaction. At step 100, a merchant gathers a number of transaction documents to be processed. The merchant will do this on a periodic basis, typically at the end of each day. The merchant bundles the transaction documents together and prepares a deposit ticket 201, shown in
With reference to
The imager receives the deposited bundle of documents (or typically many deposited bundles of documents, each from one location of a merchant), scans the deposit ticket 201 and uses optical character recognition (OCR) software to interpret the information presented on the ticket 201. (Where a MICR line 207 has been pre-printed on the deposit ticket 201, it may be read by a MICR reader, then scans the ticket and applies OCR, linking the data obtained from the OCR with the MICR-obtained data.) The imager performs a balance to confirm that the amount indicated 204 on the deposit ticket 201,
As shown in
Next, the process includes an attempt to match each image record to a data record (290), where the data record was generated through path 110 and archived in step 140, described above and includes the MICR information, the dollar amount and an item identifier, merchant bank account, point-of-sale date, and location identifier. More specifically, for each image record, the data files are searched to find a data record with a “matching” MICR and amount. (Alternatively, for each data file, the image files are searched to find a data record with a matching MICR and amount.) “Matching” records are indexed to connect the image with the data.
The system provides for the setting of parameters as to the degree to which the image record and a POS data record must be the same for them to be deemed “matches” or “matching”. More specifically, the parameters determine how closely various fields must correlate for records to be deemed “matching”. A probability as to likely matching may be determined and used to assist both the identified matches and to aid in processing unmatched records. Fields used in performing comparisons between image records and POS data records include: merchant bank account identifier; sale date; check dollar amount; MICR data (raw or parsed).
For each image record for an ACH eligible item for which a matching data record is found (300), the indexed record (containing the image and data) is archived (310). For each image record for an ACH ineligible item for which a matching data record is found (320), the indexed record (containing the image and data) is archived and an image exchange file is prepared (410) that includes the image, the MICR , the merchant's bank account number and other information as required for image exchange (330). This image exchange file is then transferred via the banking network (420).
Finally, for the ACH-ineligible matched items, settlement is provided to the merchant's bank account based on availability and reported via balance reporting and a non-ACH deposit file, typically the next business day.
Situations in which no match is found for an image record or for a data record after the date that the image from the paper document was expected, are subject to exception processing (350).
The researching 560, which is done manually, automatically or via a combination of manually and automatically, is presented to the researcher automatically based on probability matching. Research most typically involves manually querying a database(s) that stores image records and/or POS data records before a final decision has been made. After the research step (560), the item is decisioned for deposit (570). In some cases, the research step will reveal that there does indeed exist a matching image record, and, in such cases, the items will be identified as a match, then presented for settlement (580). In other cases, it will be determined during research that either a POS data record or an image record requires adjustment or repair and that upon making such repair, it can be matched; in such cases the item is then flagged as “matched” and presented for settlement (580). In still other cases, when research reveals that there is no viable matching record, the POS data record can be placed back in the queue of records that will be subject to item by item matching (290) on another day; this will give the image record additional time to appear.
Finally, in some cases, it will be determined that the POS data record does not represent a transaction that ought to be processed. This occurs, for example when an errant POS entry is made and not deleted. Such POS data records will be removed 560 from the exception queue (590) and identified in a database field to indicate that no further attempts will be made to match it.
A second category of exceptions is “received, not expected” (600). These items result when there is an image record for a transaction, but no matching data record. In such cases, the item is researched (610). As with the “expected not received” items, a decision is made (620) as to whether the “received not expected item” ought be processed for settlement, upon finding a match or discovering a repair to be made to the record to allow a match. Such now-matched items are then presented for settlement (630). Items for which no match or repair can be made are removed from the exceptions queue (640). Typically, such unmatchable items occur when a coupon, gift certificate, or non-negotiable paper instrument is errantly included among the scanned document. These records are assigned a type to indicate that they are non-cash items (640) and are not presented for settlement.
A third category of exceptions is “data mismatch” (700) where a match is found based on the MICR information, but some portion of the data from the image record does not match with the data record. For such cases, the records are researched (710) and an appropriate adjustment or correction (720) is made and the transaction is presented for settlement (730). For records for which no match can be found and no repair is called for, the non-matching image record or POS data record is removed from the exception queue (740) and is not presented for settlement.
Yet another step (not pictured) in processing exceptions may include reporting of exceptions by the TPPP to the merchants.
In a preferred method, the merchant's account can be credited at the initiation of the third party processor, based on the data file, before the image of the check is matched to the data file, or perhaps even before the check is imaged for ACH eligible items. ACH ineligible items are rendered processed through the Image Exchange Network upon a successful data and image match.
It should be noted that this system and method has been described in the context of a coordinated effort between merchants, a third party payment processor and a high-volume image scanning entity. The system may also function with additional or fewer parties and with other divisions of labor amongst the parties. For example, the matching, indexing and exception processing steps (290) are described as being done by the TPPP, but might instead be done by the imager or another entity. As another example, the third party payment processor might perform the scanning task. Such shifts in the division of labor would be facilitated with appropriate file transfer steps. Although an illustrative version of the device is shown, it should be clear that many modifications to the device may be made without departing from the scope of the invention.
Claims
1. A method for processing paper checks, comprising:
- a) receiving, at a payment processor computer, a plurality of ACH-eligible transaction records;
- b) submitting ACH transactions described in the ACH-eligible transaction records to an ACH network for processing;
- c) after step b), scanning the paper checks with a digital image scanner to create image records of the paper checks, the image records containing check images created by the digital image scanner; and
- d) comparing, at the payment processor computer, the image records with the ACH-eligible transaction records to find matches.
2. The method for processing paper checks of claim 1 wherein the payment processor computer of step a) is the same physical computer as the payment processor computer of step d).
3. The method for processing paper checks of claim 1, wherein each image record further contains a check identifier used to find matches with the ACH-eligible transaction records in the comparing step.
4. The method for processing paper checks of claim 3, wherein the check identifier in the image record is image MICR information that is compared in the comparing step with transaction record MICR information found in the ACH-eligible transaction records.
5. The method for processing paper checks of claim 1, wherein a first set of ACH-eligible transaction records is received in a first transaction file received from a first location of a first merchant.
6. The method for processing paper checks of claim 5, wherein a second set of ACH-eligible transaction records is received in a second transaction file received from a second location of the first merchant, wherein the transaction files each contain a first merchant identifier identifying the first merchant and a location identifier identifying one of the first and second locations of the first merchant.
7. The method for processing paper checks of claim 6, further comprising a third set of ACH-eligible transaction records received in a third transaction file received from a second merchant, the third transaction file containing a second merchant identifier identifying the second merchant.
8. The method for processing paper checks of claim 7, wherein a plurality of ACH transactions are submitted in a single ACH file that is submitted to the ACH network for processing.
9. The method for processing paper checks of claim 8, wherein all ACH transactions within a single ACH file are associated with the single merchant identifier.
10. The method for processing paper checks of claim 7, further comprising receiving a first batch of paper checks from the first merchant and receiving a second batch of paper checks from the second merchant and scanning the first and second batches of paper checks at the same digital image scanner.
11. The method for processing paper checks of claim 10, wherein each received batch of paper checks includes a deposit ticket including the merchant identifier associated with the merchant sending the batch of paper checks, and further wherein the merchant identifier is included in the image records containing check images created for the batch of paper checks.
12. A method for processing paper checks, comprising:
- a) receiving, at one of a first computer and a second computer, a plurality of ACH-eligible transaction records associated with a plurality of paper checks;
- b) submitting ACH transactions described in the ACH-eligible transaction records to an ACH network for processing; and
- c) after step b), comparing, at one of the first computer and the second computer, image records containing check images of the plurality of paper checks with the ACH-eligible transaction records to find matches.
13. The method for processing paper checks of claim 12, wherein step a) and step c) are both performed on the same first computer.
14. The method for processing paper checks of claim 13, wherein step b) is also performed by the same first computer.
15. The method for processing paper checks of claim 12, wherein each image record contains an image record transaction amount and a check identifier used to find matches with ACH-eligible transaction records in the comparing step.
16. The method for processing paper checks of claim 15, wherein the check identifier in the image record is image MICR information that is compared in the comparing step with transaction record MICR information found in the ACH-eligible transaction records.
17. The method for processing paper checks of claim 12, further comprising a step of providing exception processing procedures for unmatched image records and ACH-eligible transaction records.
18. The method for processing paper checks of claim 12, wherein step a) further comprises receiving a plurality of ACH-ineligible transaction records, and further comprises separating ACH-eligible transaction records from the ACH-ineligible transaction records.
19. The method for processing paper checks of claim 18, wherein step c) further comprises comparing image records with both ACH-eligible transaction records and ACH-ineligible transactions to find matches.
20. The method for processing paper checks of claim 19, further comprising:
- d) after step c), submitting to a banking network an ACH-ineligible data file representing ACH-ineligible transactions described in the ACH-ineligible transaction records, said ACH-ineligible data file including the check images from the image records matched to the ACH-ineligible transaction records.
21. The method for processing paper checks of claim 12, further comprising the step of:
- d) storing at one of the first computer and the second computer, in association with each ACH-eligible transaction record an expected date for receipt of the matching image record;
- e) identifying, at one of the first computer and the second computer, ACH-eligible transaction records that have not been matched in step c) after the expected date; and
- f) providing exception processing procedures for the ACH-eligible transaction records identified in step e).
22. A computerized method for processing a plurality of paper checks, comprising:
- a) receiving, at a third party payment processor computer, a plurality of transaction records with each transaction record containing an amount of a transaction that used one of the plurality of paper checks and MICR information extracted from the one of the plurality paper checks, the transaction records being received without a digital image of the paper check;
- b) determining, at the third party payment processor computer, whether each transaction record is ACH-eligible or ACH-ineligible;
- c) submitting, from the third party payment processor computer, ACH-eligible transaction records to the ACH network for settlement;
- d) after step c), scanning the plurality of paper check with a digital image scanner to create a plurality of digital check images, with each of the digital check images being associated with MICR information extracted from the paper checks;
- e) submitting, at the third party payment processor computer, the ACH eligible transaction records and the ACH-ineligible transaction records to a matching protocol matching the transaction records to a matched digital check image;
- f) creating an image exchange item for each ACH-ineligible transaction record for which a matched digital check image was found by the matching protocol, the image exchange item including the matched digital check and MICR information; and
- g) submitting the image exchange items to a banking network for settlement.
23. The method of claim 22, wherein the transaction records are matched to the matched digital check image by matching the MICR information in the transaction record to the MICR information associated with the digital check image.
24. The method of claim 22, wherein the transaction records are matched to the matched digital check image by matching the MICR information in the transaction record to the MICR information associated with the digital check image and by matching a transaction merchant account number associated with the transaction record with an image merchant account number associated with the digital check image.
25. The method of claim 22, wherein fields in the transaction records are matched to fields associated with the digital check images, wherein the fields include MICR information and an additional field chosen from a set comprising merchant bank account identifier, sale date, and check dollar amount.
26. A method for processing a plurality of paper checks, comprising:
- a) receiving, at a third party payment processor computer, a plurality of transaction records via a data connection with a merchant location, each transaction record comprising a transaction amount and transaction MICR data extracted from one of the plurality of paper checks received at the merchant location;
- b) submitting, at the third party payment processor computer, the transactions described in the transaction records for ACH processing;
- c) transporting the plurality of paper checks to a scanning location remote from the merchant location;
- d) scanning, after step b) and at the scanning location, the plurality of paper checks to create a plurality of digital check images, each digital check image being associated with image MICR data from the scanned paper check;
- e) receiving, at the third party payment processor computer, the plurality of digital check images; and
- f) comparing, at the third party payment processor computer, the image MICR data from the digital check images with transaction MICR data from the transaction records to find matching digital check images and transaction records with the same MICR data.
27. The method for processing the plurality of paper checks of claim 26 wherein the third party payment processor computer of step b) is the same physical computer as the third party payment processor computer of step f).
28. The method for processing the plurality of paper checks of claim 26, wherein the plurality of paper checks comprises a first set of paper checks and the plurality of transaction records comprises a first set of transaction records, and further comprising:
- g) receiving, at the third party payment processor computer, a second set of transaction records via a second data connection with a second merchant location, each transaction record in the second set comprising data extracted from one of a second set of paper checks received at the second merchant location;
- h) submitting, at the third party payment processor computer, the transactions described in the second set of transaction records for ACH processing;
- i) transporting the second set of paper checks to the scanning location remote from the second merchant location;
- j) scanning, after step h) and at the scanning location, the second set of paper checks to create a second set of digital check images;
- k) receiving, at the third party payment processor computer, the second set of digital check images; and
- l) comparing, at the third party payment processor computer, MICR information in the second set of transaction records and the second set of digital check images to find matching transaction records and digital check images.
29. The method for processing the plurality of paper checks of claim 28, wherein each transported set of paper checks includes a deposit ticket including a merchant identifier identifying a merchant, and further wherein the merchant identifier is associated with each digital check image created by scanning that set of paper checks.
30. The method for processing the plurality of paper checks of claim 29, wherein the comparing steps further comprise comparing merchant identifiers associated with the digital check images with a transaction merchant identifier within the transaction records.
31. A system for processing paper checks, comprising:
- a) a data connection that receives at least one data file containing a plurality of transaction records relating to a plurality of check transactions, the transaction records being received without an image file;
- b) a digital image scanner that scans paper checks to create digital image files; and
- c) a processor controlled by programming that i) submits transactions records to the ACH network for processing over the data connection, and ii) after submission of transaction records to the ACH network, compares said digital image files with said data files to find a matching digital image file and matching transaction records.
International Classification: G06Q 20/04 (20060101); G06Q 20/10 (20060101);