- 17 hours ago
- 10 min read
Open Banking regulation has moved from theoretical compliance obligation to live infrastructure requirement. In Europe, PSD2 (Revised Payment Services Directive) is fully in force. In Brazil, the Central Bank's Open Finance framework has expanded well beyond payments into insurance, investments, and credit data. Mexico, Colombia, and other Latin American markets are at various stages of mandating similar open API ecosystems.
For CTO and VP Technology teams at regional and challenger banks, this creates a specific and immediate problem: the regulation requires you to expose APIs to licensed third-party providers, and the quality of that exposure is increasingly subject to supervisory scrutiny. A poorly documented API with no sandbox, no self-service access, and a manual onboarding process that takes four weeks is not a compliant developer portal — it is a compliance risk.
Most banks are handling this badly. Not because they lack the will, but because they underestimate what a production-grade open banking developer portal actually requires — and overestimate how quickly they can build one in-house.
What Does PSD2 Actually Require from a Bank's Developer Portal?
PSD2 Article 30 of the Regulatory Technical Standards (RTS) on Strong Customer Authentication specifies that Account Servicing Payment Service Providers (ASPSPs) — which includes most banks — must offer a dedicated interface for third-party providers that is at minimum as performant and available as the customer-facing channel.
The Regulatory Technical Standards drafted by the European Banking Authority (EBA) on Strong Customer Authentication and Common and Secure Open Standards of Communication goes further, establishing specific technical and operational requirements for how that interface is made available. What this translates to in practice:
Technical requirements that map directly to developer portal capabilities:
Accessible interface documentation: PSD2 Article 30(3) requires that the dedicated interface be documented with sufficient technical specification for TPPs to build their integrations. Generic internal documentation does not meet this bar.
Testing environment (sandbox): Article 30(5) requires that ASPSPs make a testing facility available to TPPs before they begin live integration. The sandbox must be functional and accessible without a live production credential.
Uptime and availability parity: The dedicated interface must achieve the same availability targets as the consumer-facing channel. This requires monitoring, alerting, and SLA documentation that TPPs can rely on.
Incident notification: When the interface experiences unplanned downtime, banks are required to notify TPPs promptly. This requires a communication channel — typically a status page or notification mechanism within the portal.
Identity verification and registration: Only licensed TPPs (Payment Initiation Service Providers and Account Information Service Providers) may access PSD2 APIs. The portal must verify eIDAS certificates and validate TPP registration status against the relevant national competent authority register.
Beyond PSD2, the EBA's guidelines on operational and security risk management add requirements around change notification timelines — TPPs must receive advance notice (typically 3 months) of planned interface changes. Your portal is the mechanism through which this happens.
Why Do Banks Struggle to Build This In-House?
The compliance requirement is clear. The solution most banks reach for first — building a developer portal internally — consistently underperforms against the regulatory requirement. Three honest reasons why:
1. The regulatory bar is higher than teams initially model
Internal estimates for an open banking developer portal typically account for documentation and API exposure. They undercount the sandbox environment, the eIDAS certificate verification workflow, the TPP onboarding and verification process, the status page and incident notification system, and the ongoing maintenance required as the regulatory technical standards evolve. The EBA regularly publishes Q&A guidance that updates effective requirements. A portal that is compliant at build time can fall out of compliance within 18 months without active maintenance.
2. Gateway integration is not a solved problem at most banks
Most regional banks are not running a single, clean API gateway environment. Legacy systems, cloud migrations, and digital banking initiatives have produced multi-gateway environments where core banking APIs run on one platform and newer digital services run on another. A developer portal built against a single gateway does not surface the full picture of what the bank needs to expose under PSD2. The integration work multiplies with each additional gateway.
3. TPP onboarding is a specialized workflow with no off-the-shelf components
Verifying a TPP's eIDAS certificate, cross-referencing their registration against national competent authority databases, and routing their access request through an appropriate approval workflow is not a standard developer onboarding flow. It requires specific knowledge of how the EBA's TPP register APIs work, how eIDAS certificate chains are validated, and how to handle edge cases (expired authorizations, role scope changes, deregistrations). Most internal engineering teams encounter this problem for the first time when building the portal.
What Does a Compliant Open Banking Developer Portal Include?
A portal that genuinely meets PSD2 and Open Finance requirements — not just the minimum letter of the regulation but the operational reality of what TPPs expect — covers the following:
Public API catalog with versioned, machine-readable specifications: OpenAPI 3.0 or equivalent, covering all PSD2-mandated endpoints (AIS, PIS, and CBPII where applicable), with clear versioning, deprecation notices, and change logs.
Functional sandbox environment: An isolated test environment that reflects production API behavior, accessible to TPPs without a production credential. Sandbox credentials should be issuable via self-service with no manual approval required.
TPP registration and eIDAS certificate verification: Self-service registration flow that validates the applicant's eIDAS certificate (QWAC and QSeal where applicable), confirms their National Competent Authority registration status, and maps their authorized payment service roles to the appropriate access scope.
Self-service access request and credential management: Once registered and verified, TPPs should be able to request access, receive credentials, rotate keys, and manage their application registrations without requiring manual bank intervention for standard operations.
API access governance with full audit trail: Every credential issuance, access modification, and revocation should be logged with timestamps and approver identity. This is your evidence layer for regulatory audit.
Status page and incident communication: Real-time availability monitoring for each API endpoint, with automated TPP notification on service degradation. This is an explicit EBA requirement under Article 30(3) of the PSD2 RTS.
Change notification workflow: Mechanism to notify registered TPPs of upcoming interface changes within the required notice period. Typically this is a notification system within the portal combined with a mailing list for registered TPPs.
Analytics and adoption visibility: Understanding which TPPs are actively integrated, which APIs they are consuming, and where integration failures are occurring is operationally necessary — and increasingly expected by supervisors when reviewing the bank's open banking posture.
The compliance reality: A bank that exposes PSD2 APIs through an internal system with no sandbox, manual TPP onboarding, and no audit trail is not compliant — it is exposed. Supervisory authorities in Germany, the Netherlands, and France have each issued guidance making clear that the quality of the dedicated interface is subject to review, not just its existence.
How Does a Single Portal Work Across Multiple API Gateways?
The multi-gateway problem is one that regional banks rarely solve cleanly in an in-house build. The typical architecture that emerges over years of digital transformation looks something like this: core banking APIs on Apigee or an on-premise API management platform, cloud-native services on Azure APIM or AWS API Gateway, and potentially a Kong deployment for microservices or a recent acquisition's infrastructure.
PSD2 does not care about your gateway architecture. It requires that licensed TPPs have a single, coherent interface to your account and payment APIs — regardless of which gateway those APIs sit behind.
Apiboost is designed for exactly this environment. It functions as a gateway-agnostic developer portal layer that connects to Apigee, Azure APIM, AWS API Gateway, and Kong simultaneously. From a TPP's perspective, they see a single portal, a single API catalog, and a single access management experience. From the bank's perspective, each gateway continues to operate exactly as it does today — Apiboost adds the experience and governance layer on top without requiring any changes to the underlying gateway configuration.
This architecture also positions the bank correctly for future gateway changes. If a migration to a new platform is underway, or a cloud-first strategy is shifting workloads between gateways over time, the developer portal remains stable through the transition. TPPs do not experience disruption from internal infrastructure changes.
Deployment flexibility
Apiboost is available as a SaaS deployment or as an on-premise installation — relevant for banks in jurisdictions with strict data residency requirements or internal security policies that preclude SaaS solutions for customer-facing infrastructure. For banks already running on Azure, Apiboost is available directly through the Azure Marketplace, which simplifies procurement and allows deployment within an existing Azure tenant.
Should Your Bank Build or Buy Its Open Banking Portal?
The question is not whether your bank needs a developer portal for Open Banking compliance. The regulation answers that. The question is whether you build it yourself over 18 months or deploy one in 90 days.
That framing is not rhetorical. Experian deployed a production-ready enterprise developer portal with Apiboost in 90 days. Danfoss achieved 300% growth in their API catalog under active management after implementing a structured portal approach. These timelines are achievable specifically because Apiboost connects to existing gateway infrastructure rather than replacing it — the portal layer deploys on top of whatever the bank already runs.
The case for building
Building makes sense in a limited set of circumstances: if the bank's open banking interface is genuinely a differentiated product and customer experience (not common in most PSD2 compliance scenarios), if the bank has a dedicated platform team with previous developer portal experience, or if internal security and data residency requirements make any external solution genuinely impractical.
The case for buying
For most regional banks, the honest assessment is that building a PSD2-compliant developer portal from scratch is a 12–18 month engineering project that competes with core digital banking initiatives for the same engineering capacity. The regulatory clock does not pause during the build. And when the first build is complete, the maintenance burden — staying current with EBA Q&A guidance, handling TPP eIDAS certificate updates, keeping sandbox parity with production — is ongoing and non-trivial.
A purpose-built solution that has already solved the eIDAS verification problem, the multi-gateway integration problem, and the regulatory change notification problem is not a compromise. For most banks, it is the faster path to a compliant, maintainable open banking developer portal that TPPs actually want to use.
Frequently Asked Questions
Does PSD2 require banks to have a developer portal?
PSD2 does not use the term "developer portal" explicitly, but Article 30 of the Regulatory Technical Standards on Strong Customer Authentication requires Account Servicing Payment Service Providers to provide a dedicated interface for Third Party Providers, along with accessible technical documentation, a testing environment (sandbox), and sufficient notice of interface changes. In practice, meeting these requirements requires what is functionally a developer portal — a structured environment where TPPs can discover APIs, access documentation, test integrations, and manage their credentials. National competent authorities including the FCA, BaFin, DNB, and Banco de España have each confirmed that the quality and accessibility of the dedicated interface is subject to supervisory review.
What is the difference between a PSD2 API gateway and a PSD2 developer portal?
A PSD2 API gateway handles the technical enforcement of API security policies — authentication, rate limiting, request routing, and traffic management. It operates at the infrastructure level and processes API calls at runtime. A PSD2 developer portal is the experience layer above the gateway — it is where TPPs discover which APIs exist, read documentation, register their applications, request access credentials, and manage their integrations. The gateway and the portal serve different functions and are both necessary. A bank can have a fully compliant API gateway and still fail to meet PSD2 requirements if the developer experience — documentation, sandbox, TPP onboarding, change notification — is inadequate. Apiboost is designed specifically as the developer portal layer, sitting above any combination of API gateways without replacing them.
What is a Third Party Provider (TPP) in Open Banking?
A Third Party Provider (TPP) under PSD2 is a licensed payment service provider authorized to access bank account data or initiate payments on behalf of bank customers, with the customer's explicit consent. There are three categories: Payment Initiation Service Providers (PISPs), which initiate payments from a customer's account; Account Information Service Providers (AISPs), which access account data to provide aggregated financial information; and Card-Based Payment Instrument Issuers (CBPIIs), which confirm whether sufficient funds are available. TPPs are authorized by national competent authorities and must hold a valid eIDAS certificate to access PSD2 APIs. Banks are required to grant access to licensed TPPs and may not impose additional requirements beyond what the RTS specifies.
How does Brazil's Open Finance differ from PSD2?
Brazil's Open Finance framework, regulated by the Banco Central do Brasil, is broader in scope than PSD2. While PSD2 focuses primarily on payment accounts and transactions, Brazil's framework progressively extended to cover insurance products, pension and investment data, credit operations, foreign exchange, and more, through four implementation phases that ran from 2021 through 2022. Brazil's framework also established a centralized governance structure through the Open Finance Brasil standards body, which publishes standardized API specifications that all participating institutions must implement. Like PSD2, the framework requires participants to expose APIs to licensed third-party institutions with customer consent, through a compliant developer portal that includes sandbox access, documentation, and TPP onboarding workflows. For banks operating in both Europe and Brazil, the underlying portal architecture requirements are closely aligned, making a gateway-agnostic platform that supports both regulatory environments a practical option.
Can Apiboost work with our existing API gateway for Open Banking?
Yes. Apiboost is a gateway-agnostic developer portal layer that connects to Apigee, Azure APIM, AWS API Gateway, and Kong simultaneously. It does not replace your gateway — it adds the developer experience and governance layer on top of whatever gateway infrastructure you already run. Your gateway configuration does not change. Apiboost surfaces your existing APIs in a structured, compliant portal environment, handles TPP onboarding and credential management, provides sandbox access, and delivers the audit trail and change notification capabilities that PSD2 requires. It is available as a SaaS deployment, on-premise installation, or directly through the Azure Marketplace.
How long does it take to deploy an Open Banking developer portal with Apiboost?
Production deployments with Apiboost have been achieved in 60–90 days. The timeline is achievable because Apiboost connects to existing gateway infrastructure rather than requiring a parallel rebuild — the portal layer deploys on top of what the bank already runs. The deployment timeline includes connecting to existing gateways, configuring the API catalog and documentation, setting up the TPP onboarding and eIDAS verification workflow, provisioning the sandbox environment, and configuring access governance and audit logging. The 90-day timeframe is a reference point, not a guarantee — complexity scales with the number of gateways, the maturity of existing API documentation, and the bank's internal security review process. See Apiboost pricing and deployment options for typical engagement structures.
Talk to the people who'd actually build it
If you're scoping an Open Banking portal project for a regional bank, we'd be happy to walk through the architectural decisions with you — gateway integration approach, TPP onboarding workflow, sandbox provisioning, and the realistic 60-90 day deployment path.
The conversation is with our CTO and lead engineers, not an SDR.
Schedule a technical conversation — direct access to the team that's built dozens of enterprise developer portals over the past decade.
See how Apiboost handles multi-gateway financial services environments — if you'd rather read more before getting on a call.
Apiboost is available directly from Apiboost, through Microsoft Azure
Marketplace, or as an on-premises license — relevant for banks with data residency or internal security review requirements.
