How it works

Bookend reads the executed closing package, reconciles every variable term against the credit approval, verifies execution, and stages boarding and funding for your own maker-checker approval. It runs inside your network and produces an evidence packet for every loan that an examiner can verify.

Five steps

1. Validate. The executed package and the credit approval record (LAR) come in. Every document is classified, and every variable term is extracted with the page and position it came from.
2. Verify. Deterministic rules reconcile the note, loan agreement, guaranties, disbursement request, boarding sheet and approval. Signatures, initials, dates and notary blocks are checked against your execution templates. A closing specialist decides each exception.
3. Board. The core record is staged with a source link on every field, approved by a boarding checker who did not stage it, and committed once, through jXchange or a boarding file.
4. Fund. The wire request is staged from the disbursement authorization and approved by a second person. Your wire room sends it. Bookend never transmits a wire.
5. Evidence. The loan is sealed. A hash-chained packet shows what was checked, by whom, against what, and that nothing has changed since.

Validation and verification run as the package arrives, so findings are usually ready while the closing is still being wrapped up. Boarding and funding are two-phase and maker-checker: nothing commits to the core or moves toward the wire room without a second person.

The model finds. The rules judge. A human approves.

Bookend splits the work three ways, and each part has a clear owner.

Part	Question it answers	How it is done
The model finds	Which document is this, and where on the page is the maturity date?	Classification, extraction and OCR run in the inference container inside your network. Low-confidence classifications are routed to review, and uncertain values are flagged for a person.
The rules judge	Does the rate on the note agree with the approval?	A versioned rule with a documented tolerance. The same package and the same ruleset version always produce the same findings, and the ruleset version is stamped on every run.
A human approves	Is this exception acceptable?	A specialist accepts, overrides with a reason code and justification, or escalates. A second person approves anything that commits to the core or stages a wire.

This split is what makes a finding defensible. Whether two terms agree is never a model’s opinion, and tolerances are settings your bank controls, not model weights. See Validation pack (SR 11-7) for how the model is documented for your model inventory.

Product tour

The captures below are the actual product running on demo data.

One queue, every state

The queue. Every package by state, with open exceptions flagged and age since registration on each row.

Packages move through intake, processing, review, approved, boarded, funded and sealed. The queue filters to My work, the Team queue, Exceptions only or Aging. Packages arrive by upload, a watched folder, your LOS or document system through the REST API, or the MCP server. See Intake.

Every document classified, every value with a source

A loan page. Each document is classified on arrival; every extracted value carries a link to where it was read.

Every file is stored by its SHA-256 hash, and that hash is what the evidence chain refers to, so a document cannot be swapped after the fact. Click any value and the page opens on the spot it came from.

Provenance. The source page, with the value boxed where it was read.

Exceptions first, decisions recorded

The review workstation. Every finding cites its sources, and approval stays locked until every exception has a decision.

Each finding names its rule and shows the values from every source. An override requires a reason code and a written justification, recorded with who and when. Escalations are recorded on the loan and emailed to managers and administrators. The workstation is keyboard first: J and K move between findings, and A, O and E accept, override and escalate. See Review workstation.

Boarding and the wire are separate gates

Boarding. Every core field with the value it will carry and where it came from.

Both open only after review approval, and each has its own second-person sign-off. The stager of a boarding or a wire can never approve it, including administrators. See Boarding and wires.

Teach Bookend your own forms

Draw a box around a value and name it. Bookend reads it back on the spot and anchors it to the printed label beside it.

Bookend reads the standard closing documents out of the box. When your bank uses a form it does not recognize, an administrator uploads one example, draws a box around each value and names it. Nothing changes until the template is saved. From the next loan on, that form is read with the template, and the template is data in your database that carries forward through every release. See Teaching documents.

Figures that reconcile to the packets

The dashboard. Every figure derives from recorded evidence events.

The dashboard shows the queue by state, average review time, exception rate by rule and aging. Every figure is derived from recorded evidence events, so it ties back to the packets.

The evidence packet

The evidence chain. One row per event, each hashed over the one before it.

Every event on a loan, from intake to seal, is a link in a hash chain. The packet exports as a PDF with the verification result on page one and as JSON, and it can be verified offline without Bookend running. See Evidence packet.

Next

• Capabilities and benefits
• Deployment architecture
• Overview for the technical layout before you install