“Systems reconcile the parts. Experts understand the whole picture.”
Bridge from blog 1
In the first post, I wrote about the evolution of investment management and why the current stack was not built for AI. This is the next part of that argument: the stack did not just fragment systems. It pushed coordination into people.
Opening
The marketing version of financial operations is dashboards, straight-through processing rates and automation percentages.
The reality is messier.
A client service manager at a custodian tries to answer one client question with five or six files from five or six teams.
An operations manager at an asset manager pulls data from three systems, checks a spreadsheet, asks someone in accounting, then waits for IT to fix a mapping change that has been sitting in a backlog for months.
A trade confirm arrives as a PDF.
A reconciliation lives in Excel.
An approval sits in email.
A phone call to a custodian fills the gap.
A colleague knows exactly why a break happened because they have seen the same issue for fifteen years.
That is still investment operations in many firms.
Not because the people are weak.
The people are the reason the model still works.
That is the problem.
Financial firms never built a proper coordination layer between systems, providers and teams.
So people became the coordination layer.
AI cannot safely fix that unless the coordination layer is made explicit.
Inside the outsourcer
Take a global custodian or fund administrator servicing a large asset owner.
A client service manager sits between the client and the operating teams. Behind them are separate teams for reconciliations, settlements, corporate actions, collateral, accounting and data.
Each team has its own system view.
Reconciliations pulls from a data lake, processing system or reconciliation platform and runs its checks.
Settlements does the same.
Corporate actions does the same.
Collateral does the same.
Accounting does the same.
By the time the client service manager gets the output, they are not holding one clean operating view. They are holding files, extracts or reports from different teams, created from different systems, at different times, with different assumptions underneath.
Their job is to stitch that together before the client sees it.
That is not straight-through processing.
That is manual coordination.
The client then receives a batch snapshot shaped by the provider's operating model. It may not map cleanly to the way the client's fund office, investment team or internal reporting process needs to see the data.
So the client reconciles it again.
Count how many times the same data is extracted, interpreted, checked and re-proven between the source and the decision maker.
The first reconciliation may add control.
The fourth and fifth often add cost, delay and risk.
This is the cake factory problem from the first post.
One team sifts the flour. Another beats the eggs. Another watches the oven.
Everyone understands their task.
Too few people own the cake.
Inside the asset manager
Bringing operations in-house does not remove the fragmentation.
It usually moves it.
A typical asset manager may have separate teams for static data, pricing, portfolio accounting, NAV, collateral, reconciliations, corporate actions, settlements, compliance and client reporting.
Each team owns its slice.
Each team has its own tools, controls, spreadsheets, reports, queues and priorities.
Now trace one issue.
Someone loads a stale or incorrect price.
It flows into portfolio accounting.
It affects NAV, performance, exposure reporting or client reporting.
Accounting catches it before publication, and the hunt begins.
Where did it come from?
The vendor?
The custodian?
The accounting platform?
The pricing team?
The trader?
A manual override?
Most teams do not have clean lineage showing where the value originated, who touched it, what changed, and why.
So the investigation follows habit.
Check the custodian.
Check the trader.
Walk through the internal teams.
Sometimes "walk" is literal.
When I was in operations, issues were often resolved by email, by phone, or by getting up from your desk and finding someone on another floor who knew what had happened.
That still happens.
A lot of operational work is still done off-platform. Not because people want it that way, but because the official platform does not capture how the work actually gets done.
Reconciliation tools sit outside the middle- and back-office platform.
Client reporting sits somewhere else.
Custodian data arrives in one shape and trader data in another.
Trade confirms arrive as PDFs or emails.
Operations teams pull data out of systems, run macros, build Excel checks, and wait for IT to write SQL, build integrations, fix mappings or prioritise a change request.
That backlog matters.
In operations, a "small" mapping change can sit behind a much larger technology priority for months.
In the meantime, the team builds a workaround.
Then another workaround.
Then the workaround becomes part of the operating model.
The expert is the control layer
Most platforms can detect that something has gone wrong.
They do not always understand why, what the consequence is, or how it should be resolved.
That is where the expert comes in.
Someone who has worked in settlements for fifteen or twenty years can look at a failed instruction and know immediately that the market, broker, fee, SSI, account or cut-off does not make sense.
The platform sees an exception.
The expert sees the cause, the consequence and the likely fix.
That is not just process knowledge.
It is pattern recognition.
It is knowing what usually breaks, which provider behaves in a certain way, which field is often wrong, which exception matters, and which issue will cause a downstream failure if it is not fixed today.
That knowledge is valuable.
It is also barely protected.
It lives in people's heads.
It lives in spreadsheets.
It lives in email threads.
It lives in team habits, informal checks, old macros and undocumented workarounds.
Operations teams provide continuity. Experienced people are often the permanent memory of the firm.
But people are not permanent.
They move teams.
They leave.
They retire.
They get pulled into projects.
When they go, a lot of operating knowledge goes with them.
That is why "human-in-the-loop" is not enough for investment operations.
The human in the loop cannot just be anyone.
It needs to be the expert in the loop.
The person who understands the workflow, the market, the data, the provider behaviour, the exception history and the consequence of getting the decision wrong.
If firms want AI agents inside these workflows, they need to capture that expertise in a form the system can use.
Otherwise the agent inherits the exception queue without inheriting the judgement that resolves it.
The pressure is rising
If this operating model were static, firms could keep absorbing the problem with people.
It is not static.
Settlement timelines are compressing.
North America moved to T+1 in 2024. The UK, EU and Switzerland are scheduled to move to T+1 in 2027.
That matters because the post-trade processing window gets much tighter, especially across time zones.
A European or Asia-Pacific firm trading into the US does not experience T+1 as an abstract market structure change.
It experiences it as a shorter window to allocate, affirm, fund, instruct, match, investigate and resolve.
Regulatory reporting is also becoming more granular, more structured and more evidence-heavy.
EMIR Refit is a good example. The EU rules applied from April 2024 and the UK rules from September 2024. They increased the level of structure, validation and consistency expected in derivatives reporting.
Volumes are rising too.
Front-office technology makes execution easier.
Markets remain volatile.
Private credit, private markets and alternatives keep growing.
That creates another operating challenge I have seen repeatedly: a public-markets firm buys, builds or expands into a private-markets strategy and tries to run two very different operating models on one architecture.
That rarely works cleanly.
Public and private markets have different data, documents, valuation cycles, cash-flow patterns, controls and reporting expectations.
Merging the org chart is easy.
Merging the operating logic is where it breaks.
Every one of these pressures lands on the same fragmented foundation.
The workarounds that survived T+2 will not necessarily survive T+1.
The spreadsheets that worked for one asset class do not necessarily work for another.
The expert who could hold the process together manually cannot scale indefinitely.
AI inherits what is underneath
This is why I am sceptical of the idea that AI can simply be layered onto the current operating model and fix it.
Agents can help.
They can read documents, classify breaks, draft responses, compare files, suggest likely causes and investigate faster than a human in many situations.
But if the workflow underneath is fragmented, the agent inherits the fragmentation.
If the data lineage is missing, the agent inherits the missing lineage.
If the judgement sits in someone's head, the agent does not automatically get that judgement.
If the process is really an email chain, a spreadsheet and a phone call, the agent is not operating inside a controlled process.
It is operating around one.
That is dangerous.
AI does not just make work faster.
It makes whatever is underneath faster.
If the foundation is governed, documented and evidenced, that is powerful.
If the foundation is fragmented, ambiguous and undocumented, that is risk.
The coordination layer needs to become explicit
None of this is a people problem.
The people in these teams are capable and experienced. In many cases, they are the reason the operating model works at all.
That is the issue.
The industry never built the coordination layer between systems, providers and teams, so people became it.
Manual reconciliation is the coordination layer.
Email is the coordination layer.
The client service manager stitching together five files is the coordination layer.
The expert who spots the wrong settlement instruction before it becomes a failure is the coordination layer.
AI does not solve that by being added on top.
The next operating model needs to make that hidden coordination layer explicit.
Which system is trusted for which data.
Which workflow owns which outcome.
Which rules apply.
Which exceptions matter.
Which expert should approve the decision.
Which evidence proves what happened.
Which actions an agent can take.
Which actions require escalation.
That is the foundation AI needs.
The fix is not more people.
It is not agents bolted onto the current stack.
It is capturing operating knowledge, standardising workflows, and giving experts and agents one governed foundation to work from.
That is what Fontana exists to build.