Configurable loan products
Consumer installment, BNPL, merchant advance — and what you launch next. New products and asset classes are configuration, not code, with product-class boundaries the compliance engine respects.
Lending Core · part of the LendEasy platform
A modern loan management system, built for what you launch next
The LendEasy lending core is a bank-grade LMS where new products and asset classes are configuration, not code — with borrower self-service, integrated accounting, Metro 2 bureau reporting, and payment mechanics that never mark an on-time payer late.
New loan product — BNPL · Pay in 4
Lending core · product catalog
Product definition
4 payments · biweeklyproduct class: consumer0% periodic interest
Built-in machinery
- Reg Z APR engineon
- Metro 2 bureau reportingon
- Borrower portal & autopayon
- GL postingautomatic
Product-class boundary
Class consumer — consumer rules apply from day one, and merchant-advance rules can never silently cross over.
A new asset class is a configuration exercise — not an engineering roadmap
The system of record
Everything a loan management system owes you
The core handles the money mechanics that make or break borrower trust — and feeds the servicing control plane the high-fidelity facts that real-time compliance depends on.
Borrower self-service portal
A white-labeled portal where borrowers make payments, set up autopay, pull statements, and exchange documents — self-service that deflects calls instead of creating them.
Integrated accounting & GL
Every loan event — disbursement, payment, fee, write-off — posts to the general ledger automatically. Month-end is a review, not a reconstruction.
Credit bureau reporting (Metro 2)
Metro 2 furnishment built into the core, driven by the same ledger facts borrowers see — so what you report always matches what is true.
Value-dated payments
Payments post with their value date — borrowers who pay on the due date are never marked late while ACH settles.
NACHA return automation
R01 smart retry within network limits; hard returns auto-invalidate the instrument and open a case instead of silently re-dialing a dead account.
Autopay with Reg E-aware notices
Recurring debits with the notice obligations handled as part of the flow, not a separate checklist.
Reg Z APR engine
Actuarial APR computation with two-axis charge classification, statements, and payoff quotes.
API-first throughout
Everything the UI does, the API does. Integrations and AI agents use the same governed surface as the workspace.
Products & asset classes
New products are configuration, not code
A loan product on the core is a catalog entry: schedule, charges, APR treatment, bureau posture, portal behavior. Launching the next one is a configuration exercise — not an engineering roadmap — and every product belongs to a product class the rest of the platform respects.
Consumer installment
Fixed and variable schedules, fees, hardship and modification mechanics — with consumer protections applied because the product class says so, not because someone remembered.
BNPL
Pay-in-4 and longer split-pay plans defined in the product catalog: payment cadence, charge treatment, and bureau reporting posture set per product.
Merchant advance
Commercial products live in their own product class, so merchant-advance rules and consumer rules never silently cross — a boundary the compliance engine enforces.
Product classes are not labels — they are boundaries. The compliance engine knows which class every obligation belongs to and applies the right rule book, so a consumer protection is never skipped and a commercial rule never leaks.
Borrower self-service
A portal that deflects calls instead of creating them
Most servicing contact volume is borrowers asking questions software should answer. The white-labeled borrower portal puts payments, statements, autopay, and documents one login away — backed by the same ledger your team works from.
- Make a payment, set up autopay, or get a payoff quote — figures rendered from the same ledger your team sees
- Pull statements and documents on demand instead of calling for them
- Exchange documents over secure, expiring links — feeding the same review queues your team works
- White-labeled to your brand, on the same deny-by-default API every other surface uses
One ledger, every surface: the balance a borrower sees in the portal, the figure an agent quotes on a call, and the amount an AI agent puts in a message all come from the same ledger facts — so self-service never creates a dispute about whose number is right.
Books & bureaus
The ledger your accountants and the bureaus both trust
Two obligations most lending systems treat as exports, handled in the core itself.
Integrated accounting & GL
Every loan event — disbursement, payment, fee, reversal, write-off — posts to the general ledger automatically, under your chart of accounts, at the moment it happens. There is no nightly export to reconcile and no spreadsheet bridging the servicing system and the books. Month-end is a review of postings that already exist, not a reconstruction.
Credit bureau reporting (Metro 2)
Metro 2 furnishment is built into the core and driven by the same ledger facts borrowers see — balances, statuses, and dates from one source of truth. What you report matches what is true, value dating keeps on-time payers from being furnished as late, and disputes trace back to the facts that produced the tradeline.
Payments done right
The payment mechanics that make or break borrower trust
Most borrower complaints are not about the loan — they are about a payment handled badly. The core treats payment edge cases as first-class machinery, not exception reports.
Value dating, in plain language
A payment counts from the day the borrower made it, not the day the money finished settling. A borrower who pays on the due date is never marked late — and never charged a late fee — while ACH catches up.
NACHA returns, automated
Insufficient-funds returns (R01) retry smartly within network limits. Hard returns — closed or invalid accounts — invalidate the instrument and open a case for a human, instead of silently re-dialing a dead account.
Autopay with Reg E in the flow
Recurring debits carry their notice obligations with them — varying-amount and timing notices are produced as part of the payment flow, not tracked on a side checklist.
Reg Z APR, for the technical reader
An actuarial APR engine with two-axis charge classification — by charge type and by who it is paid to — driving disclosures, periodic statements, and payoff quotes from one computation.
Prefer to keep the core you have?
The lending core is optional. The servicing control plane binds to any system of record through a clean fact/action contract — so you can adopt the servicing layer and AI workforce today, and decide about the core on your own schedule.
How bring-your-own-core worksPart of the LendEasy platform
One core, three layers above it
The lending core is one of four products on the platform. Above it: the control plane that governs every action, the workspace where work happens, and the AI agents that share both.
FAQ
Questions lenders ask about the core
Yes. It is a complete LMS and system of record: configurable loan products, disbursement and repayment schedules, value-dated payment processing, fee and charge handling, integrated accounting with automatic GL posting, Metro 2 credit bureau furnishment, a borrower self-service portal, and a Reg Z APR engine with statements and payoff quotes. It runs standalone, or as the foundation under the servicing control plane and workspace.
Bring the product you want to launch next
Walk through the lending core with the people who built it — configure a product live, trace a payment from value date to GL posting, and see what your bureau file looks like.