Skip to main content
AI Enablement

NAV Production Redesign: From Nightly Batch to Continuous Exception-Driven Processing

April 03, 2026
NAV Production Redesign: From Nightly Batch to Continuous Exception-Driven Processing

NAV production is the canonical middle-office workflow in asset management. It runs nightly, it fails just often enough to consume meaningful management attention, and it has been fundamentally the same for 20 years: prices flow in, positions are valued, corporate actions are applied, reconciliation breaks are investigated, exceptions are resolved, and the NAV is struck. Every night. Every fund. The same sequence.

The structural opportunity is to redesign NAV production from a nightly batch process into a continuous, exception-driven workflow where the system processes data in real time, anomaly detection runs continuously rather than at end-of-day, and human attention concentrates on the exceptions and the genuinely ambiguous cases rather than every step in the sequence.

This post is about what that redesign looks like in practice, based on the asset management AI enablement engagements we have run and the anonymised case study on NAV cycle compression.

Why NAV production is stuck in batch mode

NAV production runs as a batch process because it was designed in an era when data arrived in batches. Prices came from a pricing vendor at end-of-day. Corporate actions were processed in an overnight run. Custodian statements arrived the next morning. The workflow was designed around the data delivery cadence, and the data delivery cadence was daily.

Today, prices are available in real time. Corporate action data is available intraday. Custodian feeds are continuous. The data has moved to real-time, but the workflow has not followed.

The reason the workflow has not followed is structural, not technical:

  1. The systems are batch-oriented. The fund accounting platform (SimCorp, Charles River, HiPort, Geneva) runs nightly processing cycles. Changing to continuous processing requires either the vendor to support it (increasingly they do) or the firm to build a real-time layer on top.

  2. The reconciliation process is manual. Breaks between the fund accounting system and the custodian/depository are investigated manually by the middle-office team. Each break requires human judgment. The team cannot move to continuous processing if break investigation is a sequential manual task.

  3. The governance model is sequential. The NAV must be signed off by a senior fund accountant before publication. The sign-off step is designed as a gate at the end of the batch, not as continuous attestation. Under AIFMD and UCITS, the depository expectations reinforce the batch model.

  4. The operating model assumes everyone works at the same time. Month-end close is a sprint because the entire team converges on the same window. If NAV production were continuous, the workload would be distributed across the day rather than concentrated overnight.

The redesigned workflow

The AI-native NAV production workflow has four structural differences from the batch model:

Continuous data ingestion with real-time normalisation

Prices, positions, corporate actions, and custodian feeds flow into a normalised action-data layer in real time. The data layer is structured around a position-and-fund wide-row that the valuation engine can consume at any point, not just at end-of-day.

This requires a data architecture that handles late-arriving data (a price that updates after the initial feed), corporate action adjustments, and custodian reconciliation events as event streams rather than batch replacements. The architecture is described in the data layer constraint essay.

Continuous anomaly detection

Instead of running a reconciliation at end-of-day and then investigating the breaks, the system runs continuous anomaly detection on every data event: is this price within expected range? Does this corporate action match the expected entitlement? Does this position reconcile to the custodian record? When an anomaly is detected, it is surfaced immediately with full context, not queued for the overnight batch.

The anomaly detection models are where the data flywheel applies: every false alarm and every genuine break that is investigated adds to the training signal, and the model gets better at distinguishing noise from real exceptions.

Exception-driven human attention

The middle-office team stops processing every NAV step and starts handling only the exceptions the system surfaces. A fund with clean data and no anomalies runs through the system end-to-end without human touch. A fund with a pricing anomaly gets a human review on the specific price, not a full manual NAV calculation.

This is the production function redesign: the team's role shifts from preparation to attestation and judgment. The team size may stay the same, but the work each person does is structurally different: more demanding, more consequential, and more valuable.

Continuous attestation under AIFMD/UCITS

The sign-off step shifts from a single gate at the end of the batch to continuous attestation: the senior fund accountant reviews and attests the exceptions and the system-processed NAVs throughout the day. The depository relationship, critical under AIFMD and UCITS, is engaged early in the redesign so the attestation model satisfies their expectations.

What the case study shows

Our anonymised case study walks through a 12-month engagement with a mid-sized asset manager. The starting position: nightly batch fragility, 11-day month-end close, fee compression outpacing cost reduction. The outcomes at 12 months:

  • 94% of NAV exceptions resolved before market open (versus 60% pre-redesign)
  • 5-day month-end close (versus 11 days)
  • 40% reduction in operating cost per fund
  • A reusable action-data layer now feeding 3 adjacent workflows (regulatory reporting, ESG operations, distribution analytics)

The last point is the compounding mechanism. The data layer built for NAV production is reusable for every other middle-office workflow. The second engagement (regulatory reporting redesign) started halfway built. The third (ESG operations) started further along still.

For asset managers evaluating the opportunity, the AI Enablement ROI Calculator models the 5-year cost gap using your specific team size, salary, and operational metrics.

The vendor dimension

Most asset managers run NAV production on a combination of vendor platforms (BlackRock Aladdin, SimCorp, Charles River, FactSet, Bloomberg) with multiple custodian integrations. Any redesign has to engage that vendor landscape rather than pretending it can be replaced.

This means the data architecture sits alongside the vendor platform, not inside it. The action-data layer ingests from the vendor's data feeds and the custodian's feeds, normalises both, and produces the position-and-fund wide-row that the anomaly detection and valuation engines consume. The vendor platform continues to be the system of record; the action-data layer is the intelligence layer on top.

For more on how we navigate the vendor landscape in asset management, see the AI Enablement for Asset Management service page and the FS sector playbook.

How to start

The first step is an honest current-state map of your NAV production workflow: every step, every hand-off, every reconciliation point, every exception handling path. Our diagnostic engagement produces this map in BPMN 2.0, along with the anomaly detection opportunity analysis and the depository/regulatory integration assessment.

If you want to score your readiness before engaging, the AI Enablement Maturity Diagnostic provides a per-pillar breakdown that identifies where the binding constraint sits across the five enablement dimensions.

The asset managers that redesign NAV production first will operate at structural cost-to-AUM levels that competitors who do not will struggle to match. The Investment Association publishes industry benchmarks on operating cost-to-AUM that provide useful comparison.

Ready to do the structural work?

Our AI Enablement engagements are built around the five pillars in this article. We start with a focused diagnostic, then redesign one priority workflow end-to-end as proof — including the data layer, decision rights, and governance machinery.

Explore the AI Enablement service

Ready to do the structural work?

Our AI Enablement engagements are built around the five pillars in this article. We start with a focused diagnostic, then redesign one priority workflow end-to-end as proof — including the data layer, decision rights, and governance machinery.

Explore the AI Enablement service
Monthly newsletter

More like this — once a month

Get the next long-form essay on AI enablement, embedded governance, and operating-model design straight to your inbox. One considered piece per month, written for senior practitioners in regulated industries.

No spam. Unsubscribe anytime. Read by senior practitioners across FS, healthcare, energy, and the public sector.