Platform Engineering in Financial Institutions: The Practitioner Panel
- Daniel Bryant
- Jul 17, 2025
- 7 min read
This is a lightly edited summary of a KubeCon EU Platform Engineering Day panel with Paula Kennedy (Syntasso) hosting Suhail Patel (Monzo), Jinhong Brejnholt (Saxo Bank), Rachael Wonnacott (Fidelity), and Mark Campbell (NatWest Bank).
Platform engineering is no longer a niche discipline. Paula Kennedy opened this Platform Engineering Day Europe 2025 panel by quoting the CNCF Platforms Working Group’s definition: a platform is "an integrated collection of capabilities defined and presented according to the needs of the platform users.” When done well, platforms enable faster delivery, better reliability and resilience, reduced risk (especially security and regulatory), lower costs, and a better developer experience.
She adds a Gartner prediction to set the tone: by 2026, 80% of large organisations will have platform engineering teams, and platform engineering will help solve the long-standing cooperation problem between developers and operations.
So, platforms are good. Everyone should have one.
But Paula’s real question is sharper: is that still true in heavily regulated industries like financial services? What changes when the platform sits inside a bank, an investment firm, or a trading organisation?
The rest of the panel answers that question through the lens of real-world experience. And while many challenges sound familiar to any large enterprise, the financial services context adds some uniquely sharp edges.
The biggest challenge
The biggest platform challenge in finance is not Kubernetes. It is people at scale.
Paula starts by asking each panellist what their platform teams are currently wrestling with.
At NatWest, Mark Campbell describes the biggest challenge as alignment at scale. NatWest’s tech function is a quarter of the bank, with 10,000–15,000 engineers across development and infrastructure. Introducing platform engineering means aligning thousands of opinions behind a common approach. Adoption is difficult, but the underlying challenge is shifting how the organisation works while still delivering day-to-day value to customers.
Monzo’s Suhail Patel describes a different situation. With around 500 engineers and cloud-native roots, Monzo has had platform thinking embedded from the start. Their challenge is further along the curve: how to evolve a cloud-native platform as new needs emerge, especially with machine learning and AI, while still prioritising portability and open source. Suhail points to an uncomfortable trend: vendors and cloud providers increasingly optimise for lock-in, which runs counter to what regulators and financial advisors often want.
Saxo Bank’s Jinhong Brejnholt echoes the “change is hard” theme, but frames it slightly differently. Saxo’s platform teams adopt new practices quickly, which is a strength, but each new improvement introduces change and learning for developers. Even if the outcome simplifies things, the transition is time-consuming and hard to prioritise because the value of the platform is difficult to quantify. Measuring outcomes becomes a challenge in itself.
At Fidelity International, Rachael Wonnacott highlights maturity variance across the organisation. Teams sit at different points in the distribution, from “10-star” teams racing ahead to teams that need a more basic baseline. The platform must cater to the masses, often requiring less elegant solutions to support migration, while simultaneously trying to keep advanced teams engaged. On top of that, legacy and on-prem systems still need to be brought forward.
At this point, Paula zooms out. Many of these challenges sound universal: change, adoption, scale, maturity, legacy. So what is actually different in financial services?
Universal Challenges, Different Industry
In finance, open source attracts additional scrutiny, even when it shouldn't. Unsurprisingly, regulation becomes the pivot.
Jinhong describes a bank’s “no grey zone” mentality. Even a slight reputational risk can trigger pressure to move away from a technology choice. That makes open source adoption harder, not because open source is inherently unsafe, but because the consequences of being perceived as unsafe are significant.
Suhail adds that regulators often attach meaning to the names of technologies without understanding the nuance. Mention Kubernetes, and you risk being compared to an organisation that runs it poorly. He points out the irony: many institutions find it easier to buy proprietary third-party technology because the “guarantees are written on paper,” even though open source is auditable, customisable, and modifiable in ways closed-source products are not. That ability to inspect and adapt is underleveraged, and regulatory discomfort can become a barrier to innovation.
Rachael offers a useful angle: in her experience, regulators’ root concern is often less about open source and more about the pace of change. By the time an audit is complete and an auditor is comfortable with policies and controls, the technology landscape has moved on. AI increases that acceleration, and regulation typically lags innovation.
Her framing is pragmatic: platforms can actually help with regulation because they make controls repeatable. If every namespace behaves the same way, the audit surface area can be reduced to a standardised configuration rather than a sprawling set of bespoke implementations. In other words, platform engineering can be a story of risk reduction and auditability, not just developer enablement.
Still, she notes that auditors are people, too. Explaining modern platform patterns in an accessible language is part of the job, even if it is frustrating. She also questions how much responsibility should rest with the organisation being audited, especially when auditing is a paid service.
Mark emphasises that financial institutions must be deliberate. NatWest has built an Open Source Program Office precisely to address questions such as security, support, governance, and long-term viability. The core point is that in highly regulated environments, you cannot “just adopt” a tool. You need defensible answers for stakeholders and regulators and a narrative explaining why this is safe.
Jinhong adds one more dimension that is especially relevant right now: licensing. When open-source projects shift licensing models, it creates distrust and uncertainty among regulated organisations. Even if a tool is safe today, the question becomes whether it will remain safe and usable under tomorrow’s license terms.
Measuring platform success: adoption is not enough
The panel then moves into measurement, a topic that has clearly sparked debate in previous sessions. Paula asks how they measure platform success.
Suhail focuses on internal satisfaction and enablement. A platform can be technically perfect, but if it does not help engineers ship reliable products, then it has failed. He also frames cloud-native tooling as exactly that: tools. The success measure is not the tools themselves, but whether the organisation can reliably deliver what customers need.
Mark explains NatWest’s measurement evolution. Historically, they tracked adoption through cloud migration progress: how many apps were containerised, how many ran on their platform. Now that they are building “platform as a product” capabilities, they focus on enablement: how many useful components and products they can offer, how easy those are to use, and the feedback from early adopters. Adoption metrics come later, once the platform has a critical mass of valuable capabilities.
Rachael describes a tension that many platform teams experience but do not always voice. Business goals and developer experience do not always align. Standardisation improves predictability for cost and audit, but can reduce flexibility and choice for engineers. She argues the platform must be positioned honestly: it is built for the organisation, not just for developers, and that expectation needs to be set clearly to avoid confusion and frustration.
Jinhong shares two measures Saxo prioritises. First, disaster recovery and recoverability. With DORA (DevOps Research and Assessment) now shaping expectations, the speed of recovery matters across both platforms and applications. Second, what she calls “developer suffering”: how painful it is for developers to get things done, like Kafka topic creation or database access. She also highlights a key challenge for mature enterprises: the platform experience must work both inside and outside Kubernetes, because real systems are hybrid and recovery must consider the whole estate.
Final advice: the platform can only take you so far
In closing, Paula asks each panellist for one final piece of advice.
Jinhong’s advice is to think about recovery beyond GitOps assumptions. Your Helm charts might be in Git, but many dependencies live outside the cluster: DNS records, external assignments, and other critical infrastructure that can be deleted or compromised. Full recovery requires automation across the whole system, not just Kubernetes.
Suhail warns against fixating on tools. Cloud-native technologies cannot compensate for applications that are not designed for reliability. If the foundations are shaky, adding more layers to the platform can amount to “papering over” the real problems. Platform teams must work with application engineers and build for the applications they actually run today.
Rachael builds on that with a more theoretical but important point: you can only abstract so far. Cognitive load does not disappear; it moves. Teams still need a baseline level of understanding, even with strong APIs and a single entry point. The platform cannot eliminate learning entirely, and leaders need to set expectations accordingly.
Mark shifts the emphasis to people. If you are starting platform engineering, find the right group of people. Mix broad technical experience with early-career engineers who are eager to learn. Build something genuinely useful with early adopters, gather feedback, and talk openly about progress to build momentum across the organisation.
Closing thoughts
This panel refused to romanticise platform engineering in financial services. Yes, platforms can improve speed, reliability, resiliency, cost, and developer experience. But in regulated environments, platform engineering is also about auditability, trust, and deliberate change.
The biggest lessons are not purely technical. They are organisational:
Adoption and alignment are hard at scale
Regulation amplifies the need for standardisation and clarity
Open source is valuable, but requires governance and storytelling
Platform success must be measured in outcomes, not just adoption
Abstraction has limits, and cognitive load must go somewhere
Ultimately, tools matter less than building reliable systems and enabling people
In finance, the platform is not just a delivery engine. It is a control system. And if you want it to succeed, you have to build it with that reality in mind.
→ Watch the full panel discussion: https://www.youtube.com/watch?v=KTzQTuGgBeg
→ Read more on roles and expectations in internal platforms: https://www.syntasso.io/post/platform-producers-and-consumers-beware-the-missing-persona-when-building-an-idp
Comments