NGT Tools: The Exception Framework
Adding a control costs almost nothing. Acting on what it produces costs an analyst's afternoon.
The constraint in operational controls was never detection. It's attention.
The NGT Exception Framework is the tool we built around that constraint. It runs the controls, generates the events, and does the work between the event and the person. Here is how it works, and why it deliberately produces far more events than anyone will ever read.
Two families of work
Investment operations split into two kinds of work. Reporting is production under deadline. Controls are exception-based, and they behave differently from everything else in the operation.
Every operations team knows how this fails. You add controls, the queue fills with things that turn out to be nothing, and within a few months people stop reading it carefully. Aviation and clinical medicine have studied the effect for decades and named it alert fatigue. The usual response in our industry is to run fewer controls, or widen the thresholds until the queue goes quiet. That buys silence at the cost of coverage, and it's the wrong trade.
We went the other way. Run a very high number of controls, generate a very high volume of events, and put the engineering into what happens between the event and the human.
Inside the framework: the event is the particle
The Exception Framework is one of our NGT Tools, and it has one primitive.
A control runs. When its trigger condition is met, it generates an event. That's the smallest unit in the system, and everything else is built from it.
An investigation report is what a set of events becomes once they've been aggregated, correlated and given a root cause. That's the thing an analyst opens. Everything that makes the system usable happens between those two.
Two axes of optimisation govern that path. The first makes each event more pertinent. The second makes the collection of events more informative.
Axis one: better triggers, fewer false positives
A fixed threshold is a crude trigger. It fires on a number rather than on an anomaly, and it has no view of what normal looks like for that fund, at that point in its life, under those market conditions.
Most of our work on axis one has been moving controls from thresholds to statistics, and specifically to time series methods that model expected behaviour and flag real departures from it.
Fees Anomaly Detection
Fees Anomaly Detection sits in our NAV oversight library. It checks the fee calculations produced by a fund administrator or accountant on ABOR data, across funds, managed accounts and insurance policies.
It runs several controls. One applies anomaly detection to the time series of the fees themselves, looking for sudden departures from the established pattern. Another recalculates the fee independently and compares that figure against the one received from the source.
Some clients want the second control run strictly: flag any difference above a few cents, or a basis point. We can do that, and the queue fills accordingly, because two systems computing the same fee will always disagree slightly for reasons nobody needs to investigate.
What works better is to treat the difference between the independent calculation and the reported figure as its own time series, then apply statistical tests to its distribution. A z-score on that difference separates ordinary computational divergence from something that actually changed.
The gain isn't only noise reduction. It changes what you can detect. A single day's divergence of a few basis points is invisible to a threshold set wide enough to be usable. A small deviation that persists in one direction across an accrual period becomes statistically significant long before it becomes materially large. That's the drift a threshold will never catch and a distribution will. The same framework then controls the payment when the fee is distributed.
EMIR Reporting Oversight
The same principle applies well outside NAV. Many clients use SPARK to oversee their EMIR reporting, checking the data fed to DTCC before and after submission.
Part of that is data quality in the strict sense: completeness, format, internal consistency. The more valuable part is business knowledge applied to the data, flagging values that are technically valid but wrong for a trade of that type, in that currency, for that counterparty. Knowing what a field should plausibly contain isn't a validation rule. It's domain knowledge, and it's the kind of knowledge we've packaged as NGT Skills.
Fees and EMIR are two of the tool libraries that feed the framework. There are many more: NAV oversight, multi-source reconciliation, referential and fund static data, investment compliance monitoring, ESG and regulatory reporting, performance fees, entity management, private markets mechanics. The controls differ in every one of them. The framework underneath is the same.
Axis two: events as context
Optimising triggers only gets you so far, and past a certain point it costs you sensitivity. The second axis runs the other way.
A high volume of events isn't a problem to suppress. Events are how a case gets explained.
Alongside the controls that detect potential issues, we generate contextual events: subscriptions, redemptions, dividend distributions, corporate actions, large movements in the underlying markets. None of these is an exception. Nothing is wrong. They're recorded because they change what normal looks like on that day, for that vehicle.
When an anomaly and a contextual event land on the same fund on the same day, the anomaly usually has its explanation attached before anyone looks at it.
That's the part that pays. A case is a pattern of events, and a pattern can be compared. Against the history of the same vehicle, to see whether this configuration has occurred before and what it turned out to be. And across the universe of other vehicles at the same time t, to see whether twenty funds are showing the same signature, which usually means the cause sits upstream rather than in the fund.
Similarity search across history and across the universe is the part a general model can't do at any level of capability, because the comparison set is your data and nobody else's.
What the two axes produce together
Both axes run inside the same framework. Axis one raises the quality of each event. Axis two raises the information content of the set. Run both and you get a combination that looks contradictory from outside: very high control coverage, very high event volume, very few investigations.
On one well-tuned deployment, around 1,500 NAVs a day produce roughly 30 investigation reports a week. That ratio varies by client, by asset class, and by how long the controls have been running. What doesn't vary is which number is worth optimising. Not controls run, not exceptions caught, not alerts cleared. The proportion of surfaced cases that were worth an analyst's time.
And when one of them is opened, the root cause is usually already proposed and the precedent already attached.
Seven years of operations, encapsulated in the tool
These controls have run in production for seven years, for some of the largest banks and asset managers in Europe, across their funds, their share classes and their reporting obligations. That work is where the calibration comes from.
Which fee divergences matter and which are two systems rounding differently. Which contextual events change what normal looks like for a fund on a given day. Which combinations of events explain a case and which ones happen to coincide. None of that can be worked out from first principles. You learn it from operations teams who have investigated a few thousand of them and told you, case by case, when you were wrong.
All of it now sits inside the NGT Exception Framework and the NGT Skills around it. A new client doesn't start from a blank threshold and six months of tuning. They start from methodology that has already been through that.
What carries across deployments is the methodology and the domain knowledge. The data does not. Every client runs single tenant, and their data stays theirs.
What changes with agents
The Exception Framework is an NGT Tool, which means agents can call it.
An agent doesn't consume a dashboard. It consumes the objects underneath: the event stream, the case with its correlated events, the similarity search across history and across the universe, the controls themselves. All of it reachable through MCP and APIs, scoped to what the agent's role permits, with every call attributed and logged.
An agent investigating a NAV movement doesn't start from raw data. It starts where an experienced analyst would start, with a case that already has correlated events, a proposed root cause and comparable situations attached. From there it does what an analyst rarely has time to do: pull the contextual events around the fund, run the pattern against every similar signature in the history, check whether the same configuration is showing on other vehicles this morning, call other NGT Tools to test a hypothesis, and apply the NGT Skills that encode how this kind of break usually resolves.
An analyst checks the three or four hypotheses experience suggests. An agent can check forty, on every case rather than on the ones somebody had time for. That's not a shortcut. It's a more complete investigation.
Agents write back into the framework too. Enrich the case with what they found. Record the root cause and the evidence for it. Attach the precedents. Draft the client communication. Open the workflow, assign the owner, and stop where a human decision belongs.
Because agents build workflows as well as run them, the framework itself keeps improving. A pattern that recurs without an explanation is a candidate for a new control or a new contextual event type. An agent can propose it, test it against history, and show what it would have caught and what noise it would have added. A human approves it before it goes live, like every other change to a control.
Agents own progress. People own decisions.
This goes back to where we started. The cost of triage is what capped how many controls an operation could afford to run. When that cost falls, the calculation behind axis one changes. Coverage stops trading against noise, and you can run controls you previously had to leave switched off.
Next Gate Tech builds SPARK, the operating ecosystem for agentic AI automation of investment operations. Clean data, deterministic workflows, domain knowledge, and full traceability. Purpose-built for one of the most heavily regulated industries in the world. Trusted by BNP Paribas Securities Services, Amundi, Eurizon and others across €500bn+ in assets.