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)

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.

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?

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

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:

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.

Update:

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

Financial Data Exchange

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:

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:

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.

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
Host: my-openbanking-gateway.com
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.

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.