US20080247629A1

US20080247629A1 - Systems and methods for check 21 image replacement document enhancements

Info

Publication number: US20080247629A1
Application number: US11/868,504
Authority: US
Inventors: Clark S. Gilder; Michael G. Lalonde
Original assignee: Individual
Current assignee: Global Standard Financial Inc
Priority date: 2006-10-10
Filing date: 2007-10-07
Publication date: 2008-10-09
Also published as: US20080086420A1; US7702588B2; US8600898B2; US20090094148A1; US7620603B2; US20080249931A1; US20080086421A1; US7539646B2

Abstract

The present invention provides enhanced processing of Check 21 items using an electronic payment system (EPS) to capture metadata instructions. The metadata includes instructions regarding an intended payment to a payee, and can be generated through a truncation process and optical character recognition, directly from a digitally originated check, and the like. The metadata is stored in a database or the like for further processing instead of printing a paper check. In various exemplary embodiments, the present invention provides a capability to print Image Replacement Documents (IRDs) compliant to Check 21 regulations from the metadata. Further, these IRDs can include enhanced features as described herein.

Description

CROSS-REFERENCE TO RELATED APPLICATION(S)

The present non-provisional patent application claims priority to U.S. Provisional Patent Application Ser. No. 60/850,536, filed Oct. 10, 2006, and entitled “FINANCIAL PAYMENT SYSTEMS AND METHODS,” the contents of which are incorporated in full by reference herein.

FIELD OF THE INVENTION

The present invention relates generally to Check 21 imaging systems and methods, and more particularly, provides systems and methods for enhanced processing of Check 21 Image Replacement Documents (IRDs), such as storing check data in a digital payment file instead of an image file which allows enhanced processing and printing of IRDs.

BACKGROUND OF THE INVENTION

The Check Clearing for the 21st Century Act (Check 21) was designed to foster innovation in the payments system and to enhance efficiency by reducing some of the legal impediments to check truncation (i.e., eliminating a paper check by converting into a digital image and destroying the original paper item). The law facilitates check truncation by creating a new negotiable instrument called a substitute check (also known as an Image Replacement Document (IRD)), which permits banks to truncate original paper checks, to process check information electronically via exchange of check image files, and to deliver substitute checks to banks that want to continue receiving paper checks. A substitute check is created from a check image described by the ANSI X9 standards, such as X9.37 draft, X9.140, and X9.180, all of which are incorporated in-full by reference herein. This image file is a digital bitmap in Tagged Image File Format (TIFF) format created by electronically scanning and imaging the front and back of the original paper check. The substitute check is created by printing the front and back images along with some additional information on an 8.5×11 inch sheet of paper. Under the Check 21 law, this IRD is treated as the legal equivalent of the original check and includes all the information contained on the original check (when printed, the images and data must conform to the X9.140 standard). The law does not require banks to accept checks in electronic form nor does it require banks to use the new authority granted by the Act to create substitute checks.
Referring to FIG. 1, a substitute check (or IRD) 10 is a paper reproduction of an original check that contains an image of the front and back of the original check and is suitable for automated processing in the same manner as the original check. To clear a check for consideration of payment, the depositing bank transfers, presents, or returns the substitute check 10 (or another paper or electronic representation of a substitute check) and warrants that (1) the substitute check 10 contains an accurate image of the front and back of the original check and a legend stating that it is the legal equivalent of the original check, and (2) no depositary bank, drawee, drawer, or endorser will be asked to pay a check that it already has paid. The substitute check 10 for which a bank has made these warranties is the legal equivalent of the original check for all purposes and all persons.
Conventionally, IRDs are created through a printing process which utilizes check images produced during the original paper check scanning process. This paper check scanning and imaging is accomplished using a check/reader sorter such as the IBM 3890 and the like. Disadvantageously, these conventional mechanisms require large data storage of image files and are prone to imaging problems. For example, under X9 standards a Check 21 image is required to be a Black and White (B/W) TIFF image at low resolution, approximately 200 dots per inch (dpi) TIFF image. An average A4 scan produces 30 kilobytes (KB) of data at 200 dpi and 50 KB of data at 300 dpi. Thus, as more check images are created, banks and other financial institutions require significantly more data storage.
Second, the scanned images are prone to errors, such as Optical Character Recognition (OCR) problems. For example, these recognition algorithms are not perfect and they can mistake a handwritten “7” for a “1” for example. These are called substitution errors and banks want to keep these error rates as low as possible to avoid out of balance errors. Having errors forces banks to keep human operators around to compare by hand the image and the OCR estimated amounts and correct these errors. Additionally, scanned images saved in lower resolution TIFF files provide an output image with lower quality and clarity.
Third, scanning paper checks or IRDs is slow and cumbersome; requiring additional human operators to handle paper IRDs. Even though Check 21 enabled truncation, many banks still receive paper IRDs and thus they are forced to continue paper handling operations in their Item Processing back-office departments. The per item handling costs of IRDs continues to increase as the practice of check image exchange becomes widely adopted, thus banks are looking for ways to avoid re-scanning IRDs or to avoid having to create IRDs when returning items to customers or non-image enabled banks.
Thus, there exists a need in the banking and financial industry to provide efficient mechanisms for handling Check 21 images.

BRIEF SUMMARY OF THE INVENTION

In various exemplary embodiments, the present invention provides enhanced processing of Check 21 items using an electronic payment system (EPS) to capture metadata instructions. The metadata includes instructions regarding an intended payment to a payee, and can be generated through a truncation process and optical character recognition, directly from a digitally originated check, and the like. The metadata is stored in a database or the like for further processing instead of printing a paper check. In various exemplary embodiments, the present invention provides a capability to print Image Replacement Documents (IRDs) compliant to Check 21 regulations from the metadata. Further, these IRDs can include enhanced features as described herein.
In an exemplary embodiment of the present invention, a Check 21 truncation method includes scanning a paper check, analyzing the scanned paper check to determine data associated with the scanned paper check, wherein the data includes payment instructions, bank account number, and routing number, storing the data associated with the scanned paper check as metadata in a digital payment file, wherein the metadata includes the data and a globally unique identifier, and providing an image replacement document image compliant to Check 21 based on the metadata, wherein an output from the metadata is interoperable with both paper and electronic clearing methods associated with Check 21 clearing systems.
In another exemplary embodiment of the present invention, an enhanced image replacement document method includes receiving metadata associated with a check, wherein the metadata includes payment instructions from the check, wherein the check includes one of a paper check and a digitally originated check, and wherein the paper check is truncated and the metadata is generated based on scanning the paper check, generating an image from the metadata, wherein the image includes an image replacement document of the check compliant to Check 21, wherein the image includes virtually no skew and substantially perfect quality as measured by Image Quality tests, and printing the image.
In yet another exemplary embodiment of the present invention, an image replacement document printing method includes receiving metadata associated with a check under Check 21, and printing the metadata as an image replacement document compliant to X9 specifications, wherein the printed image replacement document is generated with zero degrees of skew, and wherein the image replacement document includes substantially perfect quality as measured by Image Quality tests.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated and described herein with reference to the various drawings, in which like reference numbers denote like method steps and/or system components, respectively, and in which:

FIG. 1 is an illustration of a substitute check (or IRD);

FIG. 2 is a diagram of a Check 21 IRD system according to an exemplary embodiment of the present invention;

FIG. 3 is an image of an IRD generated from metadata according to an exemplary embodiment of the present invention;

FIG. 4 is a flowchart of a DPF operational scenario for generation and processing of DPFs according to an exemplary embodiment of the present invention; and

FIG. 5 is a block diagram of an EPS according to an exemplary embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

In various exemplary embodiments, the present invention provides systems and methods for efficient data storage of Check 21 items and for superior quality image generation of the associated Check 21 items. The present invention also provides enhanced processing of Check 21 items using an electronic payment system (EPS) to capture metadata instructions. The metadata includes instructions regarding an intended payment to a payee, and can be generated through a truncation process and optical character recognition, directly from a digitally originated check, and the like. The metadata is stored in a database or the like for further processing instead of printing a paper check. In various exemplary embodiments, the present invention provides a capability to print Image Replacement Documents (IRDs) compliant to Check 21regulations from the metadata. Further, these IRDs can include enhanced features as described herein.
Referring to FIG. 2, a Check 21 IRD system 12 is configured to create metadata files from scanned checks from a check scanner 14 and from digitally originated checks from a computer 16 or the like, according to an exemplary embodiment of the present invention. The present invention provides a digital payment file (DPF) 20 which includes metadata associated with a Check 21 IRD. Of note, this metadata does not include the physical image, and accordingly can be stored efficiently. The present invention provides systems and methods to generate an IRD image with perfect quality and other enhancements as described herein.
The check scanner 14 is a device configured to efficiently scan front and back images of physical checks. In an exemplary embodiment of the present invention, output of the check scanner 14 is converted from an image into metadata stored in the DPF 20. This provides financial institutions the opportunity to store raw data as opposed to image files when scanning either the IRDs or original paper checks. Of note, the metadata can be utilized at any time to create a perfect Check 21 IRD or to provide an Image and Cash Letter file compliant to Check 21 specifications, such as ANSI X9.180. Additionally, the computer 16 or 17 can be utilized to digitally originate a check. A digitally originated check (DOC) is a check which is created electronically and which is fully compliant to the Uniform Commercial Code (UCC) and Check 21. The present invention contemplates the usage of metadata in the DPF 20 for any valid payment format, including Automatic Clearing House (ACH), credit card, and the like transactions.
The digital payment file (DPF) 20 includes payment instructions 22, a transaction identifier 24, audit information 26, and security information 28, according to an exemplary embodiment of the present invention. The DPF 20 represents a digital payment from a payor to a payee, and can include any form of payment along the various financial payment rails, e.g., check, ACH, credit card, and the like. The DPF 20 is created and stored electronically based upon inputs from the check scanner 14, computer 16, and the like. The DPF 20 is stored in a data store 18 which can include a bank of redundant file servers, network file storage, and the like. The data store 18 can be part of a larger electronic payment system (EPS). For example, the EPS can include a data store, processor, and network interface all configured to interact with users, check scanners 14, computers 16, and the like for creation, distribution, and processing of the DPF 20.
The payment instructions 22 can include instructions for “whom to pay” (payee name, phone number, email address, or the like), some value amount (input as a decimal number of some currency), the payment issue date, the bank account number from which the payment is to be drafted (traditional checking account number and American Bankers Association (ABA) bank routing number), along with some potential set of conditions, limitations, or restrictions, along with memo field description details, and potentially some type of conditional acknowledgements which are defined to be business rules governing how and when the payment should be made (i.e., putting a contract on the back of a check, thus cashing the check is endorsing the contract).
With regards to the check scanner 14, the payment instructions 22 can be generated from an Optical Character Recognition (OCR) mechanism after a physical check is imaged. Further, the payment instructions 22 can be received from a human operator, such as when the operator physical inputs a courtesy amount from the paper check into a system. With regards to the computer 16, the payment instructions 22 can be electronically received from the computer 16, such as through the EPS.
The transaction identifier 24 is a globally unique identifier (GUID) which is a unique transaction identification used to identify a specific payment within the DPF 20. The GUID is a special type of identifier used in software applications in order to provide a reference number which is unique in the context for which it is used, for example, in defining the internal reference for a type of access point in a software application, or for creating unique keys in a database. In the present invention, the GUID is sufficiently large to avoid object collisions, i.e. duplicate numbers, and it utilizes an algorithm to ensure GUIDs cannot be easily spoofed.
The GUID or other secure transaction identifier could be used in order to negotiate or cash an IRD generated from metadata. These identifiers utilize a generation algorithm with multiple inputs, and therefore a counterfeiter requires access to these inputs as well as the algorithm to generate valid identifiers. Advantageously, this makes it difficult for external counterfeiters to reproduce them and create fake IRDs. This eliminates the “fake IRD” problem. Any Adobe Photoshop user can alter a valid IRD image or generate their own fake IRD image and make it payable to themselves if they have access to either the original IRD image or to valid account data. Thus, the existing Check 21 ideas are weak because any hackers with Photoshop can create a valid image. The metadata and IRD generation mechanisms of the present invention do not have this Check 21 weakness via this IRD security method. The GUID or transaction identifier could be used to verify an IRD before it is accepted for deposit. For example, this could include a verification service which is configured to look up the identifier to show validity.
The audit information 26 includes the history for an audit trail of the DPF 20. Since the DPF 20 is an electronic item, it can be tracked real-time. The audit information 26 can include timestamps and associated actions, such as creation, notification of payor, payor actions associated with the DPF 20, and the like. For example, the EPS can be configured to track, i.e. record and monitor, all interaction with the DPF 20.
The security information 28 includes mechanisms designed to protect the DPF 20 from fraud, counterfeiting, and tampering. The security information 28 can include Public/Private Key Infrastructure (PKI) and Certificate Authority (CA) verification, cryptography, steganography, transmission security such as Secure Socket Link (SSL) and Virtual Private Networks (VPN), secure hashes, and the like. Additionally, the security information 28 can include payee and/or payor notification and authentication requirements, such as a unique Personal Identification Number (PIN) for each DPF 20, additional levels of credentials (e.g., unique account number and login ID into the EPS), private digital security signature key (e.g., using a public key cryptography system), and the like.
The security information 28 can further include digital security features, such as digital watermarks, stenography, and cryptographic features that can be applied to the “bitmap” sent out to DPF 20 image recipients. These features apply when the DPF 20 is converted to a paper item, such as a substitute check, or an electronic representation of a paper item (e.g., an email with an image of the substitute check). These features can be used to validate that the check was not altered through the system 12. Some Digital Rights Management (DRM) features could even be “Image Survivable” meaning that they exist after an IRD printing and subsequent scanning back into an image (e.g., barcodes).
In an exemplary embodiment of the present invention, the DPF 20 represents metadata associated with a truncated check, such as from the check scanner 14, or from a DOC which is compliant to existing Check 21 paper and electronic clearing methods. These check clearing methods can include a substitute check or Image Replacement Document (IRD) compliant to ANSI X9.37 draft as well as X9.140 IRD final standard, or an Image and Cash Letter Format file compliant to X9.180 standards. The DOC is referred to as digitally originated due to the computer generation of the DPF 20 by the computer 16 to distinguish it from the traditional scanning of a paper check which could be called manual or “paper origination” of a check image.
Referring to FIG. 3, a generated enhanced IRD image 40 is illustrated according to an exemplary embodiment of the present invention. In an exemplary embodiment of the present invention, the DPF 20 of FIG. 2 can be used to generate the X9.140 standard “substitute check” or IRD which results in a paper version of the original check. Note, this paper version of the IRD is the legal equivalent of a physical check under Check 21.
In the case of a digitally originated check (DOC), the IRD image 40 can be printed by a payee and taken into their bank for deposit because it contains a full set of warranties and indemnities based on the original contract agreed to by the payor and payee which is required to be signed in order for the DOC to sent or received. Because DOCs are covered under this contract, they have a full set warranties and indemnities that are acceptable to both banks of deposit and downstream clearing banks. This DOC feature, possessing a “full warranty” state, differs from other attempts by either businesses or individual consumer users who want to print their own IRD documents and deposit them at a bank because those documents will not be accepted by the bank of first deposit (BOFD) due to the depositing bank's inability to take on un-transferable risk from an unknown originator of the IRD.
The IRD image 40 is formatted similar to a standard X9.140 IRD including a standard check front 42 with a “signature” area 44 in one of many forms; either a human digitized signature, or an e-signature compatible form, or a secure hash produced by a private key digital signature and a standard check back 46. Additionally, the image 40 includes a Magnetic Ink Character Recognition (MICR) line 48 and a legal legend 50 as required by Check 21. Further, the IRD image 40 can utilize the X9.140 “optional data” area to include processing and routing information 52 associated with the EPS, a two-dimensional barcode 54 to facilitate faster processing and security, a GUID 56, and customer service information 58. The routing information 52 can be used by itself or in conjunction with the GUID 56 to allow the EPS to track and perform other functions with the IRD image 40. Using 2D standards such as PDF417, the barcode 54 can store up to 2000 bytes of information which can be used in conjunction with a barcode reader to automatically recover all of the information associated with the IRD image 40. The GUID 56 provides the unique transaction ID associated with the IRD image 40 and the corresponding DPF 20. Finally, the information 58 can be used by banks and others to assist with issues or questions related to the IRD image 40.
The GUID 56 is a large, algorithmically generated, unique number. The mechanism uses a given a set of inputs as seed values and then generates a 16-byte (128-bit) number which is generally considered to be unique among all users at any time, everywhere on the planet. Using GUIDs 56 as either hidden or visible check numbers ensures that the EPS knows which DPF 20 has been issued, cleared, etc. and facilitates tracking the check anywhere, anytime, electronically or by IVR (phone) or human lookup. This is unlike pre-printed check numbers as they are generated on the fly at DOC creation time. The GUID 56 can also serve as an EPS Transaction ID (Tx) to find/locate a specific check within all the checks. GUIDs 56 can also be captured and stored inside the PDF417 barcode embedded on an IRD or check image for automated IRD processing.
The present invention provides IRD images 40 with superior quality and characteristics. Using a traditional scan of a paper check, a high speed reader/sorter machine takes a picture of the front and back of a check. Several errors are introduced during this mechanical paper handling process which impact further electronic processing of the image and subsequent Check 21 item. Due to inherent mechanical and optical system design defects, any mechanical paper handling process is subject to jams, miss-feeds and misalignments of the paper which result in either missing images or bad quality images (blurry) or miss-aligned images (alignment measured as degrees off or away from a horizontal axis—called skew). The impact of these scanning flaws, while rare on a percentage basis, occur so frequently in the huge volume of paper checks that the Federal Reserve system has mandated the adoption of an “Image Quality Assessment” (IQA) test before they will accept and process a set of Check 21 images from any bank. Thus the IQA tests are designed to identify and reject images which do not conform to both the Check 21 standard overall as well as the specific “readability” or “legibility” OCR tests that the banking industry has agreed are minimum image requirements. The present invention can be utilized to minimize these flaws or to limit them solely to the initial scanning with the check scanner 14.
The digital generation of the IRD image 40 from metadata creates none of the traditional paper image quality errors. Also, there is no resulting image skew from a non-existent horizontal axis based on the edge of the paper as is seen with a scanned image. The IRD image 40 is always generated with zero degrees of skew in the image because it is built from the metadata in the DPF 20, and not a stored image. Next, the IRD image 40 has perfect image quality as measured by industry standard Image Quality tests which is independent of dpi resolution due to the fact that a pure black and white bitmap is generated from metadata and not from a scanned paper item (which results in noise being introduced by the surface of the paper item). With the IRD image 40 there are no stray black noise elements, only the exact letters, numbers, fonts, and graphics which are present. The metadata instructions generate individual black bits in the bitmap. Because the IRD image 40 files have perfect image quality (pure black and white with no random image noise), and have zero degrees of skew (i.e. they are perfectly aligned to the horizontal axis of the image file), they are always readable by both humans and computers using the lowest dpi image resolution form of Check 21. Thus, this enhanced readability reduces the chances of OCR errors of the Courtesy Amount Recognition (CAR) and Legal Amount Recognition (LAR) fields if the check image is scanned by banks who still handle paper IRDs. Finally, the well known industry problem of background image “interference” (this generically is called the “puppy and kitty” problem due to the wide spread existence of these type of background images on many consumer checks) is also avoided because the IRD image 40 does not contain any background data.
Further, current Item Processing, check sorting, and encoding methods require the imaging system to validate and compare the Courtesy Amount box with the Legal Amount field and use OCR to determine the Amount to Pay. These algorithms are not perfect and they can mistake a handwritten “7” for a “1” for example. These are called substitution errors and banks want to keep these errors as low as possible to ensure that the encoded amount on the MICR line is correct and that their systems are in balance. Having OCR errors forces banks to keep human operators around to compare by hand these amounts and correct these errors. Advantageously, the IRD images 40 can be generated from digital instructions, i.e. the DOC, so if they person types a “7” they will get the image of a “7” on the digital check image.
Because the IRD image 40 is generated from metadata, it can be generated in many forms. First, the IRD image 40 can be generated in many resolution levels (measured as dots per inch or dpi) which are independent of the chosen bitmap format, such as JPEG, TIFF, PNG, and the like. Second, when the IRD image 40 is generated by the EPS, it can be generated to include optional data such as human signatures for easier processing in paper form. This optional or conditional data (on the front or back) can include instructions from the payee or depositing bank about depositing or clearing features of the specific payment. Examples of this include merging a “human digitized signature” 44 as the authorized signature directly into the back (or front) image of the check, even though it was never printed or signed (using the e-signature laws). Note that this “digitized signature” feature works if the payor or payee has uploaded samples of their human signature or other handwriting samples (ex. Agreed and Accepted), or they could choose to use a font that displays in “handwriting” format to simulate their human signature—any of these could satisfy the e-signature law as their authorized legal signature. Another example includes a “for deposit only” style stamp 60 for the back of the check, an account number for the deposit 62, or other contractual restrictions (such as agreement to a contract if the check is deposited) that are required by certain business processes or agreements. Thus, the image 40 form of the DPF 20 can contain valuable, optional data in both machine and human readable form without requiring paper processing. This further automates the processing and handling of checks and speeds up the overall business process between payor, payee, and the banking system.
The IRD images 40 are created from “instructions to pay” metadata which are similar in features to a “vector image file” vs. a “raster image file”. The benefits of using metadata (like the equations describing a vector) to generate IRD image 40 is that it provides flexibility in how the image 40 is generated. For example, under X9 standards for image exchange between banks without agreements, a Check 21 image is required to be a Black and White (B/W) TIFF image saved at a low resolution of around 200 dots per inch. Using the present invention, the EPS can generate IRD images 40 in a variety of formats such as small X9 B/W images which reduces the file size of the DPF 20 or as a high resolution JPEG images using a grayscale format for enhanced readability or clarity. Dynamically creating the “check image” gives you flexibility and choices which are suitable to the requirements of the final use or format. Thus for storage, the IRD image 40 can be made as small as possible given the amount of check data that must be displayed. This is useful for banks storing large numbers of check images. Additionally, the IRD image 40 can include low resolution image versions for creating IRDs and high resolution used for customer statement presentment or online viewing. An EPS can also produce IRD images 40 at whatever resolution (or format—TIFF, JPG, PNG, etc.) is needed by the requesting system for storage or printing. The DPF 20 record does not contain an image, only instructions to pay, thus any image type can be generated on the fly as needed. Also, the DPF 20 is very small (e.g., a few hundred bytes vs. a few hundred kilobytes for an image) which can be stored very inexpensively and converted into larger formats for different purposes. This eliminates the need for banks to use check image storing services such as ViewPointe. Instead, when needed in the future, the IRD image 40 can be pulled back into the bank to be used for customer statement processing, dispute resolution or legal evidence, etc.
Similar to “electronic endorsement” features, using metadata and other digital technologies, any bank department or receiver of the DPF 20 can automatically sign or endorse the check for processing and clearing after the check represented by the DPF 20 is deposited. This idea covers the bank stamps, time stamps and automation tracking features used to update the Check 21 item throughout its lifecycle. Using these concepts, the EPS can generate the IRD image 40 showing who signed the check, when it was deposited, how it was deposited or notify a payee that the item is a item returned under NSF rules, etc. The EPS updates the audit trail in the database of the DPF 20. The generation of multiple image forms utilizes a concept of an “image overlay” to add layers of digital stamping to the back of a check. This is not manipulation of the existing image, but instead generating each stamp in its own image layer one at a time by providing an “image overlay” layer on top of the existing back of check image 46. Note that at DPF 20 creation time, the back of image 46 is a blank image of a check back. Other unique elements of this feature are the idea of having room for “more than one” signature when multiple endorsements are needed or used, such as a third party check turned over to a store. Only the last signature is shown on the back of check image 46, others are kept on file in metadata, or a statement can be added saying “signature is on file” and produced as needed. The same idea can apply to bank processing of DOCs, their “stamps” can be digitally added and only the last one is shown if desired or if no room or if illegibility would be created by stamping over top of each other. For example, the most recent image can be kept in the display, but all other images are on file. Also useful for NSF checks to explain why the item was returned. Check 21 provides for items returned as NSF, but the present invention makes it clear to all parties what occurred and when no matter how many back and forth attempts were made to cash the check. Another benefit is the franking features are always clear and readable, thus there is no need for a “high resolution” image of the back of the check.
Existing IRDs take the Check 21 image “as is” and embed it onto paper. Thus one IRD may be printed, then rescanned and reprinted over and over for a remote clearing bank that uses a chain of correspondent banks to clear their checks. This results in the “copy of a copy of a copy” problem where both image quality and skew can be introduced at each copy iteration. But, using metadata instructions to generate a Check 21 compliant image, the present invention allows each IRD image to be an electronically generated IRD. This means there is no skewing of the image and the layout on the IRD form is correct. The present invention cannot compensate for printer alignment or paper issues which must be corrected by at the point of printing, but the image of the IRD is perfectly formatted and oriented with zero degrees of skew relative to the horizontal line of the IRD boundaries. Further, the present invention can also “re-hydrate” the IRD back into an electronic image cash letter file without scanning to eliminate the introduction of errors when IRDs are printed.
In another exemplary embodiment of the present invention, the IRD image 40 could have enhanced features not shown by the X9 standards, such as when formatted or printed as an IRD, the back of the check will be upside down above the front side of the check with instructions for folding and cutting to make a standard paper check. This orientation allows a “fold” dotted line to go between the two images, plus a “cut here” dotted line above the back of the check. The resulting cut & folded image is a perfect, one-step printed item that generates an “item processing” capable check, i.e. something that can be run through the IBM 3890 check sorting machine as is and it works just like a paper check. The back/front may be taped on the sides if needed to reduce any “gap” from having two pieces of paper back to back. Also, the IRD image 40 can tell customers how to do this or the Document Preparation Table within the Item Processing department can easily do this before sending the printed IRD image 40 into the sorting machine.
The present invention provides “add-ons” to the IRD image 40, and existing Check 21 IRD specification allows extensions (i.e., room for optional parts) for new business methods or systems. For example, the present invention can add new concepts onto the IRD image, such as instructions to call 1-800-verification for the customer or bank teller to call for self-service IRD verification, or use the barcode 54 on the check (e.g., PDF 417, or United States Postal Service—USPS) to “verify and pull” the check back into the BOFD, security hashes, or other ID verification data on the sender or receiver. Note, the 1-800-verification could be tied to a strong “brand name” to facilitate customer awareness of who the IRD issuer was so that it can not be easily spoofed with Joe's ACME IRD branded concept. Banks can subscribe to the 1-800-verification service and using phone touch tones punch in their account number and code, then the IRD GUID 56 value, which the verification system uses to validate that the bank is real and then lookup the check in the DPF using the GUID. Then, the interactive voice response (IVR) service can tell the user if the IRD image 40 is real, and optionally who the payee should be (a secondary validation feature of the 800 # service). The barcode 54 can be used to automate this process—just scan it and the user avoids the IVR touch tone data entry step. Alternatively, the bank teller could use a website to enter in the GUID 56 or Tx ID and verify the IRD.
Additionally, the IRD image 40 can include an extended the IRD layout to create space for a Notary Public stamp and a line for their signature and ID number 59, along with instructions that the depository signature is witnessed to be a valid endorsement of the IRD for payment. These optional areas on the IRD layout for the text/notification can be used such that the IRD is witnessed by a notary for the payment to be paid. For example, areas outside the IRD layout can be used for the notary stamp and signature/ID disclosure line.
Traditionally, IRDs are printed in the “portrait” mode on a printed 8.5 by 11 inch piece of paper. Optionally, the present invention could create the IRD image 40 using the “landscape” width (i.e., longwise using the 11 inch orientation) instead of the traditional 8.5 inch orientation. Using the extra “horizontal” space, the present invention could add additional Magnetic Ink Character Recognition (MICR) line fields, or barcodes 54, or transaction codes, or audit or fixed codes, etc and the like. The Item Processing department could scan the IRD lengthwise and get standard MICR line data along with the additional data on the enhanced landscape mode IRD. This adds value to allow the other IRD enhancements (barcodes 54 or long GUIDs 56) to be easily placed on the IRD versus the traditional layout.
Referring to FIG. 4, a DPF operational scenario 70 provides an exemplary embodiment of generation and processing of DPFs. The DPF metadata is generated (step 72). As described herein in FIG. 2, the metadata for the DPF can be generated through a scan of a paper check as part of a check truncation process, through generation of a digitally originated check, or through any other process. Of note, the DPF is not an image file, but rather metadata describing a payment instruction. The present invention utilizes the metadata to generate an IRD image file, when needed, or to transmit the metadata as an Image and Cash Letter File bundle, and the like when needed.
The DPF is stored (step 74). As described herein, the DPF takes up significantly less space than a raw image file since the DPF is solely data, and not an image. The storage step can be done by a bank during the check truncation process, by an individual creating a digitally originated check, or the like. The DPF is transmitted (step 76). Here, the metadata is transmitted in some form or fashion. This can include sending the metadata to a payee, sending it as a bundle to a clearing bank or clearing house, or the like. Alternatively, the transmitting step can be omitted. The idea here is that the check, whether a truncated paper check or a digitally originated check, is now in electronic form as metadata compliant to Check 21 truncation regulations.
The present invention includes a full set of warranties and indemnities applicable to banks of first deposit (BOFD) and clearing banks. These warranties and indemnities are associated with the metadata, and are agreed to by a payor and payee associated with the truncated check. The idea here is to create an agreement by which payors and payees accept before utilizing digitally originated checks. With regards to check truncation by banks and other financial institutions, these warranties and indemnities are already in place under Check 21 truncation regulations.
The IRD image or associated DPF metadata can be transmitted in any form as is known in the art. For example, it can be sent as an IRD image via an embedded JPEG or other image type in an email message. When the payee opens their email, the payee is presented with an “image” of a check in IRD form. The user prints the email and takes it into a bank for deposit. Note, the image can include an optional barcode, and it is in the form of an IRD X9.140 file. Therefore, the image is a valid IRD and the bank accepts it based upon the contract between payor, his system, and payee to extend the rights and responsibilities under Check 21 to all parties. Additionally, the check image does not need to be in IRD format to be processed electronically. This can be accomplished using a custom MIME type to handle the check image viewing within the email program as way to notify the computer than a “check” has arrived and not a random graphic picture or image, i.e. using a MIME type there is an intelligence that is conveyed or created when you generate an image that you (the originator) know to be an “item of value” (money). This concept is similar to the difference between the actual object and a picture of the object. A custom MIME type handler is used to attach the check to an email as this notifies the OS or email program that this is a special object that has value (i.e. a check). This can include a “thumbnail” image to show recipients that a valid check image is attached, such as in encrypted form. Additionally, a PIN could be required to secure the decoding of the image via a symmetric key (sent via SSL).
Also, the IRD image or associated DPF metadata can be sent as an encrypted file. The EPS system (thick client or website) can use a shared PKI infrastructure (built for example by either the EPS or by a third party Electronic Payments Clearing House or EPCH) to generate the IRD image or associated DPF metadata, then grab the payee's public key to digitally sign (or encrypt) the IRD image or associated DPF metadata into an automatically generated but encrypted file so that only the recipient/payee can open the file using their private key. The encrypted payment is transmitted to the recipient/payee as either an attachment to or directly embedded within a well known file format such as an Adobe PDF file. Note that the recipient has to previously register with EPCH to generate the PKI key pair (storing the public key online, and the private key offline) and that private key is required to be installed on any machine where the encrypted PDF image is opened. This is a simple, low cost “client side” security model that leverages the free and widely-available Adobe Reader client or other such free client software viewing program that accepts secure or encrypted files.
Next, an image is generated from the DPF (step 78). The image includes a fully-compliant IRD image as required by X9 standards. The image can be provided in various mechanisms, such as email, text message, web link (URL), secure PDF file, facsimile, and the like. At this point, the IRD image can be printed and utilized as a fully-compliant IRD. The IRD can be printed by a payee and taken into their bank for deposit because it contains a full set of warranties and indemnities based. These full set of warranties and indemnities are based on a contract agreed to by both the payor and the payee which the EPS requires to be signed in order for a digitally originated check to sent or received. Because DOCs are covered under this contract, they have a full set warranties and indemnities that are acceptable to BOFDs and downstream clearing banks. This novel digitally originated check feature, possessing a “full warranty” state, differs from other attempts by either businesses or individual consumer users who want to print their own IRD documents and deposit them at a bank because those documents will not be accepted by the BOFD due to the depositing bank's inability to take on un-transferable risk from an unknown originator of the IRD. This scenario is contemplated where an individual or business does not have an existing two-party private warranty contract with their bank which is a concept allowed for under existing UCC law. Also, under the Check 21 regulation as it exists today only banks can truncate checks by imaging them and later extend their warranties to subsequent clearing banks in either electronic or IRD form.
The DPF can be printed to create an IRD or a paper check. The digital check image and metadata are applied to the IRD layout and X9.140 specification to create a valid Check 21 item. Traditionally or by convention, an IRD was only created by scanning a paper check, this item covers the translation or transformation of the DOC metadata and image to the IRD format (different than a scanner doing it). That is, the present invention does not scan a paper item to create an IRD, but rather scans a paper item to generate metadata or inputs data from a digitally originated check to have a meta-data driven IRD.
In one exemplary embodiment, the IRD is printed from a DPF on a printer from a browser image. The metadata instructions include instructions how to generate a perfect check image and a perfect IRD layout (i.e., no skew, etc.). These get blended into a single JPG or the like image that is downloaded to a local browser client, the user sees the JPG, and selects “print” on their local computer to print the JPG, which is in the format/layout of an IRD. The paper output is a valid IRD and can clear using normal IRD process. In this scenario, the browser image can include simple security controls via JavaScript, a browser plugin or the like.
In another exemplary embodiment, payees can be locked-out from printing multiple checks through browser controls. For example, a system registers a misprinted check as “cancelled,” and the payee agrees in writing (e.g., check a box, etc.) than the misprint has been destroyed. Replacement checks (i.e. through metadata) are re-issued with completely new sets of tracking and identification numbers, codes, etc. This same agreement restates federal and state check fraud statutes. This feature may require client side code, ActiveX, or other software features. Optionally, this could include a secure printer driver injection tool to hook the print spooler. Also, these mechanisms could also utilize known security techniques to provide decryption of the DPF for security and verification.
For businesses and others with high volume IRD deposit requirements, such as lockbox services and the like, the present invention can utilize a magnetic stripe for quick data scanning of the IRDs. When enhanced IRDs enabled by the present invention are created by a remote, high volume IRD printing facility such as offered by Fiserv and the like, they could be printed onto special IRD stock that includes the magnetic stripe. The stripe could be used to encode all of the DPF metadata, including GUID, amount, date, payee, etc. Scanning the stripe eliminates the need to scan the entire IRD, thus further automating IRD processing for banks.
Additionally, printed IRDs can include additional items, such as barcodes, 1-800-verification numbers, and the like. These items can be used by the BOFD to provide greater confidence that the IRD is legitimate. Further, in the case of an electronic deposit, e.g. forwarded as metadata, bundled as an Image and Cash Letter file, the BOFD can also have greater confidence that the IRD is legitimate. The present invention contemplates electronic verification methods to verify the IRDs, i.e. utilizing the GUID or transaction identifier to determine validity over a verification system. This reduces liability by giving the BOFD enhanced confidence when receiving the IRD as opposed to conventional Check 21 items. Advantageously, the present invention allows a greater audit trail or liability chain of custody to be presented/inspected/known at all times, thus increasing check confidence.
Current Check 21 processes (i.e., paper scanning and IRD creation) can allow both the paper check (i.e., as an image) and the check as an IRD to be processed, causing double drafts for the same payment. The banks have to watch for this error and constantly trial balance their systems. Using DPFs, there is no need to track this, the present invention only authorizes DPFs one time, thus avoiding a double debit. Even if an IRD is made and the electronic DPF is deposited, the present invention only honors the first item through the system. The second will be blocked or marked returned and not paid, i.e. using a Positive Pay Database PPD enabled by the present invention helps ensure this. Existing Positive Pay systems may not capture this because both the IRD and the paper check are appear to be valid items and therefore a PPD would say “yes” to pay them. The present invention sees that the first item has processed and thus does not allow the second item (IRD or electronic) to clear—only paying one time.
In another exemplary embodiment of the present invention, the DPF can be pushed into a bank through remote deposit of a cash letter file. This is very useful for a non-image enabled bank that would normally be forced to accept an IRD and forward the paper item. Whenever a paper IRD is deposited by an account holder to the bank, the bank can choose to be “item processed” without scanning if they ask for an X9.180 image file be forwarded on their behalf from the DPF. The BOFD (depositing bank) can request that a cash letter file be generated from the IRD (e.g., via the GUID 56) and be sent to the clearing system on their behalf. For example, the EPS holds the DPF and can be directed by a depositing bank to forward to a clearing bank in electronic form via check 21 image exchange networks. The digital check image and cash letter file is transmitted to the bank for deposit and the bank can forward it on to their clearing house of choice. If the bank does not accept check 21 images, it can forward it on to the Federal Reserve on their behalf and credit the depositor's account. The remote deposit service could integrate both conventional remote deposit features (e.g., ACH or cash letter imaging) along with remote deposit of a digitally originated check. This feature is the process that takes both types and prepares a file of mixed items to be remotely deposited (i.e., paper check images and DOC images).
Advantageously, IRDs from DPFs can be “re-hydrated” from paper items back into electronic items without scanning. IRDs do not have to be used to “clear” a check, the metadata in the DPF lives in digital form all of the time. Thus the IRD can instruct the bank teller or customer to “pull” the item into the bank electronically (e.g., website, 800-checkme, barcode scanning, etc.). This saves time, money, and can eliminate the need to scan an IRD altogether. “Re-hydrating” a DPF can be done easily and makes it instantly digital again, quickly and easily, just tell the EPS where to send it and the electronic item file is sent. The forwarding and depositing of DOCs is done in an X9.180 electronic form into a depositor's bank. A DOC is first created as the first step in the check creation process. The digital check image and cash letter file is transmitted to the bank for deposit and the bank can forward it on to their clearing house of choice. If the bank does not accept Check 21 images, we can forward it on to the Fed on their behalf and credit the depositor's account or the system can convert it to ACH for deposit.
Additionally, another element of the present invention is the fact that enhanced IRDs could be utilized as traveler's checks via a UPC barcode with a fixed value amount. This allows for easy cashing of IRDs at grocery stores; when a DOC is created, the user selects “travelers check” format, and a UPC code would be added with a SKU number containing the EPS GUID+the value amount (pre-printed/fixed) embedding the SKU onto the IRD. The cashier would scan the IRD like a coupon using the UPC barcode, and the “amount” would be deducted from your check out bill. The store could cash the IRD at their bank just like a travelers check. This idea makes the enhanced IRDs as Travelers Checks useful and tradable because people can easily spend them at a grocery store or other merchant who has POS scanning equipment. The UPC barcode on the IRD makes them easily processable by the store—easy to accept like a coupon, easily verified and tracked but they clear like a check.
For payees without local printing capabilities, the present invention contemplates a remote or third party IRD creation/printing service. This feature allows a payee who receives the DOC but who does not have a printer to “print” a valid Check 21 IRD item for pickup. When a user of the present invention walks into a bank (or Western Union or other “check cashing” service, e.g.) they only need to know basic IRD data to allow the bank or service to retrieve the IRD. Because it is an enhanced IRD, it is guaranteed to be a valid IRD so it will be easily accepted (due to the fact that it has a contract covering the bank's liabilities this allows a transfer of warranties). The bank or service processes and validates the IRD as previously described by the invention allowing the remote IRD to be cashed and cleared through the system. For example, the remote service can retrieve the DPF metadata, such as through the GUID, and generate a valid IRD under X9.140. Further, the user could even walk in to a bank with only a crude JPG of the IRD—as long as the printed image has the GUID, it can be converted back into a valid IRD. A remote IRD can also be created by a remote kiosk or store using a website, a user would enter in their authentication (account ID) and tell the system the GUID and it would generates the IRD (or cash letter file) for you at the kiosk or store.
Another exemplary embodiment of the present invention demonstrates the dynamic image generation nature of IRD which can facilitate a set of enhanced “back of the check” automation features. This can be easily seen starting first at origination time, when the back of the check image contains no data (it has a blank back of check image), but subsequent processing of the DPF can generate payee metadata used to update the back of the check image. For example, the EPS can also include User Interface (UI) screens for subsequent processing by the payee. Thus, after payee acceptance of the DPF, the EPS can generate Check 21 images that have been “franked” or stamped on the back with legends such as “For Deposit Only”, “Account number 12345 at Bank XYZ”, “Agreed and Accepted” and even multiple or subsequent payee endorsements—all of which could appear separately or together in a coordinated manner on the back of check image. Another example includes the contractual restrictions (such as agreement to a contract if the check is deposited) that are required by certain business processes or agreements. Each stamped image is generated as a separate image layer from metadata stored in the DPF at the EPS which can be optionally or conditionally produced to generate the final check image format used in settlement. This is a significant improvement over the present systems where human or automated machines “stamp” over top of each other, making the final cleared image unreadable at times. The legibility and readability of the back of a check can become a major focus of attention during any dispute or litigation surrounding the payment settlement process—including who handled the check, at what time, with what endorsements or stamps. These are all areas that are easily handled by the EPS by generating a series of images representing the back of the check state at various points in time without images overlapping each other. Thus payment disputes are easily settled.
With regards to paper checks which are truncated under Check 21, using existing processes, a paper scanning bank can leverage all of the benefits of the DPF and the EPS if they use their equipment to send metadata to the EPS in lieu of check images. The banks existing IBM 3890 can be modified or extended with software to extract data from the paper originated check (POC) via OCR and then create a IRDs after the fact. This allows older banking systems to be integrated into the EPS model to leverage the full benefits of Check 21 along with unique metadata-associated features of the present invention. Creating the DPF from a scanned paper check requires OCR and validation of the data encoded on the check including: value amount, identifying payee, and using OCR of MICR line data to identify payor DDA and bank routing data. The actual image can ride along in the DPF file, but the main point of this invention is to create the “digital instructions to pay” metadata concepts from the scanned paper item and store it within the DPF. Once in the DPF format, all of the other benefits will accrue to the bank.
Advantageously, DPFs can automatically be regenerated back into digital form without scanning the IRD paper images. Unlike traditional paper check items which are scanned and then printed in IRD format, the DPF can be re-converted back into digital form at any future date by using the unique transaction identifier (GUID). The IRD check front or back image can be generated in many resolution levels (measured as dots per inch or dpi) which are independent of the chosen bitmap format, such as JPEG, TIFF, PNG, or the like. Second, when an IRD is generated by the EPS, it can be generated to include optional data such as a 2D barcode which contains the DOC metadata for easier processing when it is delivered in paper form. Third, it can include optional or conditional data (on the front or back) which can be included in the image file in order to inform and instruct the payee as well as depositing or clearing bank about optional features of the specific payment. Examples of this include merging a “human digitized signature” as the authorized signature directly into the back (or front) image of the check, even though it was never printed or signed (using the e-signature laws). Note that this “digitized signature” feature works if the payor or payee has uploaded samples of their human signature or other handwriting samples (e.g., “John Q Public”), or they could choose to use a font that displays in “handwriting” format to simulate their human signature—any of these could satisfy the e-signature law as their authorized legal signature as well as a PKI certified digital signature. Thus, the image form of a DPF file can contain valuable, optional data in both machine and human readable form without requiring paper processing. This further automates the processing and handling of checks and speeds up the overall business process between payor, payee and the banking system.
Another exemplary embodiment of the present invention demonstrates the enhanced IRD capability that is facilitated by DOCs and EPS. When IRDs are created by a remote, high volume IRD printing facility, they could be printed onto special IRD stock that includes a magnetic stripe. The stripe would be used to encode all of the DOC metadata, including GUID, amount, date, payee, etc. This automates IRD processing for banks. This idea is similar to the airline boarding passes that have stripes for automated clearing during passenger boarding process.
Referring to FIG. 5, an EPS system 80 is illustrated according to an exemplary embodiment of the present invention. As described herein, an EPS 82 is an electronic system configured to interact with a plurality of users (i.e. payors and payees), banks, and other financial institution to enable DPF generation, distribution, tracking, authentication, security, clearing, and the like. The EPS 82 is configured to communicate over a network 84 to a plurality of payors 86, payees 88, BOFDs 90, clearing banks 92, clearinghouses 94, and the like.
Generally, the EPS 82 is a computer system which can include multiple processing elements, distributed memory, network interfaces, external data storage 96, and the like. The EPS 82 is configured with processing and data storage redundancy, and is configured to communicate to the plurality of payors 86, payees 88, BOFDs 90, clearing banks 92, clearinghouses 94, and the like. The EPS 82 includes various modules, such as a User Interface (UI) 100, DPF handling 102, IRD generation 104, transmittal module 106, tracking module 108, authentication module 110, and processing module 112. The UI 100 provides a mechanism for users 86, 88, 90, 92, 94 to create and distribute DPF files. Further, the UI 100 can provide mechanisms for tracking, modification, clearing, processing, security, authentication, depositing, reissuing, and the like with regards to DPFs. Also, the EPS 82 can include mechanisms for automating these processes without the need for direct UI 100 access, such as with automated processing.
The DPF handling 102 module is configured to create, modify, update, etc. of DPF files associated with specific checks. As described herein, the DPF is a database record storing the metadata instructions related to a check. The EPS 82 is configured to store multiple DPFs in the data storage 96 or the like, and to enable the plurality of payees 84, payors 86, BOFDs 88, clearing banks 90, and clearinghouses 92 to create, transmit, receive, and process the DPFs. The DPF handling 102 module is configured to create metadata responsive to user input, through scanned check OCR, or through automated processing. Also, the DPF handling 102 module manages tracking features, audit features, and the like described further herein.
The IRD generation 104 module is configured to create IRD images with perfect quality such that they pass the stringent Federal Reserve “Image Quality Assessment” (IQA) tests (see e.g., www.frbservices.org/Retail/check21TechInfo.html “Black and White Image Standard and Quality Checks” document incorporated fully by reference herein). The IQA procedures are a series of tests that are performed on a Check 21 image file before they will accepted and processed by the Federal Reserve clearing network. The Fed IQA tests are also utilized by a variety of banks as their own internal set of Check 21 images tests, thus ensuring image file interoperability between any two banks. While the DPF can be transmitted electronically, it can also be used to generate the X9.140 standard “substitute check” or IRD which results in a paper version of the original digital check. The IRD can be printed by the payee and taken into their bank for deposit because it contains a full set of warranties and indemnities based. These full set of warranties and indemnities are based on a contract agreed to by both the payor and the payee which the EPS 82 required to be signed in order for the DPF to sent or received. Because DPFs are covered under this contract, they have a full set warranties and indemnities that are acceptable to BOFDs 90 and downstream clearing banks. This novel DPF feature, possessing a “full warranty” state, differs from other attempts by either businesses or individual consumer users who want to print their own IRD documents and deposit them at a bank because those documents will not be accepted by the BOFD 90 due to the depositing bank's inability to take on un-transferable risk from an unknown originator of the IRD. This scenario is contemplated where an individual or business does not have an existing two-party private warranty contract with their bank which is a concept allowed for under existing UCC law. Also, under the Check 21 regulation as it exists today only banks can truncate checks by imaging them and later extend their warranties to subsequent clearing banks in either electronic or IRD form.
The transmittal module 106 is configured to handle transmission of DPFs between the various payors 86, payees 88, BOFDs 90, clearing banks 92, and clearinghouses 94. As described herein, each DPF includes a GUID as a unique transaction ID. With the present invention, a bank teller could input into the EPS 66 through the UI 100 (e.g., a webpage or phone IVR system) the digits from the unique transaction identifier (GUID) which can be found on the IRD. This GUID input system is linked to the EPS 82 that originally generated the DPF, and which allowed the payee to print the IRD in the first place. The GUID value can be printed and found on the front of the IRD in the Check 21 “optional data field” location where it was placed during the IRD generation process.
Using the transmittal module 106, the teller at the BOFD 90 can request that the specific Check 21 item be re-generated as an electronic image file and be sent back into the BOFD 90 for further processing by the “Item Processing” department. To accomplish this regeneration, the EPS 82 can use the teller supplied GUID value to lookup and retrieve the specific metadata information that was stored in the DPF system. As these re-creation requests arrive at the DPF, the original metadata values (or the currently stored values) are retrieved from the EPS 82 and used to re-create the digital check file in X9.37 format for further image exchange processing. This electronic X9.37 file can then be sent or routed directly back to the BOFD 90 via a secure electronic link such as the existing Federal Reserve System using the standard Cash Letter File format. The ability to re-generate at will (or at any future time) a fully compatible Check 21 digital image without scanning or handling a paper IRD is a further unique element of the present invention. The benefits of this feature are derived from the fact that the auto “regeneration” process avoids the errors of paper scanning and is a great benefit to banks in reducing the amount of labor involved in handling of paper items. Thus, there is no need to scan an IRD submitted for deposit in order to generate the front and back check image in standard Check 21 format. The regenerated image and data values can be generated directly from the EPS 82 and sent back to the BOFD 90 in a standard Cash Letter File for further image exchange processing.
The tracking module 108 is configured to provide real-time and historical tracking of each DPF created and processed through the EPS 82. The present invention allows the DPF to be generated through the EPS 82 anytime with a full history and audit trail. This is because the DPF is electronic and all interaction with the EPS 82 can be recorded, monitored, and tracked through the tracking module 108. Additionally, the DPF can still be processed locally on paper as an IRD, or it can be recreated and sent into a bank electronically at will. All of these concepts are based on the idea that the DOC is built around the metadata “instructions to pay” stored in the DPF, and the tracking module 108 can track the various steps by recording data in the DPF. The tracking module 108 provides similar information as a shipment tracking feature, such as with UPS. The DOC issuer can view real-time status related to the DOC to determine when it is received (which can also tie to an auto-notification feature), when it was cashed, if and when it is endorsed to a third party, and the like. Additionally, significant events related to the DOC can be pre-subscribed to auto notify when they occur. For example, the payor can be auto-notified when the DOC is cashed.
The authentication module 110 is configured to provide security relative to creation and processing of the DPFs. For example, the EPS 82 uses the GUID to lookup the DPF transaction and determines how to authenticate the payee based on the authentication level chosen by the payor when creating the DPF (or setup by the payee as a condition for retrieving payments from the EPS 82 under a specific name or ID). Authentication levels can include nothing (i.e., just knowing the transaction ID or GUID is enough security for the payor), having a unique PIN number for each DOC, having additional levels of credentials (e.g., unique account number and login ID into the EPS 66), private digital security signature key (e.g., using a public key cryptography system), or other levels of security agreed to by one or both parties and supported by the EPS 82.
The processing module 112 is configured to allow payees 86, payors 88, BOFDs 90, clearing banks 92, and clearinghouses 94 to process and clear DOCs through the EPS 82. As described herein, DPFs are identified through the GUID or the like. Once identified, the processing module 112 enables forwarding or clearing of the DPF. For example, the processing module can generate the electronic image file and send it to the bank of first deposit for further processing by the “Item Processing” department. As these re-creation requests arrive at the processing module 112, the original metadata values (or the currently stored values) are retrieved from the system and used to re-create the digital check file in X9.37 format for further image exchange processing. This electronic X9.37 file can then be sent or routed directly back to the bank of first deposit via a secure electronic link such as the existing Federal Reserve System using the standard Cash Letter File format. The regenerated image and data values can be generated directly from the EPS 82 and sent back to the bank of first deposit in a standard Cash Letter File for further image exchange processing. Thus, this further demonstrates that any items produced by the invention are built using a fully Check 21 compliant process from electronic metadata (instructions to pay) stored in a database (DPF) instead of scanning paper or existing check image data.
Although the present invention has been illustrated and described herein with reference to preferred embodiments and specific examples thereof, it will be readily apparent to those of ordinary skill in the art that other embodiments and examples may perform similar functions and/or achieve like results. All such equivalent embodiments and examples are within the spirit and scope of the present invention and are intended to be covered by the following claims.

Claims

1. A Check 21 truncation method, comprising:

scanning a paper check;

analyzing the scanned paper check to determine data associated with the scanned paper check, wherein the data comprises payment instructions, bank account number, and routing number;

storing the data associated with the scanned paper check as metadata in a digital payment file, wherein the metadata comprises the data and a globally unique identifier; and

providing an image replacement document image compliant to Check 21 based on the metadata;

wherein an output from the metadata is interoperable with both paper and electronic clearing methods associated with Check 21 clearing systems.

2. The Check 21 truncation method of claim 1, wherein the storing step comprises storing the metadata in the digital payment in lieu of storing an image associated with the scanned paper check.

3. The Check 21 truncation method of claim 1, further comprising the step of providing the metadata as an Image and Cash Letter file to a bank.

4. The Check 21 truncation method of claim 1, wherein the image replacement document is generated with zero degrees of skew, and wherein the image replacement document comprises substantially perfect quality as measured by Image Quality tests.

5. The Check 21 truncation method of claim 1, wherein the image replacement document comprises the globally unique identifier, wherein the globally unique identifier is utilized for verification of the image replacement document.

6. The Check 21 truncation method of claim 1, wherein the image replacement document comprises a bar code comprising the metadata.

7. The Check 21 truncation method of claim 1, further comprising the steps of:

receiving the image replacement document; and

utilizing the globally unique identifier to electronically receive the metadata associated with the image replacement document, wherein the metadata is received as an image cash letter file without scanning the image replacement document.

8. An enhanced image replacement document method, comprising:

receiving metadata associated with a check, wherein the metadata comprises payment instructions from the check, wherein the check comprises one of a paper check and a digitally originated check, and wherein the paper check is truncated and the metadata is generated based on scanning the paper check;

generating an image from the metadata, wherein the image comprises an image replacement document of the check compliant to Check 21, wherein the image comprises virtually no skew and substantially perfect quality as measured by Image Quality tests; and

printing the image.

9. The enhanced image replacement document method of claim 8, wherein the printing step is performed at a computer attached to a printer, wherein the computer comprises a browser configured to receive the image and print the image, and wherein the browser comprises security controls.

10. The enhanced image replacement document method of claim 8, wherein the printing step comprises printing the image on paper comprising a magnetic strip, and wherein the magnetic strip comprises the metadata associated with the check.

11. The enhanced image replacement document method of claim 8, wherein the printed image is compliant to ANSI X9 specifications.

12. The enhanced image replacement document method of claim 8, wherein the printing step comprises printing a back image of the check folded behind a front image of the check to provide a paper check capable of paper processing.

13. The enhanced image replacement document method of claim 8, wherein the image comprises a space for a notary field.

14. The enhanced image replacement document method of claim 8, further comprising generating a barcode in the image, wherein the barcode comprises the metadata.

15. An image replacement document printing method, comprising:

receiving metadata associated with a check under Check 21; and

printing the metadata as an image replacement document compliant to X9 specifications, wherein the printed image replacement document is generated with zero degrees of skew, and wherein the image replacement document comprises substantially perfect quality as measured by Image Quality tests.