Open Banking: Read/Write API & Tooling

This is the final post in our Open Banking series. The previous articles talked about Open Banking components and their introduction within the existing infrastructure, as well as the assumptions of security responsibilities among the participants and the challenges this brings. We conclude the series with an overview of the Read/Write API permission model, technical workflow and tooling required for a successful security assessment.

By Daniela Schoeffmann

Assurance Consultant

21 May 2020

First, a few acronyms and essentials from the previous blogpost as a reminder:

  • ASPSP - Account Servicing Payment Service Provider
  • TPP - Third Party Provider
  • PSU - Payment Services User
  • PSD2 - European Union Revised Payment Services

A full glossary is available here.

The Read/Write API was introduced and described in the previous article, but here are the main components briefly listed:

  • AISP - Account and Transaction Information
  • PISP - Payment Initiation
  • CBPII - Card Based Payment Instrument Issuer access

Permission Model

The Read/Write API is the main component of Open Banking, as it handles all access requests for transactions and account data. When describing the permission model, it is therefore important to keep in mind that the end user is interacting with the bank through a third party. The basic workflow was illustrated in figure 1 in the first article.  

The access a TPP has to the Read/Write API is restricted to only what is necessary for the service they provide. Money managing apps are an easy example. There are some apps that focus on budget management and will only need to read account information (AISP API). Other apps may also offer users the ability to make payments, and therefore the TPP would need to reach the AISP and PISP APIs.

The Read/Write API is designed to offer very specific and granularly controlled access to PSU’s (end user) accounts. For any level of access, the TPP needs to create a "consent", and requires the end user to approve it directly through their bank.

Note that the consent is defined by the TPP; therefore it is important that ASPSPs present the user with concise information about the access requests before they authorise the TPP to query the data. The Open Banking specification provides guidelines for the user interface to make the user experience per bank as concise and familiar as possible.

The diagram below shows the user journey for the Account and Transaction API (AISP). The same overall user flow is also applied to PISP and CBPII.

Figure 1: AISP user flow -

  1. The end user wants to display their account balance in a money managing application.
  2. The TPP application redirects the user to their bank to authorise the specific access request. The user logs into their online banking account and confirms that the TPP app can access the account balance. The authorisation view contains the exact access request and how long the TPP will have permission to access the data.
  3. The user gets redirected back to the TPP application with the authorisation for the TPP to query the data.
  4. The TPP application can then connect to the respective Open Banking AISP endpoint for the account balance and display the information in the TPP application until the access request expires.

The diagram shows a simplistic view of the user flow. The next section will go into more technical detail on the user flow and the challenges of testing the Read/Write API. Additionally, we will talk about our Open Banking testing tools.

Testing the Read/Write API

The complexities of the user flow are not immediately obvious when looking at the user flow diagram above (figure 1). Open Banking involves three participants as opposed to the usual client/server model, and utilises various technologies such as user redirects, mutual TLS, message signing and manual authentication and authorisation by the PSU. All of this makes automated testing more complex than that of a regular web services assessment.

The following subsections will first describe the technical workflow and then provide more information on the technologies involved. The knowledge presented in this article can be used for testing TPPs and ASPSPs. However when testing the Read/Write API implementation of an ASPSP the consultant needs to cover more of the user workflow. Therefore we are focusing on the perspective of testing an ASPSP.

Technical Workflow

When testing the Read/Write API for ASPSPs, the consultant needs to assume the roles of a PSU and a TPP simultaneously. The tester therefore needs to:

  • Configure and test mutual TLS;
  • Authenticate to the ASPSP’s OAuth endpoints;
  • Call the respective Read/Write API to create consents and perform the authorised actions;
  • Generate the redirect from the TPP to the ASPSP;
  • Authenticate to the ASPSP as a PSU to authorise access requests (consents);
  • Handle the redirect (callback) from the ASPSP;
  • Implement and configure message signing as per the Open Banking specification.

The diagram below shows an example sequence for an end user making a domestic payment through Open Banking. The grey areas highlight the mutual TLS connection between the TPP and ASPSP and the blue sections mark requests where message signing is required by the TPP.

Figure 2: PISP Domestic Payment Sequence

More detailed sequence diagrams can be found within the Open Banking specification for each version and component, for example Read/Write version 3.1.2 – PISP.

Mutual TLS

Registered bodies within the Open Banking ecosystem have two sets of certificates; for transport and message signing. The Open Banking Security Profile defines that connections to the Read/Write API need to be secured with mutually authenticated TLS (MTLS). The MTLS connection is handled with the transport certificate.


Before a TPP can make requests to the ASPSP’s Read/Write API, they need to authenticate with the OAuth endpoint. This is annotated in figure 2 as “pre-auth OAuth token” and is used to create consents and other requests that don’t require authorisation by the user.

For the other endpoints a different OAuth token needs to be generated with an authorisation code which is included in redirect from the ASPSP to the TPP after consent authorisation. This will be further explained in the “Redirects” section.

For more information on OAuth for Open Banking please refer to the specification. Specific information for each ASPSP can be found within the implementation guide in the Open Banking specification or through the developer portals of the ASPSP.

Message Signing

Along with mutual TLS, the Open Banking specification defines message signing as an additional measure to ensure non-repudiation for specific, sensitive API endpoints from both TPPs and ASPSPs.

The Open Banking signing algorithm stipulates a library compliant with RFC 7515 (critical headers) and RFC 7797 (un-encoded/detached payload). At the time of writing this blog post, the Jose4J Java library by Brian Campbell is one of the few that comply with both of the mentioned RFCs. This may restrict implementation of the message signing algorithm to programming languages with compliant libraries.

The code snipped below is an example for Open Banking message signing with Jose4J:

The important features are highlighted in yellow:

  • Disable Base64 encoding (line 25);
  • Set the critical headers (lines 16, 17 and 29);
  • Generate a detached JWS with the required claims (line 31).

More details on the Open Banking message signing requirements can be found on the Confluence page for each of the Read/Write versions, i.e. version 3.1.

We have incorporated the algorithm into a small graphical user interface for usability. The image below shows an example AISP consent payload and the resulting detached JWS header.

Figure 3: Message Signing

The JWS can then be included in the request with the “x-jws-signature” header as shown in the following example ( is the placeholder for the detached JWS of figure 3):

User Redirects

As shown in the AISP user flow diagram (figure 1), there are two user redirects. With the first redirect the user is sent to the ASPSP to authenticate and then authorise the access request. After the consent authorisation, the user is redirected back to the TPP. The next diagram (figure 4) is a more focused view of the redirect’s technical side.

Figure 4: Redirects

To complete the user flow when testing an ASPSP, we need to:

  • Generate the redirect from the TPP to the bank.
  • Handle the redirect coming from the bank.

Below is an example redirect request from the TPP to the ASPSP. The values within “<>” are placeholders and need to be changed or generated for each consent.

The most important parameters are the “redirect_uri” and the “request” which contain the TPP callback URL and the authorisation request details respectively. More information on the other OAuth2 parameters can be found here.

The JWS includes consent and TPP information. Below is an example JWS structure from the Open Banking specification:

Figure 5:'sDraftv1.1.2-HybridGrantParameters

With the redirect the user is sent to the bank’s authentication portal.

The redirect request parameters need to be generated for each consent. Below is a screenshot of the GUI we have created for this:

Figure 6: User Redirect to ASPSP

After the user has authorised the consent, the bank will send the user to the URL specified in the TPP redirect. This URL needs be one of the registered endpoints from the Software Statement Assertion (SSA). If it is not, then the bank must not forward the PSU.

Below is an example redirect URL:

The “id_token” parameter contains details about authorised consent and the OAuth code (highlighted in yellow) is used by the TPP to create the next access token to perform the authorised action against the Read/Write API. The code is only valid for a few short seconds as specified in the OAuth2 RFC 6749 “to mitigate the risk of leaks”. After all, this code is used to generate the access token for executing a payment or to view sensitive financial data.

Therefore the new access token must be requested immediately after receiving the callback:

Open Banking Burp Suite Extension

We use Burp Suite for the majority of testing web applications and web services. While Burp already offers a lot of great native functions including its many extensions, they didn’t quite cover the user flow of Open Banking (such as the specific message signing algorithm and the user redirects). That is why we have created an Open Banking extension for Burp, featuring the algorithms mentioned in the previous section.

Figure 7: Open Banking Burp Suite Extension

The extension can generate the user redirect just by highlighting the consent ID in a response body and sending it to the extension, automatically sign messages within Repeater and Intruder to enable fuzzing, and also handles the callback redirect from the bank and subsequent OAuth request.

These are just the basic functions required for a successful Open Banking engagement. We have further plans for the extension and are actively continuing development.


The Open Banking homepage and implementation specification offer a wealth of information about this new way of interacting with banks. However, when starting out with this topic it can be quite overwhelming as the system works with a lot of participants and technologies (and acronyms!).

We hope the series of Open Banking articles have given a good insight into what Open Banking is about, how it works, its challenges and how it can be successfully tested. The tooling and code presented in this article should offer a good start for manual assessments of the Read/Write API and we are planning to release an initial version of the Burp Suite extension soon.

If you have a question for us or require any further information, please get in touch.

Contact Us

About Daniela Schoeffmann

Assurance Consultant

Find out more

Book a Meeting

CHECK IT Health Check Service
Cyber Essentials
CESG Certified Service
First - Improving Security Together
BSI ISO 9001 FS 581360
BSI ISO 27001 IS 553326
PCI - Approved Scanning Vendor