Work with us

Technology Architecture and Best Practices for Enabling Financial Data Portability

Open Banking is the enablement of financial data portability across the financial services ecosystem by unifying technical infrastructure and standards that define how, when, and what data is shared between parties.

Open finance facilitates a greater level of control for consumers over their financial data.  It also underpins an innovation landscape for companies to provide new products & services to meet evolving consumer needs. 

All these new products and services are delivered through APIs.  APIs allow third parties to securely pass data between systems and provide a better customer experience.

Simply put, Open Banking is “the evolution of the kind of API-based integrations that organizations have been building for decades.” – Eyal Sivan, Mr. Open Banking

We’ve developed this resource to help technical teams adopt an Open Banking approach by explaining a high-level solution architecture that is organization agnostic. We also explore technology best practices that we believe will increase the chances of a successful Open Banking adoption journey.

Download the Whitepaper

We’ve made this free resource available to help technical teams prepare to deliver an open banking future.  We’d welcome your feedback on its value.
Download the Free PDF version here.

Open Banking architecture whitepaper


Whitepaper Topics

Beyond Screen Scraping

Screen scraping allows TPPs (third-party providers) to have access to a customer’s banking information through the user’s credentials (login and password) which are stored in a database. The apps developed by the TPP impersonate the actual customer and fetch as much data as they need by inspecting the HTML content from the bank’s portals. This leads to a variety of security issues:

  • Regardless of the specific data elements required by the TPP app (say the app just needs your saving account balance), in practice they have access to everything an actual user would after logging in (mortgages, credit card, loans, risks analysis, etc.)
  • If for some reason your credentials get stolen by an attacker, they will have the ability to make any transaction, just like the user would
  • Once the credentials are shared, users lose control over what providers can see and for how long
  • Although the TPP tries to protect customer data, the truth is that sharing credentials (especially the ones that have access to your money) will always make the user vulnerable
  • Screen scraping may also be a potential violation of the bank’s terms and conditions (many banks have specific conditions on the expected usage of their products, especially when it comes to inter-personal user accounts)

A diagram showing how bank data is shared using screen scraping methods

It is important to highlight that the problem here is not the TPPs but the way that financial data is obtained. Third-party applications themselves must deal with multiple challenges including the usage of proper means to keep credentials secured and keeping up with frequent changes by the banks’ portals (let’s recall that Screen Scraping relies on fixed data elements present in a web page). In this way, screen scraping is both hard to maintain and open to potential risks.

This is where Open Banking differs from screen scraping. By promoting the development of secure and regulated APIs to make consumer’s financial data available, banks and FinTechs are working with regulatory bodies to create standards (communication protocols) to link banks with third-party apps. This movement is clearly establishing a financial network that can securely exchange information.

Open Banking: From the Consumer Perspective

Around the world, customer data has enabled a more efficient, interconnected ecosystem approach to deliver financial services.

But practically speaking, what does this mean for consumers?

open banking ecosystem overview

Through permission based data management, customers have access to new applications that promise convenience, security and control over their financial experience like never before.

It is important to emphasize that Open Banking’s intent is not simply exposing our financial information to any provider to access it. Any action conducted around sharing customer’s data (such as bank balance, transaction data, payment initiation, etc.) can only take place with their specific consent and the entities who are able to integrate and access will be strictly regulated by the respective financial authorities of each jurisdiction.

Through smarter data usage, consumers have access to new applications that promise convenience, security and control over their financial experience like never before.  We’ve developed a number of open-banking enabled use cases with clients but here are a few of the biggest opportunities for consumer driven finance to deliver new and improved products and services for consumers:

  • Account aggregation: Allows customers to get an overview of their various accounts across different banks.
  • Personal Finance Management: Provides the customers with a complete overview of their financial situation (including a monthly spending budget).
  • Instant Credit Risks: Allows lenders to gain an almost instantaneous overview of an applicant’s credit history (especially useful to speed-up credit applications).
  • Subscription Management: Detects all the recurring payments from the customer and shows them in one interface.
  • Taxes Preparation: Banks can communicate with accounting platforms to retrieve tax data, which will allow them to realize operational efficiencies to reduce call volumes during the tax season.
  • Payment Initiation: Think of this as a simplification of the payment experience, where there will be multiple payment options within the same payment interface; additionally, payments will be processed in minutes or hours versus days.
  • And more…

Adopting a Standards Based Approach

Regulators must confront numerous challenges such as security regulations for trustworthiness. Many countries (including Canada) are still formulating their Open Banking regulations and each nation will have its own version of the rules as there is a lack of a global standard.

From a technical standpoint, ecosystem participants are expected to provide the development of Open Banking APIs that follow  Open API Specifications.

These specifications define the message structure of the data to be exchanged, including elements such as HTTP headers, Methods, URIs, Practices, etc., and the means to expose them using the right infrastructure so that services can be offered in a highly available and secure way.

FDX API Standards from The Financial Data Exchange

FDX (Financial Data Exchange) is a non-profit industry standards body operating in the US and Canada.

The purpose of the FDX is to unify the financial services ecosystem around a common, interoperable set of technical standards for user-permissioned financial data sharing.

Over the last few years this organization has quickly establishing itself as the de facto North American Open Banking standard.

Today, FDX is used to share over 65 Million consumer records across the North American financial ecosystem, and their membership includes most major US banks and FinTech companies. From the FDX implementer standpoint, the most important step is to get the technical certification as this is the means to demonstrate full conformance to the standards on in-market products.

Ecosystem participants aiming to achieve FDX certification  must ensure compliance with the following requirements:

  • Data Completeness
  • FDX API Conformance
  • FDX Security Profile Conformance
  • Automated Recipient (app) Registration Support
  • Capability and Metrics Endpoints
  • UX Consent Principles
  • FDX Registration Integration
  • FDX Monitored Performance and Availability
  • Statements Support

Open Banking Open API Specifications

Open API specifications are a key element in the overall regulatory work done by FDX. In the current version, there are standardized domain/operational areas such as Personal Information, Accounts Transactions and Money Movement, based on the common needs of the market, and all these resources have been organized as below:

FDX Open Banking Open API Specifications

Because these resources have been specified using OAS (Open API specification), the APIs must be exposed must be REST endpoints which have to be protected with different levels of security involving mainly transport and message-level techniques. It is up to each implementer to decide what technology (programming language/framework) or infrastructure approach (on-premises, cloud, hybrids, brands, etc.) to put in place as part of the implementation plan.


FDX releases updates to the FDX OAS twice a year.  More details can be found on their website and access is free with registration.

Technical Architecture

Logical View of Technical Architecture for Open Banking


For most financial institutions the idea of adopting financial standards such as Open Banking (or even Open Finance) comes with some amount of reengineering of the existing operational applications and infrastructure services.

Often times the main driver for a transition of this magnitude will always be adopting a modern architectural style complemented with integration techniques that are battle proven.

Microservices Architecture is quickly becoming an effective reference model in the platform banking ecosystem due to its inherent flexibility, scalability, and resilience.

Depending on the technology infrastructure, core banking platform approach, and integration maturity of the organization-  the level of support required to meet this transition will vary.

Broadly speaking, financial institutions fit into one of two categories relating to their technology approach:

Modern Architecture + Banking Core

Legacy Core + Architecture

This category refers to organizations with modern cores, typically with service-oriented and mature API-based architectures, in general they already leverage cloud deployment-based models.

Learn more about Composable Architecture 

These are generally banks that still rely on monolithic applications with multiple point-to-point integrations. For some cases these solutions are running in traditional mainframes or regular on-premise infrastructure.

Regardless of the scenario, by considering an enriched microservices-based architecture these organizations will enable a critical driver for their platform’s evolution, and all of this is due to the nature of this design style which allows greater integration flexibility (enabling rapid delivery and consumption of new capabilities while minimizing risk) through a deliberate approach with short- and long-term goals.

Architecture Building Blocks

The intent of this reference architecture is to capture the most important elements needed to support a fully functional Open Banking implementation. A core aspect of the solution is the enablement of the existing Operational System by introducing an Orchestration and Composition layer on top of them (essentially this represents and adaptation of your existing application services such as Customer or Accounts platforms). Such a layer is nothing more than a combination of well-defined microservices optimized to respond to Open Banking needs following the corresponding tech specs.

With that said lets deep dive into each building block to define their purpose and context:

API Gateway

The API gateway will be our end-virtualization tool responsible for the exposure of the APIs. It sits between a client and our backend services. This building block acts as a reverse proxy to process all API calls, intercept the traffic, perform aggregation when needed (to fulfill complex requirements) and return the appropriate result. Additionally, this component will help the organization understand how people use the OB APIs since it comes usually with modern monitoring tools.

Any API exposed by this device is in practice a compliant REST Endpoint that follows the OAS specs defined by FDX, it means that behind it, any service can be wired regardless of its technical interface (that’s the part where we can play around with virtualization), in addition to this, since it is the first “interfacing” point for callers, it must be the place to enforce security by implementing modern policies such as MTLS, Open ID Connect, OAuth 2.0 and FAPI.

Data Grid Layer

Its main goal is storing information in memory to achieve very high performance (and increase resiliency of the data in the event of server failure), the Data Grid Layer will represent our management system for objects that are shared across multiple microservices. One of the most significant benefits it provides is the incredible low response time, predictable scalability, and very high throughput.

By design, this component must support continuous availability and information reliability by using redundancy (which implies having in place a sophisticated approach to keep copies of information synchronized across multiple servers).

Each microservice interfacing with this layer must determine whether storing data is appropriate based on the nature of the scenarios, especially as the data stored in it is basically cached information that may be outdated.

Identity and Consent Manager

Identity and Consent Manager is responsible for the authentication and authorization required to ensure that OB APIs are secure. It is a framework of policies/technologies to ensure that the right users have the appropriate access to financing resources (backend APIs), as part of the access control, security profiles such as FAPI are put in place.

This building block also provides an administration view for your organization that allows you to search and manage your customers’ consents.

Identity Provider

The Identity Provider is an enterprise service that stores and manages digital identities.
It is mostly used for storing the identities of the  consumers/users that are interacting with the OB APIs throughout the third-party apps.

This building block is exclusively accessed by the Identity and Consent Manager, and it is considered as one of the (core) existing banking systems.

Analytics Engine

This data analytics component includes visualization tools (such as reports and dashboards) and business intelligence (BI) systems, as it is fed with the data collected from the API Gateway (usually stored as a data lake). Data scientists and other technical users can build analytical models that allow bank areas to not only understand their past operations, but also forecast what is happening in the Open Banking ecosystem.

API Portal

The portal is responsible for delivering the Developer Experience to third party developers. It acts as a bridge between Open Banking APIs and consumers by providing information about the APIs at every stage.

API portal will allow educating developer communities about the constraints and aspects needed to call the exposed Open Banking APIs, this component communicates with the API Gateway to provision applications and associated credentials.

Enterprise API Manager

API Manager is the main driver of the API lifecycle, and will track the enablement of Open Banking APIs from their creation, testing, documentation, publishing and discovery.

In addition, the API manager will act as the management plane of the API Gateway by managing the policies to be applied on it (security, rate limiting, enablement, etc.)

Logs Aggregation Engine

This component is responsible for collecting, standardizing, and consolidating log data from across all the OP Optimized Microservices to facilitate streamlined log analysis.

By capturing event log files from the microservice layer, IT teams will be able to convert their log files into actionable insights in real-time or near real-time.

OB Optimized Microservices

It’s a combination of multiple microservice-based applications that expose REST endpoints following the OAS specs defined by FDX. These endpoints are directly consumed by the API Gateway (which is responsible for virtualization and policy enablement).

Think of these applications as custom, highly scalable adapters that interface with the existing Core Banking Systems to enable the data stored by them so that this is available for consumption from outside the bank in a compliant format.


open banking optimized microservice


These building blocks become the core of open banking solutions and will present the right conditions for introducing orchestration and composition.

Depending on the nature and technical interface exposed by the existing core banking systems, different strategies can be put in place. Here are some expected cases:

  • REST Based Integration: Ideal for downstream systems exposed as REST APIs
  • Legacy Protocols Integration: Indented for scenarios where services with legacyprotocols are present (TCP/IP Sockets, Mainframes, RPC style Web Services, etc.)
  • Async Based Integration: Ideal to integrate systems that rely on messaging (IBM MQ,JMS, Kafka, etc.)
  • Direct Data Integration: Intended for scenarios where the data can be directlyaccessed from a repository (Databases, file systems, etc.)Downstream SystemsRepresents the existing core banking systems that store financing information such as credit, customer info, transactions and account data.
  • Our approach does not seek to displace or deprecate these systems but enable them in the Open Banking Ecosystem by leveraging the Open Banking Optimized Microservices.

Cloud Infrastructure

Cloud infrastructure is a key element of enabling financial data portability, because it allows scalability, flexibility, cost savings, and faster speed to market, amongst others.

Having the capability to spin up new instances or retiring them in seconds will be crucial for
our technology plan.

That’s why choosing an approach based on a Container Orchestration Engine such as Kubernetes is the ideal way to go.

In this way, the core elements (Open Banking optimized microservices, API Gateway/Manager/Portal and Consent Manager) of the architecture can be deployed as scalable Kubernetes PODs.

Cloud Infrastructure for Open Banking Diagram

However, this doesn’t mean that all the services and capabilities required by Open Banking are necessarily PODS in the Kubernetes cluster. Many cloud providers come with prebuilt capabilities that are perfect fit for our needs, here is a list of the most common cases based on our experience:

  • Identity Manager Service
  • Log Aggregation Service
  • Data Grid/Cache Service
  • Logs Aggregation
  • Data Storage

Open Banking Security

Security is a key consideration in our Open Banking ecosystem and from the FDX standpoint, the work to be done is definitively quite complex to be explored in a single section. But for simplicity, the most important detail we must be aware of is that every incoming request to our API Gateway must be accompanied by a JWT token which is in turn obtained by leveraging OAuth 2.0 and OPEN ID Connect flows.

Each Open Banking client sends requests using HTTP GET, POST or PUT (DELETE is not allowed) that include an OAuth token in the Authorization header following a structure as the one below:

GET /accounts HTTP/1.1
Authorization: Bearer w0mcJylss-Affgyrbvbvyrtyty6re34dssaa= Accept: application/json
Accept-Charset: UTF-8 Accept-Encoding: gzip

The data provided as a response by an Open Banking API is limited to what the user could see using his standard login and the scopes referred in the OAuth token. As per specification, these tokens can be Bearer or MAC. But that is not all. Open Banking relies on both JSON Web Signatures and JSON Web Encryption to ensure end-to-end consistency and protect each piece of data. To take advantage of these security mechanisms both the data provider and data recipients should have RSA key pairs and the public keys should be available as signed certificates on a JWKS endpoint.

Best Practices and Recommendations

Based on our experience developing, implementing and supporting Open Banking within the financial services ecosystem, here are our top nine recommendations you shouldn’t miss in your endeavour towards adopting Open Banking:
1. Leverage existing platforms as much as possible
Especially when it comes to projects at this scale, a typical doubt that appears is whether to purchase an enterprise platform that fits with the building blocks required in the solution or develop them from scratch. Because this can be a complex transformation, whenever possible use open source or purchase toolsets for any need that is not your actual core business (instead of trying to implement custom application services), there are competitive vendors (such as Axway) with all of the packages needed in the architectural plan that can integrate seamlessly with your existing ecosystem.
2. Enable automatic Security Scans for Open Banking APIs
Open Banking is all about exposing APIs to interact with external parties and inherently this practice may raise potential vulnerabilities. This is why Open Banking adopters can (and must) frequently harden and refine their security infrastructure and resources to face future attacks properly.
Nowadays there are multiple alternatives to secure APIs across their entire lifecycle. Preferably, look for choices that make use of adaptive technologies like artificial intelligence (AI) and machine learning (ML).
Define periodic jobs to run your security scan and keep its rules up to date.
3. Don’t set your Open Banking architecture in stone
Static architectures in the Open Banking world are not convenient because standards are still evolving to address changing needs.
Be flexible and consider “change” as a natural event in the process. Design your Open Banking ecosystem to allow changes causing minimal impact. Avoid premature optimizations.
4. Accelerate your delivery process by relying on CI/CD
Having the capability to ship software quickly and efficiently is more important now than ever. Open Banking architecture itself is complex by nature and demands the setup of various software components that require a mechanism to facilitate an effective process for getting services to production faster by ensuring an ongoing flow of new features and bug fixes. Removing traditional roadblocks must be a priority while keeping the DevOps approach of aligning development and operations teams via the most efficient delivery method.
5. Isolation is a “must” for your architecture building blocks (Docker/Kubernetes)

We’ve already mentioned that Open Banking is made up of different components
that cover a variety of responsibilities, and we have gone over the importance of each. This is why leveraging a solution for high availability and solution encapsulation is another key aspect in the endeavour towards Open Banking.
Technologies such as Docker containers and Kubernetes further enable the foundation of your architecture.
Because a high-level of resilience is a must, ensure that your infrastructure is robust by design and hence your OB services will be highly available.  Your goal should be getting to the point where your Open Banking APIs remain online even if some of the components
go offline.
6. Define an API catalog with all the Open Banking capabilities
The more organized your APIs and resources are the better.
This is something you can achieve by adopting an API management platform that will provide you with a 360-degree view of the APIs in your ecosystem, not only the ones exposed to the outside but the ones that operate in the inside of your architecture.
Elements that will be tracked include the version, contract type (OAS, protobuf, graphql, wsdl, etc.) physical location, purpose, authors, dependencies, security policies, proxies, and consumers.
Empower your teams to take advantage of this resource and include it in the software development life cycle so it is  maintained properly.
7. Take advantage of the data ingested by your APIs
In this modern era, companies need to make informed decisions about their products, services or business strategies through the data their systems collect. APIs are by far the ideal mechanism to gather such data (especially if we consider the number of expected transactions in an Open Banking solution).
Data analysts help sort through this data but that’s not enough, make sure your architecture leverages the proper building blocks (analytics engine, log aggregators and an API Gateway) to manage and exploit each piece of data gathered by your system, this will be the only way your organization will be in a position to draw conclusions, make predictions, and drive informed decisioning.
8. Opt for a Cloud Infrastructure whenever possible
Organizations across the world are relying on cloud deployment services, even in situations where sensitive data must be moved from traditional data centers (on prem) to the cloud.
Cloud computing models provide organizations with realistic flexibility in the sense that you can quickly scale resources such as memory, CPU and storage to meet business demands without having to invest in physical infrastructure.
Keep in mind that Open Banking (as with any other solution) has special scalability needs that would be hard to satisfy with a non-cloud model.
9. Rely on abstractions as the main enabler of your existing capabilities
The architecture we’ve proposed in this document doesn’t imply you must refactor your core systems to expose the required data. It  presents a model in which an adapter layer enables your existing services to be used as compliant Open Banking resources and that is possible due to the old but solid principle of abstraction.
This protection layer allows you to mitigate impacts with existing consumers (dependencies) while preparing for Open Banking enablement. It also introduces routines such as transformations, routing and content enriching.



The Ecosystem Economy is Here to Stay.

The Ecosystem Economy is Here to Stay.


The forecasted growth of API calls generated by Open Banking by 2027. 1

95% Of Small Business Owners

Consider themselves to be heavy users of fintech for both personal and business needs.2

$330 Billion

In global Open Banking payments by 2027. Adoption will be driven by Bill Payments + E-commerce integrations.3

Fintech Partners

Let’s Chat About Your Open Banking Strategy