Product
From executed package to boarded loan, with proof at every step.
Bookend sits after document generation and before boarding. It doesn’t generate documents, it isn’t an LOS, and it never sends a wire. It reads what was signed, checks it against what was approved, and hands your people a decision — with the evidence attached.
Pipeline
Five stages, one loan at a time
- 1
Validate
Package + approval in. Split, classify, OCR where needed, extract with page and position.
- 2
Verify
Reconciliation and execution rules run. Findings carry their sources. Review with reason codes.
- 3
Board
Stage the core record with provenance; a checker approves; commit once, resumable, provider answer recorded.
- 4
Fund
Stage the wire request from the DR&A and approval; a second person approves; export for your wire room.
- 5
Evidence
Seal the loan. Export the packet. Verify the chain any time, offline.
Intake
Every package, however it arrives
Upload from the queue, drop a folder on a watched share, send it from your LOS or document management system through the API or MCP server. Native PDFs and scanned executed copies are both handled; the credit approval record comes in as your own LAR format, mapped once through a profile.
Extraction
Nothing without a source
Documents are classified and every variable term is located with a page number and bounding box. The value on screen is a link: click it and the page opens with the exact spot highlighted. Confidence gating routes anything doubtful to a person instead of accepting it silently.
Document taxonomy
Note, loan agreement, guaranties, security agreement, disbursement authorization, notices, E&O, boarding data sheet, change in terms, credit memo — and “other”, never silently dropped.
Field catalog
Principal, rate, index, margin, dates, term, payment, late charge, interest method, parties, collateral, fees, disbursements, officer, branch, call code, purpose.
Canonical values
Money and rates are decimals end to end — never floats — so comparisons are exact and tolerances are yours to set.
Reconciliation & execution
Deterministic rules you can read
Whether the note agrees with the loan agreement is not a model’s opinion. It is a versioned rule with a documented tolerance, and its page in the product explains exactly what it compares. Execution checks work the same way: signature, initials, date and notary zones per document type, from templates you control.
Agreement rules
Principal, rate (with index and margin), loan and maturity dates, payment schedule, borrower name, guarantor set, interest method, governing law.
Arithmetic & presence
Term versus dates, disbursements summing to principal net of fees, fees against the approval, collateral present when the loan is secured.
Execution checks
Signature, initials, date and notary presence per document, from the bank’s execution templates. Findings show the zone on the page.
Review
Accept, override, escalate — with a reason
A closing specialist works the exception list with the keyboard. Overrides require a reason code and a written justification; managers can be required for overrides by policy; escalations notify by email. Approval is a checklist, and it is blocked until every exception has been dealt with.
Boarding & funding
Two phases, two people, one commit
Staging builds the core record with a provenance link on every field. A boarding checker who did not stage it approves. The commit happens once, is resumable if anything interrupts it, and the core’s answer is recorded verbatim. The wire request follows the same maker-checker path and is exported for your wire room — Bookend never transmits a wire.
Jack Henry first
SilverLake, CIF 20/20 and Core Director: the boarding transaction over jXchange, enabled through the Vendor Integration Program. A duplicate is resolved by inquiry, never posted twice. More core adapters are in the works.
How the jXchange boarding worksFile export
JSON, XML and CSV boarding files with deterministic names, for cores without write access or as a fallback during enablement.
Versioned field maps
Core field mappings are versioned and previewable against a real loan before they go live.
Evidence
The packet an examiner can verify
Every event on a loan — intake, each pipeline stage, each finding, each action, each approval, boarding, funding, sealing — is a link in a hash chain. Change one byte in the database and verification fails at that link. The packet exports as a human-readable PDF with the verification result on page one, and as JSON for machines.
Operations
A dashboard that counts only what happened
Queue by state, throughput, review time, exception rate by rule and aging — every figure derived from recorded events, nothing synthetic.
Surfaces
Workstation, API, MCP
Who uses the review workstation?
Closing specialists, loan operations managers, boarding checkers and auditors — each with a role that limits what they can do. It is a React application served from the same container stack, designed for dense, keyboard-first work on a standard workstation display.
How do our systems integrate?
A REST API with an OpenAPI document, and an MCP server that exposes the same operations (list loans, get findings, preview boarding, submit a package, export evidence, queue statistics) to an LOS, an internal automation or an assistant — with the same tokens, the same permissions and a full audit trail of every call.
What does the examiner get?
A per-loan evidence packet as PDF and JSON: document hashes, every extracted value with its source, findings and their resolution with reason codes, approvals with who and when, and the chain verification result.
Start with a Closing Workflow Review
Forty-five minutes with your head of loan operations: we map approval → documents → execution → boarding → funding, count the touches, and pull three recent boarding exceptions. You get a one-page Closing Error and Capacity Map — whether or not you go further.