CMBS Loan Servicing Software Problems: The 7 That Break Your Reporting Month

Why does the covenant engine end up as a dropdown?

Because it is what a reasonable developer builds after reading three loan agreements and noticing that they all compute something called a debt service coverage ratio. The similarity is real at the level of the name and disappears at the level of the arithmetic. Read ten agreements and you find ten combinations of numerator components, deductions with their own rules, whether debt service is actual or a stated constant, the period basis, the test frequency, the threshold, the cure rights, and how many consecutive periods must fail before a trigger springs.

The failure is discovered late, which is what makes it expensive. The engine handles the first several loans boarded during the build, because they were the ones used to design it. Then boarding moves into the wider portfolio and the exceptions arrive in a rush: the loan with a seasonality carve out, the one measuring occupancy against a named anchor tenant with a going dark clause, the one whose debt yield definition deducts something no other loan deducts. Each exception either forces an engine change or gets waved through into a workbook, and once one loan is back in Excel the discipline is gone.

What works is a per loan definition object captured at boarding: components, deductions, denominator treatment, period basis, frequency, threshold, cure terms and consecutive period requirement, reviewed against the document by someone who read it. The engine then executes definitions rather than implementing methods. Test the design before signing by handing a prospective developer your three most awkward loan agreements and asking them to express the tests. If they reach for a configuration screen, they have not read a loan agreement.

What goes wrong when the loan documents have never been abstracted?

This is the schedule risk that sinks more commercial servicing projects than any engineering problem, and it is not a software task. If your covenant definitions, reserve conditions, trigger terms, cure rights and allocation mechanics have only ever lived in the documents and in an asset manager's head, somebody now has to read several hundred loan agreements and turn them into structured definitions. That is a legal and asset management workstream, it needs people who can interpret a clause, and it runs on its own calendar.

The failure pattern is predictable. Abstraction is assumed to be part of the build, the developer assumes the client will supply the definitions, the client assumes the developer will extract them, and both discover the gap at the point where boarding was supposed to begin. Meanwhile the portfolio keeps reporting monthly, so the people who would do the abstraction are the same people producing the package.

Sequence it deliberately. Start abstraction in week one, in parallel, staffed separately from the reporting cycle. Prioritise by exposure rather than alphabetically, so the largest loans and the ones nearest a trigger get done first. Accept a partial boarding model where a loan can exist with payments and property data before its covenant definition is complete, flagged as unabstracted, so the system reflects reality instead of pretending. Portfolios that already maintain abstracts move noticeably faster, and portfolios that do not should treat the abstraction cost as a line in the project budget rather than as a surprise.

Why do the servicing extract and document pipelines break after launch?

Two integrations carry this category and they fail differently. The first is the extract from your system of record, usually McCracken STRATEGY or SS&C Precision LM. It rarely breaks outright. It breaks on timing and on edge cases: an overnight extract that arrives after your determination date cut-off, a reversal or correcting entry posted in a prior period that your layer already reported on, a loan modification that restates a payment history you had treated as settled. Because the totals still look plausible, these surface as a reconciliation difference nobody can explain rather than as an error.

Design for it explicitly. Reconcile the extract against control totals on every run and refuse to proceed when they disagree. Treat prior period adjustments as first class events with their own restatement handling rather than as silent overwrites. And know, in advance, how frequently you can actually read the system of record, because a monthly deadline built on a nightly extract has a very different shape from one built on a weekly file.

The second is borrower document intake. Rent rolls arrive with merged cells and a totals row in the middle. Operating statements arrive as owner spreadsheets with bespoke charts of accounts, property manager exports, and scans. Extraction handles this well with a human review step and badly without one. The failure after launch is not the model getting a number wrong, it is a borrower changing their reporting format between quarters and nobody noticing that the mapping now sends a line to the wrong account. Monitor mapping stability per borrower, not just extraction confidence, and flag the quarter where a chart of accounts changed shape.

What happens when advancing, appraisal reduction and attestation evidence are missing?

Master servicers carry advancing obligations with recoverability determinations, and appraisal reduction events change advancing. Builds that model the reporting package but not the advancing lifecycle leave the hardest judgement in the process outside the system, which means the evidence for it also sits outside the system. When a recoverability determination is later questioned, the file consists of an email thread and a spreadsheet.

The wider version of this problem is the attestation regime. Reg AB servicing criteria attestation examines your process, and a process whose only control is a careful individual is difficult to attest to honestly. Many builds produce a generated package and stop there, without asking whether the package can be reproduced from stored inputs six months later, which is the question your accountants will actually ask.

Build reproducibility in from the start, because retrofitting an audit trail costs several times as much as designing one. Every generated package should be regenerable from the exact inputs used, with a record of who confirmed which normalisation decision and which values produced each computed test. Validation rules should run before submission rather than after, so a failing package cannot leave the building. Advancing decisions should be workflow objects with the determination, the reasoning and the supporting valuation attached. The same records that satisfy an attestation are the ones that make a transfer to special servicing survivable.

Should you build custom or stay on STRATEGY and workbooks?

If you hold a few hundred straightforward whole loans on your own balance sheet with no securitised reporting obligation, do not build. A servicing system, disciplined workbooks and a competent analyst are genuinely enough, and a platform would be an expensive way to organise a manageable problem. Spend the money on document abstraction instead, because structured loan abstracts help you whatever software you use and they outlive any system.

McCracken STRATEGY earns its position as the system of record for payments, escrow administration, investor accounting and the general ledger, and replacing it is not a sensible first move for anyone. SS&C Precision LM covers similar ground with different strengths on loan accounting. Backshop is genuinely good at origination and asset management workflow, particularly for debt funds and life companies underwriting their own paper. If your gap is workflow rather than deal specific arithmetic, one of these may close it without a build.

Build the layer beside them when two or more of these hold. Your covenant math lives in a workbook per deal and one person can explain it. You report into multiple trusts, or you are a master servicer with sub servicers feeding you. Borrower financial normalisation consumes weeks of analyst time each quarter and still runs late. You hold whole loans split across securitisations and allocate them in Excel. Or your package production cannot survive attestation without a heroic individual, which is a control weakness dressed as a good employee.

How do hidden costs get into the quote?

Four items account for most of the difference between the estimate and the outcome.

• Loan document variety. A book of similar bank originated loans is far cheaper to model than a conduit book assembled from many originators. Loan count is a poor proxy for cost. Ask for the estimate to be stated against document variety instead.
• Trust and template count. Each trust you report into carries its own package and its own quirks, and the allocation logic between pari passu notes has to be modelled from the deal documents rather than assumed.
• Servicer role. Special servicing adds an entire workflow around transfers, appraisals, modifications and resolution. If there is any prospect of taking loans into special servicing, say so at scoping rather than discovering it during a transfer.
• Document abstraction. Covered above and worth repeating, because it is the item most often left out of both sides of the plan and it is the one that determines the schedule.

A borrower portal and investor distribution are worth having and belong in a later phase. They are visible, they demonstrate well, and they do not reduce the work in your reporting month, which is where the return is.

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

The builds that work draw the data model correctly on the first whiteboard: property, then loan, then note, then trust, with the whole loan modelled once and each note carrying its share and its trust relationship. Allocations of principal, interest, fees and advances then compute from shared cash events, and a corrected rent roll fixes every trust package at once. Builds that model loans and payments, in the shape of consumer lending software, cannot represent a pari passu split at all and discover this after the first large loan is boarded.

They also keep the human in the normalisation loop and make the human faster rather than removing them. The analyst confirms the mapping from the borrower's chart of accounts to your standard chart, because that decision drives the covenant result and the reported net operating income, and no analyst should sign a number they did not see derived. The gain is moving from typing to reviewing, which is what makes a quarterly cycle fit inside the quarter.

The builds that fail promise a covenant configuration screen, assume abstraction is someone else's job, and treat the audit trail as a phase two item. Settle ownership before kickoff, in writing: the repository, the infrastructure accounts and the structured loan abstracts. At Digital Heroes the client owns all of it from the first commit. The abstracts are arguably worth more than the code, because they represent the work of reading every loan document, and they should never sit in accounts you do not control.