Skip to content
Bookend

Why Bookend

Your documents never leave the bank.

Most document-AI vendors send your loan files to cloud AI services. Bookend ships as containers that run inside your network, and no frontier model or external AI service ever sees a loan document. There is no tenant to secure, no data-processing addendum to negotiate for loan documents, and nothing to explain to your vendor-risk committee about egress.

Architecture

Inside your network, on your terms

Bookend deployment: app-ui, api, inference, database and adapters on one internal network inside the bank; only the UI is reachable from the bank LAN. Bank network · Docker Compose on your VMware or Hyper-V estateapp-uinginx · the only exposed portapiREST · MCP · rules · jobsinferencerules engine + OCR · CPU onlydatabasePostgreSQL or SQL Serverdocumentscontent-addressed volumeOutbound only, each one visible in Settings and switchable offjXchange (your core) · SMTP (your relay) · metering heartbeat (counts and health, no loan data)
  • Reference sizing: 16 vCPU, 64 GB RAM, 500 GB storage. No GPU. Per-bank volumes run comfortably on CPU.
  • Database: PostgreSQL by default or your SQL Server, with the same schema, same forward-only migrations, two principals (owner for migrations, least-privilege for the application).
  • Updates: signed releases you pull on your own change-control schedule. No unattended updates. Preflight checks refuse to start on a schema mismatch.
  • Core hosted by Jack Henry? The containers still run in your network and reach the core over jXchange as they would on-site.
  • Air-gapped: supported. Heartbeats off; a signed quarterly usage report replaces them.

Explainability

Deterministic rules, human approval

The extraction engine’s job is narrow: classify documents and find fields. Judgment (does this rate agree with that one, does this guarantor have a guaranty) is a versioned rule with a page that explains what it compares and with what tolerance. That is what makes a finding defensible to an auditor, reproducible on the same input, and safe to tune by policy.

  • Reproducible

    Same package, same rules version, same findings. The ruleset version is stamped on every reconciliation run.

  • Tunable by policy

    Money, rate and date tolerances and name normalization are settings you control. Reason codes are yours.

  • Reviewed by a person

    Every loan passes a specialist. Nothing is boarded, and no wire leaves, without approval inside your existing maker-checker controls.

AI

No frontier models. No external AI.

No frontier model and no external AI service processes your loans, and nothing leaves your network for AI processing. Classification, extraction and execution checks are deterministic rules. The only machine learning is the open-source Tesseract OCR engine, which reads scanned pages on CPU inside the container with its published, pre-trained weights; native PDFs never pass through it. An optional helper can use a large language model to draft a starting template during setup. It is off by default and stays off unless your bank explicitly turns it on with a model you already have. Without it, your team teaches forms by hand, which is the standard path.

Controls

Maker-checker, everywhere it matters

The person who stages a boarding cannot approve it, even as an administrator. The person who stages a wire cannot approve it. Overrides carry reason codes and justifications; escalations are recorded and mailed. Sealed loans are read-only. These are enforced in the platform, not suggested by a procedure.

Model risk

A validation pack for your model inventory

Under SR 11-7 and OCC guidance, proportionate to a community bank, the extraction engine is an item in your model inventory. Every release ships with its validation pack: golden reference packages with their expected results, a documentation page for every rule, and the extraction accuracy report, alongside release notes that record every change. Confidence gating routes low-confidence numeric and party fields to a person rather than accepting them.

Metering

Exactly what leaves the bank, shown on screen

Bookend is priced per closed loan, so it needs a count. The heartbeat carries an install id, the version, the period, two integers (closed loans, document pages), coarse health and the license key for Bookend to validate, and nothing else. The Metering screen shows the payload verbatim before and after it is sent. Air-gapped installs generate a signed quarterly report instead.

The Bookend metering screen showing the exact heartbeat payload (install id, version, period, closed loan count, document page count, health and license key) and the delivery history.
The payload viewer: install_id, version, period, closed_loan_count, document_page_count, health, license_key. That is the whole message.

Start with a Closing Workflow Review

Forty-five minutes with your head of loan operations: we map the path from approval to documents to execution to boarding to funding, count the touches, and pull three recent boarding exceptions. You keep a one-page Closing Error and Capacity Map, whether or not you go further.