How loan boarding automation should work

Three jobs, three different tools

Most “AI for loan documents” pitches blur three different jobs together. Keeping them apart is what makes the result explainable.

• Finding. Which document is this, and where on the page is the maturity date? This is pattern recognition, and a model is the right tool for it, as long as the model runs where the documents are and its accuracy is measured and published with every release.
• Judging. Does the rate on the note agree with the rate on the loan agreement and the approval? This is a comparison with a tolerance, and it should be a rule: versioned, documented, reproducible on the same input, and tunable by credit policy rather than by retraining.
• Deciding. Is this exception acceptable? That is a person’s job, with a reason code and a justification, and with a second person on anything that commits to the core or moves money.

The pipeline

1. 1

   Intake

   Upload, watched folder, LOS, or API. Native PDFs and scanned executed copies. The credit approval comes in the bank’s own format and is mapped once.

2. 2

   Extraction

   Documents are classified and every variable term is located with a page and bounding box. Low-confidence values go to a person instead of being accepted.

3. 3

   Reconciliation

   Versioned rules compare each term across the documents and the approval. Each term gets an agreement or an exception, explained line by line.

4. 4

   Review

   A specialist works the exceptions: accept, override with a reason code, or escalate. Approval is blocked until every exception is resolved.

5. 5

   Board & fund

   The record is staged with provenance, a checker approves, and it commits once. The wire request is staged and approved the same way, then exported to the wire room.

Every value keeps its source

An extracted value is only useful if you can check it. Every term should carry its provenance (the document, the page, and the position), and the value on screen should be a link that opens the page with the exact spot highlighted. Money and rates should be decimals end to end, never floats, so that comparisons are exact and tolerances mean what they say.

Confidence should gate acceptance. A low-confidence numeric or party field goes to a person rather than being accepted quietly. And when a bank’s own form differs from the ones the model was validated on, a specialist should be able to fix the source on the page and have the platform learn the form as data the bank owns, not as a code change.

Rules you can read

The rule catalog for commercial loan boarding is not long, and every rule has a page that explains it:

• Agreement: principal, rate (index and margin separately), loan and maturity dates, payment schedule, borrower name, guarantor set, interest method, and governing law.
• Arithmetic and presence: term versus dates, disbursements summing to principal net of fees, fees against the approval, collateral present when the loan is secured, and a guaranty for each guarantor.
• Execution: signature, initials, date, and notary presence by document type, from templates the bank controls.

The ruleset version is stamped on every reconciliation run, so a finding from last quarter can be reproduced this quarter. The ten common boarding errors map one-to-one onto this catalog.

Review: accept, override, or escalate

A closing specialist works the exception list, keyboard first. Overrides require a reason code and a written justification. Policy can require a manager for overrides of certain rules. Escalations notify by email and are recorded. Approval is a checklist that stays locked until every exception has been handled. None of that is automation replacing judgment. It is automation making sure judgment is exercised, and recorded, on every loan.

Two phases, two people, one commit

Staging builds the core record with a provenance link on every field and validates the required fields before anything is sent. A boarding checker who did not stage the record approves it, and the software enforces that even for administrators. The commit happens once, resumes if it is interrupted, resolves a duplicate by inquiry rather than a second post, and stores the core’s answer verbatim on the loan. The wire request follows the same maker-checker path and is exported for the wire room.

What the software must never do: transmit a wire, board without a second approval, post twice, accept a low-confidence value quietly, or let the person who staged a record approve it.

Evidence an examiner can verify

Every event on a loan (intake, each pipeline stage, each finding, each action, each approval, boarding, funding, and sealing) should be a link in a hash chain. Change one byte in the database and verification fails at that link. The packet exports as a readable PDF with the verification result on page one, and as JSON for machines. That is what turns “the system checked it” into something internal audit can file.

Model risk, proportionate to a community bank

Under SR 11-7 and OCC guidance, the extraction model is an item in the bank’s inventory. The vendor should supply the validation pack with every signed release: test sets, accuracy by field type, known failure modes, monitoring guidance, and change history. Because judgment lives in the rules and every loan is approved by a person, the model’s blast radius stays narrow.

Where it runs

Loan documents are the most sensitive thing a lending operation handles. The model should run inside the bank’s network, in the same containers as the rest of the platform, with no cloud inference on loan files. The on-premises deployment guide covers what that involves.

This is how Bookend is built

The design above is the Bookend platform, described without the product name. Product detail, including screenshots of the review workstation, the evidence packet, the metering payload, and the API and MCP server, is on usebookend.com. The services engagement is how it gets proven on your own closings before the first live loan.