Check image analysis is software that reads the image of a check, extracts what is written on it and looks for signs that it was altered, forged or counterfeited. The Federal Reserve's check fraud toolkit presents it as a way to stop fraud before money leaves: at the teller window, in mobile deposit or as the check clears. A claims team uses the same technology after the loss, for a different question: was this paid check altered, counterfeit, forged at the signature or at the indorsement? That answer decides whether the loss stays with the paying bank or can be recovered from the bank that took the deposit, so an error is not a wrong hold but a wrong payer. The only honest way to know whether an image analysis tool gets that answer right on your checks is to replay last year's closed claims, whose outcome you already know, and count every case where its type would have changed who paid. Botminds' Check Fraud Claims uses image analysis this way, inside a comparison agent that reads the paid image against what the customer issued, and the replay is how a bank tests it before a live claim depends on it.
Where the solution's own screens appear, they show sample data on fictional banks and customers. The replay scorecard below is illustrative arithmetic to show its shape, not a result from any bank or from the product.
Check image analysis in five steps, and what each means for a claim after the loss
| Step | What the Federal Reserve’s toolkit says it does | What the step has to do for a fraud claim |
|---|---|---|
| 1. Image capture | Scans the front and back to create a digital image, from scanners or mobile cameras | Work from the image the bank paid, and from the depositary bank’s image if it differs; mobile captures vary in quality |
| 2. Data extraction | Reads account and routing numbers, check number, date, payee and amount | Extract the same fields from the customer’s duplicate copy, register, bill or issue file, so the two can be compared field by field |
| 3. Validation | Checks the data against known standards and databases | Check the stock, serial range and MICR line against the customer’s own check order |
| 4. Fraud detection | Looks for mismatched fonts, signature irregularities and other anomalies | Score every type, altered, counterfeit, forged signature, forged indorsement, not just “suspicious or not” |
| 5. Decisioning and retention | Pays, returns, holds or flags the item, and stores the image and data | Pass the type, with each finding and its source, to a person who approves it; keep it for the rebuttal and the examiner |
What is check image analysis?
It is the use of software to read and test the picture of a check rather than the paper. The Federal Reserve's check fraud toolkit breaks it into five steps, from capture through extraction and validation to fraud detection and a decision, and describes the detection step plainly: "This can include detecting inconsistencies in fonts, signatures and ink patterns." Optical and intelligent character recognition turn the handwriting into data; machine learning compares that data and the image itself with known good and known bad items.
Banks are asking for more of it. In the Federal Reserve Financial Services 2026 survey of risk officers, the list of solutions respondents identified for check fraud losses began with "AI image analysis to detect alterations and anomalies", followed by positive pay, manual reviews with staff training, and monitoring of new accounts. Nearly all of that demand is about stopping the next check. The AI check fraud detection guide covers image analysis as a deposit-side control; this guide is about the check that has already been paid.
Detection and claims ask image analysis different questions
The same engine can serve both desks, but it has to be tested against the question each desk asks. At deposit, the tool compares a check with the depositor's history and the payor's earlier items to decide whether to hold it. After the loss, the claims desk already knows the check was fraudulent; it needs the type, with evidence that will stand up when the depositary bank disagrees.
One technology, two questions: check image analysis at deposit and after the loss
At deposit or in clearing: Is this item likely to be fraudulent? Hold, return or pay.
After the loss, on a claim: Which kind of fraud was it? That decides which bank bears the loss.
At deposit or in clearing: The depositor’s pattern, the payor’s earlier checks, known bad items.
After the loss, on a claim: What the customer issued: duplicate copy, register, bill, issue file, check order, earlier signatures.
At deposit or in clearing: A wrong hold on a good customer, or a fraud released.
After the loss, on a claim: A claim sent on a forgery, or an altered check written off that the other bank owed.
At deposit or in clearing: Seconds to a day, inside the funds-availability rules.
After the loss, on a claim: Days, inside the 30-day warranty notice period.
At deposit or in clearing: A score and a reason a hold notice can state.
After the loss, on a claim: A type, the rejected types and each finding with its source, for the claim and the rebuttal.
Why replay closed claims, rather than run a demo?
Because a closed claim has an answer key. Every claim the bank closed last year ended in one of a few ways: recovered in full from the depositary bank, recovered after a rebuttal, recovered in part, written off as a forgery or counterfeit, or charged back to the customer for a late report. Feed the tool the evidence the specialist had on day one, without the outcome, and compare its type with the type the claim was closed on. A demo on a vendor's chosen checks shows that the tool can read a check. A replay shows what it would have done to your money.
The comparison that matters is narrower than overall agreement. A tool that calls an altered check "altered: payee" instead of "altered: payee and amount" has not changed anything. A tool that calls it a counterfeit has moved the loss from the depositary bank to your bank. So the replay counts disagreements in two groups: those that would have changed who paid, and those that would not. Only the first group carries money, and every case in it deserves a person's reading.
An illustrative replay of 400 closed claims: the disagreements that move money are the ones to read
What data do you need to test check image analysis?
Twelve months of closed claims, with the evidence the specialist had and the outcome the bank reached. The evidence matters more than the volume: a replay that feeds the tool only the paid image tests detection, not claims typing, because the claims question is always a comparison with what the customer issued.
What to pull for each closed claim before a replay
- The paid image, front and back
As the bank received it from the image exchange, with the depositary bank’s indorsement and stamp on the back.
- The issued record
The customer’s duplicate copy or register, the bill or invoice, the positive pay issue file for business accounts.
- Six or more earlier paid checks
For the signature and handwriting comparison, from the same account and the same months.
- The check order
Stock, vendor and serial range, which is what separates an altered check from a counterfeit.
- The type the claim closed on, kept apart
And whether a person changed it along the way, with the reason.
- The outcome and the money
Paid, paid after rebuttal, part paid, denied, written off or charged back, with amounts and dates.
- The depositary bank’s reply
Especially “counterfeit, not altered” denials the bank accepted, which are where a replay can find money.
Hold the outcome back from the tool, and from anyone who sets it up. A replay in which the final letter or the write-off memo is in the evidence measures the tool's ability to read the answer, not to reach it.
How accurate is check image analysis?
Only your own replay can say, and a single accuracy percentage is the wrong way to say it. Accuracy depends on the bank's check mix, the quality of its images, how much issued data it holds and how its specialists typed claims in the past. A tool that does well on business checks with payee positive pay files can do worse on consumer checks with nothing to compare against but a carbon copy. Report the replay in the four groups shown above, by check type and by account type, and read every payer-changing case.
Read the claims the tool would not type too. A tool that types everything has no floor; one that asks too often saves nobody time. The comparison agent in Check Fraud Claims works to a floor of 0.85 and lists its readings below it, and the replay is the evidence for where the bank sets that floor: high enough that payer-changing errors are rare, low enough that specialists start most claims from a decided type.
Can AI tell an altered check from a counterfeit?
From the image alone, not reliably; from the image beside the customer's issued record, usually. An image-only model looks for traces of change: lifted lines, mismatched fonts, uneven ink. Those traces are getting harder to see. The Federal Reserve's toolkit warns that "Generative AI can manipulate images of stolen checks, reducing typical signs of check washing", and that criminals use it to build convincing counterfeits from real images. A washed and digitally retouched check deposited by phone may show no trace at all.
What generative AI cannot change is the customer's own record. If the paid check is on her stock, from her order, with a serial in sequence and her signature, it is her check, and the payee or amount that differs from her copy was changed. That comparison is what lets a claims tool type a check when the image itself looks clean, and it is the evidence a rebuttal needs when a depositary bank calls the item a counterfeit.
In Check Fraud Claims, the back of the check names the bank that owes the warranty

Where a replay will mislead you, and how to read it anyway
A replay's answer key was written by people, and some of it is wrong. Specialists working by eye accept denials, type checks under time pressure and write off claims that a closer look would have recovered. When the tool disagrees with a closed claim and the tool is right, the disagreement is money the bank left behind. Read each payer-changing case with a second specialist and record which side was right; the cases where the closed claim was wrong are often the strongest argument in the business case.
Three other effects bend the numbers. Closed claims include only fraud that customers reported, so the replay says nothing about checks nobody noticed. Claims typed from an original paper check, because the thief deposited it at a branch, are easier than image-only claims and should be counted separately. And claims written off without a full review carry a weak label; keep them, but mark them, so a disagreement there is read as a question rather than an error.
Does check image analysis need model validation?
The 2026 interagency model risk guidance does not cover it directly if the tool is generative or agentic, and it is aimed at large banks. The OCC's bulletin 2026-13, issued with the Federal Reserve's SR 26-2, leaves generative and agentic AI out of scope because the technology is new and moving fast, and it expects the guidance to matter most to banks above $30 billion in assets. What that leaves a bank to decide for itself is examined in whether a customer risk rating model is a model.
Outside the guidance is not outside scrutiny. A tool whose output moves losses between banks, and whose types end up quoted in claims and rebuttals, is one an examiner and an internal auditor will ask about. A replay on closed claims, with the disagreements read and recorded, is the evidence they will want, whatever the bank calls it. In Check Fraud Claims every agent step is kept on a read-only trail with the agent's version, so a replay of last year and a review of this year are read the same way.
The Check Fraud Claims audit trail: every agent step, with its version

What to ask a check image analysis vendor for claims work
Ask questions a replay can answer, not questions a slide can. A vendor that cannot run on your closed claims before you sign is asking you to take its accuracy on trust, and the first claim it gets wrong will be one another bank argues about.
Before you buy check image analysis for fraud claims
- Will you replay our closed claims, blind, before we sign?
Twelve months, with the outcome held back, reported in the four groups and by check type.
- Does it compare the image with what the customer issued?
Duplicate copy, register, bill, issue file, check order. Image-only scoring is detection, not claims typing.
- Does it score every type, and show the rejected ones?
A rebuttal to “counterfeit, not altered” needs the reason the counterfeit type was rejected.
- Does it pin each finding to the image, with its source?
A number with no findings cannot be quoted in a claim or defended to an examiner.
- Can we set the floor, and does it ask below it?
The floor is a bank decision, versioned and approved, not a vendor default.
- Can anyone change a type without a second person?
A changed type moves money between banks; it should need a reason code and a checker.
- Does it work on the images we actually have?
Exchange images, mobile captures, substitute checks and the depositary bank’s image when it is sent.
Be equally clear about what the claims use is not. It does not replace the detection that should stop the next washed check at deposit, it does not replace the image archive, and it does not decide whether a customer was careless: that is a judgment the liability rules leave to people. Check Fraud Claims fits where a bank has a claims queue, an image archive and some issued data to compare against; a bank whose customers keep no copies and use no positive pay will see less from it, and the replay will show that before anything is bought. Once a type is decided, who is liable for altered checks follows from it, and the packet that carries it is in the breach of warranty claim form. To have it replay your own past claims, start from Check Fraud Claims.
Questions people ask
Is check image analysis the same as positive pay?
No. Positive pay matches each presented check against the issue file a business customer sends, by check number, amount and often payee, and sends mismatches back to the customer as exceptions. Image analysis reads the picture itself. For a claim the two work together: the issue file is the strongest evidence of what the customer issued, and image analysis shows where the paid item departs from it.
Can check image analysis read handwriting?
Yes, within limits. The Federal Reserve's toolkit describes optical and intelligent character recognition converting the payee, the written and numeric amounts and the date into machine-readable text. Intelligent character recognition is the part built for handwriting, and a claims tool should still compare several sources rather than trust one reading of a hand-written payee.
How many closed claims does a replay need?
Enough to contain the payer-changing cases, which are rare by design. A year of a bank's claims is a sensible start; a smaller bank may need two years, or a replay that includes every forged-signature and counterfeit write-off, because those are the types a tool most often confuses with alterations.
What does a replay cost the bank?
Mostly the work of pulling the evidence: images from the archive, duplicate copies and issue files from the claim files, and the outcomes from the general ledger. The tool's run is fast; reading the payer-changing cases with a second specialist is where the time goes, and it is the part that teaches the most.
Does a replay test the depositary bank's side?
It can, on claims other banks sent against yours. Replaying those asks a different question: would the tool have found the claim good from the deposit, the image and the depositor, and would it have proposed the hold in time to keep the balance? That replay measures money saved on the other side of the balance sheet.