A fund's NAV falls 10%. Nothing in the agreement fires: the trigger is 20%. But the bank's own policy sets the settlement limit and the direct-risk limit for that fund as a percentage of NAV, so both limits should now be 10% smaller. Somewhere between the NAV arriving and the limit changing, the work has to happen. In most banks we have seen, it happens in a spreadsheet, at quarter-end, or not at all.
This is the piece of fund monitoring with the least system behind it. Breach detection has covenants and a legal document. Data collection has a calendar and a chase. Limit resizing has a policy paragraph and a person who is meant to remember.
Why it goes wrong
The policy is simple and the execution is not. Two limits derive from one NAV, often in different currencies, so there is an FX rate in the calculation. The NAV has to be official, not indicative, and not stale. A big move needs a human decision; a small one does not. The change has to land in the limit system, which is usually a different system, and the person who approves limits is not the person who reads NAV notices.
Put those together and you get a process that a spreadsheet can only approximate. Either every move is a manual change, and the team stops making them below some informal size, or the limit is left where it was set at onboarding and quietly drifts away from the NAV it was meant to track. Both outcomes are invisible until an exposure review asks why a fund that has halved still has its original line.
What the flow should be
We think the right shape is short and entirely internal. No amendment, no counterparty involvement, nothing that changes the legal position. Just the bank's own policy, executed on time and on the record.
- Proposal with rationale. On every validated official NAV, the register computes the new limit for each product from the rule that applies to that fund, states the NAV, the rule, the FX rate and the previous limit, and cites the notice.
- Sampled review. An approval policy decides which proposals need eyes. Within a set percentage move, on an official and current NAV, the change is applied automatically and logged. Outside that band, or on a stale or indicative figure, it is held for a person. The policy is per fund type, and it can be tightened for a fund on watch.
- One-click approval. The held proposals sit in one queue with the rationale beside them. The credit officer approves, rejects or adjusts, and says why in a sentence. That sentence is stored.
- Audit trail. Every applied change, automatic or approved, is a row with the old value, the new value, the observation it came from, the rule and the actor. The limit history for a fund reads as a sequence of decisions rather than as a current number.
The policy already says the limit follows the NAV. The system's job is to make that sentence true every month without a spreadsheet in between.
What this is not
It is not a replacement for the limit system. The proposal and the approval live in the register; the applied limit is exported to wherever limits are held, with the same audit reference on both sides. It is not a change to the agreement, and it never touches the counterparty. And it is not an automation that removes judgement. It removes the arithmetic and the remembering, and it puts the judgement where it belongs: on the moves that are large enough to deserve it, in front of the person entitled to make them.
The teams we talk to describe the same relief when they see the queue for the first time. The work was always theirs. It was just never anywhere.