LendEasy/DocsLMS + Servicing·v1
Start integrating
GuidesOverviewSystem architecture

System architecture

How LendEasy is layered — a lending core that owns financial truth, a servicing control plane that owns operational work, and typed execution boundaries for human and automated workers.

LendEasy is a single platform built from distinct layers, each with a clear job. One layer owns financial truth, another owns the operational work of servicing, and a shared workforce of people and AI agents acts through one governed path. Knowing the layers explains why an action is allowed, where a fact comes from, and who is accountable for a change.

The layers

        Human agents   +   AI agents         the workforce
                    |
                    v
            Governed action path             compliance gate in front,
                    |                         evidence graph behind
                    v
          Servicing control plane            cases · tasks · queues · promises
                    |                        approvals · reconciliation
                    v
           Fact & action contract            facts in, governed actions out
                    |
                    v
       Lending core (system of record)       balances · schedules · payments
                                             accounting · delinquency

Facts flow up from the core; governed actions flow down to it. Nothing reaches a borrower or the core except through the compliance gate, and every material decision lands in the evidence graph.

The lending core

The LendEasy Lending Core is the platform’s native system of record. It owns customers, loans, balances, repayment schedules, payment allocation, transactions, accounting, and delinquency. It serves one loan-summary read model, orchestrates payments and funding end to end, generates statements on a scheduled job, computes and finalizes the APR disclosure automatically at loan approval, and applies account-state changes — charge-off, write-off, re-age, closure — as governed commands under case governance and native maker-checker. As an additional deployment option, a published contract lets LendEasy servicing also run around a core you already operate: see Bring your own system of record.

The servicing control plane

The servicing control plane owns the operational work around that ledger: cases, tasks, queues, interactions, evidence, conditional approvals, compliance decisions, promises, and audit. Its implemented API is the /v1/servicing namespace of the same API base as the core. It holds the operational state you are driving toward, observes the authoritative state in the core, and reconciles the difference — surfacing any gap as work. See the Servicing Plane overview, implemented API surface, and Reconciliation & drift.

The fact and action contract

The two halves meet at one stable contract: authoritative facts flow in, governed actions flow out. Every fact carries its source and an as-of time, execution-critical facts are re-read at the moment of action, and submission is idempotent so a retry never doubles a financial effect. For the LendEasy Lending Core the contract is realized in process — a typed executor resolves facts and capabilities, applies governed actions, and records their case effects. Servicing depends on this typed contract rather than the core’s native schema, which is what additionally allows the same boundary to be bound to a core you already operate without changing case or workflow logic; the separately documented bring-your-own-core HTTP binding is the roadmap contract for that seam.

The governed action path

AI and SYSTEM workers never receive an untyped core bypass. Their registered workflow automation produces durable typed case effects or calls a closed governed operation. A logged-in human may call a canonical Lending Core customer or loan command directly with LendEasy-Case, but still needs that operation’s exact LMS permission; the case is causation, not authority.

The owning contact or account operation invokes the compliance engine and returns a structured outcome — allowed, approval required, blocked, unavailable, or missing facts. Allowed work executes immediately. Only a genuine approval, deferred, manual, or external boundary materializes an action request. Behind every step, the evidence graph records the decision, facts, causation, execution result, and any approval.

One workforce, one platform

Human agents and AI agents are distinct worker types under the same permissions, compliance, and audit. And though the layers stay separate internally, a lender operates one product — one login, one tenant model, one permission system — not two systems bolted together.

Unified search across guides, recipes & the API referenceEsc