Capabilities and benefits

Bookend is one pipeline with nine capabilities. Each section below says what the platform does and links to the page that documents it in detail.

Nine capabilities

1. Intake

Packages arrive from the queue (upload), a watched network share, or your LOS or document system through the REST API or the MCP server. Native PDFs and scanned executed copies are both accepted; scans are read with OCR inside the inference container. The approval comes in your own LAR format (JSON, CSV, XML or DOCX, or a PDF approval read like any other document), mapped once through a versioned LAR profile. A resubmitted package becomes a new version and never overwrites the earlier one. See Intake.

2. Extraction with provenance

Every document is classified, and every variable term is located with a page and a bounding box. Click a value and the source page opens on the spot. Low-confidence classifications go to review, and uncertain values are flagged for a person rather than accepted quietly. Forms Bookend does not recognize can be taught by an administrator by drawing a box around each value on one example.

3. Reconciliation

Seventeen deterministic, versioned rules compare the note, loan agreement, guaranties, disbursement request, boarding sheet and approval:

• Agreement rules: principal, rate (with index and margin compared separately), loan and maturity dates, payment schedule, borrower name, guarantor set, interest method, late charge.
• Arithmetic and presence rules: term against dates, disbursements summing to principal, fees against the approval, collateral present when the loan is secured, a governing law clause.

Money, rate and date tolerances and name normalization are settings. Shipped rules can be switched off by bank policy and bank rules can be added; a disabled rule is named on every run and in the evidence chain.

4. Execution verification

Signatures, initials, dates and notary blocks are checked on each document against execution templates your bank controls. A missing mark becomes an exception with the zone highlighted on the page.

5. Boarding

A staged record is built from your core field map, with a source link on every field, and required fields are validated before anything is sent. A boarding checker who did not stage it approves. The commit happens once and is resumable, through jXchange or through JSON, XML or CSV boarding files for any core. The core’s answer, success or refusal, is stored verbatim on the loan. See Boarding and wires.

6. Funding

The wire request is built from the disbursement authorization and the approval, with sources on amount, payee and beneficiary. A second person approves it, and it is exported as a PDF or a file drop for your wire room, which releases it under your existing dual control. Bookend never transmits a wire.

7. Evidence

Each loan has an append-only, hash-chained packet covering extractions, comparisons, overrides, approvals, boarding and funding. A nightly job re-verifies every chain. The packet exports as a PDF with the verification result on page one, and as JSON. See Evidence packet.

8. Operations

The dashboard shows the queue by state, average review time, exception rate by rule and aging, all derived from recorded events. Diagnostics, release notes and an audit query are built in. People work in five roles: administrator, manager, closing specialist, boarding checker and auditor (read-only). Integrations use a separate service role whose rights come from the scopes on its API key. See Users and roles.

9. Integration

The REST API and the MCP server expose the same operations (list loans, get findings, preview boarding, submit a package, export evidence) with the same tokens, permissions and audit trail. The API is described by an OpenAPI document published with every release.

Six benefits

Each benefit below follows from the capabilities above.

Every loan, not a sample

Reconciliation runs on every package before boarding. The exception review your QC team does on a sample after the fact becomes a gate in front of the core. Follows from reconciliation and execution verification.

No re-keying

Terms are lifted from the executed documents, mapped to your core fields, and shown with a link to the exact line they came from. A person approves them, and nobody types them again. Follows from extraction with provenance and boarding.

Execution gaps caught before funding

Unsigned pages, missing initials and empty notary blocks are exceptions on the review screen, with the zone highlighted on the page, before anyone stages a wire. Follows from execution verification.

Judgment stays with your people

Every exception is accepted, overridden with a reason code and written justification, or escalated. Escalations are recorded and emailed. Approval unlocks only when every exception has a decision. Follows from the review workstation and maker-checker boarding and funding.

Defensible to an examiner

Whether two terms agree is decided by a versioned rule with a documented tolerance, not by a model. The evidence packet exports as PDF and JSON and can be verified offline. Follows from reconciliation and evidence.

Inside your network

Bookend runs as containers on your VMware or Hyper-V environment, with extraction running in the inference container. Loan documents stay in your network. The only message sent to Bookend is a metering heartbeat with no loan data, which you can read on screen before it goes, and air-gapped installs are supported. See Deployment architecture.

What Bookend does not do

Bookend does not generate documents, originate or approve loans, or transmit wires. It never boards without a second approval, never posts the same loan twice, and never lets the person who staged a record approve it. Your documentation system or counsel still produce the documents, your LOS still approves, your core still books the loan, and your wire room still sends the wire.