Open banking has steadily increased competition, accelerated innovation, and given consumers more control over their financial data. But for most banks and financial institutions, the reason to participate isn’t the regulation — it’s the customer. People now expect account aggregation dashboards that pull every account into one view, the ability to pay directly from their bank, loan decisions in minutes instead of days, and savings tools that move money on autopilot. The institutions that can’t deliver these experiences lose customers to the ones that can.

For risk and technology executives, that customer mandate creates a tension that doesn’t resolve itself: delivering these experiences means opening your most sensitive systems to a growing ecosystem of third parties (such as fintechs, aggregators, payment processors, and developers); and the more connected your institution becomes, the more exposure you carry. The regulatory environment only intensifies the pressure created by rising customer expectations. In the EU, PSD2 has formalized open banking as a compliance requirement. In the US, the CFPB’s Section 1033 rule was intended to create a similar federal framework for consumer-permissioned data sharing, including recognition of Financial Data Exchange (FDX) as a standard-setting body. But that framework is now effectively on hold: the rule is enjoined and under reconsideration, leaving institutions to advance open banking programs without a settled federal compliance baseline. What hasn’t paused is the threat landscape: API attack vectors keep evolving, and adversaries are increasingly using AI to find and exploit them faster than defenders can close the gaps.

In mature markets, this isn’t a new problem. First-generation deployments were often stitched together under time pressure, and years later they’ve hardened into fragmented, costly estates: multiple point products, per-instance licensing that penalizes broad coverage, and forced upgrade cycles that keep the bill climbing. The opportunity now is to reassess that approach and the cost that came with it.

That API security gap, between what open banking requires you to expose and what you can actually defend, is where institutions are most vulnerable, and where the decisions you make about infrastructure matter most.

The attack surface you’re required to have

In traditional application security, reducing the attack surface is a primary objective. In open banking, you cannot reduce it; you can only manage it. PSD2 mandates that qualifying Third-Party Providers (TPPs) be granted API access to customer account data. FDX defines how those APIs should be structured. Neither tells you how to prevent that access from being exploited.

The most common exploit patterns in open finance APIs are instructive. Broken Object Level Authorization (BOLA)—where an authenticated but unauthorized party manipulates an API request to access data belonging to another account holder—is consistently ranked as the top API security risk by OWASP. It is particularly dangerous in open banking because the APIs are purpose-built to return sensitive financial data. The question is not whether an attacker can reach the API. They can, and in many cases, they are supposed to be able to. The question is whether your infrastructure can tell the difference between a legitimate TPP request and a malicious one.

Injection attacks, improper authentication, and over-permissioned TPP access round out the top risk categories. That last one deserves particular attention. Institutions frequently grant third-party developers broader access than their use case requires. That is because scoping access is operationally difficult, onboarding timelines are compressed, or the initial integration was designed before the full risk implications were understood. That over-permissioning compounds across dozens or hundreds of TPP relationships, creating an exposure profile that grows quietly alongside your open banking program — especially as deprecated zombie APIs and undocumented shadow APIs accumulate outside the company’s known and governed API estate.

Why infrastructure is the right place to solve this

Open banking security is sometimes framed as an API governance problem, or a vendor management problem, or a compliance program problem. It is all of those things. But at the transaction level—where an API call is made, authenticated, routed, and responded to—the control point is infrastructure.

The institutions that manage open banking risk most effectively are not the ones with the most security tools. They are the ones that have consolidated security enforcement into the layer where traffic actually flows. That starts with API discovery that surfaces every endpoint actually receiving traffic—including the undocumented shadow and zombie APIs—so nothing operates unseen. From there: WAF and injection protection at the API layer. OAuth 2.0 and mutual TLS (mTLS) enforcement at the authentication boundary. Rate limiting to detect and contain abuse before it escalates. And granular access controls that allow institutions to define, enforce, and audit exactly what each TPP integration is permitted to access without relying on the TPP to self-limit.

When these controls are distributed across multiple point products, they create seams. Policies defined in one tool don’t automatically apply in another. Visibility is fragmented. Audit trails are incomplete. In a regulatory environment where you may be asked to demonstrate exactly what data was accessed, by whom, and under what authorization, fragmented visibility is a compliance liability, not just an operational inconvenience.

The case for a unified control plane

Citrix NetScaler’s position in open banking security starts with the same architecture that has made it the application delivery infrastructure of choice for major financial institutions for decades: a single platform, a single codebase, and a single control plane that spans on-premises data centers and multi-cloud environments.

For open banking specifically, this means that WAF, API protection, OAuth 2.0/mTLS enforcement, rate limiting, and access control policies are all defined once and enforced consistently across every API endpoint, in every environment, for every TPP integration. There is no synchronization problem between security tools because there is only one security layer. There is no visibility gap between environments because observability runs through a single control plane.

The operational implications are significant. As open banking API estates grow—more TPP integrations, more endpoints, more environments—the complexity of managing security across a fragmented toolset grows with it. A unified platform scales without adding operational overhead proportionally.

Unlike per-instance or per-application licensing models that make comprehensive coverage progressively more expensive, NetScaler’s enterprise licensing carries no per-instance limits, so institutions can extend consistent security across their full estate without the cost structure that typically discourages thorough deployment or the forced upgrade cycles that turn a security requirement into a recurring negotiation.

There is also a performance dimension that risk executives sometimes underestimate. Security controls that introduce latency into API transactions create pressure to reduce coverage (fewer inspection rules, lighter enforcement) in the interest of maintaining the transaction speeds that open banking users expect. NetScaler’s one-pass architecture processes security and delivery functions simultaneously, minimizing the latency impact of comprehensive API protection. You do not have to choose between thorough security, acceptable performance, and the operations cost of scaling both.

What governance actually requires

The JPMorganChase CISO’s public letter to third-party suppliers—calling on vendors to treat security as equal to or above launching new products—reflects a shift that is underway across the industry. Major institutions are raising their expectations for TPP security posture, and regulators are raising theirs for the institutions themselves.

Meeting those expectations requires more than policy. It requires infrastructure that enforces policy consistently, generates audit-ready records automatically, and gives security and compliance teams a single place to review, adjust, and demonstrate their controls. The institutions that will manage open banking risk most effectively over the next several years are those that treat their API security infrastructure as a strategic asset—not a collection of point solutions assembled to meet last year’s requirements.

Open banking opened the door. The question is not whether to let people through it. The question is whether you can see everyone who’s walking through, verify they are who they say they are, and make sure they only go where they’re supposed to go.

That is an infrastructure problem. And it has an infrastructure answer.

Learn more about how NetScaler secures financial services application delivery and open banking API infrastructure here.