LMS - loan system of record

A loan outlives
the model that approved it.

Every borrower, application, offer, payout and repayment lives here. What does not live here is the scoring. That sits in Arin, so your models can keep changing without anyone rewriting your loan book.

A desk with financial documents and a calculator under warm lightLending
Every borrower, offer and repayment on one record.

What LMS owns

Everything a loan has to remember.

Lending was the one record we did not have yet, alongside procurement, retail, warehousing, assets and health. Everything below is logged, and sending the same request twice gives you the same answer rather than a second loan.

Origination

Lenders, products, borrowers

Lenders, loan products, borrowers and the applications filed against them. Every change is logged, and a retry never creates a second loan.

Consent

A consent ledger, not a flag

Consent given and consent withdrawn are both added as lines. You can see where it stands now and how it got there.

Decision

The decision as a record

The decision is saved against the application along with the reasoning, plus every earlier decision.

Offer

Offers and disclosure

The offer is recorded. So is the fact that you showed the borrower the terms.

Disbursal

Funding and schedule

Recording the payout builds the repayment schedule and marks the loan as funded, in one step.

Servicing

Payments and delinquency

Payments against the schedule, with paid, remaining and overdue already worked out.

Why the split

A loan needs two different things at once.

It needs records that last for decades. It also needs decisions that change every month. Put both in one system and one of them suffers. Either the record gets frozen to protect the models, or the models get held back to protect the record.

LMSowns The record

It has to be correct, it has to keep its history, and it has to last for decades. A loan outlives the model that approved it, so the record cannot depend on that model.

Arinowns The decision

Eligibility, affordability, risk, ranking and arrears all change constantly. They belong somewhere built to keep changing.

So we split them. Lending gets a record that lasts. Decisioning gets to keep improving. Neither one holds the other back.

The loan lifecycle

Each step is a record, not a status.

Recording the payout is what builds the repayment schedule and marks the loan as funded. One step, instead of three systems agreeing about it later. Each stage also raises an event, so Arin hears about changes from the record itself.

01

Applied

Borrower, consent, application

02

Decided

Arin's DecisionRecord

03

Offered

Terms disclosed and recorded

04

Disbursed

Funding lays out the schedule

05

Serviced

Payments, standing, closure

The decision as a record

The why survives the model.

When Arin decides, the decision is saved against the application: the eligibility, the scores and the reasoning behind it, plus every earlier decision. Models are meant to change. The reason you approved a loan last year is not.
  • A rejection notice is its own recorded event, not something inferred later
  • Approve, reject and withdraw are each explicit steps, each logged
  • The offer is recorded, and so is showing the borrower its terms
A quiet office interior with desks and natural lightDecision
The rationale kept with the application.

Consent and compliance

“On what basis was this loan granted?”

That is what an examiner asks, years later, about one specific loan. It is also the hardest thing to answer once your decisioning has moved on three versions. Here, the answer never depends on that model still existing.

One file per application

An examiner asks about one loan. So there is one place that pulls together its consents, disclosures, decisions and audit trail.

Reconstructable from LMS alone

Who agreed to what, when, and why the loan was approved. All answerable from here, even if the model that decided it is long gone.

Consent is a ledger

Nothing is overwritten. A consent that was later withdrawn still shows that it was given, and when.

Disclosure is evidenced

Showing the borrower the terms is its own recorded event. That is the difference between believing they were told and proving it.

Servicing

A schedule that knows what is overdue.

The schedule comes back with paid, remaining and overdue already worked out, so nobody starts the day reconciling. Payments go against it, and a loan's standing is whatever Arin advised. Recorded here, acted on by people.
  • Arrears is advice we record, not a verdict we reach
  • Every change is logged, and a repeated request never double-counts
  • Agent tools use the same services your own screens do. One set of rules
Filed paper records stacked in an archiveServicing
Paid, remaining and overdue, already resolved.

LMS in the lending stack

Where the decision lives.

LMS is a loan record with the decisioning kept outside it. It is not a scoring engine, not a sign-in system, not a billing platform and not an investment product.

LMSLoan origination suitesCore lending platforms
What it isThe loan system of record, with decisioning deliberately outside itOrigination workflow with a rules engine insideA broad lending platform owning records and decisions together
Where decisions liveIn Arin - so models can change without migrating the loan bookIn an embedded rule DSL, versioned with the applicationInside the platform, on its release cycle
Why survives the modelEach application carries the decision record that justified itUsually a rule version reference, if retainedVaries; often reconstructed from logs
Examiner's questionAnswered from LMS alone - one compliance file per applicationAssembled across origination and servicing systemsAnswered from the platform, if the history was kept
Agent surfaceScope-gated MCP tools calling the same services REST doesAPI and webhook integrationsVendor integration framework

LMS walkthrough

See the loan record, end to end.

Tell us how your lending stack handles records and decisions today. We will show you what it looks like with the two kept apart.