System architecture

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 Lending Core is the system of record. The built-in core 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. Lenders with an existing core can keep it as the financial record instead: 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, approvals, compliance decisions, the action-request lifecycle, promises, and audit. Its 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 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 built-in Lending Core the contract is realized in process — a typed executor resolves facts and capabilities, applies governed actions, and records their case effects — while a bring-your-own-core binding implements the same contract over HTTP. Because the platform depends on the contract rather than a core’s native schema, the same servicing layer runs above either unchanged.

The governed action path

People and AI agents never touch the core directly. A borrower contact, message, or account change is first evaluated by the compliance engine, which returns a structured decision — allowed, approval required, or blocked — and account-changing work runs through the action request gateway under maker-checker approval. Behind every step, the evidence graph records the decision, the facts it used, and its approvals in a tamper-evident chain.

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.