Stop Striking the NAV
Why do we batch everything into a close? Because human attention is scarce, so you ration it to a deadline and throw bodies at the cutoff. Why do we stack maker, checker and checker's checker? Because correlated redundancy was the only kind money could buy. Both of those are taken apart in We Taught People to Be Computers. This piece assumes them and asks a narrower question: what does a NAV operation look like on the other side?
AI attention doesn't degrade, so assurance no longer has to be batched. The NAV stops being something you produce at a deadline and becomes something continuously assembled and reconciled as data arrives, with assurance running underneath whatever strike cadence your product actually needs, daily, monthly, or quarterly. You still strike an official, point-in-time number whenever you want one. But striking it becomes a snapshot of a state that was already assured, not a scramble to build one. The close becomes a non-event.
And because that attention is effectively unlimited, you can finally check the way you always wished you could. Real assurance comes from independent confirmation. A mirror position that should move in step. The same number derived three unrelated ways. A second source that shouldn't agree by accident. The value of a check is its independence, not its existence, and we could never afford that with people. Now we can.
Some things still can't be confirmed from the data, no matter how many independent angles you take. When one of those items is material, you do the single most valuable thing a person can do: go back to the source and get it confirmed. That is what your people are for now. Not re-keying and re-checking, but standing behind the number, adjudicating what the independent views flag, and chasing down the handful of high-impact items only a human can resolve. It is the highest-leverage use of expertise in the entire process, and today it is buried under rote review.
Notice what the quarterly valuation becomes in this world. Today the whole close waits on it. In a continuously assured book, everything else is already standing, so the mark stops being the close and becomes the last piece dropping into an already complete picture.
And here is what it adds up to. Today the fund administrator is the bottleneck. The close gates the reporting, the reporting gates the decisions, and the administrator's capacity quietly caps how fast the manager can move. Do this right and that stops being true. The books are always current, always assured, and the number is there the moment anyone needs it. The administrator stops being the thing everyone waits on and becomes the reason the whole chain can move faster.
You do not start with the NAV.
Pick one fund and one asset class, and run continuous assurance alongside the existing close without changing a thing you publish. The current process stays the system of record. What you are building is evidence, and the evidence that matters is in two columns: every break the parallel run caught that your close did not, and every break it flagged that turned out to be noise. The second column decides whether anyone will trust the first.
Instrument before you change anything. Most firms cannot answer, on the day they start, how many breaks they currently find after the strike rather than before, or what their errors look like by type. Without those numbers you will have no way to prove later that anything improved, and the question will be asked.
Three things break on the way, and all three are predictable. Continuous assurance is only as continuous as your feeds, so the first thing you learn is which counterparties and which administrators send a file when it suits them. Independent derivations are only independent if they do not quietly share an upstream source, and in most operations more of them share one than anybody expects, which means the first version of your independence is partly an illusion you have to go and find. And the exception queue gets loud before it gets useful. Let it cry wolf for a quarter and your people will stop reading it, which is very difficult to undo.
You will know it worked from three numbers, none of them about speed. The share of breaks caught before the strike rather than after it. How far the error profile has shifted from the loud kind to the quiet kind, which you can only see if you were classifying errors before you began. And the hours between the last piece of data arriving and a number somebody will put their name on. That last one is the only one a client feels directly, and it is the one that decides whether you are the bottleneck.
Stop striking the NAV. Start continuously assuring it.