Loan Servicing Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the payment engine get scoped as the small part of the job?

Ask ten private lenders what they want from a servicing platform and nine will describe screens: a portfolio dashboard, an investor portal, a borrower payment page. The engine underneath, the thing that decides what a balance is on any given day, gets one line in the requirements document. Then the build starts and the truth arrives. Your notes are not one product. You have interest only bridge paper on actual/360, a construction facility accruing on drawn balance rather than face amount, a note whose default rate steps from 11 percent to 18 percent on day 11 of delinquency, two loans carrying prepaid interest reserves, and older paper with a waterfall where late fees are satisfied before interest.

Each of those is a rule, and the rules combine. A default interest period inside a month where a partial payment arrives and the waterfall pays fees first is not three features. It is one behaviour that has to be correct in every order those events can occur. Quotes go wrong here because a developer who has not built lending software prices the screens and treats accrual as arithmetic.

The fix is unglamorous and it works. Before anybody quotes, write out a term grid: every note structure you currently service, its day count convention, its accrual base, its fee schedule, its default trigger and its waterfall order. Ten rows is normal for a lender at $100 million, and that grid is the real specification. Then insist the engine reads it as configuration per note rather than as code, and that acceptance means replaying your twenty most awkward historical loans against balances you already believe.

What goes wrong when years of spreadsheet history are migrated?

Migration is the most underestimated line in a loan servicing project and in Digital Heroes delivery experience it consumes 15 to 20 percent of the budget. The reason is that a spreadsheet is not a transaction log. It is a set of balances with formulas attached, and an event sourced ledger needs the events. Somebody has to reconstruct, per loan, every accrual, payment, fee, reversal and adjustment that produced the number you believe today.

What surfaces during that reconstruction is the uncomfortable part. Payments applied to principal that should have gone to interest. Per diem computed on a 365 day year for a note written actual/360. An extension fee charged twice on one loan and never on another. Late fees waived by a phone call nobody recorded. On a book of any size some of these exist, and once the ledger exposes them you have a decision to make with counsel about which get corrected with the borrower or the investor and which are absorbed.

The workable pattern is a cutover date. History before that date is imported as an opening balance transaction per loan with the supporting workbook attached as evidence, rather than fabricated in detail you cannot defend. History after it is rebuilt event by event and reconciled to the penny against your existing numbers, loan by loan, with every variance entered in an exceptions register that has a named owner and a resolution. Expect that register to be longer than you planned, and expect the parallel run to last a full month end rather than a week.

Why do ACH, bank files and the accounting sync break after launch?

Because the happy path is what gets built and the return path is what gets tested in production. Pulling a payment is easy. What is hard is the day fourteen borrowers are drawn, three come back as insufficient funds, one comes back as an account closed, and one is a reversal on a payment posted eleven days ago that has already appeared on an investor distribution.

Each of those needs its own behaviour: reverse the posting, restore the prior balance, decide whether a late fee now applies under this note's grace period, notify the servicing team, and correct the investor position without silently rewriting a statement that has already gone out. Handle returns as an afterthought and the ledger and the bank drift inside the first month, at which point nobody trusts either.

The same weakness appears in the accounting sync. A retry after a timeout posts the journal entry twice, and your controller finds it at quarter end. Insist on three things in the first release rather than the second. Return handling for the specific codes your bank actually sends, tested against a file your bank has accepted. Idempotency on every posted transaction, so one event cannot post twice regardless of retries. And a reconciliation view that lists unmatched bank items as exceptions instead of swallowing them. Then run one complete month end alongside your current process before you switch the spreadsheet off.

What happens when fractional investor accounting is treated as a reporting feature?

Investor participations are not a report. They are a second ledger sitting on top of the first, and projects go wrong when they discover this in month five. A $2 million loan split among six investors at uneven percentages produces six positions, each accruing, each receiving a share of every payment net of your servicing retention, and any of which can transfer mid month.

If distributions are computed by a month end report that reads the loan ledger, the report and the ledger separate the first time anything unusual happens: a reversal, a holdback, a position sold on the fifteenth, a fee borne by one investor and not the others. Now your statements and your books disagree, and the only person who could explain the difference is the analyst who wrote the workbook and left.

Build the participation ledger as a first class object. Positions per loan tracked to the cent with effective dates, distribution runs that post as transactions rather than compute inside a report, and statements generated from what was actually posted. That is also what gives you the branded portal where investors see their positions, pull monthly statements and download year end summaries in a format their accountant accepts, which is the difference between an analyst spending most of each month on distributions and spending it on the next raise.

Should you build custom or configure what you already own?

Some readers should stop here and go configure The Mortgage Office. If you service under roughly 100 loans, the capital is your own balance sheet, and your notes are conventional interest only or amortising paper, it is a mature product that does this job properly, and Bryt Software is a reasonable alternative at similar scale. Outsourcing to a third party servicer such as FCI Lender Services is cheaper again if you would rather not own the operation at all. Building at that size means you now own software instead of loans, which is the wrong asset for a lender that small.

LoanPro deserves the same fairness at the other end. It is a configurable servicing core built for volume, and if your product fits its model and you have the loan count to justify the pricing, it is a credible answer that will beat a build on time to value.

Building earns its place when at least two of these are true. You service outside investor capital across fractional positions. Your credit committee routinely approves terms that end up in a side spreadsheet because the system cannot express them. Servicing headcount is growing faster than the portfolio. Per loan or per module fees are compounding against your margin. Or the investor experience is part of how you raise capital, in which case a vendor branded portal is a commercial problem rather than a preference.

How do hidden costs get into the quote?

Four ways, and all of them are visible in advance if you ask the right question.

• Migration priced as data loading. If the proposal carries a line called data migration with a small number beside it, the developer intends to import balances. Reconstructing and reconciling history is a workstream, not a task.
• Payment integration priced as an API connection. Going live with a processor, or generating files your bank will accept, runs on the bank's calendar, involves test files, and includes a period where returns behave differently from the sandbox. Those weeks are not yours to control.
• Each additional note structure. The eleventh row on your term grid is not 10 percent more work than ten rows, but it is not free either, and a fixed price quote written against a partial grid becomes a change order in month three.
• Obligations discovered late. If you ever report to credit bureaus, Metro 2 formatting is exacting and is not a weekend of work. State lender licensing, usury limits and data security for borrower and investor personal information are your counsel's call, but the software has to encode whatever they decide.

There is also the cost nobody writes down: the parallel run, where your team operates two systems through a month end. Budget the overtime. Then plan on 15 to 20 percent of the build cost per year afterwards for hosting, monitoring, patching and small changes, which for platforms in this category typically lands between $15,000 and $60,000 annually.

What separates a build that works from one that fails here?

The teams that succeed share a small number of habits, and every one of them is testable before you sign anything.

They model the ledger as immutable transactions with balances derived from history, and they say so on the whiteboard without being prompted. A design containing a loans table with a current balance column that gets updated in place cannot survive a backdated payment, a reversal or an audit, and no amount of later effort rescues it.

They raise day count conventions before you do. On a $50 million book the difference between actual/360 and actual/365 is real money accruing quietly in one direction, and a team that has shipped lending software treats it as the first question rather than a detail for later.

They can name the payment processors they have taken live, describe exactly how they handled returns, and explain how they ran a penny level reconciliation during a spreadsheet migration. They put ownership of the code and the infrastructure accounts in writing before kickoff, in a repository you control, because a servicing system you rent recreates the lock in you are trying to escape.

And they ship a first release that services real loans in parallel inside 12 to 16 weeks rather than a complete platform in a year. That is not speed for its own sake. The exceptions in your own book, the ones nobody remembered to mention, only surface when the engine meets them, and you want that happening while the team is still building rather than after they have moved on.