From Compliance Obligation to Competitive Platform: How WSO2 Goes Beyond Open Banking Compliance
- Ashirwada Dayarathne
- Associate Technical Lead, WSO2
UK Open Banking has moved well beyond the regulatory compliance era and is focusing on creating business value with the platforms. With the latest standards now in effect, variable recurring payments (VRPs) going live, and the FCA's Open Finance plans running all the way to 2030, the real challenge for CTOs and tech leads has shifted. It's no longer about whether to comply, but rather how to do it without constantly rebuilding your systems and how to actually get business value from the effort.
The regulatory moment
The biggest spec change since 2018
V4.0 is the most significant Open Banking update since the original mandate. For banks still on v3.1.x, it's not a simple upgrade; it touches security, consent, and payment messaging at once, with four key areas demanding attention: ISO 20022 alignment, FAPI 1.0 Advanced, updated VRP consent handling, and revised third-party registration flows.
The FAPI security cliff
FAPI 1 ID2 was retired in March 2025. Migration means updating your authorization server, client registration, and token endpoints. If you're on a vendor platform, find out whether they've shipped a compliant release yet.
VRPs: From sweeping to commercial
Commercial VRPs went live in Q1 2026, expanding beyond sweeping to cover subscriptions, utility bills, and invoice settlement. VRP type must now be explicitly declared in both consent and initiation flows; banks that only built sweeping support will need a cross-team effort to get there.
The compliance calendar
CMA9 banks get 6 months to implement major spec changes, and non-CMA9 banks get 9 months from the publication date. The clock starts on the date of specification release, not when the team becomes aware of the change. With Open Finance and the Data Act driving continuous change through 2026 and beyond, compliance is not a one-time project.
Build vs. buy
Building Open Banking compliance in-house almost always costs more than onboarding an established platform. Each spec version transition requires a team that can read OBL change logs, map them to conformance test changes, re-implement affected components, run the conformance test suite, remediate failures, and coordinate TPP communication. This is not generalized software engineering; it is a specialized capability that takes time to build and is expensive to retain.
Your best engineers are already stretched across production systems, incidents, and security patching, and the compliance calendar won't wait for a quiet quarter. When a security vulnerability hits, your team carries the full cost of researching, fixing, and testing it alone, but a vendor platform splits that burden across every customer it serves.
Compared with building and maintaining equivalent compliance capabilities in-house, WSO2 offers significantly lower total cost of ownership. The platform arrives conformant to the current UK spec, is updated with each OBL release, and comes with FAPI certification already in place, which will save costs that would otherwise fall entirely on the bank's own engineering budget.
Built for open banking from day one
WSO2 was designed for regulated financial services from the start. It was not a general API gateway that bolted on compliance later. Every major UK Open Banking spec update since the original mandate has been absorbed into the platform, which means banks running WSO2 inherit that institutional knowledge without having to build it themselves.
When WSO2 first engaged with UK Open Banking, existing consent frameworks weren't built for the dynamic, per-transaction model the spec required. WSO2 built a consent engine from scratch to meet it and then generalized it to support Open Finance, Australia's Consumer Data Right, Berlin Group, and more.
WSO2 has maintained continuous OpenID Foundation certification from FAPI 1 through FAPI 1.0 Advanced and is actively aligned with FAPI 2.0. For architects evaluating platforms, that certification history is one of the few independently verifiable signals that a vendor actually tracks the spec.
The UK Open Banking standard has served as the architectural blueprint for open banking regimes worldwide, including Brazil, Bahrain, Hong Kong, and others. WSO2's UK compliance work translated directly into faster delivery in those markets, meaning banks benefit from platform depth that only comes from genuine multi-jurisdictional experience.
Compliance and commercial value
Most banks treat compliance and commercial opportunity as separate problems. They don't have to be. WSO2 covers every UK regulatory obligation with consent lifecycle management, FAPI 1.0 Advanced security, VRP APIs for both sweeping and commercial use cases, TPP authorization, and regulatory reporting, all built in and certified.
The same platform that handles compliance also drives commercial outcomes:
-
Corporate banking API layer - enabling corporate ERP integration and payment automation and deep integrations with business client workflows.
-
Embedded finance - ability to acquire customers through non banking channels and generate revenue by monetizing the APIs
-
White-label developer portal - giving TPPs a polished onboarding experience that accelerates your ecosystem and reduces integration support overhead.
-
API monetization - rate plans, usage analytics, and billing hooks for banks ready to offer premium API tiers beyond the mandated baseline.
-
Consent and usage analytics - the data layer that tells your product team which Open Banking capabilities to double down on.
The FCA's Open Finance roadmap will pull mortgages, pensions, SME lending, and insurance into regulated data sharing by 2030. Banks on WSO2 are already positioned for this as the consent engine, API gateway, and TPP onboarding flows are designed to extend to new data domains without a platform rebuild. The architecture you're deploying today is your Open Finance foundation. And if you're evaluating platforms, it's worth asking: will this still hold up in 2030, or are you buying yourself a rebuild in three years?
Architecture and long-term partnership
Fit into what you have - Most banks already have IAM, core banking, and API gateway investments they're not walking away from. WSO2 is composable by design; you take the components you need, integrate with the systems you're keeping, and expand at your own pace. No rip-and-replace required.
Start where you are, grow at your pace - Start with the Open Banking Accelerator layered on your existing API infrastructure and expand to the full WSO2 stack if required and when you are ready. Or replace a legacy gateway with WSO2 API Manager and use the Accelerator to bring it into UK spec compliance immediately. Either way works; there's no forced entry point or upgrade cycle.
Your infrastructure, your rules - WSO2 supports the full range of deployment models required by regulated financial institutions:
- Cloud-native, Kubernetes-ready, deployable on AWS, Azure, or GCP with no architectural compromises.
- On-premises full support for data-sovereign deployments where regulated institutions cannot move to the cloud.
- Hybrid gateway on-prem, management and analytics in the cloud. The split that works for your team, not ours.
We track the spec so you don't have to - When the spec changes, WSO2 ships a conformant update, no re-engineering consent flows, no re-certifying security profiles, no rebuilding APIs from scratch. Keeping you compliant is part of the product.
In the room when the rules are written - WSO2 works with the working groups that shape the specs like OBL, the OpenID Foundation, and JROC, so customers get compliance-ready releases before the deadline, not after.
Expert help, every step of the way - WSO2 gives you expert services, including;
- Dedicated Open Banking engineering team for platform support, compliance queries, and spec interpretation.
- Professional services for v3.1.x to v4.0 migration, VRP enablement, and Open Finance readiness assessments.
- A global community of WSO2 Open Banking practitioners across the UK, Europe, Australia, and beyond.
- Long-term support (LTS) releases are aligned to the spec lifecycle, with no forced upgrades on our schedule.
The platform decision that defines your next decade
UK Open Banking in 2026 is moving from regulatory compliance to different financial use cases. Commercial VRPs are live. An Open Finance roadmap is pulling mortgages, lending, pensions, and insurance into the same data-sharing model through the end of the decade, and the specification is still moving.
The platform decision made today will either enable that future or constrain it. A compliance tool that requires a rebuild for every spec change, cannot extend to new data domains, or lacks the architectural flexibility to sit alongside existing infrastructure is not a compliance investment. It is a liability with a renewal date.
WSO2 isn't built just to keep you compliant, instead it's designed to turn regulatory mandates into a high-yield revenue engine. By delivering a composable architecture that plugs seamlessly into any infrastructure, the platform handles complex FAPI security standards out of the box, freeing your engineering teams to focus on building high-value, fee-generating financial services. Instead of treating spec updates as an endless stream of billable support hours, WSO2 absorbs compliance maintenance as a product promise. This lets you turn open banking from a cost center into a scalable commercial platform, backed by a team that has already proven this model across the world’s most competitive financial markets.
Ready to go deeper?
The WSO2 Open Banking Executive Brief unpacks how leading banks are turning compliance infrastructure into a platform for growth with architecture patterns, deployment options, and a closer look at the full capability stack. If this article raises any questions, the brief answers them.