Why Every Lender's Portfolio Analytics Lives in Excel
The LMS data trap — why portfolio managers, CROs and CFOs end up rebuilding loan data in Excel, and the five RFP questions that surface it before signing.
“All analysis has to be done in other applications. The ability to build custom reports inside the platform would be beneficial.”
— G2 reviewer, a cloud-native global Loan Management System.
That single sentence, written by a customer of one of the most-deployed cloud Loan Management Systems in the world, is the most honest description of the lending technology reporting problem on the public internet. It is also the reason every lender’s portfolio analytics, credit risk monitoring, and finance pack ultimately gets rebuilt in Excel.
This is not a story about analysts who prefer spreadsheets. It is a story about Loan Management Systems and Loan Origination Systems whose data layers were built for transaction processing, not for the questions a portfolio manager, a CRO, or a CFO actually needs answered about a loan book.
- The reporting complaint is architectural, not vendor-specific. Nine different LMS and LOS surfaces, the same line: the analysis happens somewhere else.
- The data model was built for the transaction, not for the question. Tables are normalised for the loan event; history is overwritten in place when a modification or status reversal lands.
- Reporting weakness is a pricing model. Every report the platform does not produce by default becomes a paid engagement, a custom build, or an exfiltration project.
- The shadow stack in Excel is a risk-register entry. It breaks data lineage, forecloses the AI agenda, and makes the next platform migration harder than it had to be.
- The data layer belongs in section one of the RFP. Five contractual asks that flush out the trap before signing — listed below.
Why does the same reporting complaint surface across every LMS and LOS vendor?
The vendors differ. The complaint does not.
“The way data is structured is convoluted and opaque… When modifying a loan, the table loan_reverse_status_archive erases the past, which is problematic for accounting.”
— Capterra reviewer, a consumer-loan servicing platform.
That second clause matters more than the first. A servicing platform that overwrites its own history mid-modification is not a reporting weakness. It is an audit problem dressed as a reporting weakness.
On a leading US consumer-lending LOS, the limitation is configuration, not corruption. A Capterra reviewer notes: “The LOS is not very customizable, and it would be great if users could rename fields and make certain fields required/not required without the assistance of [vendor] Support.” (Capterra). A separate reviewer summarises the philosophy: “Everything has to be done the way [the platform] wants it to be done as opposed to creating a custom experience/approach that fits your organization’s needs.” (Capterra). A lender that cannot rename a field cannot model its own product taxonomy in its own LOS. The portfolio cuts that follow will not align with how the business actually thinks about its book.
The same complaint shows up on an India-headquartered lending platform — “minimal set of standard reports, accounting module is very limited, and no support for taxation, budgeting and other advance needs” (Capterra) — and on a US loan-servicing platform: “Generating reports within [the platform] can be a tedious process requiring manual intervention, which consumes valuable time and increases the likelihood of errors” (Capterra).
A G2 reviewer of a major US digital banking platform names the commercial structure that makes the pattern durable:
“If an organization is automation/development heavy, every single report will cost money, access to their own data will cost money, and customizations will cost money.”
— G2 reviewer, a major US digital banking platform.
That last quote is the through-line. Reporting weakness on a Loan Management System is rarely a roadmap oversight. It is a pricing model. Every report the platform does not produce by default becomes a paid engagement, a custom build, or an exfiltration project. The lender absorbs the cost as analyst time, vendor invoices, and risk findings.
Why was the data layer built this way?
LOS and LMS platforms historically optimised for one thing: processing a loan application, originating the loan, and servicing the schedule. The schema reflects that. Tables are normalised for the transaction, not for the question. Fields are named for the vendor’s product configuration, not for the lender’s reporting taxonomy. History is overwritten in place when a modification, a re-amortisation, or a status reversal happens, because that is cheaper at the transactional layer than maintaining a temporal model.
An industry analyst captures the consequence: “Legacy LOS lock-in often means data is stored in proprietary formats or tightly bound schemas, and access requires custom reports or vendor involvement.” (Citeables). The lender owns the loans. The vendor owns the shape of the data about the loans. The price of bridging the two is paid every quarter, in analyst hours.
The downstream cores compound the trap. A G2 reviewer of a tier-1 global banking core reports: “[The core] doesn’t support large data reports, and fund transfer history data is not visible; it captures only 1 year of data in the core application.” (G2). A one-year retention window inside the source-of-truth system is not a reporting deficiency. It is a structural denial of long-horizon portfolio analysis.
And when a lender does try to move off, the data follows reluctantly. An open-source LMS upgrade discussion repeats the pattern: after upgrading from one generation to the next, users were unable to access any reports, though they could access them when downgrading to the previous version (Mifos users mailing list). Even an open-source LMS migration breaks the reporting layer.
What gets rebuilt in Excel — and why is that a risk-register entry?
Every lender we have looked at runs some version of the same shadow stack. Loan-level extracts pulled overnight into a finance team’s shared drive. A portfolio analyst’s macro that joins servicing data to a separate disbursement file. A risk function maintaining its own expected-credit-loss workbook because the LMS cannot expose the right vintage cohorts. A regulatory reporting cell rebuilding HMDA, CIBIL, RBI CIMS, or FCA returns from manual exports because the in-platform report comes back inconsistent.
That shadow stack is operational debt with three downstream consequences.
- Broken data lineage. A regulator asking how a number was produced — under BCBS 239, under IFRS 9 ECL, under RBI’s data-governance directions, under FCA Consumer Duty — needs an answer that traces back to a system of record. A spreadsheet transformed three times by three analysts is not that answer.
- A foreclosed AI agenda. Pricing, default prediction, collections prioritisation, fraud detection, next-best-action — every one of these models needs clean, joined, governed, temporal data over the full loan lifecycle. An LMS that overwrites history in place cannot supply it. A platform whose reports live in a vendor-licensed module cannot supply it.
- A harder next migration. Every spreadsheet workaround built around a missing LMS report is a hidden contract that the replacement platform will be measured against. The shadow stack becomes the de facto requirements document — and almost nobody documents it.
How does the LMS data trap become the AI ceiling?
Every CDO and CIO is being asked to deploy machine learning over the loan book. Pricing models that adjust to bureau and alt-data signals in real time. Default-prediction models that catch deterioration two payments earlier than a static scorecard. Collections-prioritisation models that route the right ticket to the right channel on the right day. Fraud-detection models that catch a pattern across applications no human reviewer would see.
Every one of those workloads needs the same thing underneath: clean, joined, governed, temporal data over the full loan lifecycle.
The ceiling sits one layer below model selection. It sits in the data layer. An LMS that overwrites history in a loan_reverse_status_archive table cannot supply temporal data. A platform whose reports live behind a vendor-licensed module cannot supply governed data. A schema the lender cannot extend without a vendor SOW cannot supply data shaped to the question.
The data trap is the AI ceiling. Lenders evaluating an AI vendor whose first slide is the model architecture are debating the wrong layer.
What should lenders ask before signing the next LOS or LMS contract?
A procurement team writing an RFP on a Loan Management System or a Loan Origination System should treat the data layer as a first-class evaluation criterion, not a footnote under “reporting.” Five contractual asks that flush out the trap before signing:
Can the lender export every loan-level field — including custom fields, audit timestamps, and modification history — to a warehouse the lender owns, on a schedule the lender controls, without a per-report fee? Ask for a real export running against a non-trivial portfolio, not a demo dataset.
Does the platform maintain a temporal data model, or does it overwrite history in place when a status, an amortisation schedule, or a co-lending allocation changes? Require the vendor to demonstrate a status reversal and show the audit trail that survived it.
Can a lender’s own administrator rename a field, add a custom attribute, and have it flow through the data export and the in-platform reports — without a vendor SOW? The “rename fields without [vendor] Support” reviewer complaint is the test case.
What is the documented schema of the data exposed to the lender’s warehouse, who owns it, and what happens to it on contract termination? The exit clause is the data clause’s evil twin — the lender’s negotiating leverage is highest on the way out, and that is exactly when the vendor’s data model can punish them.
What is the per-report, per-API-call, and per-customisation cost model? The reviewer quoted above named the failure mode. The contract clause to look for is whether report generation, data access, and minor schema additions are inside or outside the standard fee.
These questions belong in section one of the RFP, not the appendix. The portfolio analytics function lives or dies on the answers.
Takeaway
Every lender’s portfolio team has become Excel-fluent because the Loan Management System was built to process loans, not to explain them — and every vendor’s pricing model rewards keeping it that way.
Frequently asked questions
Why does every lender’s portfolio analytics end up in Excel?
Because the data layer of every major Loan Management System and Loan Origination System was designed for transaction processing, not for the questions a portfolio manager, a CRO, or a CFO asks of a loan book. Tables are normalised for the loan event, fields are named for the vendor’s product configuration, and history is overwritten in place when a status changes or an amortisation is rerun. The portfolio team rebuilds the data in Excel because the platform cannot answer the question — and because every report the platform does not produce by default becomes a billable engagement.
What is the LMS data trap, and how does it become the AI ceiling?
The LMS data trap is a structural design choice: the lender owns the loans, the vendor owns the shape of the data about the loans, and the price of bridging the two is paid every quarter in analyst hours. The ceiling for AI sits one layer below model selection — every machine-learning workload over the loan book (pricing, default prediction, collections prioritisation, fraud detection) needs clean, joined, governed, temporal data over the full loan lifecycle. A platform that overwrites history mid-modification cannot supply that. The data trap forecloses the AI agenda before the model is even chosen.
What should a lender ask about the data layer in an LOS or LMS RFP?
Five contractual asks. (1) Can the lender export every loan-level field — custom fields, audit timestamps, and modification history — to a warehouse the lender owns, on a schedule the lender controls, without a per-report fee? (2) Does the platform maintain a temporal data model, or does it overwrite history in place when a status, schedule, or co-lending allocation changes? (3) Can a lender’s own administrator rename a field and have it flow through exports and reports without a vendor SOW? (4) What is the documented schema of the data exposed to the warehouse, who owns it, and what happens to it on contract termination? (5) What is the per-report, per-API-call, and per-customisation cost model in writing?
Why does an LMS that overwrites history mid-modification fail BCBS 239 and IFRS 9 audits?
BCBS 239, IFRS 9 ECL, RBI’s data-governance directions, and FCA Consumer Duty all require that a regulator can trace any reported number back to a system of record with a complete, non-destructive audit trail. An LMS that overwrites a loan modification’s previous state — or that retains only one year of fund-transfer history inside the source-of-truth system — cannot supply that trace. A spreadsheet that has been transformed three times by three analysts cannot supply it either. The audit fails not because the analyst made an error but because the platform’s data model did.
Read next:
- 100 LMS Reviews — The Same Six Complaints Recur — the broader pattern. Six lines surface across every LMS and LOS vendor; the data-layer complaint is one of them.
- The Customization Trap: When LMS Vendors Bill Every Change — the sibling commercial trap. Every “small change” funnels through a billable vendor project, for the same reason every report does.
- The 30-Call Limit: Why Your LOS API Quietly Caps Your Lending Velocity — the data trap’s architectural cousin. API rate limits are commercial controls dressed as infrastructure; so is the reporting layer.
- The LMS RFP toolkit — the vendor-neutral kit for putting the five data-layer questions into a running RFP, alongside a checklist, scorecard, and security questionnaire.
Sources:
- G2 — a cloud-native global Loan Management System reviews
- Capterra — a consumer-loan servicing platform reviews
- Capterra — a consumer-lending LOS reviews
- Capterra — an India-headquartered lending platform reviews
- Capterra — a US loan-servicing platform reviews
- G2 — a major US digital banking platform reviews
- Citeables — vendor lock-in and legacy LOS data formats
- G2 — a tier-1 global banking core reviews
- Mifos users mailing list — open-source LMS upgrade reporting friction
Ashok Auty is the co-founder of Lokta and co-creator of Apache Fineract. He has spent two decades building lending infrastructure — and reads every vendor’s public review record, because the data-layer complaint surfaces on every one of them, regardless of the brand on the box.
