Despite years of investment, core modernisation remains an ongoing challenge for many Australian banks. The infrastructure is ageing, the technical debt is compounding, and the distance between where the business needs to go and what the core can currently support is, in some cases, widening faster than it's closing.

The standard diagnosis: legacy is the problem. Modernise the core and innovation follows.

Here's the part that doesn't make the roadmap presentations. Most of Australia's major financial institutions have been modernising for years.

They've migrated workloads, adopted hybrid cloud, stood up APIs over the top of core systems, and hired platform engineers to wrangle the whole arrangement into something resembling a coherent architecture.

And yet the gap persists.

Not because the technology is unavailable. Because the complexity of managing the transition — across compliance obligations, cost pressures, data fragmentation, and operational risk — is larger than any single team, vendor, or project timeline can hold.

The question was never cloud or no cloud. It was: Who owns the complexity in the gap between where you are and where you need to be?

That's where the real modernisation problem lives.

Legacy core platforms — the mainframes, the monolithic banking systems, the decades-old transaction engines — are often framed as the villain of digital transformation. The framing is understandable but imprecise.

The core isn't frozen because no one knows how to modernise it. It's frozen because the risk calculus of moving it is genuinely complex.

These are systems that process millions of transactions daily, operate under strict APRA oversight, and sit at the centre of data architectures that have accumulated thirty years of interdependencies. The decision to modernise isn't a technology decision. It's a business continuity decision, a regulatory decision, and a cost decision, simultaneously.

What legacy platforms actually constrain isn't innovation in the abstract. It's the speed at which innovation can be operationalised. A bank can build a beautiful customer-facing app. It can deploy real-time personalisation at the front end. But if the data feeding that app is living in a batch-processing core that reconciles overnight, the experience is a facade over an infrastructure that hasn't moved.

The constraint isn't the core itself. It's the data latency, the integration debt, and the pace at which changes can be safely deployed.

There's a persistent narrative in technology circles that hybrid cloud is a transitional state, a halfway house between on-premises legacy and a pure-cloud future that every serious FSI is supposedly moving toward.

The data and market signals disagree. For many Australian banks, hybrid and multi-cloud aren’t a stepping stone. They’re the long-term operating model. Not because of a failure of ambition, but because they fit the regulatory, operational, and risk profile of financial services — and align with APRA’s risk-based expectations for cloud use.

APRA's CPS 231 and CPS 234 frameworks don't prohibit cloud. But they impose material obligations around operational risk management, data sovereignty, and third-party oversight that make a full lift-and-shift to public cloud (for core workloads, at least) a significant compliance undertaking. The FSIs moving fastest aren't the ones pursuing full cloud migration. They're the ones that have accepted hybrid as the architecture and designed for it deliberately: sensitive data and core workloads in controlled environments, customer-facing and analytics workloads in scalable cloud infrastructure, with unified data pipelines holding the whole thing together.

The question isn't whether to go hybrid. It's whether your hybrid architecture is intentional or accidental.

There is no single path to core modernisation, and any vendor or consultant who tells you otherwise is selling you their preferred approach, not the right one. What works depends on the institution's risk appetite, regulatory posture, existing architecture, and — critically — the internal capability available to manage the transition.

That said, the evidence from FSI modernisation programs globally points to a few consistent patterns.

Phased, domain-by-domain modernisation tends to outperform ‘big bang’ replacement on risk and survivability because it reduces disruption, contains failure, and lets teams learn as they go.

Pulling one domain off the legacy core (payments, or lending origination) and migrating it to a modern platform while leaving the rest intact reduces blast radius, allows for genuine learning. It's slower. It's also survivable. And it aligns far better with APRA’s emphasis on operational risk management and maintaining critical operations through disruption.

Parallel-run (‘coexistence’) architectures are also common in always-on banking environments. Running legacy and target systems concurrently, with gradual migration and strong controls, adds overhead but it materially reduces downtime risk, especially in high-volume transformations.

What doesn't work: treating core modernisation as a project with a defined end state. The FSIs that have made the most progress are the ones that have reframed it as a continuous capability — a permanent shift in how they design, deploy, and operate systems, not a migration with a go-live date and a champagne moment.

“Making that shift — from a one-time migration to a continuous capability — requires a different approach. A phased, risk-managed model helps FSIs move forward without unnecessary risk, while co-managed models give them access to deep expertise without giving up control of their systems and decisions.” says Adrian Capolino, Head of Technology Solutions at Canon Business Services ANZ.

The compliance conversation around cloud modernisation in financial services has a bad habit of going in one of two directions. Either APRA obligations are treated as a reason not to move — a regulatory ceiling that forecloses options — or they're treated as a box-ticking exercise that sits at the end of the project, to be managed by the legal team once the architects have finished.

Neither position is tenable.

APRA's prudential standards — CPS 231 on outsourcing, CPS 234 on information security, and the newer CPS 230 on operational resilience — aren't obstacles to cloud modernisation. They're a design brief. They tell you what the architecture must do to demonstrate: clear accountability for third-party risk, robust data security controls, documented recovery capabilities, and evidence that the board understands the risks it's taken on.

The FSIs making the fastest progress are the ones that have absorbed the APRA framework into their architecture decisions from day one — not bolted compliance onto a design that wasn't built for it. The difference in outcome is significant. The difference in timeline is even more significant.

Working with a partner who understands the APRA landscape — not just the technology, but the regulatory intent behind it — isn't a nice-to-have. It's the difference between a migration that sails through its prudential review and one that stalls in it.

Cloud promised predictable costs. AI complicated that promise considerably.

The economics of cloud infrastructure were relatively straightforward when the primary workloads were application hosting and data storage. Variable costs were manageable because usage was relatively predictable. The arrival of AI, specifically, the appetite for large-scale model training, inference at volume, and real-time data processing, has introduced a class of compute demand that is neither predictable nor cheap.

For Australian FSIs deploying AI for fraud detection, credit risk modelling, or customer personalisation, the compute costs associated with model inference can spike dramatically during periods of high demand. Without rigorous cost governance and an architecture designed for cost visibility, cloud spend can scale faster than the business value it's generating.

The answer isn't to avoid AI workloads. It's to build the cost governance in before the spend starts. That means tagging and attributing cloud costs at the workload level, building autoscaling policies that respond to demand curves rather than worst-case estimates, and maintaining a unified data layer that prevents the same data from being processed multiple times across siloed environments.

The institutions that arrive at AI-readiness with clean, governed, unified data are the ones that get ROI. The ones that arrive with a fragmented estate get a very large cloud bill and a very modest model.

Financial institutions aren’t short of data. They’re frequently short of data they can actually use — quickly, reliably, and across the business.

The fragmentation problem is architectural. Decades of system acquisitions, product-line silos, and bolt-on integrations have produced data estates where the same customer can appear in seven different systems with seven slightly different records, where risk data sits in a different environment from customer data, and where the pipeline between raw transaction data and actionable insight runs through so many transformations that by the time it arrives, it's stale.

Unified data architecture — a single, governed layer through which all data flows, regardless of where it originates or where it lands — isn't just an infrastructure efficiency. It's the prerequisite for every high-value use case financial institutions are trying to pursue: real-time fraud detection, personalised product recommendations, credit risk modelling that reflects the customer's actual current position rather than their position as of the last batch run.

The modernisation programs that treat unified data as an outcome — something they'll build once the core migration is complete — are building on sand. The programs that treat it as a foundation are the ones that arrive at AI-readiness with something to actually work with.

There's a floor beneath all this that rarely gets named in modernisation discussions, because it's assumed. It shouldn't be.

Financial systems don't get to have downtime. Not scheduled, not unscheduled. The operational resilience requirements embedded in CPS 230 make this explicit but banks and FSIs have always known it. The expectation of always-on availability is loadbearing for customer trust, regulatory standing, and the institution's licence to operate.

What changes in a modernised, cloud-enabled environment is the way resilience is engineered.

On a legacy monolith, resilience meant redundancy: two of everything, failing over to the second when the first went down. In a distributed cloud architecture, resilience means something more sophisticated: circuit breakers, graceful degradation, chaos engineering, and recovery time objectives that are tested in production, not just documented in a BCP.

The institutions that conflate modernisation with resilience — assuming that moving to cloud automatically makes them more resilient — are making a category error. Cloud gives you the tools. The architecture and the operational discipline are what actually deliver the always-on outcome.

Here's the position most FSI technology leaders won't say out loud: the gap between "we need to modernise" and "we have the internal capability to do it at the required pace, with the required risk controls, while keeping the lights on" is, for most institutions, substantial.

This isn't a failure of ambition. It's an honest accounting of the talent market, the regulatory environment, and the operational demands of running a financial institution while simultaneously rebuilding its foundations.

The co-managed model, where an external partner takes genuine ownership of defined parts of the modernisation program with clear accountability structures and integrated governance, addresses this gap in a way that neither full outsourcing nor pure in-house delivery can.

CBS's end-to-end model is built around this principle. From legacy assessment and migration strategy through to cloud operations, compliance support, and AI-ready infrastructure design, the engagement is structured to reduce the burden on internal teams at the points of highest complexity — without displacing the institutional knowledge and governance that has to stay in-house.

“The reality is, not every capability can be built in-house at the right speed. Co-managed models bring that missing depth — without taking control away from the organisation.” says Ricki.

The modernisation conversation in Australian financial services has been running for a decade. The institutions still stuck in it aren't stuck because the technology isn't available. They're stuck because they've been trying to solve a complexity ownership problem with a technology procurement decision.

Cloud and core modernisation matter. Not because the legacy core is the villain but because the gap between where most FSIs are and where they need to be is real, consequential, and narrowing faster than internal capacity can manage alone.

The question isn't whether to modernise.

It's whether you have the right architecture — and the right partner — to hold the complexity while you do.

Canon Business Services ANZ works with Australian financial institutions at every stage of the cloud and core modernisation journey from legacy assessment through to AI-ready infrastructure. To discuss what end-to-end support looks like for your institution, speak with our team today.