INVESTMENT OPERATIONS · AI-NATIVE CONTROL

The evolution of investment management and operations, and why the current stack was not built for AI

Visual system hero showing a governed operating layer between systems and AI

I have worked in investment management and financial services for close to 20 years.

A lot has changed in that time.

Settlement cycles have compressed. Regulation has increased. Platforms have become broader. Cloud has changed how systems are deployed. Outsourcing has scaled across the industry.

But if you look closely enough, most of the processes and daily tasks have not changed as much as the industry likes to say it has.

Approvals still get chased manually. Custodians and asset managers still speak by phone every day to resolve issues that should have been handled automatically. Excel is still used across most teams, not just for analysis, but for controls, reconciliations, workflow tracking and decision support.

In some corners of the industry, faxes still exist. More importantly, their modern equivalents are everywhere: email approvals, manual exception queues, shared drives, spreadsheets, screenshots, reconciliations, workarounds and institutional knowledge that lives in people’s heads.

The industry has modernised the systems. It has not fully modernised the way work moves between systems, providers and teams.

That matters because firms are now trying to adopt AI on top of operating models that have been layered, patched and outsourced for more than three decades, workflows that were never designed for autonomous or semi-autonomous execution.

AI cannot magically fix that. It inherits what is underneath, the operating logic.

Section 1

How we got here

Thirty years ago, settlement cycles were much longer. US equities were T+5. Some European markets were measured in weeks rather than days. Over time, usually after market stress, regulation and operational pressure forced the industry to move faster.

The global financial crisis brought more regulation, more reporting and more scrutiny. North America moved to T+1 in 2024. The UK, EU and Switzerland are due to follow in 2027.

The direction of travel is obvious. Markets expect more speed, more transparency and more control.

But the operating model underneath has not always kept up.

Historically, the front and back office were split. The front office had the closest thing to live data because it is needed to make investment decisions. Everything downstream was significantly delayed. Operations and accounting teams relied on manual processes, home-built systems, files, reconciliations and paper trails.

Then enterprise investment platforms emerged. They gave firms broader coverage across the investment lifecycle and created a better attempt at front-to-back integration.

That was a major improvement.

But a firm’s process from investment through operations to accounting does not happen inside one system, not even if a firm buys a front-to-back platform. It happens across custodians, administrators, brokers, data vendors, internal teams, specialist systems, approvals, exceptions and controls.

That cross-system operating layer remained the hard part.

Section 2

Outsourcing solved cost, but broke parts of the data value chain

At the same time, outsourcing became the default answer to operational complexity.

That was rational. Firms needed scale. They needed lower cost. They needed more capacity. They needed to deal with more regulatory obligations, more products and more markets without building everything internally.

So, work moved to large overseas operating centres: the classic “your mess for less” model. Processes were broken into smaller tasks, which meant teams became responsible for individual steps, which meant losing sight of the whole picture.

The cost benefit was clear.

The control trade-off was less obvious.

Traditional outsourcing broke the data value chain. The front office stayed live, or close to live, but once a process moved into operations, accounting or a third-party provider, data moved through batch files, scheduled extracts, manual checks and delayed reconciliations.

That created a familiar problem.

What is the source of truth?

Diagram showing conflicting sources of truth around an official operating view
The source-of-truth problem is not just data quality. It is competing operating views without a governed layer between them.

Is it the custodian? The investment platform? The accounting book? The order management system? The portfolio manager’s Excel spreadsheet?

In most firms, portfolio managers and investment teams keep their own models because they do not fully trust the official operating view in the moment. That should tell us something.

The industry did not just outsource work. It often outsourced context.

That is why I think of traditional outsourcing like a cake factory. One team sifts the flour, another beats the eggs, another butters the tin, another watches the oven and another makes the boxes.

Everyone knows their task. Too few people know that it’s a cake being made, and almost none know why the cake is being made.

Cake factory metaphor showing outsourcing broken into isolated task views
The cake factory metaphor becomes the recurring visual shorthand for outsourcing without context.

That model can work when the goal is labour arbitrage and task execution. It does not work well when the goal is AI-native operations, because agents need context. They need to understand the workflow, the data, the exception history, the controls and the intended outcome.

Section 3

Cloud changed deployment, not the operating model

Cloud then changed how technology was delivered.

Platforms became easier to host and scale. Multi-tenancy became possible in more areas. Vendors could capture more market data, research data, operational data and reference data than ever before.

That created real efficiency.

But cloud did not, by itself, change the operating model.

A cloud-hosted process can still be manual and certainly doesn’t mean it’s multi-tenancy. A modern platform can still rely on email approvals and a scalable architecture can still hide fragmented operating logic.

This is the trade-off firms have lived with for the past decade or more.

One path is consolidation. Move more of the lifecycle onto a broader platform that can improve consistency and reduce some integration burden, but it can also require compromise on functional depth, heavy tailoring and a long implementation cycle.

The other path is best-of-breed. Use specialist systems where they are strongest, which preserves functionality, but it historically increases the burden around integration, ownership, lineage, reconciliation and control.

Neither path fully solves the problem between systems.

And that is where AI now arrives.

Section 4

Where AI meets the current stack

The temptation is obvious.

Put agents on top of the existing platform, put them on top of the outsourced process, put them next to the exception queue, add them over the batch reconciliation, let them read files, draft emails, classify breaks, propose mappings and summarise issues.

Some of that will help, some tasks will get faster, manual effort may reduce and some processes will look better.

But that is not the same as changing the operating model.

The industry data is already pointing in that direction. MIT’s Project NANDA research has been widely cited for showing that most enterprise generative AI pilots are not yet translating into measurable financial return. The important point is not the headline percentage, it is the diagnosis.

The issue is not simply model quality. It is brittle workflows, weak contextual learning and poor alignment with day-to-day operations.

That matches what I see in financial services.

If your data value chain is broken by batch handoffs, AI inherits that.

If your reference data is inconsistent, AI inherits that.

If your workflows and integrations are held together by tribal knowledge, AI inherits that.

If exception handling depends on someone knowing which custodian file is usually wrong, which field needs to be overridden, or which issue actually matters, AI inherits that too.

An agent operating on top of a fragmented workflow does not create intelligence.

It creates faster ambiguity. In financial services, faster ambiguity is risk.

Section 5

What AI-native actually means

Being AI-native is not the same as adding AI to an existing platform. We will be doing a blog post about this soon, stay tuned.

Changing your operating model to be AI-native starts with standardisation across workflows and processes.

As an example for operations: corporate actions, settlements, reconciliations, collateral, reference data and exception handling are not as unique as firms often believe. The details vary by firm, asset class, provider and jurisdiction, but the pattern is almost identical.

Data arrives, the data is validated, transformed, checked against a rule or tolerance. An exception is raised, then someone investigates, a decision is made, an approval may be required. Then a downstream system or provider is updated and all the evidence is retained.

Historically, firms have built too much variation and the standard gets lost.

AI-native operations should do the opposite.

Standardise the logic that should be standard, capture the variation where it matters and govern both.

That requires three foundations.

Diagram showing governed workflows, operational memory and agent harness as AI-native foundations
The AI-native argument resolves into three foundations: governed workflows, operational memory and the agent harness.

First, governed workflows. A workflow is not a task list, it defines what data is required, which checks need to pass, who owns the outcome, what happens when something breaks, what approvals are required and what evidence needs to be retained.

Second, operational memory. Every firm has people who know how the work really gets done. They know which exceptions matter, which file is usually wrong, which manual override is acceptable, and which issue creates real risk. For these experts, it’s muscle-twitch intuition. Today, too much of that knowledge sits in people’s heads, spreadsheets, inboxes, vendor configurations and workarounds.

That knowledge needs to become structured infrastructure. A knowledge graph is one way to do that. A knowledge graph is not another database, it is a representation of how the firm actually operates: the data, systems, rules, workflows, owners, exceptions, approvals and evidence.

Third, the agent harness. Here, the question is not just which model is being used. The questions are: what can the agent access, what skills does the agent have, what tools can it use, which workflow is it operating inside, where must it escalate, how is its output evaluated, and who owns the outcome?

Agents should not be free-roaming bots in financial operations.

They should operate inside governed workflows, with clear permissions, controls, evidence and expert oversight.

They have to be deterministic.

The industry talks about human-in-the-loop. In investment operations, I think the better phrase is expert-in-the-loop.

The settlements specialist. The private markets operations lead. The derivatives operations owner. The person who understands the workflow and the consequence of getting it wrong.

The goal is not human approval of every click; it is expert oversight where judgement genuinely matters.

Section 6

The next evolution

Many firms have already started by layering AI onto what they already have. That is understandable and it will produce incremental gains.

But it will not unlock the full value of AI.

The firms that go further will use AI as a forcing function to redesign operating control.

They will standardise the workflows and processes that should have been standardised years ago and then they will capture the operational memory that currently sits in people, spreadsheets, vendor platforms and workarounds. They will use agents inside governed workflows, not around them, and they will let experts own outcomes rather than manually chase every step.

They will be able to connect best-of-breed systems without losing control of the data value chain.

The next evolution across investment management will not be one more platform, one more outsourcing model or one more AI assistant.

It will be a governed operating layer across the systems, providers, data and workflows firms already use: a control layer that standardises workflows, preserves evidence, connects operational memory and lets AI act only inside clear permissions and expert oversight.

Fontana is building that layer. Not to replace the core investment systems firms rely on, but to make the work between them governed, auditable and ready for AI-native operations.

That is the foundation AI needs.

That is what Fontana exists to build.

Design pack

Reusable campaign assets

This article now has a small visual system around it rather than a single decorative image. The hero, section visuals, diagram, share card and pull-quote card can be reused across Substack, LinkedIn and investor materials.

LinkedIn/share cardOpen SVG asset
Pull-quote cardOpen SVG asset