Every commercial loan a community bank closes produces a stack of executed documents. The note, the loan agreement, the security documents, the guaranties, the disbursement statement. Seven or eight documents, often a couple hundred pages.

Ninety-five percent of that stack is boilerplate. The other five percent is the principal, the rate, the index and margin, the maturity date, the payment schedule, the collateral, the guarantors, and where the money goes. That five percent is where boarding errors live.

And at most community banks, a closing specialist still compares it by hand. Across every document, against the credit approval, then keys it into the core and prepares the wire. On every loan.

The Gap Nobody Owns

Here's what surprised me when I started digging in. There's plenty of software on either side of that step. Documentation vendors generate the closing package. Loan origination systems manage the approval. The core system of record holds the loan once it's boarded.

But nothing checks that what was signed matches what was approved before it goes into the core. Documentation vendors generate documents; they don't validate them. And most of the lending AI money has gone to the front of the process: applications, spreading, credit memos. The back of the process, where a wrong maturity date quietly becomes a wrong loan on the books for ten years, got a checklist and a tired human.

So I built the piece that sits after document generation and before boarding. It's called Bookend, and it's live today.

What Bookend Does

Bookend reads the executed closing package, reconciles every variable term against the credit approval, verifies execution (signatures, dates, the parties who were supposed to sign), and then stages boarding and funding for the bank's own maker-checker approval. It's built for Jack Henry banks first.

The guiding rule is simple: software finds, rules judge, a human approves.

  • Finding is extraction. Pages get OCR'd, and fields get pulled out using templates for each document type. AI helps build those templates in a studio at setup time, and an admin approves each one. At runtime, extraction is deterministic. The same package produces the same answer every time.
  • Judging is 100% deterministic C# rules, each with an ID. Does the principal agree across the note, the agreement, and the approval? Do the disbursements sum to the loan amount? No model decides whether two numbers agree. That's arithmetic, and it should be done like arithmetic.
  • Approving is a person. Boarding and wires require a second person to sign off. Bookend never sends a wire. Ever.

Plenty of AI products blur those three steps into one confident-sounding answer. In lending, "the model thought the rates matched" isn't something you want to say to an examiner.

Inside the Bank's Network

This was the first architecture decision and the least negotiable one. Bookend runs on-prem, inside the bank's network, as a set of Docker containers. Loan files don't leave the building.

Most new entrants in this space assume cloud inference on loan files. A bank's vendor-risk committee is not going to accept that, and honestly, I don't blame them. So instead of spending a year fighting that battle one bank at a time, I designed it out. The only thing that phones home is a daily heartbeat with counts and health data for billing. Never loan data.

It supports both Postgres and SQL Server, because banks run what they run. The schema is hand-written DDL for both dialects, applied by a migrator that refuses to run if the live database has drifted from what it expects. Data access goes through Tuxedo, the ORM from my Noundry stack. Boring, explicit, and auditable, which is exactly what you want sitting next to a core banking system.

Evidence an Examiner Can Check

Every loan gets an evidence packet: what was extracted, which rules ran, what they found, who reviewed it, who approved boarding. Each event's hash includes the previous event's hash, and the tables are append-only at the database-permission level, not just in application code. A nightly job re-verifies every chain. Sealed loans are read-only.

When retention policy deletes the underlying document files years later, the hashes stay, so a sealed packet still verifies. Exports come out as PDF for humans and JSON for machines.

It's the same principle I keep coming back to in everything I build lately. Don't ask anyone to trust your records. Make them checkable.

An MCP Server That Can't Do Damage

Yes, there's an MCP server, so a bank's own AI tools can ask questions like "which loans are waiting on a second approver" or "what exceptions came up on this package." It's deliberately read-mostly. Nothing exposed over it can approve, board, or stage a wire, and every call is audited.

If you're adding agent access to anything that touches money, that's the pattern: let the agent see, never let it act on the irreversible stuff without a human in the loop.

Delivered, Not Downloaded

Bookend isn't a self-serve signup. Every bank gets an implementation that includes a parallel run on 20 to 30 of its own past closings, so the team can see exactly what Bookend would have caught, on their own documents, before it touches a live loan. Pricing is per closed loan. The target is 99.5% or better field accuracy after human review, and a 200-page package processed in ten minutes or less.

If your closing team spends its days re-keying the same five percent of every package, and your examiners keep asking how you know boarding matched the approval, this is built for you.

Bookend is live at usebookend.com. If you're at a community bank on Jack Henry and want to see it against your own closings, book a call.