Jack Henry jXchange

The jackhenry.jxchange core adapter boards approved loans into a Jack Henry core through jXchange. It is isolated in its own assembly behind Bookend’s core-adapter contract, so a bank changes endpoints, credentials and field codes through settings and core field maps, never through code.

Status

• Built and tested: the adapter, its REST binding, the two-phase boarding flow, inquiry-based duplicate protection and versioned field maps. Every release exercises it end to end against a jXchange mock that ships as a demo sidecar.
• Not yet certified: Jack Henry Vendor Integration Program (VIP) enablement is in progress. Until it completes, the adapter has not been run against a live Jack Henry core, the seeded field codes are illustrative, and an install that needs to board today uses file export, the default provider. Switching to jXchange later is a settings change; the approvals and the evidence trail are identical.

Bindings

Binding	Status	Calls
REST	active	POST {endpoint}/jxchange/v1/ping, POST {endpoint}/jxchange/v1/loans, GET {endpoint}/jxchange/v1/loans/{reference}
SOAP	envelope builder only, not selectable	AcctAdd-style envelope (InstRtId, ExtRef, one Fld per mapped code)

The REST calls send HTTP Basic credentials when a username is set. The body of a boarding post is:

{
  "institutionId": "<core.jxchange.institution_id>",
  "externalRef": "BK-DEMO-001",
  "packageVersion": 1,
  "idempotencyKey": "<staging key>",
  "fields": { "LN-ACCT": "BK-DEMO-001", "LN-PRIN": "1250000.00", "…": "…" }
}

A successful response carries coreReference and status; a response without coreReference is treated as a failure.

The demo stack’s jxchange-mock service implements this contract: it validates the payload shape, waits one to two seconds and answers with a core-style reference (SL-<year>-<number>); it returns 409 on a duplicate externalRef and 422 with a field list on shape errors.

Settings

Key	Purpose
core.provider	jackhenry.jxchange selects this adapter (one provider per deployment; the default is file.export)
core.jxchange.endpoint	REST base URL (http://jxchange-mock:8090 in the demo)
core.jxchange.username / core.jxchange.password	Basic credentials (the password is a secret setting, encrypted at rest)
core.jxchange.institution_id	Institution routing id, sent as institutionId (InstRtId in the SOAP envelope)

Field map

The seeded jackhenry.jxchange v1 map uses illustrative codes, not real Jack Henry identifiers: LN-ACCT, LN-PRIN, LN-RATE, LN-RATE-TYPE, LN-INDEX, LN-MARGIN, LN-ORIG-DT, LN-MAT-DT, LN-TERM-MO, LN-PMT-AMT, LN-PMT-FREQ, LN-PMT-CNT, LN-INT-METH, LN-LATE-PCT, LN-LATE-GRACE, LN-BORR-NAME, LN-BORR-TYPE, LN-GUAR-{n} (expanded per guarantor), LN-COLL-DESC, LN-COLL-CODE (bool_to_code:SEC,UNS), LN-OFFICER, LN-BRANCH, LN-CALL-CODE, LN-PURPOSE. A bank’s implementation replaces the map with POST /v1/core-field-maps (a new version; the previous one is deactivated) and previews it against a real loan with POST /v1/core-field-maps/{id}/preview?loan=REF. See Core field maps.

Transforms: text, upper, money (two decimals), rate5 (five-place fraction), date_iso, date_yyyymmdd, int, bool, json, list (joined with ; ), expand_list ({n} in the code), bool_to_code:A,B.

Two-phase boarding

1. Stage (POST /v1/loans/{ref}/boarding/stage, a signed-in admin, manager or specialist, loan in approved). The map is applied to the loan’s extracted values, validated (LN-ACCT, LN-PRIN, LN-RATE, LN-ORIG-DT, LN-MAT-DT and LN-BORR-NAME are required, as are an endpoint and an institution id), the endpoint is pinged so an unreachable core is caught before approval, and the full preview with per-field provenance is recorded. Send an Idempotency-Key header to make a retried stage replay the original record instead of staging twice.
2. Approve (POST …/boarding/approve): a signed-in admin or boarding checker who is not the person who staged the record.
3. Commit (POST …/boarding/commit): posts the loan. Success records the coreReference and moves the loan to boarded. A provider error is stored verbatim on the boarding record and the same call retries it. A 409 (the core already holds the reference) is resolved by an inquiry on the reference and recorded as already boarded, never as a second post.

GET /v1/loans/{ref}/boarding/status returns the boarding record plus a live inquiry against the core once a core reference exists.

Connection test

POST /v1/settings/test/core (setup wizard step 6, and the test button in Settings) pings the endpoint and reports the response verbatim.