We've tracked 80+ regulatory frameworks, 50,000+ financial institutions, and hundreds of APIs. The data is not converging. Here's what that means if you're building fintech infrastructure.
The category always outgrows its name.
We started with PSD2 APIs and a directory of banks. Over 8 years and millions of visitors later, the questions coming into Open Banking Tracker look nothing like they did in 2017. People still ask about payment APIs and bank connectivity, but increasingly also about accounting software connectors, e-invoicing mandates, and what "Open Finance" regulation actually looks like across 30+ jurisdictions.
So we built the Open Finance Map to reflect where things have moved. Here's what the data tells us.
80+ regulations. Zero convergence.
The Open Finance Map is a filterable, interactive view of every open banking, open finance, and e-invoicing regulation we track globally. As of today, that's 80+ frameworks across six categories:
- Open Banking (34)
- E-Invoicing (31)
- Open Finance (16)
- Payment Services (5)
- Digital Identity (1)
- Operational Resilience (1)
Each regulation links to a detail page with structured data: jurisdiction, regulatory type, status, scope of coverage (AIS, PIS, CBPII, VRP, and more), effective dates, and plain-language descriptions.
70 of those regulations are active today. 18 are upcoming.
The global patchwork, for developers
If you're building cross-border financial infrastructure, this is what you're dealing with:
- PSD2 in Europe, with PSD3 provisionally agreed in November 2025 and heading for compliance in 2027-2028
- Section 1033 in the US, phased through 2030 on paper but currently frozen by litigation and under reconsideration
- Consumer Data Right in Australia (live since 2020, now expanding to action initiation)
- Account Aggregator in India (the real success story: 2.61 billion financial accounts enabled, 780+ institutions onboarded)
- SGFinDex in Singapore
- Open Banking Saudi Arabia (Phase 2 with payment initiation live since September 2024)
- Consumer-Driven Banking in Canada (Bill C-15 tabled November 2025, Phase 1 targeting mid-2026)
Each with different scopes, different timelines, different technical standards, and different definitions of what data is even in scope. If you've ever tried to normalise bank transaction data across two providers in the same country, imagine doing it across these frameworks.
What sits behind the map
What makes this different from a static regulatory overview is the dataset behind it. The Open Finance Map is backed by the Open Banking Tracker's full dataset:
- 54,776+ banks and financial institutions
- 435+ third-party providers
- 64+ API aggregators
- 60+ data points per institution
You can drill from a regulation into the country page, then into individual institutions, their API availability, sandbox status, registered TPPs, and aggregator coverage.
The underlying data is open source on GitHub with 200+ stars and active community contributions. The community catches errors and fills gaps faster than any internal team could. Open data has been the right call.
E-invoicing: the regulation developers aren't watching
Most of Europe will have mandatory e-invoicing within 5 years. Over 50 countries already have active or upcoming mandates. The EU's ViDA package entered into force in April 2025, with mandatory cross-border B2B e-invoicing by July 2030.
If you're building anything that touches invoices, procurement, or accounts payable/receivable, this is coming for you. The regulatory perimeter for structured financial data now extends well beyond bank accounts, and the overlap with open finance regulation is growing fast.
The Open Finance Map is the first interactive tool that tracks both open banking and e-invoicing regulations in one place. Most developers I talk to had no idea how many overlapping mandates they'll be dealing with in the next three years.
AI agents need financial data standards yesterday
This is where it gets interesting for developers. The interest in structured financial APIs is not theoretical anymore. We recently added an Agentic Banking section to the tracker, covering banks with MCP (Model Context Protocol) server support.
The assumption behind AI agents acting on financial data is that the data will be structured, standardised, and accessible enough for autonomous software to act on reliably.
After 8 years of tracking this: we are nowhere near that level of consistency. If human developers still struggle with inconsistencies between different banks' API implementations within a single country, good luck deploying an agent that needs to work across jurisdictions.
The agentic finance conversation is exciting, but it's running ahead of the infrastructure reality. Access without consistency is just noise at scale.
The parallel movement: Open Accounting
Open Banking gave consumers control over their bank transaction data. Open Finance extends that to investments, pensions, and insurance. But there's a parallel movement most regulatory maps miss entirely: Open Accounting.
Accounting software holds some of the most valuable structured financial data for businesses: invoices, general ledgers, chart of accounts, vendor records. The data that matters for financial decision-making is not limited to bank accounts. The regulatory world already recognises this. The developer ecosystem should too.
A few observations after 8 years
Payments work in the UK. 33 million open banking payment transactions in November 2025 alone. 16.5 million live user connections. It took 8 years to get there in one country. Globally, we're still navigating 80+ incompatible frameworks.
Regulation is fragmenting, not converging. The UK succeeded because of consistent governance and a single trusted standard. Almost nobody copied those parts.
Open data compounds. The tracker's data is on GitHub. Contributors catch errors and fill gaps faster than any internal team. If you're building infrastructure for a regulated space, consider open-sourcing your compliance data.
The compliance surface area is expanding. E-invoicing, accounting data access, payroll verification. If you're only watching PSD2/PSD3, you're seeing half the picture.
Explore the data
The Open Finance Map is live and free to use. Filter by region, status, or regulation type. Drill into any country for institution-level API data. All backed by the deepest open banking dataset available.
The honest question I keep coming back to: are we actually getting closer to interoperability, or just adding more frameworks? I don't know the answer. But if you're building in this space, you should know what you're building on top of.
I'm Gertjan De Wilde, CEO of Apideck and creator of Open Banking Tracker. We've been tracking open banking APIs since 2017. If you're building fintech infrastructure, I'd love to hear what you're running into.
Top comments (2)
The infrastructure gap you're describing runs deeper than data standardization. Even before consistency across frameworks is solved, there's a more immediate problem: how does an agent authenticate to these financial APIs without the credential value entering agent context?
Most agentic banking implementations today put API credentials in environment variables or MCP server configs, somewhere the agent's context can reach. A prompt injection attack against an agent with Stripe or Plaid credentials in memory is a different class of risk than a human developer with the same credentials.
We've been working on this specific layer, zero-knowledge credential management where the agent references credentials by name, the proxy resolves from the OS keychain and injects at the transport layer, and the value never enters agent memory at any step. The agent can call 80 different financial APIs and never hold a single credential value.
It doesn't solve the standardization problem you're describing, that's a much harder and longer problem. But it's one piece of infrastructure that needs to exist before agentic finance is safe to deploy at scale, regardless of how the regulatory fragmentation resolves.
github.com/The-17/agentsecrets if you want to look at the architecture
Interesting!