Why Project Finance UAT Passes But Covenant Monitoring Fails in Production

Project finance implementations have a specific failure pattern that appears in UAT sign-off and then resurfaces — badly — in production. The system passes every test case in the UAT register. DSCR is computed. The DSRA balance is shown. The waterfall runs. The UAT manager signs off. Six months after go-live, the bank's credit monitoring team raises a defect: covenant breaches are not triggering the downstream workflows they are supposed to, distributions are not locking up correctly, and the reserve account lifecycle is not behaving as the credit agreement specifies.

The reason is consistent: project finance UAT plans are almost always written by people who understand systems testing but have not worked through a complete loan lifecycle on a real infrastructure deal. They test the computation. They do not test the covenant as a trigger mechanism.

DSCR: One Computation, Five Downstream Behaviours

The most common project finance UAT gap involves DSCR testing. Teams confirm the computation: net operating income divided by debt service, checked against the threshold, displayed on the monitoring screen. One test case, one pass.

What a DSCR breach actually needs to trigger in a properly implemented system is not one outcome — it is a sequence:

• Breach notification — automated alert to the credit team and, depending on the agreement, to the borrower's agent
• Distribution lock-up — cash flow from the project waterfall must be blocked from reaching the equity distribution account
• Cure period activation — the system must open a defined window (typically 30–90 days) during which the borrower may remedy the breach
• Cure period monitoring — the system must track whether the cure condition is met at the next test date
• EoD escalation if uncured — an uncured breach at the end of the cure period must trigger an Event of Default workflow, which carries its own set of downstream actions

A UAT plan that tests DSCR computation and stops there has tested approximately 20% of what the bank needs to operate this covenant in production.

DSRA: Four States, One Test

The Debt Service Reserve Account is a structural feature of almost every project finance deal — a cash reserve maintained by the borrower to cover a defined number of months of debt service if project revenues fall short. It sounds straightforward. In practice, the DSRA has four distinct states that each require a different system behaviour, and UAT plans routinely test only the first.

The four DSRA states that need separate test coverage

• Establishment — the reserve is funded at financial close, at the required level, and the system reflects this correctly
• Maintenance — the balance is checked on each scheduled test date; if the balance has fallen below the required minimum, a top-up obligation triggers
• Draw — when project revenues are insufficient to cover a scheduled debt service payment, the DSRA is drawn upon; the system must process this draw, update the balance, and record the drawdown correctly
• Replenishment — after a draw, the borrower must replenish the DSRA within a defined period; the system must track this obligation and escalate if replenishment does not occur

Most UAT plans contain test cases for establishment. Draw and replenishment — the states that matter most when a project is actually under stress — are left out entirely, or deferred to a post-go-live "Phase 2" that rarely happens before production use begins.

TRA Waterfall: Sequence Matters More Than Total

The Trust and Retention Account (or equivalent waterfall account structure) is where project finance implementations most frequently produce production defects that are expensive to unwind. The waterfall defines the priority order in which cash from the project flows to different claims — operating costs first, then debt service, then reserves, then equity distribution.

The testing failure is predictable: teams test whether the waterfall runs. They confirm that cash is allocated to each bucket. What they do not test is whether the sequence is enforced correctly when one level of the waterfall cannot be fully funded.

Consider a scenario where operating costs consume more cash than expected and the remaining funds are insufficient to cover both scheduled debt service and the required DSRA top-up. The credit agreement specifies which claim takes priority. The system must enforce that priority and block the lower-priority claim, not split the available funds proportionally. A UAT plan that only tests a fully-funded waterfall will never reveal whether this logic is correctly implemented.

Why This Gap Persists

Project finance domain knowledge is concentrated in a small number of people who have worked on the credit or syndications side of an infrastructure deal. That knowledge almost never sits inside the IT delivery team implementing the system. The team understands the system. They do not know what the covenant is supposed to do when it breaches, because they have never been the person responsible for monitoring it.

The result is a UAT plan that is technically thorough — every configured field is tested, every screen is reviewed, every report is run — but functionally shallow. The business logic that matters most under stress is never exercised.

The other contributing factor is timeline pressure. Covenant lifecycle testing — particularly DSRA draw and replenishment, and breach cure period tracking — requires setting up complex preconditions that take time to construct. Under a compressed UAT schedule, these scenarios are the first to be deferred.

What a Functional Review Adds Before UAT Begins

The most effective intervention is not to add more test cases to an existing UAT register. It is to review the UAT plan against the credit agreement before testing starts, identify the covenant mechanisms that are missing from coverage, and build the test scenarios that exercise them.

This review typically surfaces three to five scenario classes that are absent from the plan: breach trigger chains, reserve account lifecycle states beyond establishment, waterfall sequence enforcement under partial funding, and Event of Default downstream workflows. Each of these can be specified as test cases before UAT begins, which is the point at which fixing them costs the least.

Bankly's Project Finance Consulting practice provides functional domain support for teams implementing project finance modules on Temenos, Oracle FLEXCUBE, Finacle, and custom builds — including UAT plan review, ready-to-use test cases covering DSCR, DSRA, and TRA waterfall scenarios, and on-project consulting during the testing phase.