NAV reconciliation across time zones

It's 9:03am in New York. A portfolio manager opens their dashboard and sees yesterday's NAV for a Luxembourg-domiciled fund. Except it isn't yesterday's NAV. It's the day before's. The fund administrator published the update at 6pm CET — which was after the US data cut-off. Nobody's wrong. The data is just stale.

This is the kind of problem that doesn't show up in architecture diagrams. It shows up as a support ticket from a client who says "your NAV doesn't match Bloomberg." And they're right. It doesn't. Because Bloomberg got the update three hours after your system locked its snapshot.

The timing problem is a data quality problem

Most people think of data quality as accuracy: is the number correct? But in fund data, timeliness is a quality dimension. A NAV of 142.37 for LU0599946893 is perfectly accurate — it's just from Tuesday, and today is Thursday.

The industry runs on a patchwork of publication schedules. Luxembourg transfer agents typically publish NAVs between 4pm and 7pm CET. Irish funds often publish earlier. Asian funds publish on a completely different cycle. US mutual funds publish after market close, around 6pm EST.

If you're aggregating across all of these — which any global platform does — you're constantly reconciling data from different points in time.

Stale vs missing: pick your poison

You have two options when a NAV hasn't arrived yet:

• Show the last known value with a staleness indicator. The number is accurate as of its date, but it's not current.
• Show nothing. The field is blank until the fresh value arrives. This is more honest but creates gaps in reports.

Neither is great. In practice, most platforms show stale data with a timestamp, because blank cells in a client report generate more panic than dated ones. But this creates a subtle problem: downstream calculations don't know the data is stale.

If your system calculates a portfolio's total AUM by summing the latest NAV times shares outstanding for each fund, and three of those NAVs are 24 hours old while the rest are current, your AUM figure is a fiction. A plausible fiction, but a fiction.

What reconciliation actually means here

True NAV reconciliation across time zones requires tracking three things per data point:

• Valuation date — the date the NAV represents (the "as of" date)
• Publication timestamp — when the source actually made it available
• Receipt timestamp — when your system ingested it

Most systems only track the first. Some track two. Almost nobody tracks all three. But you need all three to answer the question: "When I ran that report at 10am EST on Wednesday, was every NAV in it from Tuesday's valuation, or were some from Monday?"

The correction problem

It gets worse. NAVs get corrected. A transfer agent publishes 142.37 at 6pm, then sends a correction to 142.39 at 8pm. If your system already ingested the first value and pushed it to a client report, you now have a versioning problem.

Do you overwrite silently? Do you flag the correction? Do you re-run every downstream calculation that used the old value?

In seven years of fund data operations, I've never seen a platform handle NAV corrections elegantly. Most handle them eventually. That's the best you can hope for.

The approach that works is treating every NAV as an immutable event: fund X, valuation date Y, value Z, published at T1, received at T2, version N. You never update. You append. The latest version for a given fund and valuation date is the current truth.

Practical patterns

Define cut-off windows per region. European NAVs expected by 7pm CET. US NAVs by 7pm EST. Asian NAVs by 10am HKT. If a value hasn't arrived by the cut-off, flag it as late — don't silently show yesterday's number.

Track publication SLAs by source. Over time you'll build a profile: this transfer agent publishes 95% of NAVs by 5:30pm CET. When they're late, you know it before the client does.

Propagate staleness metadata downstream. If a report uses a stale NAV, the report should know. Not buried in a log file — visible in the output. "AUM calculated using 47 current NAVs and 3 values from prior day."

Reconcile against multiple sources. If Bloomberg, the transfer agent, and the fund's own website all agree on 142.39, you're golden. If they disagree, the most recently published value from the authoritative source wins — but log the discrepancy.

None of this is glamorous engineering. It's plumbing. But it's the plumbing that determines whether your clients trust the numbers on their screen at 9am on a Wednesday morning. And in this business, trust is the only product that matters.