For Jack Henry banks

Bookend is built for banks on Jack Henry cores first: SilverLake, CIF 20/20 and Core Director. It works alongside what you already run.

Keep your LOS, your document vendor and your core

Nothing you run today is replaced. Your documentation system or counsel still produce the closing documents. Your LOS still originates and approves the loan. Your core still books it, and your wire room still sends the wire. Bookend validates what was signed against what was approved, then stages the boarding record and the wire request for your approval.

One adapter, configured per core

The jXchange adapter is configured per core through settings and a versioned core field map, not code. The map says which core field each extracted term goes to and how it is formatted. Every version can be previewed against a real loan before it goes live, and earlier versions are kept. Your implementation replaces the seeded map, which uses illustrative field codes, with one built from your own core fields, product codes and GL codes.

Where jXchange enablement stands

Write access to a Jack Henry core through jXchange is enabled through the Jack Henry Vendor Integration Program (VIP), starting with your test environment.

To be exact about status today:

• The jXchange adapter is built and tested against a mock core that stands in for jXchange. Its REST binding is active. A SOAP envelope builder is present for cores that need it, and is off by default.
• VIP enablement is not yet complete. Bookend does not claim Jack Henry certification.
• Enablement is requested during the install stage of your implementation and runs in parallel with it. It can take longer than the engagement, which is why boarding files exist as a first-class path.

Technical detail for integrators is on the Jack Henry jXchange adapter page.

Boarding files while enablement completes

Before jXchange write access is enabled, or for any core that takes a file, Bookend produces deterministic JSON, XML and CSV boarding files with the same source link behind every field. Your team loads the file into the core the way it loads other files today.

Switching to jXchange later is a settings change (core.provider). The field map, the two-phase approval and the evidence packet are the same on either path. Only the commit step changes.

Staged, checked, committed once

1. Stage. The executed terms are mapped to your core fields, and the required fields are validated before anything is sent. The full preview, with a source on every field, is stored as the boarding record.
2. Check. A boarding checker who did not stage the record approves it. The software enforces this for every user, including administrators.
3. Commit once. The commit posts a single transaction. Through jXchange, if the core already holds the loan, the duplicate is resolved by inquiry and recorded as already boarded, never posted a second time.
4. Record the answer. The core’s response, success or refusal, is stored verbatim on the loan. A refused commit can be retried after the cause is fixed, without re-keying anything.

See Boarding and wires for the states and the API.

If Jack Henry hosts your core

The Bookend containers still run in your network. They reach the core over jXchange the same way they would reach a core in your own data center. Loan documents stay in your network either way; what goes to the core is the boarding record you approved.

Other cores

The adapter contract is core-agnostic. Banks on other cores can board through boarding files today, and additional core adapters are in development as products.