Document intake: the safest first AI project in lending

If we had to name a single place for a community bank or credit union to start with AI, it would be document intake. It is not glamorous, and that is exactly why it works. The volume is high, the task is repetitive, the results are easy to measure, and a person can check the output before anything important happens.

What it is

A loan file is a pile of documents: pay stubs, tax returns, bank statements, identification, proof of insurance, titles, appraisals. Someone has to figure out what each document is, pull out the fields that matter, check that nothing is missing, and send problems to the right person. Document intake automation does the first part of that work. It classifies each document, extracts the fields, checks completeness against a checklist, and routes exceptions.

It does not make a credit decision. That separation is the reason it is a good first project.

Why the risk is manageable

Extraction is a bounded task with a right answer. You can check it against the source page. A wrong value is caught in review, and the cost of an error at this stage is a few minutes of rework, not a bad loan. Compare that with using AI to score applicants, which raises fair lending, explainability and model risk questions all at once. We cover those in our piece on explainable decisions.

Design it with a person in the loop

• Every extracted value links back to the exact place in the source document, so a reviewer can verify it in a second.
• Low confidence values are flagged for a person, not guessed at.
• Nothing is approved automatically in the first phase.
• Reviewers can correct values, and every correction is logged.
• Access to documents follows the same permissions as your current systems.

Roll it out in three stages

1. Shadow mode. The tool runs beside your staff for about a month and changes nothing. You compare its output with what people entered and measure the gap.
2. Assist mode. The tool pre-fills fields and flags problems. People review and confirm.
3. Selective straight through. For the lowest risk document types, where accuracy has been proven over time, review becomes sampling instead of every item.

Many institutions never need the third stage. The first two already return most of the time.

What to measure

Set a baseline before you start. Useful measures are minutes of staff time per file, the share of files that arrive at underwriting with a missing or wrong item, extraction accuracy by field and by document type, and the override rate, meaning how often reviewers change what the tool produced.

Test on your own documents, redacted as needed, not on the vendor's samples. Demos use clean, well scanned files. Your real mix includes crooked scans, phone photos and forms from many sources, and that is where accuracy is decided.

Controls to put in place

• Vendor due diligence, including where documents are processed and whether your data is used to train anything for others. See vendor diligence for AI.
• Retention, logging and access controls that match your existing policies for member data.
• A short model risk summary that states what the tool does and does not do. See model risk in proportion.
• A documented fallback so work continues if the tool is unavailable.

Common pitfalls

Teams most often run into poor scan quality, a long tail of unusual document types, staff who were not involved in the design, and accuracy claims based on easy samples. Involve the processors early. They know which documents cause trouble, and they will tell you.

A practical first step

Pick one loan product and the five document types that account for most of the volume. Collect two hundred recent examples. Measure how long intake takes today and how often files come back for rework. That baseline is the most valuable thing you will produce, whether or not you buy anything.