Loan Covenant Monitoring Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the covenant module get scoped as a picklist and then need rebuilding?

Because the demonstration looks right. Every credit platform shows a library: leverage ratio, fixed charge coverage, debt service coverage, tangible net worth. You choose one, enter a threshold and a test frequency, and the system tests it. Nobody in the room disagrees, because everyone is thinking about the covenants they can name rather than the agreements they have actually signed.

Then implementation starts and someone opens the top twenty credit files. Adjusted EBITDA in the sponsor backed deal adds back restructuring charges up to a cap, excludes an unconsolidated joint venture and includes pro forma effect of an acquisition. The deal next to it defines fixed charges to include owner distributions and the one after that does not. Two credits carry step down schedules. One has an equity cure right that retroactively fixes a breach if capital is injected inside a set window.

At that point the project has two bad options. Encode the negotiated definitions somewhere the system cannot see, which means a spreadsheet, and you have rebuilt the problem you were paying to remove. Or have a developer hand code each definition, which turns every new credit agreement into a change request and every amendment into a support ticket.

The fix is a week of reading before a line of code. Take your fifty largest exposures, open the definitions section of each agreement, and write out in plain language every add back, cap, exclusion, pro forma adjustment, equity cure and step down you find. That document is the specification. Then make anyone bidding show you, on screen, how a credit administrator authors one of those definitions as a formula over spread line items without engineering help. If they cannot, the scope is wrong, and week one is a much cheaper place to learn that than month five.

What goes wrong when you migrate spreads and covenant definitions out of the credit files?

The source data is in two awkward states. The covenant definitions are prose, sitting in Word documents and scanned PDFs in the loan file. The spreads are numbers in analyst workbooks built under conventions that were never written down. One analyst treated owner distributions as a fixed charge and another did not. Guarantor K-1 income was spread by whoever was free that week. Nothing catches the difference, because there was never a rule, only a habit.

The failure mode is importing that history exactly as it stands. You end up with a portfolio where a leverage ratio in one credit does not mean the same thing as the same ratio in another. The early warning reports then run on top of it, produce results credit officers know are wrong, and the system loses their trust inside a quarter. Trust in a credit system is spent once.

The fix is to rebuild the mapping rather than import the output. Build a chart of accounts crosswalk per borrower that persists between periods, then restate at least the last four periods under the new mapping so trend lines are comparable. Older history stays in the file as a document, clearly labelled as historic and not used in trend calculations. Document extraction genuinely helps here, since statements, tax returns and their standard schedules are structured enough to populate a draft spread, but treat the output as a draft an analyst corrects. The correction rate falls sharply for repeat borrowers once the crosswalk exists.

Budget the analyst hours explicitly and name the analysts. This is credit work, not engineering work, and quietly assuming the development team will absorb it is one of the most reliable ways to slip a schedule by six weeks.

Why do the core banking and borrowing base feeds break after launch?

The behavioural signals that make early warning worth having, meaning deposit balances, line utilisation, payment behaviour and overdraft activity, live in your core system rather than your credit file. Joining them is the point. The problem is that core extracts are usually built once, by whoever had time, as a nightly file with no monitoring around it.

Then the core is upgraded. A field is renamed, a file arrives empty, or the job silently fails. The watchlist keeps rendering, but on data that stopped moving five weeks ago. Nobody notices, because a watchlist that gets shorter looks like good news, and the first sign of trouble is a credit officer asking why a borrower who is clearly struggling has not appeared on it.

Borrowing base certificate ingestion fails the same way with a different trigger: the borrower changes their template and the ineligibility calculation silently reads the wrong column.

The fix is to make data freshness a visible fact rather than an assumption. Every derived signal carries the timestamp of the data it was computed from, and screens display it. A feed that has not delivered on schedule raises an operational alert to a named person, not an email nobody owns. Totals reconcile daily against a known core report so a partial file is caught rather than accepted. And whoever owns the integration should be on the distribution list for your core provider's release notes, which sounds obvious and is almost never arranged.

What happens when breach workflow, waiver expiry and the reporting tickler are left out?

These three get cut from scope more often than anything else, because they look like administration rather than analysis. They are where the money actually goes.

A breach is a legal event with a sequence attached: verification that the calculation is right, a decision on whether to send a reservation of rights letter to preserve remedies, a credit officer assessment, a waiver or amendment with pricing, a risk rating review, and often a change in accrual status that flows to regulatory reporting. Run that by email and there is no coherent record, which matters twice. When the credit deteriorates, your remedies depend on what you preserved. When an examiner asks how the bank responded to an identified weakness, a chain of forwarded messages is not an answer.

Waiver expiry is the quiet one. A covenant waived for two quarters, recorded as a note with no end date, stops being tested and never starts again. Nobody decides to abandon the protection. It simply stops existing, and the discovery usually happens during a workout.

The reporting tickler drifts for a different reason. Every credit carries obligations distinct from its covenants: audited statements, interim statements, borrowing base certificates, guarantor tax returns, insurance and compliance certificates. They are typed into a spreadsheet that was accurate on the day it was built, then a loan is modified, a guarantor released, a facility added, and the tab is not updated. Examiners test this reliably because it is the easiest thing in a credit file to check.

The fix is to generate obligations from the credit structure rather than typing them, so adding a facility creates its reporting requirements and releasing a guarantor removes theirs. Model the breach as a case carrying the calculation snapshot and the cited agreement section, with approvals at the authority level your policy requires and correspondence generated from your own templates. Give every waiver a mandatory expiry date and conditions, so the covenant returns to testing automatically. That single field prevents a category of loss that is otherwise invisible until it is expensive.

Should you build custom or configure what you already own?

A meaningful number of the lenders who ask us to build this should not. If your book is mostly your own standard paper with conventional covenants, under roughly 150 covenanted credits, and your growth plan does not change that, buy. Abrigo and Baker Hill NextGen are built for exactly that institution and carry regulatory alignment you would otherwise construct from scratch. Moody's Analytics CreditLens tracks covenants competently against standard definitions. If you already run nCino as your lending platform and your covenants are conventional, use what you are paying for before commissioning anything new.

There is also a version of this problem that is not a software problem at all. A surprising share of lenders own a covenant module they never configured, because the implementation ran out of budget after the loan origination workflow went live and the tickler was left for later. If your complaint is that alerts do not fire and obligations are not tracked, spend a week with your existing vendor's implementation team before you spend six figures. Being able to say you tried that is also the first question a sensible board will ask.

Build when the constraint is definitional. Covenants negotiated per deal that a picklist cannot express, borrowing groups spanning multiple entities and guarantors where global cash flow is the real analysis, behavioural early warning that requires joining credit data to core banking activity, or a private credit fund with limited partner reporting obligations that no bank product addresses. The clearest signal is a shadow spreadsheet maintained alongside a vendor system. That spreadsheet is your specification, and its existence is an admission that the packaged fit failed.

How do hidden costs get into the quote?

Five items account for most of the overrun in credit portfolio work, and four of them are invisible in a feature list.

• Spreading templates. Commercial and industrial, commercial real estate, agriculture and not for profit borrowers each need their own template and their own treatment rules. A quote scoped against one template and delivered against four is not a small variance.
• Core integration. Every core platform is different, and the work is in the reconciliation and monitoring rather than the first extract. Ask which specific core the developer has pulled utilisation and deposit behaviour from before, by name.
• Borrowing base certificates. Ineligibility rules are per deal, the arithmetic is unforgiving, and borrowers send their own formats. This is frequently priced as a screen and delivered as a subsystem.
• Global cash flow. A borrowing group with ten related entities and three guarantors is a materially harder model than a single operating company, and the difference is rarely reflected in the estimate.
• Everything a regulated lender needs around the software. Third party risk review, penetration testing, disaster recovery documentation, access reviews, and the parallel run itself. Two full testing cycles run in parallel with the old process is real cost and it is not optional.

What keeps the number down is narrowing the first release: your commercial and industrial book, one template family, and the covenant definitions from your fifty largest exposures. That population teaches the system almost everything it needs to know.

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

Credit administration owns the definitions, not the development team. If authoring a covenant requires a developer, the system will drift out of date the first quarter someone is busy, and the shadow spreadsheet will come back within a year.

The parallel run is treated as a deliverable rather than a formality. Two consecutive testing cycles, computed both ways, reconciled line by line, with every difference explained before the old process is retired. That is where you find out that a definition was encoded wrongly, and it is much cheaper to find it there than in a notice to a borrower.

One named person owns the tickler and the escalation ladder. Systems do not chase borrowers. People do, and the system makes the pattern visible so they chase the right ones.

And the ownership question is settled in writing before kickoff: the repository, the cloud accounts and the right to hire another firm. At Digital Heroes the client owns the code from the first commit, and for a regulated lender that also answers the vendor concentration question an examiner will eventually raise.