Skip to content
Bookend

Implementation

Delivered, not downloaded.

Bookend is one signed release for every bank, adapted to yours by an implementation engagement: your documents, your approval record, your core, your credit policy, and your controls. We prove it on your own historical closings before the first live loan and hand it over with what your auditors expect. Four weeks is typical. You are live on boarding files in week four, with the jXchange commit switched on when enablement completes.

Before the engagement

Two steps that cost you almost nothing

A 45-minute Closing Workflow Review leaves you with a one-page Closing Error and Capacity Map whether or not you go further. If it makes sense, a paid pilot runs Bookend on your next twenty closings (redacted if you prefer, boarding files only, no core write), with findings reviewed alongside your specialists each week.

The engagement

Five stages, one team on each side

  1. 01 · Week 1

    Discovery

    The loan types and account packages in scope, your document sources, approval record format, boarding practice and core fields, wire process, roles and segregation of duties. Network, database, TLS and mail decisions. The vendor-risk questionnaire, answered.

    Done when: A signed configuration workbook and the environment request.

  2. 02 · Week 1

    Install and enablement

    The release verified and started on your host, TLS at your edge, the onboarding wizard completed with your relay and database, roles created. jXchange enablement requested through VIP; boarding files as the interim path.

    Done when: Readiness green, SMTP and core tests passed, security sign-off on the install.

  3. 03 · Week 2

    Configuration and mapping

    A LAR profile for your approval format. A core field map version with your product and GL codes. Execution templates for your document set, and your own forms taught by pointing at values on one example. Rule tolerances, reason codes and justification policy set to your credit policy.

    Done when: Every canonical field maps; a preview boards a real loan cleanly.

  4. 04 · Week 3

    Parallel run

    Twenty to thirty historical closings processed alongside your existing process. Accuracy by field type, findings against known outcomes, and where your documents differ from the validated templates, a specialist fixes the source on the page and Bookend learns the form.

    Done when: An accuracy report you accept; specialists working the workstation unaided.

  5. 05 · Week 4

    Training and go-live

    Role-based training. Go-live with human approval on every loan (that never changes). The evidence packet walked through with internal audit and compliance; the validation pack filed in your model-risk inventory.

    Done when: First production loans sealed; audit accepts the packet; support handover.

Who is involved

What we need from the bank

Implementation is light on your calendar but it is not zero. These are the people we work with, and roughly when.

  • Head of loan operations

    Sponsor and decision-maker throughout; discovery, the parallel-run reviews, the go-live decision.

  • A closing specialist

    The subject-matter expert for your documents and your approval record; the first user of the workstation in the parallel run.

  • IT and information security

    Host, network, database, TLS and mail decisions in discovery; the install; the vendor-risk review.

  • Core administrator or Jack Henry liaison

    jXchange enablement through VIP, test credentials, product and GL codes for the field map.

  • Internal audit or compliance

    The evidence packet walkthrough and the model-risk inventory entry before go-live.

  • A boarding checker

    The second person in maker-checker for boarding and wires, trained before the first live loan.

What stays the same

Configuration, never a fork

Nothing in the engagement changes the software for your bank. Field maps, approval-record profiles, execution templates, tolerances and reason codes are versioned data in your own database, previewable before they go live and carried forward through every release. Something your documents or your core need that the release cannot express becomes a product improvement for every bank rather than a custom build you would be stuck maintaining.

Cores

Jack Henry first

  • SilverLake, CIF 20/20, Core Director

    Boarding through jXchange, enabled through the Jack Henry Vendor Integration Program, with a versioned field map per core.

    How the jXchange boarding works
  • File export, any core

    Deterministic JSON, XML and CSV boarding files with provenance behind every field. This is the interim path during enablement and the permanent path for cores that take a file.

  • More adapters in the works

    The adapter contract is core-agnostic by design. Additional core adapters are being developed as products, not as one-off projects; ask us about your core.

Questions

Why is implementation required at all?

Because the product is only useful once it knows your approval record, your core fields, your document set and your credit policy, and because a bank should not put software between its closing packages and its core on anyone’s word. The parallel run on your own historical closings is the proof, and the evidence walkthrough with audit is what makes go-live defensible.

How long does it take?

Four weeks from kickoff to go-live is typical for a bank that has the environment provisioned and twenty to thirty historical closings gathered at kickoff. Install is a runbook, mapping and templates are data, and the parallel run processes the closings in an afternoon. The rest of that week is your specialists reviewing findings. jXchange enablement through VIP runs in parallel and can outlast the engagement; the file-export path means go-live never waits for it.

What if our documents are not LaserPro?

Counsel-drafted packages on larger loans are covered by the Premium tier. Discovery looks at your actual document set; the parallel run tells us where extraction needs adjustment before anything is live.

Does it work beyond commercial loans?

The method is the same for any package boarded from executed documents: consumer installment and indirect loans, residential mortgages and home equity lines, SBA and agricultural loans, and account-opening packages. Commercial packages are where the shipped catalog goes deepest today. Discovery works through one of your recent packages for each line of business in scope and tells you plainly which part is configuration and which part would wait on a signed release.

Who runs the platform afterwards?

Your IT team, with the runbooks that ship with the product: install, upgrade, backup and restore, incidents. Releases are signed bundles you pull on your own change-control schedule; Premium support can apply them with you.

Do you change the software for us?

No. Everything the engagement does is configuration, mapping, tuning and proof inside the shipped release. That is what keeps upgrades routine and the validation pack meaningful.

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.