Open banking reshaped how account data and payments move between financial institutions and third parties, but it did so by quietly creating one of the most interdependent software ecosystems in financial services. Every time a user authorizes a budgeting app to pull transaction data or initiates a payment through a third-party provider, a chain of SDKs, certificate authorities, directory services, and API gateways executes code from half a dozen different suppliers. The chain is usually invisible to the user and often invisible to the bank whose data is being shared.
The regulators who built the open banking frameworks focused heavily on authentication, consent, and data protection. Supply chain security was not the headline in PSD2, the UK's Open Banking Standard, or the CFPB's Section 1033 rule, but it became the underlying story as implementations matured. The practical lesson from five years of live open banking traffic is that the components that mediate trust between ASPSPs (account servicing payment service providers) and TPPs (third-party providers) are themselves software supply chains, with all the attendant risks.
The PSD2 Architecture and Where Code Lives
The second Payment Services Directive mandated that banks expose customer-permissioned account and payment APIs to licensed third-party providers. The technical standards -- the Regulatory Technical Standard on Strong Customer Authentication and Secure Communication, known as the RTS on SCA, and the various national implementations -- prescribe how the APIs should work but leave the implementation details to each market.
In practice the architecture has three layers. The ASPSP exposes an API that conforms to a market standard (Berlin Group NextGenPSD2, STET in France, Polish API, UK Open Banking). The TPP consumes the API using an SDK that wraps the market standard. Between them sits a certificate authority ecosystem, with eIDAS-qualified certificates issued by QTSPs (qualified trust service providers) identifying TPPs to ASPSPs, and increasingly a directory service that helps each side discover and validate the other.
Each of those layers is code, and each piece of code is a supply chain. The ASPSP's API implementation is often built on top of a vendor's open banking gateway product. The TPP's integration relies on a commercial aggregator SDK or an in-house client library. The certificates are issued and revoked through QTSP software. The directories are run by entities like Open Banking Limited in the UK or the commercial directory operators in other markets.
UK Open Banking: The Mature Case Study
The UK Open Banking implementation, rolled out from 2018, is the most mature open banking ecosystem in the world and has been the testing ground for most of the supply chain lessons. Open Banking Limited operates the OBIE directory and certificate services, publishes the API specifications, and certifies TPPs.
The directory itself is software, and the client libraries that TPPs and ASPSPs use to interact with it are software, and the dependencies of both have been the subject of security disclosures over the years. The UK FCA's operational resilience regime, which took full effect in March 2025, explicitly requires that firms identify important business services, map the resources that support them -- including third-party technology -- and set impact tolerances. Open banking connectivity is an important business service for most UK retail banks, and the mapping has to include the software supply chain underneath.
The Certificate Chain Problem
eIDAS-qualified certificates are the backbone of open banking authentication in the EU. The QTSPs that issue them are regulated entities, supervised by national bodies and listed on the EU Trusted List. When a TPP connects to an ASPSP, the ASPSP validates the TPP's certificate against the Trusted List and checks revocation status.
The supply chain risk here operates at two levels. First, the QTSP itself is a software operation, and its signing infrastructure has to be hardened against the kinds of attacks that have affected CAs in other contexts. The WebTrust audits for QTSPs and the eIDAS conformity assessments address this, but the scrutiny is less intense than for public web CAs. Second, the client libraries that validate certificates on each side of the connection are software with their own vulnerabilities. A parsing bug in a certificate validation library, or a downgrade vulnerability in the TLS stack, or a missing revocation check can break the trust model.
The PSD2 RTS requires that certificate validation include revocation checking, but the implementations vary. Some ASPSPs check OCSP on every request; others cache aggressively; a few get it wrong. Each approach has its own supply chain exposure, and each has been the subject of at least one published disclosure.
The US Direction: Section 1033 and FDX
The Consumer Financial Protection Bureau's Personal Financial Data Rights rule under Section 1033 of the Dodd-Frank Act, finalized in October 2024, is the US's first systemic open banking regulation. It requires covered financial institutions to make consumer transaction data available to authorized third parties through secure APIs.
The rule does not mandate a specific technical standard, but it recognizes industry standards developed by qualified industry standard-setting bodies. Financial Data Exchange (FDX), a nonprofit body that publishes the FDX API specification, is the most prominent candidate. The FDX spec itself, the reference implementations, and the growing ecosystem of commercial FDX SDKs all become part of the supply chain once the rule is in full effect.
The US framework differs from the EU in that it does not rely on a unified certificate authority ecosystem equivalent to eIDAS. Identity and authentication between data providers and authorized third parties are handled through bilateral agreements and, increasingly, through directory services operated by aggregators and industry utilities. Each of those adds software supply chain surface.
Aggregator Concentration
Both the EU and US open banking ecosystems show a pattern of aggregator concentration. A small number of commercial aggregators -- Plaid, Tink, TrueLayer, Yodlee, MX, and a handful of others -- sit between most TPPs and most ASPSPs. They provide SDKs that abstract away the market standard differences, they maintain their own relationships with ASPSPs, and in some markets they also provide consent management flows.
The concentration has obvious benefits for interoperability but creates a concentrated supply chain risk. An aggregator SDK embedded in ten thousand third-party applications is a high-value target. The Codecov breach and the various npm-supply-chain incidents of recent years illustrate what can happen when widely used developer tooling is compromised, and aggregator SDKs are the open banking equivalent.
Regulators are increasingly attentive. DORA's designation of critical ICT third-party providers will likely catch at least one major open banking aggregator, and the FCA's operational resilience regime already expects firms to assess aggregator dependencies explicitly.
The Practical Controls
Supply chain controls in open banking break down into a few areas. Inventory: the ASPSP or TPP needs to know which open banking components are in its production systems, including SDKs, certificate validation libraries, and directory client code. SBOMs for each service in the path, refreshed on every build, are the baseline.
Vulnerability monitoring: components in the open banking path need to be watched against NVD, vendor advisories, and coordinated disclosure feeds. Open banking SDKs and aggregator libraries often publish security advisories through their own channels, and these need to be wired into the same triage flow as CVEs from public feeds.
Change control: SDK updates, certificate rotation, and directory client changes need review equivalent to any other production change. Some aggregators push silent SDK updates, which is convenient for bug fixes and dangerous for security review. The contract and the build pipeline should both reflect a policy on this.
Resilience testing: DORA-aligned threat-led penetration testing and FCA operational resilience testing should exercise the open banking path end to end, including the failure modes of each third-party component.
How Safeguard Helps
Safeguard gives open banking teams visibility into the SDKs, certificate validation libraries, and aggregator components that sit in their production path, with continuous SBOM monitoring against the vulnerability feeds that matter for financial services. Policy gates prevent unapproved SDK versions from reaching production and surface silent updates from aggregators before they ship. When a vulnerability is disclosed in an open banking component, Safeguard tells the team which services and which partners are affected, supporting the FCA operational resilience mapping and the DORA ICT third-party register with data that is always current.