Security and compliance

Bookend narrows the data-security scope by design. The software runs in your network, extraction runs in your network, and the only thing sent to Bookend is a metering heartbeat you can read on screen. This page collects what third-party risk, information security, model-risk and audit teams usually ask.

Subprocessors for loan data

There are none. Closing documents, extracted terms, findings, approvals and the evidence chain live in your database and your document volume. Bookend staff have no access path into a deployment; support works from diagnostics and logs that your team chooses to share, and loan documents never need to leave the institution for a support case. See Data handling.

Maker-checker, enforced

The person who stages a boarding record or a wire request can never approve it, even as an administrator. The platform enforces this; it is not left to a procedure. Review approval stays locked until every exception has a decision, and an override requires a reason code and a written justification. Bookend never transmits a wire. See Boarding and wires.

Identity and access

• Sign-in: passwords hashed with Argon2id, or one-time sign-in links sent by email. Each method can be turned on or off.
• Multi-factor: authenticator-app codes (TOTP), with per-user enrollment, a policy switch to require it, and an administrator reset for a lost device.
• Single sign-on: OpenID Connect to your identity provider, such as Entra ID or Okta. The provider authenticates; Bookend authorizes. Only existing, active Bookend users can sign in this way, and accounts are never created on the fly.
• Tokens: short-lived RS256 access tokens (1 to 60 minutes, set by you) signed with a key generated on first boot, and rotating refresh tokens with theft detection. Tokens are kept in browser memory, not cookies.
• Integrations: API keys with scopes, used by the REST API and the MCP server alike.
• Roles: administrator, manager, closing specialist, boarding checker and auditor (read-only), plus a service role for API keys.
• Recording: every sign-in, token refresh, API key issue and MCP call is recorded.
• Limits: per-principal and per-address rate limits, sign-in attempt limits, security headers and a content security policy on the UI.

See Users and roles.

Secrets at rest

SMTP and core credentials, the identity provider secret and the token signing key are encrypted with AES-GCM under a master key your bank holds. One-time codes, refresh tokens and API keys are stored only as hashes.

Append-only evidence and row-level audit

• Evidence. Every event on a loan is hashed in a canonical form and chained to the one before it. The application’s database account can insert evidence events but cannot update or delete them. A nightly job re-verifies every loan’s chain, logs any break as an error for your monitoring, and shows the result on the diagnostics page. Sealed loans are read-only. See Evidence packet.
• Audit. Business tables carry a row-level change history with the actor, written in the same transaction as the change. Secrets are excluded from the recorded values. Both the evidence chain and the audit history are queryable in the product.

Model risk (SR 11-7 and OCC guidance)

The extraction and classification model belongs in your model inventory. Its scope is narrow: it classifies documents and locates values. It does not decide whether terms agree (versioned rules do), and it does not approve anything (people do). Every signed release ships a validation pack proportionate to a community bank: test sets, accuracy by field type, known failure modes, monitoring guidance and the change history. Per-bank adaptation, such as your LAR profile, core field map and taught document templates, is configuration stored in your database and never leaves it.

Exactly what leaves the bank

What	When	Contents
Metering heartbeat	Daily, unless turned off or air-gapped	Install id, version, reporting period, closed-loan count, document page count, coarse health and the license key. No loan data. Shown verbatim on System → Metering before and after it is sent.
Signed quarterly usage report	Air-gapped installs only, delivered by your team	The same counts for a calendar quarter, signed by your install.
Boarding record	When a boarding checker approves a commit	The approved record, sent to your own core over jXchange, or written as a file for your team to load.
Evidence packets and diagnostics	Only when your team exports or shares them	Whatever your team chooses to send. Diagnostics contain no loan data.
Template suggestion text (optional)	Only if an administrator configures ai.endpoint and asks for a suggested template	The text of the one sample document the administrator uploaded. Off by default, and can point to a model inside your network.

Every outbound connection is listed on Deployment architecture.

Change control

Releases are signed bundles containing images, checksums, release notes, forward-only migrations and the validation pack. Your team verifies and applies them in your maintenance window. Bookend never updates itself, and the application refuses to start against a schema it does not expect. Runbooks for install, upgrade, backup and restore, and incidents ship with the product.

SOC 2 and penetration testing

SOC 2 reports are not yet available. SOC 2 Type I is planned, with Type II the following year, together with an annual penetration test and a business continuity plan. Until the reports exist, we say so plainly. Security and model-risk questionnaires are answered in full under NDA, and the security overview and the current validation pack are available on request through usebookend.com.