I was lucky when I started in operations. I joined a few years after a major transformation had already happened. The investment had started, new systems had gone in, and the business had tried to modernise.
And still, much of the work happened in Excel.
I would pull Bloomberg data and compare it to the system, then compare the system to a separate reconciliation tool. I would speak to actuaries using their own Excel models, and client service teams using another set of data for applications and redemptions. And we had not even got to performance fees and waterfalls. A lot of that was still calculated in Excel and eye-checked back to the book of record.
That is not because people were doing a bad job. It is because the operating model around them still relied on people stitching the stack together.
Ten years later, I walked back into the same business. The world around it had changed. Cloud had become normal. Regulation had increased. Settlement timelines had compressed. Margins were under pressure. Leadership teams had different targets. AI was starting to emerge.
But the stack was still on-premise, still heavily configured, a long way from standard, carrying decisions made for a different operating environment. That is when you realise something important.
Operations technology does not stay broken because people do not know it is broken. It stays broken because fixing it is expensive, risky and hard to justify.
Operations is judged differently
I have never liked the phrase “operational alpha”.
It sounds good in a sales deck, but it misses how operations is actually judged. The front office can justify technology through alpha, capacity or investment performance. Operations and accounting usually have to justify technology through cost reduction, risk reduction, control improvement or regulatory necessity.
That changes the entire investment case.
If a portfolio manager buys a system that helps performance, the value story is relatively easy to understand. If an operations team wants to change a core process, the conversation is different. How much cost comes out? How much risk is reduced? How quickly does the payback arrive? What breaks during the transition? Who owns the parallel run? What happens if NAV, reporting, cash, reconciliation or client outputs are wrong?
You cannot casually replace the systems and processes that calculate NAV, support reporting, reconcile positions, process cash and evidence controls. These processes may be inefficient, but they are critical.
So firms hesitate. And that hesitation is rational.
The old answer was a big transformation
The traditional answer has usually been a large transformation programme. New platform, new target operating model, new data model, new implementation partner, new migration plan, new budget.
These programmes can run for years. They touch accounting, operations, reporting, data, controls, client outputs and third-party providers. The cost is high, the delivery risk is real, and the people who understand the problem best are usually the same people keeping the business running.
They are closing NAV, resolving breaks, answering clients, managing cash, supporting audits and preparing regulatory reports. Transformation becomes another job on top of the job.
There is also the capex and opex problem. Large transformation programmes often need capital budget: big upfront spend, multi-year planning, steering committees and long approval cycles. A lot of modern technology sits differently. It is subscription fees, managed services, cloud infrastructure, usage-based pricing and continuous improvement.
That can make more sense operationally, but it creates friction inside large firms. A solution can be strategically right and still be hard to approve because it lands in the wrong budget, the wrong year, or the wrong part of the organisation.
So operations teams get trapped. They do not have enough budget to fix the foundation properly, but they have enough pressure to keep patching it. So the tactical workaround wins again.
Tactical workarounds become the architecture
Most operational workarounds start for good reasons. A spreadsheet gets built because the system cannot produce the right view. A macro gets written because the same file needs cleaning every morning. A manual check gets added because a provider feed is not always reliable. A side report gets created because the client wants data in a format the platform does not support. An IT ticket gets raised for a simple mapping change and sits in a backlog behind larger priorities.
None of that is irrational in the moment. It is usually the fastest and safest way to keep the process moving.
The problem is what happens over time. One workaround becomes ten. Ten become a process. The process becomes accepted. Then someone leaves. The spreadsheet stays. The macro stays. The manual check stays. The reason for it becomes less clear.
Ten years of rational tactical workarounds becomes an irrational operating model. That is what I have seen again and again. Not one big failure, just small decisions compounding for years.
The same thing happens with standardisation. Every transformation starts with a target operating model. Then a client needs something slightly different. A desk has a specific requirement. An asset class does not fit the model. A downstream report depends on an old field. Each exception makes sense on its own, but over time the standard bends.
Then bends again. Eventually the firm has implemented a new platform but recreated much of the old complexity inside it.
AI changes the economics, not the need for control
This is where AI matters. Not because AI removes the need for operational transformation. It does not. And not because AI means firms can cut people and declare victory. I do not buy that either.
AI changes the economics because it can reduce the cost of fixing the long tail of data-heavy operational work. Historically, a lot of that work was too small, too messy or too specific to automate properly.
Onboarding a new client. Migrating data from one platform to another. Mapping a custodian file. Checking a private markets extract. Validating reference data. Reconciling two views of positions or cash. Producing the evidence pack for why a value changed.
Each one matters, but each one sits in the awkward middle ground: important enough to consume time, not always large enough to justify a full transformation project. So firms handled them manually, semi-manually, with Excel, or with a tactical workflow built by someone who later left the business.
That is where AI should be useful. Not as a magic layer over a broken stack, but as a way to make workflow discovery, data mapping, rule capture, validation, testing and exception analysis faster and more repeatable.
But only if AI is operating inside a controlled structure. The workflow still needs to be governed. The data still needs to be validated. The rules still need to be approved. The evidence still needs to be retained. The expert still needs to own the outcome.
Otherwise the firm has not fixed the operating model. It has just created a faster way to produce another workaround.
What Fontana is building
I do not think the answer is another large rip-and-replace programme. Most firms already have too much invested in their systems, data models, reporting processes and provider relationships. They are not going to throw all of that away. Nor should they.
The better question is what layer is missing. For me, it is the layer that controls the data-heavy work between systems, providers and teams: onboarding, data migration, mapping, validation, reconciliation, exceptions, approvals and evidence.
That is where so much operational effort still sits. It is also where the knowledge of the firm is least well captured.
The next generation of operations technology should make that work explicit. What data is required, where it comes from, which rules apply, which checks need to pass, which exceptions matter, who owns the decision, and what evidence proves the outcome.
That is not operational alpha. It is operational control. And operational control is what lets firms scale without adding the same manual effort every time the business changes.
This is the problem Fontana is focused on. We are not trying to replace every system a financial firm already uses. We are focused on the data-heavy operational processes that sit between those systems.
The work that is critical, repetitive, knowledge-heavy and still far too manual. The aim is to capture the operating logic, standardise the workflows that should be standard, preserve the firm-specific variation that matters, and give experts and agents one governed foundation to work from.
That is how I think operations technology finally changes. Not through another enormous transformation that takes years before value appears. Not through agents bolted onto the same fragmented workflows. Through controlled, reusable workflows that make the long tail of operations easier to automate, govern and improve.
That is what Fontana exists to build.