Platform engineering in banking and financial services isn't just about building better tools - it's about navigating compliance, governance, and scale while keeping developers productive. In a recent leadership panel, three practitioners managing thousands of developers and trillions in payment volume shared hard-won lessons from building platforms in highly regulated environments. If you're working in BFSI or any compliance-heavy domain, these insights are directly applicable to the challenges you're facing today.

Main insights

• Duplication across business units is the biggest blocker to platform adoption - not leadership buy-in
• Compliance and governance must be embedded in golden paths, not bolted on as gates
• Platform engineering becomes the control plane for responsible AI and agentic development
• The human and cultural dimensions of platform adoption matter as much as the technical foundation

The panel brought together Jay Moran, who leads platform engineering at Fiserv supporting 8,000 developers across core banking and merchant acquiring systems; Manu Sood, who runs platform delivery and operations at Avid Exchange, a B2B payments company serving 8,000 buyers and 825,000 suppliers; and Eamonn Ryan, who leads product development for Visa's issuing solutions, bringing experience from Google's payment infrastructure and developer productivity teams. Mallory Haigh and Ajay Chankramath facilitated the discussion, drawing out practical insights across all three organizations.

You can watch the full discussion here if you missed it.

The real blocker: Duplication, not leadership

When the panel asked the audience what slows platform adoption most, the results surprised even the panelists. Leadership alignment and funding ranked high - but the overwhelming answer was "every business unit solving it separately." Jay Moran put it plainly: "That's absolutely my number one problem."

The challenge shows up in two compounding ways. First, identifying universal problems becomes nearly impossible when 100 teams have already chosen 100 different solutions. As Jay explained, "Each of them have already optimized locally. In their mind, this is the only way we could ever possibly do this." Second, that diversity creates operational debt that accumulates over time - Jay recalled being up all night resolving an incident caused by a team still running practices from 2005.

Manu Sood described how Avid Exchange tackled this by positioning platform engineering as foundational capability rather than just another infrastructure team. "We looked at the undifferentiated complexities in the infrastructure - you don't need different ways to manage your secrets, your APIs, your observability, your baseline CI/CD," he said. The key was balancing autonomy with standardization: "You still have the autonomy, you can build what you want to build, but it doesn't mean you have to build it alone and build it 50 times."

For platform teams in BFSI, this framing matters. The value proposition isn't control - it's eliminating redundant effort so product engineering teams own the business and the product outcomes and the customer outcomes, rather than reinventing shared infrastructure.

Compliance as capability, not gate

In financial services, compliance isn't optional. But the panel agreed that governance must accelerate delivery, not slow it down - and that only happens when you build it into the foundation from the start.

Jay described the audit burden directly: "There is nothing better than having a path that already presents the evidence, all the artifacts needed to show that yep, we had two exceptions." Rather than treating compliance as a checkpoint at the end of a delivery cycle, the platform encodes it into the golden path itself.

Eamonn emphasized that compliance requirements vary significantly by domain: "There are very specific compliance requirements for the type of data or even down to the type of transaction that you're dealing with." Platform engineering addresses this by applying guardrails at the domain level. "If you're dealing with financial transactions and you have a security finding or vulnerability related to that, there is a golden path to fix that within that very specific domain."

Mallory synthesized the practical outcome: "If we can make that golden path so compliant by default, not only does it make us have an easier user experience from the self-service perspective, but now we have something that we can really monitor, we can really audit, we can really track."

Manu drew an important distinction between two types of guardrails. Hard guardrails - covering PII, account numbers, and AI gateways that enforce anonymization - are non-negotiable. Soft guardrails are architectural patterns that prevent teams from drifting into unsupported configurations. Both serve developers, but in different ways: one protects the organization, the other protects the team from future pain.

The metrics that matter

The panel challenged conventional platform engineering metrics. While DORA metrics remain a useful baseline, success in BFSI increasingly depends on connecting platform work to business outcomes and developer experience.

Jay tracks both internal sentiment and external business signals. "We leverage the DX folks to really ask people how they're doing and we're seeing slow but moving improvements in a few categories that are directly representative of what platform engineering offers." He also measures time to market for new features and time to revenue for client onboarding - metrics that make platform value legible to business stakeholders.

He was candid about a gap that many platform teams face: "I know our cyber security cost. I know my own cost for developer experience. What I don't know is the cost to the 8,000 developers sitting out in the field." The hidden costs - features delayed because teams are handling security remediations instead of shipping - are real but hard to quantify. Closing that measurement gap is an ongoing challenge worth prioritizing.

Preparing for agentic development

The conversation around AI and agentic development produced one of the panel's clearest takeaways: platform engineering becomes more important as AI adoption grows, not less.

Manu stated it directly: "Agentic development makes platform engineering more important, not less, and allows us to move governance from something that the humans have to remember to do to platform enforcing that governance or embedding that governance in the platform itself."

Eamonn described the challenge of working with AI agents in production: "We have agents and I like to call them my engineers that I didn't actually interview them and they're quite unpredictable. So we have to put these guardrails in place." He emphasized that platform engineering must provide guardrails across both the inner loop - code generation constrained to target architecture - and the outer loop - deployment governed by domain-specific compliance and reliability requirements.

Jay highlighted the amplification effect that makes platform foundations so critical: "All the agent and AI is going to do is amplify what you have." Teams already operating within the platform's golden paths responded to incidents like Log4Shell significantly faster than teams working outside it. AI doesn't change that dynamic - it accelerates it in both directions.

Mallory offered a grounding prerequisite: "If we can't even write a readme.md, how the hell can we write an agent MD?" Organizations must solve platform engineering for human developers first. Adding autonomous actors to a fragmented, undisciplined environment doesn't solve the underlying problems - it scales them.

The human side of platform adoption

Jay closed with what he called the most important insight of the discussion: "I'm going to deviate a little bit, but I'll say it's the human aspects of what we're talking about."

Changing how people work is hard in any organization. In financial services, where regulatory compliance has been "drilled into your brain for a very long time," it's harder still. Platform teams aren't just shipping tooling - they're asking practitioners to trust a new way of working that may feel less safe than what they know.

"We as platform engineering teams must - I love Mallory's concept of she's the platform therapist and it's so accurate because that's what we all are when we actually engage with our users," Jay said. "We're having to change what they know is like this is the way that we're safe. This is the way that we comply and you're asking them to really take a leap of faith sometimes or at least be open to change."

Mallory reinforced the commitment required: "You have to invest in the mindset. You have to invest in the practice. You have to believe in it. It is something you do and you believe in, no matter the vertical you're in."

​

If you enjoyed this, find more great insights and events here from our Platform Engineering Community.

If you want to dive deeper, explore our instructor-led Platform Engineering Certified Leader course and connect with peers from large-scale enterprises who are driving cultural transformation.

​

Key takeaways

• Solve duplication before scaling: The biggest barrier to platform adoption in BFSI isn't leadership buy-in - it's locally optimized solutions proliferating across business units. Build your value proposition by demonstrating that global optimization outweighs local customization, and frame the platform as foundational capability rather than another infrastructure team.
• Embed compliance in golden paths: In regulated industries, compliance must be built into platform capabilities from day one, not added as a gate at the end. Domain-specific guardrails make self-service both easier and more auditable, reducing burden on development teams while satisfying audit requirements automatically.
• Platform engineering enables responsible AI: Agentic development requires strong platform foundations with audit trails, approved templates, policy boundaries, and identity management. Without these, AI amplifies existing problems rather than solving them. Solve platform engineering for humans first, then extend those foundations to autonomous actors.
• Invest in the human side: Platform adoption is as much about changing organizational culture and work habits as it is about building technical capabilities. Platform engineers must act as change agents - helping teams understand why standardization benefits them, not just mandating it from above.