[SPONSORED CONTENT]
What followed was a frank exchange among oversight, accounting, IT, and operations leaders. Below are the themes that defined the conversation.
The Gap Between Oversight Labels and Oversight Reality
Ask most firms how their NAV oversight function spends its time, and the answer reveals a structural problem hiding in plain sight. Teams designated for oversight are largely occupied with upstream work: sourcing data, converting formats, resolving inconsistencies across providers. By the time that work is done, the capacity for actual oversight has been significantly reduced.
One participant offered a figure that landed with the room: roughly 40% of what firms call NAV oversight today is genuine oversight work. The remainder is data preparation, misclassified by leadership and therefore invisible as a problem to be solved.
The cause isn’t individual performance. It’s architecture. Oversight teams operate downstream of a fragmented information flow, receiving inputs from multiple providers in inconsistent formats with no shared definitions. Assembling the data and checking the data have become the same job, and assembly is winning.
Why Fixing the Symptom Isn’t Enough
PDFs came up repeatedly as a case study in the limits of tactical fixes. Many asset managers continue to receive data from administrators in PDF format, extract it manually into spreadsheets, and then reconcile it across internal systems. It is a time-consuming process that most operations teams know well.
AI-assisted extraction has made this faster. The technology exists to take a PDF in and return structured data out, and several participants had experimented with it. But the consensus in the room was firm: automating an extraction step doesn’t address why PDFs remain the communication standard in the first place. A workaround applied to a broken process is still a broken process.
Where the Friction Actually Lives
A thread that ran through much of the discussion was the location of the problem. For many firms, the friction they manage daily isn’t internal in origin; it comes from the provider ecosystem around them.
Participants described a familiar set of conditions: administrators using different data formats and definitions, sometimes varying across teams within the same organisation; public and private market data arriving in effectively different languages; and asset managers absorbing all of it and translating it into something coherent for internal use.
One participant noted their firm manages relationships with eight to ten administrators. The honest conclusion the group reached is that no single asset manager has the leverage to change how that ecosystem operates. Scale helps at the margins, but it doesn’t create the common standards the industry needs.
Several participants expressed appetite for a collective solution: a shared utility, a minimum standardized data package, or some form of industry-wide coordination that moves firms beyond bespoke provider feeds. The mechanism was less clear than the need.
The Build Versus Buy Reality Check
The build versus buy question surfaced, as it tends to in any honest conversation about investment operations technology. The consensus reflected the complexity of the decision rather than a clean answer in either direction.
Many firms have arrived at their current state through years of incremental decisions: legacy processes patched with in-house tools, internal solutions built around specific needs, systems that made sense at the time and now present retention and documentation risks. When the people who built those tools leave, the institutional knowledge leaves with them.
Buying introduces a different set of risks, particularly the risk of being locked into a provider roadmap that diverges from your own operational direction over time. The group’s conclusion was not that one path is better, but that the question demands deliberate thinking: clarity about the purpose of each initiative, realistic assessment of what delivery requires, and a considered view of how the operating model needs to work on the other side.
A Grounded View of What AI Can and Cannot Do
Given the volume of industry conversation around AI, the Edinburgh group’s perspective was notably measured. The technology has been available in various forms for years; what’s changed is its accessibility in operational contexts. For pattern recognition, anomaly detection, and certain categories of data work, it is genuinely useful.
The boundaries the group identified were equally clear. AI does not replace human judgment, particularly in processes where accuracy is critical and auditability is required. Governance around data lineage and quality control remains essential. And there was specific concern about deployments that reduce transparency: participants still want to verify AI outputs, and the value of that verification depends on someone actually doing it.
The group also pushed back on the conflation of AI with automation more broadly. Tokenization, blockchain, and other emerging technologies belong in the same forward-looking conversation, but each needs to be evaluated on what it can practically deliver today rather than what it represents conceptually.
Evidencing Resilience, Not Just Achieving It
Operational resilience came up in a way that reframed the usual discussion. The group’s view was that the substance of resilience expectations hasn’t changed dramatically; what has changed is the requirement to demonstrate it. Firms are increasingly asked to evidence their controls, their oversight processes, and their recovery capabilities with a level of explicitness that goes beyond what was previously expected.
The practical implication is that the work of proving resilience has grown faster than the underlying obligation. Preparation and early identification of issues before they escalate were consistently cited as the markers of a genuinely resilient operation, as distinct from one that responds well after the fact.
The Provider Relationship Gap
A candid portion of the discussion addressed what asset managers want from their technology and service providers and where that expectation currently falls short.
The appetite is for systems and data that function across the operating model rather than solving isolated problems for individual functions. Point solutions that work well in one area but create new integration challenges elsewhere were cited as a recurring frustration.
There was also pointed commentary on the nature of provider engagement. Sales teams across the industry hear the same operational pain points from multiple clients. Participants felt that represented an opportunity being left on the table: providers are positioned to surface patterns, share what’s working elsewhere, and contribute to collective solutions. The current tendency to treat each client conversation as a discrete sales interaction was seen as a missed opportunity for the industry as a whole.
Themes for Future Conversation
The Edinburgh session closed with several threads identified for continued discussion: how to govern AI in processes where accuracy and auditability are non-negotiable; what modern operating model design actually requires in practice; what a minimum standardized data package might look like at an industry level; and how firms move from a collection of technology projects toward something more coherent and interconnected.
The gap between understanding and operational reality remains wide. The data is fragmented, provider communication is inconsistent, and legacy ways of working remain deeply embedded. What the Edinburgh group reflected was that the sector is clear-eyed about what needs to change. The work now is in closing that gap with intention.
If you’d like to be part of the next FundGuard roundtable, join the FGX community here.
To read more articles from FundGuard, visit our content hub on Funds Europe.
