Solving production problems with ICL files
Image Cash Letter files (ICLs), aka X9.37 files, are becoming bigger and “badder.” As financial institutions continue to ramp up production volume, the issues that were troublesome but relatively rare are now making an impact with multiple daily issues that can overwhelm operations, quality assurance, and customer service personnel at financial institutions. All My Papers provides software development kits and applications to address these issues.
A production X9.37 file can routinely contain 30,000 check images or more, instead of the early production of a few hundred to a few thousand items, and can be well over a gigabyte in file size, instead of a few hundred megabytes. This change is an order of magnitude bigger and one “bad” item can stop the reception, transmission, or processing of a multi-million dollar Image Cash Letter. Since these types of electronic files are transferred near the end of the business day, a non-valid file can produce a significant impact on a financial institution’s cash flow.
Corporate Remote Deposit Capture services are expanding rapidly and many people are using a “modified” X9.37 file format to send check images and their associated data. Systems for Remote Deposit Capture are creating custom variations on the X9.37 file format, even using versions of X9.37 prior to the officially released DSTU X9.37-2003.
As mentioned in Working with X9.37 File Variations, ICLs are used for a variety of reasons. Some of the uses for an X9.37 file are:
- Participate in the services offered by the Federal Reserve Board (FRB) for Check 21
- Send check images and data information from Remote Deposit sites and kiosks
- Create a file to produce a valid Image Replacement Document (IRD) or substitute check
- Send intra-bank information from regional or international locations
- Send information to exchange services such as Viewpointe or SVPCO
- Send check images and data to another bank or financial institution
- Use within financial software. Some software companies have their own proprietary versions of ICLs to use within their applications.
The specific requirements for each of these uses are slightly different, and slightly in computer file formats can mean that a file cannot be read by a particular type of software. If the software cannot read the file, the processing stops and so does the cash transfer.
Things That Can Go Wrong With Images in an X9.37 File
Image Cash Letters contain images of checks and other items. The properties and attributes of the image can seriously impact the capability of the software application to “read” the file. Some of the things that can cause a file to crash a software system, to not open, or to not be accepted are:
- No check image (the DSTU X9.37 – 2003 standard does not require an image)
- Compression is not Group 4
- Wrong type of TIFF (Tagged Image File Format) image (there are over 50 types)
- Multiple Stripe TIFF images instead of single stripe images
- Resolution other than the 200-240 dpi generally expected
- Resolution misinformation can affect image dimension attributes
- Byte Order [a sequence of bytes is stored in a computer’s memory. In a big-endian system, the most significant value in the sequence is stored at the lowest storage address (i.e., first). In a little-endian system, the least significant value in the sequence is stored first.]
- Not a black and white image (grayscale or color)
- Tag information is wrong or missing
- Compressed image file does not meet requirements (either too small or too big)
- Image orientation is wrong
- Wrong image (front and back check images reversed)
- Not a check image (deposit slip, batch header, IRD, etc.)
- Fill order not one - How the bits in a byte are filled
- Sub file not one - Single TIFF image per TIFF file
This is just a partial list of things that can go wrong. Any one of them can stop the process. All My Papers software will detect these problems before they can crash your system.
Print Ready vs. Exchange Ready vs. NOT Ready
The X9.37-2003 DSTU will accommodate many different image types and even records. In all cases the file must conform to the X9.37 DSTU or it is simply NOT Ready.
One goal for an ICL could be Exchange Ready. If it is Exchange Ready it should have universal acceptance between the different exchange organizations such as SVPCO, Viewpointe or Endpoint. A critical part of this goal is the content of the image data. Different institutions will accept different image content. However, all institutions will accept a binary compressed TIFF image with the proper Tags, bit ordering, compression type, and the proper values for myriad other settings. An Exchange Ready X9.37 file means that the file is well formed and the image contents will be accepted by all institutions. W A R N I N G: Each institution will publish a companion document to the X9.37 DSTU. This document will often place additional restrictions on the semantic data, such as mandatory field values in the file outside of the scope of the syntactic data, e.g., blank fill or zero fill.
An IRD must have front and back images to be valid. The X9.37 DSTU does not require an image with each item. So, first and foremost, a Print Ready X9.37 must have images, front and back in the proper order, for all check items.
There may be other non-check items in the file that can be printed. For example, if a credit item is included, it does not provide a legal IRD and can be printed with or without an image. A file acceptable for exchange may not be acceptable to the IRD print software. The X9.37 file suitable for IRD printing can have compressed image formats that will not be accepted for exchange. As long as the IRD print software can print the image type, it is acceptable. A Print Ready X9.37 means that the file is well formed and will generate valid IRDs for the appropriate items in an IRD Print application. Our software identifies valid IRDs.
Migration to X9.100-180 and Record 61 Support
X9.37-2003 DSTU is just what the initials indicate, a Draft Standard for Trial Use. It is used and will be used for a long time to come. However, there are institutions who want to move to the new actual standard, X9.100-180, as soon as possible, because the new standard supports credits and deposits. See our solutions page A New Standard Is Here for more details about this. This means that many organizations will need to support two different standards at the same time: the DSTU and the new 180.
One needs a tool to convert X9.37 files to X9.100-180 files. Our tool is able to convert all the different Record 61 formats that arise to accommodate the widest range of X9.37 files. This same conversion tool can provide a broad array of X9.100-180 test files since all existing X9.37 files can become test files for the new standard.
Including deposit tickets in ICLs can result in miscounts of items and wrong totals. Since X9.37-DSTU does not officially support deposit tickets, nor does the Federal Reserve Board guideline, if deposit tickets are included in the file then the dollar amount could double in the control records. When printing an IRD you do not want to produce an IRD with a deposit slip image, especially with the legend “this is a negotiable instrument…”. A way to deal with non-standard items in ICLs is required to process the information. We prevent deposit slips from being included in your ICLs.
Types of Checks
There are various types of checks included in ICLs, especially those files used in Remote Deposit Capture environments. Those types generally fall into these categories:
- Commercial business checks
- Retail/Personal checks
- Traveler’s checks
- Postal Money Orders
- And the ubiquitous “Other”
Some of these check types generate notoriously bad images that make data extraction very difficult and unreliable. Our automatic image repair can increase the read rate of your MICR OCR and CAR/LAR software.
Verifying the MICR Code
Depending on how the information was originally extracted from the check image there can be mistakes in the MICR code data: wrong account number, wrong routing number, wrong or missing symbols, etc. Sometimes the front and back of the check images can get mixed up.
Using our software to automatically verify the MICR line data from the check image and to compare it with the record information in the ICL should be an important part of every financial institution's quality assurance program. As reported in presentations at Limiting Your Liability... and other organizations, the wrong MICR data on an IRD can produce an invalid IRD that makes the printer liable for the full amount.
Duplicate Item and File Detection
Duplicate items can be a real problem when you are dealing with electronic files. Some things that can happen are:
- Remote deposit items are electronically sent and then the physical paper checks are sent for deposit as well
- The ICL files can get sent twice
- The IRD printer jams and the IRDs are printed twice
- There is a glitch in the transmission software and the file gets sent twice and duplicated
- The same check item is include in multiple bundles or ICLs
Checking file names is one method to look for duplicates, but verifying that the content is the same, even with different file names, is a better approach to minimize duplicate file issues. Our method of assigning a digital “fingerprint” to the file and tracking that “fingerprint” is a better approach. Each image file will also be “fingerprinted” so that duplicate items do not get presented. Another method of duplicate detection we use is checking the MICR data to see if the same routing number, account number, check number, and amount is presented more than once.
Universal Conversion Tools
All My Papers software is used by many software companies, financial institutions, and Remote Deposit Capture vendors. Our goal is to create tools that will allow you to work, cope, and deal with the myriad of variations for Image Cash Letters, X9.37 files.
All My Papers software will:
- Create Forward X9.37 files
- Create Return X9.37 files
- View and analyze X9.37 files
- Edit and delete items within X9.37 files at the bundle, item, or field value level
- Print valid IRDs from X9.37 files on standard laser duplex printers
- Validate conformance to the FRB guidelines for an X9.37 file
- Convert from one Record 61 format to another
- Convert to/from EBCDIC/ASCII Intel/Motorola
- Convert image data to generally acceptable form
- Convert X9.37 files to X9.100-180 files including Record 61 conversion
Contact All My Papers
Contact All My Papers to automate check Image Cash Letter (ICL) file processing.