Bring your own system of record

Bring Your Own Core is a production integration mode, not an architecture slogan. Your system remains authoritative for balances, schedules, posted transactions, delinquency, and the account state it owns. LendEasy owns servicing cases, work, communications, compliance decisions, promises, and evidence.

The boundary is deliberately narrow:

authoritative facts  →  LendEasy servicing plane
governed actions     ←  LendEasy servicing plane
acknowledgements     →  LendEasy servicing plane
reconciliation       ↔  both systems

1. Publish capabilities

The binding starts with a versioned capability document. A workflow discovers what is possible instead of guessing from vendor name.

GET /v1/servicing/core-bindings/core_47K/capabilities

{
  "bindingId": "core_47K",
  "version": "2027-04-18.3",
  "facts": {
    "loan.summary": "lms_provided",
    "loan.schedule": "lms_provided",
    "loan.payoff": "lms_provided",
    "loan.apr": "unavailable",
    "autopay.state": "lms_provided"
  },
  "actions": {
    "take_payment": "lms_provided",
    "pause_autopay": "lms_provided",
    "re_amortize": "manual_only",
    "apply_restriction": "lms_provided"
  }
}

Facts are LMS_PROVIDED or UNAVAILABLE. Actions are LMS_PROVIDED, MANUAL_ONLY, or UNAVAILABLE. Capability versions are effective-dated, and every case action records the version consulted.

MANUAL_ONLY is a real execution mode with approval, specialist task, applied reference, and reconciliation. UNAVAILABLE blocks workflows that require the capability; it never degrades into a note.

2. Map identity without leaking schemas

The binding maps stable LendEasy IDs to stable source IDs by entity type and scope.

Mappings preserve historical aliases after a source migration. A source ID collision or one-to-many ambiguity stops ingestion and opens identity reconciliation; the platform does not pick a likely record.

3. Supply facts with provenance and freshness

A canonical fact envelope separates value from confidence in that value:

{
  "fact": "loan.delinquency",
  "entityId": "7204",
  "value": {
    "daysPastDue": 22,
    "amountPastDue": "517.14",
    "oldestUnpaidDueDate": "2027-04-09"
  },
  "source": "core_47K",
  "sourceVersion": "acct-etag-99104",
  "asOf": "2027-05-01T08:00:00-07:00",
  "observedAt": "2027-05-01T08:00:03-07:00",
  "freshness": "fresh"
}

Each fact type has a maximum age by use. A 15-minute-old delinquency fact might be acceptable for queue ranking but too stale for waiving a fee or initiating contact. The consumer specifies its purpose; the binding refreshes or returns STALE / UNAVAILABLE.

Missing is not zero, false, or an empty list. If a core cannot answer bankruptcyRestrictionActive, the compliance decision becomes UNAVAILABLE_DUE_TO_MISSING_FACTS when that fact is required.

4. Submit typed, idempotent actions

LendEasy sends the approved action, operational context, expected source version, and execution key.

POST /connector/v1/actions
Idempotency-Key: act_HBR_PMT_812-attempt-1

{
  "actionId": "act_HBR_PMT_812",
  "actionType": "take_payment",
  "entity": {
    "loanId": "7204",
    "sourceAccountId": "LN-0081442"
  },
  "expectedSourceVersion": "acct-etag-99104",
  "parameters": {
    "amount": "517.14",
    "currency": "USD",
    "effectiveDate": "2027-05-08",
    "sourceInstrumentId": "BANK-TOKEN-204"
  },
  "context": {
    "caseId": "case_HBR_COL_51",
    "reasonCode": "promise_installment",
    "approvalId": null
  }
}

The source must treat identical retries as the same action. If expectedSourceVersion is stale, it returns a conflict with current version; it must not execute against changed facts.

5. Normalize acknowledgements

An acknowledgement says what the source accepted or applied—not what LendEasy requested.

{
  "actionId": "act_HBR_PMT_812",
  "outcome": "pending_external",
  "sourceOperationId": "PAY-99120",
  "sourceVersion": "acct-etag-99105",
  "acceptedParametersHash": "sha256:49b1…72dd",
  "pollAfter": "2027-05-08T10:05:00-07:00"
}

Unknown source outcomes become FAILED with unknown_source_outcome; they cannot be mapped to completed for convenience.

6. Reconcile continuously

Reconciliation checks action request, acknowledgement, refreshed fact, source transaction, and any money-rail settlement.

Reconciliation does not “fix” money by submitting the original action again. Repair is a separately authorized compensating action.

Worked delinquency flow

Harbor reaches 22 days past due in an external core.

1. Signal. The binding publishes a changed delinquency fact for loan 7204 with asOf and source version.
2. Identity. The source account maps unambiguously to Harbor and Maya. LendEasy opens or links a collections case using the signal reference as its deduplication key.
3. Context. The case fetches loan summary, schedule, payments, active promises, restrictions, contact points, and consent facts. Each displays source and freshness.
4. Compliance. Before a call, LendEasy refreshes execution-critical facts. The external core reports no bankruptcy or account restriction; the servicing plane contributes consent and contact-budget facts.
5. Interaction. A voice attempt passes the gate and reaches Maya. The interaction records the exact decision and source fact versions.
6. Promise. Maya commits to two payments. LendEasy owns the promise; no write is made to the core merely to record it.
7. Action. On May 8, an authorized payment action is submitted to the core with an execution key and expected account version.
8. Acknowledgement. The core returns PENDING_EXTERNAL and a payment operation ID. LendEasy suppresses duplicate action submission, not all servicing blindly.
9. Completion. A later source event reports the payment posted. The binding refreshes payment, allocation, balance, and delinquency facts.
10. Reconciliation. The posted $260, action parameters, and source transaction agree. The first promise installment becomes kept; the case waits for the second.

At step 4, if the restriction fact were unavailable, the call would be blocked for missing facts. At step 8, if the core timed out, retrying with the same key would retrieve the same source operation instead of taking $260 again.

Degraded modes

The UI distinguishes STALE, UNAVAILABLE, and NOT_APPLICABLE. Operators can see what still works and why a specific action does not.

Readiness checklist

• Capability contract covers every fact and action used by enabled workflows.
• Stable identity mappings are backfilled and collision-tested.
• Fact envelopes include source version, asOf, observation time, and freshness.
• Action idempotency survives timeout after source commit.
• Acknowledgements return applied parameters and authoritative identifiers.
• Event and read paths converge on the same normalized fact.
• Reconciliation detects missing, extra, duplicate, and divergent effects.
• Failure injection proves safe behavior during stale facts and partial outages.
• Runbooks name owners for identity, payment, ledger, and restriction drift.