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, your controls — proven on your own historical closings before the first live loan, and handed over with what your auditors expect. Six to ten weeks, typically.
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
- 01 · Weeks 1–2
Discovery
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.
- 02 · Weeks 2–4
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.
- 03 · Weeks 3–6
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. 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.
- 04 · Weeks 5–8
Parallel run
Twenty to thirty historical closings processed alongside your existing process. Accuracy by field type, findings against known outcomes, tuning where your documents differ from the validated templates.
Done when: An accuracy report you accept; specialists working the workstation unaided.
- 05 · Weeks 8–10
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 — not a custom build you would then be stuck on.
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 worksFile export, any core
Deterministic JSON, XML and CSV boarding files with provenance behind every field — 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?
Six to ten weeks from discovery to go-live is typical. jXchange enablement through VIP runs in parallel and is the usual long pole; the file-export path means it never blocks the parallel run or training.
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.
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 approval → documents → execution → boarding → funding, count the touches, and pull three recent boarding exceptions. You get a one-page Closing Error and Capacity Map — whether or not you go further.