Lending Core overview

The LendEasy Lending Core is the flagship system of record the platform is built on. It owns the facts that everything else depends on: products and their policy, loans and their schedules, disclosures, payments, autopay, statements, and the double-entry ledger those records post to. The servicing plane runs natively on this core; as an additional deployment option, the same servicing workflows can also run on a core you already operate — see bring your own system of record.

Three product families

A product is the behavior contract behind every obligation: it supplies defaults and hard constraints, and the terms a loan resolves at origination are frozen on the loan, not looked up at servicing time.

Merchant advances are a separate product family with their own terms, lifecycle, accounting, and API resource — selecting one never toggles an installment loan into a commercial contract. The example portfolio — Harbor, Juniper, Cedar, and Northstar — carries one consistent set of balances and dates through every family’s guides.

The loan lifecycle at a glance

A loan advances only through explicit, permissioned lifecycle commands: SUBMITTED proposes terms without moving money, approval authorizes them — and computes and finalizes the APR disclosure in the same step — and the loan becomes ACTIVE only when released funds post as a disbursement through the funding API, value-dated to the posted date rather than the day someone clicked “fund.” Delinquency, hardship, restrictions, and servicing plans are overlays on an active obligation, never replacement states, and charge-off, write-off, and contract termination are distinct governed outcomes — never aliases for normal payoff.

The money story

A payment is an operational intent first and a ledger transaction later, so “accepted by the processor” is never mistaken for settled money. Posting is value-dated: Harbor’s $517.14 ACH debit settles on September 15 but posts effective September 12, the date the borrower paid, and delinquency follows the value date. Every terminal payment is checked three ways — provider settlement, payment intent, ledger transaction — and a settled debit with no posting surfaces as a typed reconciliation exception, not a silent gap.

Underneath, accounting is strict double entry: every posted transaction balances to the cent, and Harbor’s first installment is readable straight from the journal — $517.14 of cash against $424.39 of principal and $92.75 of interest.

The disclosure story

For covered closed-end consumer credit, the APR engine applies the actuarial method of Regulation Z, Appendix J to the loan’s dated cash flows. Every charge definition carries an immutable finance-charge classification with a legal-basis citation, and the calculation fails closed — an unclassified fee can never reach a disclosure, and an unknown fee is never treated as excluded.

The disclosure is part of the lifecycle, not an endpoint to remember: it is finalized automatically at approval (an APR-enabled product cannot approve a loan without one), revalidated at disbursement against the actual funding facts, and superseded — with both records retained — if those facts changed. The finalized record stores every input, convention, and tolerance it used, so an auditor can reproduce Harbor’s disclosed 17.29 from a 13.25% nominal rate and a $252.00 prepaid fee without access to live configuration.

The governance spine

Every change to authoritative loan state is a governed command with its own permission. Human calls carry a LendEasy-Case header naming an open case when case management is enabled, maker-checker can park any flagged command for a different approver, and every execution writes an append-only governance record — who acted, in which context, through which route. The servicing action catalog documents 24 governed actions across schedule, interest, charge, refund, restriction, and terminal families, each with its own page. Undo is specific, never generic: where a dedicated undo command exists it is itself governed, and nothing deletes history.

The autopay interlock

Autopay is a policy-driven payment initiator, never a ledger shortcut: it reads current due facts each cycle and creates one normal, idempotently keyed payment intent per due obligation. Enrollment requires the borrower’s preauthorized-transfer authorization evidence, and the Regulation E notice window is wired into configuration itself — a FULL_DUE enrollment is accepted only when the product’s statement lead leaves the ten-day advance notice described in § 1005.10(d), because the due-date statement is the notice artifact. Cancellation is the revocation of record.

Explore the Lending Core

• Products & templates — the behavior contract behind every loan, including disclosure and statement policy.
• Example portfolio — Harbor, Juniper, Cedar, and Northstar: the four contracts every guide reuses.
• Loan lifecycle — from application to an evidence-backed terminal state.
• APR & disclosures — the Appendix J solve, worked end to end on Harbor.
• Payments & repayments — intent, settlement, value-dated posting, and returns.
• Accounting — balanced journal entries and the authoritative export surface.
• Autopay — amount and timing policies, notice coupling, and per-rail failure policy.
• Statements — cutoff windows, frozen snapshots, and governed regeneration.
• Servicing actions — the 24-action governed catalog and its maker-checker contract.
• Merchant advances — receivables purchase, remittance, and reconciliation.