Skip to content

Check (ICL)

ICL, Image Cash Letter, is the file format defined under Check 21 (the Check Clearing for the 21st Century Act, 2003) for transmitting check images electronically through the Federal Reserve. It's the rail behind mobile check deposit, lockbox processing, and any programmatic check capture flow.

GIB exposes ICL submission for integrators who capture check images (typically via a third-party RDC vendor) and need to deposit them through the Federal Reserve. Submission is per-cash-letter, can carry many checks, and follows the X9.100-187 file specification.

When to use it

  • Programmatic check deposit (mobile, lockbox, branch capture)
  • Returning a deposited check from your platform's perspective
  • Adjusting or recleaning a deposited check

If you don't accept paper checks, you don't need this. Most fintech platforms that accept checks integrate a third-party RDC vendor (Mitek, Ensenta, Alogent, etc.) and send the resulting ICL to GIB.

If you're a licensed MSB cashing checks, you also record the parties to each event; see Check cashing (MSB transactions).

Operations

Operation Description API reference
Parse ICL file Validate an X9 or JSON file without creating Transactions; use before submitting publicTransactionParseICL
Create ICL transactions (file) Submit an X9.100-187 or JSON file to create Transactions synchronously transactionCreateICL
Create ICL transactions (bulk) Submit a file of more than about 100 checks asynchronously; returns immediately, processes in background transactionCreateICLBulk
List transactions Retrieve and filter ICL Transactions, including returns getTransactions
Get transaction history Retrieve audit history for a Transaction getTransactionHistory
Get transaction files Retrieve raw ICL file(s) associated with a Transaction getTransactionFiles
Originate a return Return a deposited check createTransactionReturn

To filter for return Transactions specifically, query getTransactions with transfer_type=return.

File format

ICL files conform to X9.100-187 (sometimes referenced by the older X9.37 name). Key record types:

  • Cash Letter Header (Type 10): origination bank, processor, settlement date
  • Bundle Header (Type 20): group of checks within the cash letter
  • Check Detail (Type 25): MICR data, amount, check number
  • Check Image View (Type 50/52): front and back images, encoded
  • Check Detail Addendum: optional metadata, endorsement information

You can submit either the binary X9.100-187 file or its JSON-equivalent representation; GIB's spec is at API reference → ICL.

Deposit tickets

Every forward (deposit) file must be balanced. Each check in a bundle is a debit, a request for the bank it is drawn on to pay. A balanced bundle also carries the matching credit: a deposit ticket, the electronic version of a paper deposit slip, which tells GIB's core which account receives the funds. The ticket comes first and equals the sum of the checks that follow it. A file of checks with no ticket is unbalanced. GIB requires the ticket.

For a worked example with code, see Build a Balanced ICL Deposit File.

A deposit ticket is an ordinary Check Detail (Type 25) record, not a separate credit record type:

  • Position. It is the first Type 25 record in the bundle.
  • One account per ticket. A ticket credits one account at GIB. It can cover any number of checks deposited to that account.
  • Amount. A positive amount equal to the sum of the checks it covers.
  • Counts and totals. The ticket is an item. Include it in the bundle, cash letter, and file item counts and total amounts (Types 70, 90, and 99).
  • Routing number. The payor bank routing number is the GIB routing number for your program. GIB gives it to you at onboarding.
  • On-Us. The receiving account number and your program's deposit tran code, separated by a slash: <account number>/<tran code>. GIB gives you the tran code at onboarding.
  • Addendum. A Type 26 addendum whose BOFD account number is the receiving account. This is how the API recognizes the record as a ticket and does not record it as a check. Giving the ticket an ECE institution item sequence number of 0 also works.
  • Images. A front image is required. A rear image is optional.
  • MICR. Not required.

Two checks deposited to one account produce a bundle of three items:

Item Type 25 record Payor bank routing number On-Us Amount
1 Deposit ticket <GIB routing number> <account>/<tran code> $300.00
2 Check 1 from the check's MICR from the check's MICR $100.00
3 Check 2 from the check's MICR from the check's MICR $200.00
Bundle total 3 items, $600.00

The bundle total amount includes the ticket, so it is twice the value of the checks. To deposit to a second account in the same file, start a new bundle with its own deposit ticket. GIB can provide a parsed sample file showing a complete deposit ticket record.

How a balanced file posts

The ticket and the checks go different places:

  • The ticket posts to your account. GIB's core credits the account in the ticket's On-Us field with the ticket amount, as one deposit. Your account statement shows one deposit per ticket, not one line per check.
  • The checks clear through the Federal Reserve. GIB removes the ticket before sending the checks on for collection.
  • The API records each check. Each check becomes its own Transaction. The ticket does not. When the bundle's deposit posts, GIB matches it to the bundle's checks together.

So a bundle of 40 checks appears as 40 Transactions in the API and one deposit on the account. Reconcile at the bundle level.

Image quality requirements

The Federal Reserve enforces strict Image Quality Assurance (IQA). Cash letters with failing images are rejected at the file level, no checks within the cash letter are deposited. Your image-capture vendor must deliver:

  • 200 DPI minimum, 300 DPI recommended
  • Bitonal (1-bit) or 8-bit grayscale; color permitted but not required
  • Clear MICR readability
  • Both front and back faces, with the back showing GIB's endorsement
  • No skew, rotation, or fading

Endorsements

Each deposited check must carry GIB's endorsement on the back image, including:

  • "For deposit only"
  • GIB's routing number (091208154)
  • The depositor's account number at GIB
  • The capture date

Most third-party RDC vendors apply this automatically when configured for GIB. If you're capturing in-house, your code applies the endorsement before submission.

Lifecycle

ICL follows the standard Transaction state machine.

Timing & cutoffs

For ICL submission cutoffs and Federal Reserve processing windows, see the central Timing & cutoffs.

Funds availability (Reg CC)

Per Regulation CC, deposited check funds are subject to availability holds. GIB applies the bank's standard Reg CC schedule. The available balance reported by the API reflects holds, see Balances. Surface Reg CC holds in your end-user-facing UI; don't promise instant access to deposited funds.

Returns

Deposited checks can be returned by the paying bank (NSF, account closed, stop payment, fraud, IQA dispute). ICL returns use a code set distinct from ACH returns, see the full list at API reference → ICL Return Codes.

For ICL return windows and consumer-return timing, see the central Timing & cutoffs.

GIB links a return to the original check by the check's ECE institution item sequence number, so each one must be unique. If your capture system cannot guarantee that, send the header X-Generate-Trace-Reference: 1 when you create the Transactions. GIB replaces the sequence numbers with unique values and lists them in the X-Generated-Transaction-Trace-References response header.

Adjustments and reclears

If a check returns for a non-fraud reason and you want to attempt collection again, submit a new ICL Transaction referencing the original via trace_reference_original. For amount adjustments, submit a new Transaction.