Bring your own system of record

Connect an existing lending core through a concrete fact/action contract with identity mapping, freshness, idempotency, acknowledgements, reconciliation, and safe degraded states.

Your core keeps the money; LendEasy keeps the work — and the whole contract exists so neither one ever has to guess what the other knows.

Bring Your Own Core is the integration contract for composing LendEasy servicing around a lending system you already run.

system of record

Your core stays authoritative for

Balances, schedules and posted transactions
Delinquency and account state
What it accepted, and what it actually applied

the servicing layer

LendEasy owns the servicing around it

Cases, work, compliance decisions and evidence
Governed actions, submitted with an execution key
Promises, contact budgets and consent facts

Four things cross the boundary and nothing else: authoritative facts in, governed actions out, acknowledgements back, and reconciliation in both directions.

1. A workflow discovers what is possible, never guesses

The binding starts with a versioned capability document.

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.

LendEasy entity	Source mapping	Rule it must satisfy
Customer	`customerId ↔ sourcePartyId`	One active mapping per source identity and tenant.
Loan	`loanId ↔ sourceAccountId`	Immutable after activation except controlled merge repair.
Instrument	`paymentInstrumentId ↔ sourceInstrumentId`	Mask and ownership agree; no raw account data.
Transaction	`payment/action ID ↔ sourceTransactionId`	Stable enough to deduplicate and reverse.
Restriction	`restrictionId ↔ sourceRestrictionId`	Type, scope, effective interval, and status agree.

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. Missing is not zero

A fact record separates the value from our 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 structured, safely retryable 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. An acknowledgement says what the source accepted

Outcome	Caller behavior
`COMPLETED`	Store authoritative result and reconcile resulting facts.
`PENDING_EXTERNAL`	Poll or await event using the returned operation ID.
`REJECTED`	Preserve structured code; return to workflow without retrying blindly.
`MANUAL_REQUIRED`	Create specialist task tied to the same action.
`FAILED`	Retry only if failure class is explicitly retryable.
`CAPABILITY_UNAVAILABLE`	Stop and refresh capability version.

{
  "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. Reconciliation never fixes money by resubmitting

Five records, one change. Reconciliation is not a health check on the connection — it is the question of whether all five still tell the same story, and each disagreeing pair has its own name and its own response.

Drift	Severity	Example response
Accepted but no completion after SLA	Warning → critical	Poll, then specialist review.
Source says completed; balance unchanged	Critical	Freeze dependent automation; compare allocation.
Applied amount differs from approved amount	Critical	Record both; failed-action review.
Source transaction exists without LendEasy action	Context dependent	Import as external action or investigate bypass.
Duplicate source transactions for one action	Critical	Stop retries; recovery workflow.

Repair is a separately authorized compensating action, never a resubmission of the original.

Worked delinquency flow

Harbor reaches 22 days past due in an external core.

Signal. The binding publishes a changed delinquency fact for loan 7204 with asOf and source version.
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.
Context. The case fetches loan summary, schedule, payments, active promises, restrictions, contact details, and consent facts. Each displays source and freshness.
Compliance. Before a call, LendEasy refreshes execution-critical facts. The external core reports no bankruptcy or account restriction; the servicing workspace contributes consent and contact-budget facts.
Interaction. A voice attempt passes the gate and reaches Maya. The interaction records the exact decision and source fact versions.
Promise. Maya commits to two payments. LendEasy owns the promise; no write is made to the core merely to record it.
Action. On May 8, an authorized payment action is submitted to the core with an execution key and expected account version.
Acknowledgement. The core returns PENDING_EXTERNAL and a payment operation ID. LendEasy suppresses duplicate action submission, not all servicing blindly.
Completion. A later source event reports the payment posted. The binding refreshes payment, allocation, balance, and delinquency facts.
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

Degradation	Safe behavior
Event stream delayed	Mark affected facts stale; fall back to read-through where permitted.
Read API unavailable	Keep cases visible; block actions needing fresh facts.
Action API unavailable	Queue only explicitly retryable submissions; do not claim execution.
Capability document expired	Continue read-only views with warning; block new capability-dependent actions.
Identity mapping conflict	Quarantine affected events and actions.
Reconciliation lag high	Lower automation, surface drift, and protect duplicate-sensitive actions.

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 records 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.

BYOC does not require the source to adopt LendEasy’s internal model. The adapter absorbs native schemas; the published fact/action contract remains stable for workflows, compliance rules, and API clients.