Fund counterparty monitoring

Every fund counterparty, tested the day its NAV arrives

For second-line credit risk and credit control at banks that face funds under ISDA, GMRA and financing agreements. The NAV triggers are extracted from the executed documents, every deliverable has a due date, every test re-runs on arrival, and the limits follow the NAV with an approval trail.

ISDA Schedules & CSAsGMRAsPrime brokerage & financing termsFund finance facilitiesUmbrella agreements & side lettersProspectuses & factsheets
The problem

The clause is written once. The check happens every month.

A NAV decline trigger takes an hour to negotiate and then lives for a decade in a PDF. Nothing connects the term to the calendar, so the check depends on someone remembering, for every fund, for as long as the trade is on. ExactCov is the register that owns that calendar.

CitedEvery threshold, basis and due date opens to its page in the stored agreement.
DatedEvery pass carries the observation it tested and the date it arrived. Stale is a state, not an age.
RoutedBreaches, overdue deliverables and blocked items go to a named owner with the evidence attached.
AuditedEvery write is a row with an actor. Corrections supersede; nothing is overwritten.
The register

What is extracted from each agreement

The vanilla NAV decline over one, three and twelve months is the backbone. The variance around it is where template-based monitoring fails, so the register holds it as fields, not paragraphs.

Tests

Each trigger with the convention the clause actually names.

  • Decline over a window, a NAV floor, an absolute level or a ratio
  • Measured month-end, quarter-end, on any reported NAV, or any day against peak
  • Basis: headline, flow-adjusted or per share, with the fallback recorded when flows are unknown
  • Consequence: additional termination event, default, notice shortening or alert only

Deliverables

Each reporting obligation becomes calendar items with due dates and cure periods.

  • NAV reports, estimated NAVs, audited accounts, prospectus updates
  • Daily, weekly, monthly, quarterly, annual, on request or on change
  • Delivery lag in calendar or business days
  • Consequence of a miss, from alert to termination event

Events and structure

The clauses that arrive by notice, and how funds relate to each other.

  • Manager change, key person, adviser change, self-reporting duties, cross-default
  • Umbrella agreements: terms inherited by each sub-fund, overridable per fund
  • Floors tied to audited year-end, re-based when the audit lands
  • Suspension, resumption, liquidation and merger notices change state, never silently

Two people should never disagree about what a test was run against

The same NAV notice gives four defensible answers depending on the basis. The basis is a stored field on the test, decided when the agreement is read and cited to the clause that decided it. Each result records the value used, the comparator observation and whether a fallback applied.

Which NAV? Headline, flow-adjusted, per share, total
Month-end NAV notice Total NAVUSD 440m prior monthUSD 500m NAV per share9.80 prior month10.00 Net redemptionsUSD 40m Umbrella total NAV−3.1% move over the month 0% trigger −10% Headline total−12.0% fired Flow-adjusted total−4.0% Per share−2.0% Umbrella, not the class−3.1% flow-adjusted: (440 + 40) / 500 = −4.0%. per share: 9.80 / 10.00 = −2.0%. The clause names one basis. Store it on the test, with the page that named it.
The same notice, four defensible answers. Which one is right depends on the basis the clause names, so the basis has to be a stored field on the test.
The morning brief

Four lists, in the order you would ask

The first screen each morning is not a dashboard. It is the four questions a credit officer asks, answered from the register, each row opening to the documents behind it.

  • In breach. Tests that failed, with the observation, the comparator and the clause.
  • Stale data. Funds whose deliverable is past due or whose dealing is suspended, with the exposure behind them.
  • Underperformers. NAV change against the fund's own benchmark over the same window.
  • Near breach. Headroom inside the warning band, ranked by distance and trend.

Drill down by team, fund type, geography, sector or strategy, with exposure at risk on every row.

Chase and escalate

Silence is an event

Every deliverable moves through scheduled, due, overdue and cured or defaulted. Passing the due date marks the figure stale everywhere it is used and puts the fund on the morning list. The chase is logged against the item, so "asked twice, no reply" and "nobody asked" are different facts.

  • Chase log per fund: channel, contact, outcome and note, with the last chase date on the fund.
  • Escalations of four kinds, operational, warning, breach and dependency, each with an owner, an acknowledgement and a close.
  • Stale policy per fund type: keep and flag, haircut after a number of days, or freeze new trades.
  • Baseline over the trailing window: on time, late and missing per counterparty, team and fund type, so the on-time rate is a fact.
Limits that follow NAV

The work with no system behind it, given one

Settlement and direct-risk limits are set as a share of NAV. When the NAV moves, the limit should move. On every validated official NAV the register computes the new limit per product, states the rule, the FX rate and the notice, and applies it or holds it for one-click approval. Internal only; the counterparty and the agreement are never touched.

  • Proposal with rationale on every validated observation, cited to the notice.
  • Policy gate per fund type: within the band, on an official and current NAV, applied automatically and logged; otherwise held for a person.
  • One-click approval with a sentence of reasoning that is stored with the change.
  • Audit trail of old, new, observation, rule, FX rate and actor, exported to the limit system with the same reference.
Limit resizing, in full
Official NAV validated, not stale Proposal new limit per product, rule, FX, rationale, notice Policy gate move within band? yes no, stale,or estimate Auto-applied logged under the engine Approval queue one click, with a reason Audit trail old, new, observation, rule, FX rate, actor, decision text: a sequence of decisions, not a current number Limit system applied value, same reference export internal only: the counterparty and the agreement are never touched
Proposal with rationale, a policy gate that decides which proposals need eyes, one-click approval for the rest, and a trail that records every outcome before the limit system hears about it.
Early warning

Signals beyond the covenant tests

A trigger tells you a fund has fallen. These tell you it is falling.

Benchmark

NAV change against the fund's own benchmark over the policy window, three months by default. Underperformers ranked, with the observations and benchmark levels used.

Redemption pressure

The NAV change split into performance, per share, and flows. Assets falling faster than NAV per share is flagged before it becomes a trigger.

Watchlists and priority

Stressed sectors and geographies you maintain; every matching fund surfaces with its exposure. Emerging-market and higher-leverage funds carry a priority multiplier, not a separate list.

Headroom bands

Warning bands at 20, 15 and 10 percent by default, set globally and overridable per fund. Alerts fire on crossing a band, not only on breach.

Scenario

A uniform or per-fund NAV shock re-runs every test and re-ranks the book without writing state. Which names does a 10 percent fall put through a trigger?

Search

Filter by region, sector, asset class, currency, holding, headroom or days stale, or ask in a sentence. If something happens in the market, which names does it hit? Export to Excel.

For the auditor

Numbers a second line can defend

Every figure on every screen traces to a page in a stored document: the threshold to its clause, the observation to its notice, the test result to both. Every write goes through one path that stamps who, when and from what. Observations, results and limit changes are append-only; a correction is a new row that supersedes the old one.

Extraction proposes; code verifies each quote against the page; a person confirms at onboarding. From then on the register is data. Headroom, due dates, state changes and limit proposals are deterministic arithmetic over cited inputs.

EVERY FIGURE TRACES TO A PAGE Screen headroom 8.2% Test result value, basis, comparator Observation NAV 440m, official Stored notice page 3, passage Stored schedule clause, page 11 citescitescitescitesthreshold cites the clause EVERY WRITE IS AUDITED, APPEND-ONLY limit 25m → 22.5mrule: 5% of NAV · obs #418engine · 06:10 · applied limit 22.5m → 25msupersedes row aboveA. Rao · 09:42 · approved next row appends here; no row is ever edited or deleted
Two rules: every figure on a screen can be followed to a page in a stored document, and every change is a new row with an actor. Corrections supersede; they never overwrite.
Getting started

Run it in parallel. Don't run a pilot.

The agreements are loaded once. The NAV notices that already arrive by email are copied to a mailbox we watch, or pulled from the same portal your team uses. Nothing changes for the team. After one monthly cycle you compare their book with ours, disagreement by disagreement, each with a citation on our side.

Week 0Agreements in, register confirmed at onboarding, calendar generated.
Weeks 1 to 4Notices flow to both. Tests, chases and limit proposals run on our side only.
Week 4Compare: stale we saw, late and chased, tests that disagree, limits that should have moved, what the book never held.
AfterPer fund in scope with a floor. Every user who should see the register sees it.

See it against your own book

Bring a handful of ISDA schedules and the NAV notices you already receive. We show the register, what is stale, and what would have fired.