A NAV decline trigger takes about an hour to negotiate. Someone on the desk proposes 10% over a month, 15% over a quarter and 25% over a year. The fund's counsel pushes back on the one-month figure, everyone agrees to test it on month-end NAV net of subscriptions and redemptions, and the language goes into Part 1(h) of the ISDA Schedule. The document is signed, scanned and filed. That is the last time most people read it.
The clause then lives for a decade. It is in force every business day of that decade. Every month a NAV statement arrives from the administrator, and somewhere in the bank a person is meant to compare that statement with a figure from one, three and twelve months ago and decide whether the trigger has fired. In most books, that comparison happens in a spreadsheet, on a tab that was set up by an analyst who has since moved desks.
The risk is not the term
When people talk about counterparty risk on funds, they talk about the terms: were the thresholds tight enough, did we get a NAV floor, did we get a key-person clause. Those are fair questions for the hour of negotiation. They are the wrong questions for the following ten years, because a well-negotiated trigger that nobody tests protects you exactly as much as no trigger at all.
The clause is written once. The check has to happen every month, for every fund, against the right number, for as long as the trade is on.
Look at what that check actually needs. The NAV has to arrive on time, and someone has to notice when it does not. The arrived figure has to be the one the clause names: month-end, official, net of flows, per share or total. The comparison window has to be the window in the document, not the window the spreadsheet happens to hold. The result has to reach the person who can act on it, with the evidence attached. And all of this has to happen again next month, whether or not the analyst is on holiday.
None of that is hard in the way negotiating a term is hard. It is hard in the way that doing something correctly six hundred times is hard.
Nothing connects the term to the calendar
The gap is structural. The legal document lives in one place. The reporting obligation, if it is tracked at all, lives in another. The NAV data arrives by email and lands in a third. The credit limit that depends on the NAV lives in a fourth. Nothing in that chain knows that the 10% in the PDF and the figure in the administrator's email are meant to meet on the fifth business day after month-end.
So the check depends on a person remembering. When the book has thirty funds, that person exists and the check gets done. When it has three hundred, it becomes a quarterly exercise. When it has three thousand, it becomes something the bank tells its regulator it does.
What we think the answer looks like
We are building ExactCov around one idea: every term that has a test date belongs in a register that owns the calendar. The trigger is extracted from the executed document with a citation to the page. The reporting obligation behind it is turned into due dates. When the NAV arrives, the test runs against the basis the clause specifies. When it does not arrive, the figure is marked stale and someone is chased. When the test fails, the breach is routed to the desk that holds the limit, with the clause and the notice side by side.
Everything else we write here hangs off that thesis: stale data, which NAV to test, what the agreements actually say, how limits should move. Start with the one point. The clause is written once. The check happens every month, and the check is where the risk lives.