Open Banking Architecture: How to Integrate Banks with External Financial Services

What Is Open Banking from an IT Architecture Perspective?

Open Banking is a model in which banks make defined data and financial capabilities available to authorized external providers through controlled interfaces. Depending on the use case, these interfaces can support regulated account information and payment initiation services or broader commercial partnerships.

From an architecture perspective, the critical principle is separation. External applications should interact with documented API contracts, not with internal databases, proprietary core banking interfaces, or implementation details of legacy systems.

Who Participates in an Open Banking Integration?

The typical participants are:

• ASPSP (Account Servicing Payment Service Provider): the institution maintaining the customer’s payment account and providing relevant access interfaces.
• TPP (Third-Party Provider): an authorized external provider accessing permitted services, such as account information or payment initiation.
• PSU (Payment Service User): the customer using the relevant payment or account service.
• API platform and banking backend: the technical components that authenticate requests, enforce permissions, execute business operations, and communicate with source systems.

Regulated Open Banking vs. Commercial API Partnerships

Not every bank–fintech integration is automatically a PSD2-regulated AIS or PIS service. A bank may also expose APIs under commercial agreements for embedded finance, partner onboarding, or other services.

This distinction matters because the applicable security profiles, authorization processes, contractual obligations, and regulatory requirements may differ. Architecture decisions should start with the precise service model rather than assuming that every partner uses the same integration flow.

Open Banking also does not mean making all banking data or operations available to every partner. Access must be limited to the capabilities and scope appropriate for the particular service.

What Technical Challenges Make Bank–Fintech Integration Difficult?

The cost of an Open Banking integration often comes from the complexity behind the API, not the endpoint itself. A single account information request may involve several systems with different protocols, data models, availability characteristics, and security rules.

Fragmented Data and Business Logic

Account balances, transaction history, customer information, and payment status may be maintained by different systems. A third-party provider expects a consistent response, even when the bank must assemble it from multiple internal sources.

Legacy Protocols and Data Models

Core banking systems may expose proprietary interfaces or use older messaging patterns. External APIs, by contrast, need stable contracts, predictable error handling, and formats appropriate to the selected standard.

Inconsistent Authorization Models

Technical authentication of a partner is only one part of the problem. The bank must also establish whether a specific operation is permitted for the relevant customer, account, and scope of access.

Availability and Performance Dependencies

If every API request depends synchronously on a heavily loaded legacy component, that component becomes a bottleneck for external services. Without timeouts, traffic controls, and failure isolation, a source-system incident can affect multiple partners.

Limited End-to-End Observability

An error reported by a fintech may originate in the gateway, authorization service, integration adapter, or core banking system. Without correlation identifiers and distributed tracing, diagnosing the failure can require manual investigation across several teams.

This is why implementing an API gateway alone does not solve Open Banking integration. A gateway can control traffic, but it cannot automatically reconcile inconsistent business data, authorize account-level operations, or eliminate legacy dependencies.

What Should a Reference Open Banking Architecture Look Like?

A scalable Open Banking architecture separates external access from internal banking systems. Each layer has a defined responsibility, allowing the bank to change its integration mechanisms without unnecessarily affecting partners.

Responsibilities of Each Architecture Layer

These components do not have to be deployed as separate applications. Some responsibilities may be combined or distributed depending on the bank’s architecture, existing platforms, and applicable interface requirements.

The architectural goal is not to maximize the number of services. It is to establish clear boundaries so that external contracts remain stable and internal changes are easier to control.

What Is the Role of API Gateway and API Management in Open Banking?

An API gateway is the controlled entry point for external traffic. API management adds capabilities for publishing, documenting, monitoring, versioning, and managing interfaces throughout their lifecycle.

In Open Banking, these capabilities help a bank operate multiple partner integrations without creating a separate technical entry point for each provider.

Key API Management Capabilities

• Publishing documented API endpoints and routing requests to appropriate backend services.
• Enforcing selected access policies and traffic limits.
• Managing API versions and planned deprecation.
• Monitoring response times, error rates, and traffic patterns.
• Supporting partner documentation, onboarding, and sandbox environments.
• Providing technical logs and metrics for incident investigation.

Why Does an API Gateway Not Replace Business Authorization?

A gateway may verify that a request comes from an authenticated client and meets technical policy requirements. This does not necessarily prove that the client is authorized to retrieve a particular customer’s transaction history or initiate a payment from a specific account.

Such decisions require checks against the applicable permissions, account relationships, service rules, and authorization state. These checks belong in the relevant authorization and business service components, even if some enforcement is coordinated through the gateway.

Confusing client authentication with operation-level authorization creates a serious risk of unauthorized data access. The distinction should be explicit in architecture diagrams, API specifications, and test cases.

How Should Authentication, Authorization, and Access Permissions Be Designed?

Open Banking security requires several related but distinct decisions: who is making the request, whether the provider is entitled to use the interface, whether the customer has completed the required authorization process, and whether the requested operation falls within the permitted scope.

Third-Party Provider Identification

The bank must identify and verify external providers using mechanisms appropriate to the regulatory regime and selected interface standard. These may include certificates, trusted provider information, and secure client authentication mechanisms.

Provider identity should be checked as part of a broader access-control process. A technically valid connection must not be treated as permission to access every API capability.

OAuth 2.0, OpenID Connect, and Security Profiles

OAuth 2.0 can support delegated authorization, while OpenID Connect provides an identity layer where applicable. More restrictive profiles, such as those developed by the OpenID Foundation’s Financial-grade API (FAPI) working group, may be relevant depending on the selected architecture and standard.

These mechanisms should be implemented according to the applicable profile rather than assembled as an informal collection of security features. Token validation is necessary, but it is not a substitute for checking business permissions.

Strong Customer Authentication

Strong Customer Authentication (SCA) must be applied where required by the relevant rules and process. The architecture should support the appropriate customer authentication journey while preserving the context of the requested operation.

The exact flow depends on the type of service, applicable exemptions, and adopted interface specification.

Managing Access Scope and Revocation

Access decisions may need to be associated with a particular user, account, service, operation, and period of validity. The system must also handle expiration, restrictions, and revocation.

For example, if a customer’s relevant access authorization is withdrawn, the bank must prevent subsequent requests that no longer meet the applicable authorization conditions. The implementation should not rely only on a token that remains technically valid.

Auditability of Access Decisions

The bank should retain appropriate evidence of authentication events, access decisions, permission changes, and API operations. Logs must be protected and should not unnecessarily expose sensitive customer information or credentials.

Audit records are valuable not only for compliance. They also help engineers reconstruct failures and determine whether an unexpected response originated from an authorization decision, a technical error, or a source-system issue.

How to Integrate Open Banking APIs with Core Banking and Legacy Systems

Core banking systems were not necessarily designed to serve large numbers of external API consumers. Directly exposing their internal interfaces can increase coupling, operational load, and the cost of future changes.

A more controlled approach places domain services and integration adapters between the public API and the source systems.

Domain Services as a Stable Business Layer

An Open Banking domain service implements a defined capability, such as retrieving permitted account information or processing a payment initiation request. It works with business concepts relevant to the API rather than exposing the proprietary structure of the underlying core system.

This separation helps keep external contracts stable when internal data sources or integration mechanisms change.

Legacy Adapters and the Anti-Corruption Layer

An adapter translates requests and responses between the Open Banking service and the source system. It may handle protocol conversion, field mapping, error translation, and connection-specific requirements.

An anti-corruption layer goes further by preventing legacy concepts and data models from spreading into newer services. This is especially useful when the bank is modernizing components incrementally.

Identifying the System of Record

For every exposed data element or operation, the architecture should establish which system is authoritative. A balance displayed by one component may not have the same meaning or update timing as a balance calculated elsewhere.

Without clear ownership, different API responses can become inconsistent. The problem cannot be solved simply by transforming field names.

Managing Timeouts and Source-System Failures

External APIs need defined timeout policies, error responses, concurrency controls, and appropriate failure isolation. Retries must be designed carefully, particularly for operations that can change state or initiate payments.

For payment-related operations, idempotency and status reconciliation are important safeguards against duplicate execution or uncertainty following a timeout.

Example: Account Transaction History

A third-party provider requests transaction history through the Open Banking API. The domain service verifies the applicable access scope, then calls an adapter that translates the request into the format supported by the source system.

The adapter maps the response back into the agreed API contract. If the bank later changes its internal transaction history component, the external interface can remain unchanged as long as the new adapter preserves the required semantics and behavior.

This reduces the need for partner-side changes and makes modernization less disruptive.

Which Integration Patterns Work Best in Open Banking?

There is no single integration pattern suitable for every Open Banking operation. The appropriate approach depends on response-time requirements, source-system capabilities, the type of business operation, and the applicable API specification.

When Is Synchronous Communication Appropriate?

Synchronous calls are useful when the API must return data or a decision within a defined time. However, the architecture should not allow slow source systems to consume unlimited gateway or application resources.

Timeout budgets, concurrency limits, and appropriate fallback behavior help protect the platform. Any fallback must remain consistent with the semantics and requirements of the API.

When Does Asynchronous Processing Help?

Some internal operations may benefit from queues or asynchronous orchestration. This can decouple processing stages and help absorb temporary load.

However, a bank cannot freely change the behavior of a regulated external interface. If the applicable specification requires a particular request–response or status model, the implementation must preserve it.

How Should Event-Driven Integrations Be Controlled?

Event-driven patterns can support internal state propagation and permitted notification mechanisms. They require clear event ownership, duplicate handling, replay policies, and monitoring.

For financial operations, the team must explicitly define what each event means. An event indicating that a payment instruction was received is not equivalent to confirmation that the payment was finally settled.

How Do AIS and PIS Flows Work in Open Banking Architecture?

Account Information Services (AIS) and Payment Initiation Services (PIS) use related security and integration components, but they represent different business operations. They should not be modeled as interchangeable API calls.

AIS – Access to Account Information

In a typical AIS scenario, an authorized provider retrieves account information within the applicable scope of access.

1. The customer starts the account information process through an external service.
2. The bank verifies the required authentication and authorization elements.
3. The provider obtains access within the permitted scope.
4. The provider sends a request to the Open Banking API.
5. The domain service verifies the request and retrieves data from the relevant source systems through the integration layer.
6. The bank returns a response consistent with the API contract and access permissions.

The architecture must also handle expired or revoked access. A previously successful request does not guarantee that future access remains authorized.

PIS – Payment Initiation

PIS concerns the initiation of a payment instruction, not simply reading account information.

1. The authorized provider submits a payment initiation request.
2. The bank validates the request and applicable permissions.
3. The customer completes the required authorization process.
4. The relevant payment system accepts or processes the instruction according to its rules.
5. The API exposes the appropriate status information defined by the interface contract.

The system must distinguish between receiving a payment instruction, accepting it for processing, executing it, and final settlement. These stages may have different meanings and timing.

Hypothetical AIS Integration Scenario

Consider a bank that wants to allow an authorized AIS provider to retrieve account information. The bank maintains account balances in its core system and transaction history in a separate component.

The provider initiates the access process. The bank verifies the provider’s identity and the applicable customer authorization. The request passes through the API gateway to an Open Banking service, which checks the account-level access scope.

The service calls the relevant adapters, receives the required data, and maps it to the API contract. The bank records the appropriate access and technical events for monitoring and audit purposes.

If access is revoked, subsequent requests must be evaluated against the updated authorization state. If the source system is unavailable, the API should return an appropriate error or status rather than silently supplying inaccurate data.

This example is hypothetical and does not describe a verified Edge One Solutions client implementation.

How to Secure Open Banking APIs Against Abuse and Outages

Open Banking security extends beyond encrypting traffic and validating API credentials. The bank must protect sensitive data, enforce permissions, prevent abuse, and limit the impact of failures across connected systems.

Open Banking API Security Checklist

OWASP API Security Risks

The OWASP API Security Top 10 is a useful reference for assessing API vulnerabilities, including broken object-level authorization, broken authentication, and unrestricted resource consumption.

For banking integrations, object-level authorization is particularly important. A request containing a valid account identifier must not succeed unless the caller is permitted to access that specific account and operation.

PSD2, RTS, and Operational Resilience

Regulated Open Banking interfaces must account for the applicable PSD2 requirements and Regulatory Technical Standards on Strong Customer Authentication and Common and Secure Communication (SCA/CSC).

DORA is relevant to ICT risk management and operational resilience in financial institutions. Its requirements should be assessed alongside the bank’s internal architecture and service management policies.

Security controls must be designed for the actual service and jurisdiction. A generic API security checklist does not replace the applicable regulatory and interface-specific requirements.

How to Test and Monitor Open Banking Integrations

Partner onboarding becomes slower and more expensive when integration defects are discovered only after production access is granted. A well-designed Open Banking platform should provide repeatable tests, documented contracts, and sufficient observability to diagnose problems across system boundaries.

Contract and Conformance Testing

Tests should verify that requests, responses, errors, and status transitions match the selected API specification. This includes field formats, required parameters, authorization-related behavior, and version compatibility.

Where relevant, the bank should also perform conformance testing against the adopted Open Banking standard or profile.

Integration Testing with Source Systems

Tests must cover mapping accuracy, source-system errors, timeouts, and differences between internal and external data models. Test doubles are useful during development, but they should not replace appropriate integration testing with representative backend environments.

Security and Negative Testing

Critical scenarios include invalid credentials, expired access, revoked permissions, unauthorized account identifiers, malformed requests, and attempts to exceed traffic limits.

Payment-related tests should also cover duplicate requests, ambiguous outcomes after timeouts, and status reconciliation.

Performance and Resilience Testing

The bank should test expected load, peak traffic, source-system degradation, and recovery behavior. It is important to understand how a slow legacy system affects gateway capacity and other API consumers.

Sandbox for External Partners

A partner sandbox can provide documentation, sample requests, synthetic data, and predictable test scenarios. This reduces dependence on bank engineers during initial integration and helps partners identify issues before production onboarding.

End-to-End Observability

API metrics should be complemented by distributed tracing and correlation identifiers linking the partner request to the gateway, domain service, adapter, and source system.

Logs should enable investigation without unnecessarily exposing account data, authentication credentials, or other sensitive information.

How to Expand Open Banking Without Increasing Core Banking Dependencies

Every new partner should not require another direct connection to a legacy system. Otherwise, the number of integration paths grows, maintenance becomes more expensive, and core banking changes become harder to coordinate.

Stabilize External API Contracts

Partners should depend on clearly defined API behavior, not internal implementation details. Versioning and compatibility policies help banks evolve their services without forcing unnecessary changes on existing consumers.

Separate Domain Services from Legacy Adapters

Domain services should express banking capabilities. Adapters should handle the specifics of internal protocols and data formats. This separation makes it easier to replace a source system or change integration technology.

Reduce Point-to-Point Integrations

Centralized API management and reusable integration capabilities reduce the need to build every partner connection from scratch. However, centralization should not create a single component containing all business logic or become an uncontrolled bottleneck.

Modernize Bottlenecks Incrementally

When a legacy component repeatedly limits performance or requires extensive manual changes, the bank can modernize that component while preserving the external API contract.

Such changes may involve replacing an adapter, introducing a domain service, improving caching where permitted, or redesigning a specific internal workflow.

The objective is controlled modernization, not replacing core banking simply because the bank wants to introduce additional partners.

Keep Open Banking Within the Wider API Strategy

Open Banking may become an important part of the bank’s broader API architecture, but it should not automatically take over every internal integration responsibility.

Public or partner-facing API capabilities and internal integration services may have different security, availability, and lifecycle requirements. Their responsibilities should be defined explicitly.

How to Measure the Effectiveness of an Open Banking Architecture

Architecture quality should be evaluated through outcomes that matter to both engineering and the business: partner onboarding speed, API reliability, operational effort, and the cost of introducing new services.

These metrics should be compared over time and interpreted in context. For example, an increase in authorization failures may indicate abuse attempts, partner configuration errors, or a newly introduced defect. The number alone does not explain the cause.

Likewise, a shorter onboarding process is valuable only if the bank maintains the required security, testing, and operational controls.

When Should a Bank Involve a Technology Partner?

Open Banking architecture often requires coordinated work across backend development, API integration, legacy systems, security, and QA. An external technology partner can help when internal teams need additional engineering capacity or specialist integration support.

Edge One Solutions can support banks and financial institutions in areas such as:

• Backend development and implementation of domain services.
• API design, development, and integration.
• Middleware and integration-layer development.
• Legacy system adapters and architectural modernization.
• API testing and test automation.
• Additional software engineering and QA capacity.

The goal is to help the bank maintain control over its architecture while reducing the engineering effort required for each new integration.

For a broader overview of relevant capabilities, see Edge One Solutions’ banking and financial services offering.

Conclusion: Scalable Open Banking Starts with Architectural Separation

Open Banking should not require banks to expose core banking directly to external providers or develop a new point-to-point integration for every fintech partner.

A well-designed architecture separates partner access, API management, authentication, business authorization, domain services, and communication with legacy systems. This enables more predictable integration development and reduces the impact of internal technology changes on external services.

For CTOs, the business value is clear: a more manageable partner ecosystem, better control over operational risk, and a stronger foundation for launching additional financial services without repeatedly modifying core banking.