Technology is changing in months while major platform decisions can last decades. How do Trustees, Executives, investors and regulators distinguish genuine innovation from the next expensive experiment?
Every legacy system was modern once. The challenge today is that we are making technology decisions measured in decades while technology itself is increasingly changing in months.
For more than twenty years, the superannuation and wealth industry has been trying to solve many of the same technology problems: ageing administration platforms, fragmented data, complex integrations, manual processes, expensive change and the difficulty of providing members and advisers with the seamless experience they increasingly receive elsewhere.
During that period there has rarely been a shortage of potential solutions. New-generation administration platforms would replace legacy systems. Service-oriented architecture and then APIs would solve integration. Cloud would transform infrastructure economics. SaaS would provide evergreen technology and shared development economics. Distributed ledger technology would remove reconciliation and create new models of record keeping. More recently, increasingly sophisticated data architectures, automation and now AI and agentic workflows promise to transform the economics of administration and servicing.
Many of these technologies are genuinely important. Some have fundamentally changed enterprise computing. The problem is not the technology itself. It is our repeated tendency to believe that the latest technology will finally remove complexity that is actually the product of decades of regulation, products, data, operating models, customer requirements and accumulated decisions.
There has never been a silver bullet. There have only been better tools — and the continuing requirement to know when, where and how to use them.
That distinction matters because the stakes are getting larger. A major core-platform decision can affect an organisation for 10, 15 or even 20 years. Yet the technology assumptions underpinning that decision may change materially before implementation is even complete.
The destination is moving while we are trying to reach it
The traditional transformation model was relatively easy to conceptualise. Understand the current state, define a target state, select the technology, implement it, migrate and then realise the benefits. In practice it was never quite that simple, but at least the destination could be treated as reasonably stable.
That is becoming much harder.
A large transformation may take several years from strategy and procurement through implementation, migration and stabilisation. During that period regulation changes, customer expectations move, security requirements increase, new providers emerge and existing providers consolidate. Cloud economics change. Data architectures evolve. New development tools appear. And now AI is changing at a pace that makes even relatively recent technology strategies look dated.
The organisation can therefore travel an enormous distance, invest substantial capital and successfully deliver what it originally set out to achieve, yet still feel as though it is treading water. The transformation has not necessarily failed. The destination has moved while the organisation was travelling towards it.
This is why I am increasingly uncomfortable with the term future-proof. Nobody knows precisely what the technology environment will look like in 2040, and pretending that we can select a platform today that somehow anticipates it is unrealistic.
A better objective is to choose technology that can continually become modern again.
Don’t ask whether a platform is built for the future. Ask whether it can keep changing as the future changes.
The newest technology is not necessarily the answer
There is an understandable attraction to starting again. If existing systems are complex, expensive and difficult to change, surely a new-generation platform designed without twenty years of accumulated legacy must be better.
Sometimes it will be.
But new technology has a different problem: it has not yet accumulated twenty years of operational learning.
Large financial platforms contain much more than software. Over time they accumulate knowledge about products, taxation, legislation, transactions, member behaviour, unusual events, exceptions, controls, reconciliations and the thousands of things that happen in production but rarely appear in an RFP.
A mature platform may carry technical constraints, but it may also embody enormous institutional knowledge. A new platform may have a beautiful architecture but still need to discover much of that complexity for itself.
This is why I don’t think old versus new is a particularly useful way of thinking about legacy.
A twenty-year-old platform that has been continuously modernised may be less “legacy” than a five-year-old platform that has become highly customised, difficult to test and expensive to upgrade.
Perhaps the better definition is that technology becomes legacy when the cost, risk and difficulty of changing it begin to outweigh the value of continuing to evolve it.
That produces a much more useful question for a Board:
Don’t ask how old the technology is. Ask how expensive the next change has become.
We have been here before
The industry’s experience with distributed ledger technology is instructive. DLT and blockchain generated enormous interest because they appeared capable of addressing some very real problems around distributed records, trust, reconciliation and transactions. There were credible use cases and substantial investment across financial services.
But the proposition that DLT would broadly sweep away conventional enterprise transaction-processing architectures proved much harder to realise. The technology had to coexist with regulation, privacy, existing systems, operating models, performance requirements and the commercial reality of migrating enormous established ecosystems.
That does not mean DLT “failed”. It means the real world proved more complicated than the initial technology proposition.
We should remember that as AI becomes the next great wave.
The same lesson applies to “next-generation” platforms. A new platform can genuinely have superior architecture, development economics and flexibility. But architecture diagrams do not prove production resilience, and a successful implementation for a smaller organisation does not automatically prove scalability to millions of members, decades of transaction history and institutional complexity.
Innovation requires somebody to go first. The governance question is how much production and capital risk should your members, customers or shareholders carry while the proposition is being proven?
Even choosing a database is becoming complicated
The changing database environment is a good illustration of how difficult technology decision-making has become.
Historically, the choices supporting major financial transaction systems were relatively concentrated around mature relational database technologies. Today architects can choose from relational databases, distributed SQL, document and key-value databases, graph databases, columnar and time-series technologies, cloud-native managed databases, data lakes, lakehouses and increasingly vector databases designed to support AI-related workloads.
There are good reasons for this innovation. Different technologies are optimised for different problems, and increasingly a sophisticated enterprise architecture may legitimately use several of them.
But this also makes the decision much harder.
The technically fastest database may not provide the right transaction integrity. The most scalable may not be the most economic at your workload. A highly attractive cloud-native service may increase dependency on one provider. A specialised database may create future skills or support risk. An apparently inexpensive solution can become surprisingly expensive as transaction, storage or processing volumes grow.
For critical financial infrastructure, the equation is much broader than performance:
stability, security, transaction integrity, availability, recovery, scalability, auditability, interoperability, portability, skills, support and lifetime economics all matter.
And we then need to ask whether the technology we select today will still have a viable ecosystem in ten or fifteen years.
This illustrates the real problem.
Enterprise architecture is rarely about finding the “best” technology. It is about finding the right combination of trade-offs for the job — while retaining the ability to change when those trade-offs change.
Then along comes AI
AI could be the most significant technology change in this entire discussion. It is already changing software development, knowledge work, data access and customer interaction. It has the potential to transform servicing, advice, operations and exception management, while increasingly capable agents may eventually orchestrate activity across multiple systems in ways that challenge our traditional ideas about workflow and applications.
We should embrace that opportunity.
But we should also be careful not to turn AI into the next silver bullet.
I am seeing increasing investment interest in wealth, superannuation and financial technology built around a proposition that can appear remarkably simple from the outside. Find an industry with fragmented technology, manual processes and high operating costs; introduce modern workflow, data and AI; automate the work; reduce headcount; scale across more customers; improve margins and create considerable enterprise value.
There are undoubtedly opportunities to do exactly that.
The problem is everything sitting between those boxes on the investment slide.
Financial-services complexity did not arise solely because nobody had invented a clever enough workflow engine. Much of it exists because organisations are trying to reconcile legislation, tax, prudential regulation, consumer protection, product rules, historical data, transaction integrity, operational controls and genuinely different customer requirements.
The experienced operations person who appears to be an expensive human step in a process may actually be applying judgement to exceptions the underlying data and systems cannot safely resolve.
Before automating the human out of a process, understand what the human was actually doing.
AI can make good people enormously more productive. It can accelerate development, identify patterns, interpret information, support decisions and potentially remove significant amounts of manual work.
But it can also allow an organisation to build the wrong solution much faster.
AI can reduce the cost of building software. It does not reduce the cost of misunderstanding the problem.
And misunderstanding the problem in regulated financial services can consume enormous amounts of capital.
Why apparently simple technology propositions become expensive
The pattern is familiar. A new technology proposition starts with an elegant architecture and a compelling business case. The first client arrives and requires some variation. Historical data needs more remediation than expected. Exceptions emerge. Integrations multiply. Regulatory requirements need interpretation. Controls are added. Testing expands. Another client has different requirements. More development is required. Specialist resources are recruited and timelines extend.
Gradually the clean technology proposition begins accumulating the complexity it was designed to replace.
This is not necessarily evidence of bad technology or poor management. Sometimes it is simply what happens when a theoretical solution encounters a complicated operating environment.
But it does mean investors and customers should be sceptical of business cases that assume complexity can simply be automated away.
The danger is not merely that the new technology fails.
The danger is that it succeeds in recreating the complexity it was supposed to remove.
This is particularly important for private-equity and other investors looking at financial technology. Technology-enabled margin expansion can be very real, but the investment thesis needs to understand what is genuinely automatable, what is client-specific, what is regulatory, what requires judgement, and how much of the development investment can actually be reused across multiple customers.
Otherwise the apparent software business can quietly become a highly customised technology-services business with very different economics.
SaaS does not remove the problem either
SaaS can create powerful economics when a provider maintains a genuinely common product and spreads development, regulatory change, security and technical investment across many customers.
But “SaaS” itself tells us surprisingly little about whether that happens.
Over time, client-specific development, different configurations, integrations, regional requirements and separately evolving components can result in what I think of as effective branching: a common change can no longer safely reach all relevant customers without separate adaptation, testing or release activity.
The important question is therefore not simply whether a provider has a “single code base”.
It is how many different versions of reality the provider must understand and test every time something changes.
The same applies to highly modular and composable architectures. APIs and best-of-breed components can create significant flexibility, but each boundary also creates an interface to secure, monitor, version, test and operate.
Every architectural boundary buys flexibility at the cost of coordination.
There is no universally correct answer between integrated and modular, old and new, incumbent and challenger, proprietary and open, or vendor-hosted and client-controlled.
There are trade-offs.
That is why experienced judgement matters.
Technology still needs knowledgeable humans
Perhaps this is the point we risk losing in the excitement around AI.
Successful financial technology sits at the intersection of three different requirements.
It needs to understand what the customer actually wants and how their business operates. It needs to understand what the regulator requires and how those obligations translate into processes, controls and evidence. And it needs to understand what can be delivered at an economic price that produces a sustainable return for shareholders or other capital providers.
Optimising one while misunderstanding the others rarely produces an enduring platform.
The winning model is not AI instead of human expertise. It is deep domain expertise amplified by AI, modern architecture and disciplined capital allocation.
That expertise is difficult to manufacture quickly.
It comes from understanding how financial products behave in the real world, how legislation becomes software, why operational exceptions exist, what clients genuinely value, how systems behave at scale and where technology expenditure actually creates economic value.
This is also why Boards, Executive teams, advisers and investors face an increasingly difficult problem. The technology environment is changing so rapidly that the knowledge required to challenge a major technology proposition is itself becoming perishable.
A Board cannot reasonably be expected to understand every new database architecture, AI model or orchestration technology. Nor should it.
But somebody around the table needs sufficient current, independent and deep expertise to challenge the proposition.
Are Boards and their advisers keeping up?
Technology governance has improved materially. Boards receive far more information about cyber, operational resilience and transformation. Funds employ experienced CIOs, CTOs, CISOs, data leaders and digital executives. Consulting firms have substantial technology practices.
That is positive.
But understanding technology risk is not necessarily the same as understanding technology strategy.
A Board can have excellent reporting on cyber incidents, project milestones, budgets and service levels without understanding whether the architecture is becoming easier or harder to change, whether the provider’s product is genuinely remaining common, whether technical debt is accumulating or whether the technology assumptions behind a five-year transformation are already being overtaken.
Protecting a complex technology estate is not the same as having the right technology estate.
Consultants face the same currency challenge. A rigorous RFP methodology cannot substitute for deep and continuously maintained knowledge of the platforms being assessed. A provider can change substantially in five years: ownership, architecture, product, cloud strategy, customer base, development economics and management can all change.
If we expect technology platforms to maintain their currency, we should expect the same from those advising Boards about them.
So what should we actually be looking for?
I don’t think the answer is another checklist of fashionable technologies.
For critical financial infrastructure, we should be looking for an architecture and operating model capable of balancing six characteristics that are individually easy to demand and extraordinarily difficult to optimise simultaneously:
Stability — can we trust it to operate critical services every day?
Security — can it protect members, customers, data and transactions?
Scalability — can it operate reliably and economically as volumes and complexity increase?
Adaptability — can we change components, products and processes as requirements evolve?
Longevity — can the environment continually modernise rather than gradually becoming another legacy estate?
Economics — can all of this be delivered at a sustainable lifetime cost?
The solution scoring highest on one dimension may not score highest on another. The newest may not be the safest. The most mature may not be the most adaptable. The most modular may not be the cheapest to operate. The most integrated may not provide the greatest optionality.
That is why the real job is optimisation rather than technology selection.
And perhaps there is a seventh characteristic sitting above all six:
the quality of the people making the trade-offs.
The questions I would put to a Board
Before committing members, customers or shareholders to another long-duration technology decision, I would want clear answers to a relatively small number of questions.
What are we assuming will still be true in ten years? Which parts of the proposed architecture are genuinely proven at comparable scale and complexity, and which are effectively experiments? If an important technology assumption proves wrong, can that component be replaced without replacing everything around it? Can the provider demonstrate—not simply assert—stability, security, scalability and the ability to remain current? What will it cost over 10 or 15 years to keep changing the environment rather than merely get it live? And finally, who is independently challenging these answers, and do they genuinely understand the technology, the customers, the regulation and the economics?
I would also ask one question that rarely appears prominently enough in a technology business case:
What happens if we are wrong?
That is not pessimism. It is good architecture and good capital governance.
There is no silver bullet
The next generation of superannuation and wealth technology will undoubtedly make greater use of AI, modern databases, cloud, APIs, automation and increasingly intelligent orchestration. Some emerging businesses will use those capabilities to disrupt incumbents, lower costs and create substantial value.
We should want that to happen.
But critical financial infrastructure cannot be built around the assumption that we will correctly identify every technology winner in advance.
Members need stability and security. Clients need functionality and adaptability. Regulators need control, resilience and accountability. Investors need scalability and sustainable economics.
Balancing all of them remains difficult.
And despite everything AI may change, that balancing act still requires serious human judgement from people who understand the industry deeply enough to know what should change, what should not, and why.
Perhaps the best technology decision is not the one that bets most confidently on the future. It is the one that leaves you best placed to respond when the future proves you wrong.
Every legacy system was modern once. Every silver bullet begins with a compelling story.
The challenge for Trustees, Executives, investors and regulators is knowing the difference between genuine architectural progress and another expensive technology experiment.
That is becoming harder, not easier.
And it is why the quality, independence and currency of the expertise around these decisions may ultimately matter as much as the technology itself.
