Alex Noyes

Open Banking: An API-Driven Approach to Financial Data Sharing

Open banking offers users a way to have easier access to their own bank account information, like via third-party applications. This is  achieved by allowing third-party financial service providers access to the financial data of a bank's customers through the use of APIs, which enable secure communication between the different parties involved.

Some notable examples of banks and financial institutions that are leveraging open banking to offer enhanced services, increased transparency, and a more personalised banking experience for their customers:

Barclays has launched an open banking API platform, providing access to a range of APIs for account information, payments, and transactions.

Klarna has launched an innovative open banking platform called Kosma, revolutionising access to more than 15,000 banks in 27 countries

Wells Fargo has an API portal that provides a suite of tools and sample code for developers, along with a testing environment.

Monzo utilises open banking to make easy bank transfers, see all your accounts at once and even prove your income to get an overdraft.

Additional examples include Truelayer, Trading 212, Plaid, Revolut, and Mint. Each of these organizations utilizes open banking in various ways, from account aggregation to payment processing and personal finance management. Take a look at the Open Banking Tracker for more information.

As far as API journeys are concerned, the intricate, sequential interactions of open banking can be quite demanding when it comes to monitoring. The layers of authentication, authorization, encryption and data transfer mean that a single transaction will involve multiple steps and several API endpoints working together, each bound by the step before. This means that monitoring an isolated endpoint is not enough, and that we’ll rather have to look at the flow as a whole, while still surfacing the right information in case of failure to let us quickly understand what has broken in this complex exchange.

To better understand the challenges that monitoring open banking flows poses, let’s look at an example flow from the Klarna XS2A App.

The Open Banking XS2A App handles all consumer interactions. It is used whenever the API flow requires an input from the consumer, such as selecting the consumer bank or the strong customer authentication towards the bank. In addition, depending on the selected flow, the XS2A App may be used to select a specific bank account or to authorize an account-to-account payment.

Now, let’s break down the flow into its constituent steps:

Start Session: The process kicks off with a PUT request to Klarna's session initiation endpoint, where we set up the necessary parameters for an open banking session. Language preferences, bank details, user information, and the scope of consent for accessing various account services are all defined here so the session scope is defined from the start and cannot be hijacked for any other purpose.

Start Account Details Flow: Upon obtaining a session ID, we proceed with another PUT request, this time to initiate an account details flow. By further specifying account identifiers and cryptographic keys, we are ensuring that all communication is secure.

Select Test Bank: A POST request follows, aimed at selecting a bank for the user. This step simulates the customer's bank choice within the Klarna playground. 
a. [Optional] Get Flow Configuration: Next, we perform a GET request to retrieve the current state of the flow. This step ensures that the transaction sequence is progressing as expected.

Encrypt Responses: This phase involves sending responses encrypted using both AES and RSA encryption algorithms. The encrypted payload is sent back to the API endpoint using a POST request, including the RSA-encrypted AES key and the AES-encrypted data.
This multi-layer encryption approach ensures that the encrypted data can only be decrypted by the API endpoint with the corresponding RSA private key, and the AES key remains protected throughout the transmission.

Complete Flow: This step ties up the transaction flow by posting the acquired redirect details back to Klarna's API, confirming the API actions and moving the process forward.

User Bank Account Selection: The account value fetched in step five is sent over. We have to encrypt the account numbers for security.

Get Consent: A POST request is made to secure consent for data access, a regulatory requirement for open banking services. The response includes URLs for account details and balances, which will be used in subsequent requests.

Get Account Details and Balance: The final POST request involves fetching the user's account details and balance, signifying the completion of the transaction flow. These requests validate the consent token and return the specific account information.

Testing a single API endpoint with Playwright

The flow we just analyzed is composed of 8 steps and 11 requests.

If we were to write a Playwright script to test the first request in isolation, it might look something like this:

Running this script on a schedule might give us precious information already, but given how interconnected these endpoints will be in the context of the open banking flow we are testing, we’ll want to chain each request to test the flow end-to-end.

Playwright can help us big time here, by allowing us to wrap each request and subsequent response manipulation in its own test.step() to keep our code cleaner and our reporting more understandable.

Here is what the whole flow would look like end to end (we’ve numbered the steps in the code to match our flow breakdown from above):

Note that we’ll need to export the KOSMA_AUTH_TOKEN environment variable set to the value of Kosma’s demo auth token.

Our script comes with an additional dependency on top of just Playwright, functions.js, which looks as follows (and also includes jsbn.js.):

To make sure the flow is reliably functioning in its entirety, we need to run our test at regular intervals, making it effectively a monitoring check. Our check will probably need to run from multiple locations, and surely will need to be tied to one or more alert channels. The Checkly CLI enables us to get started quickly defining all of this without leaving a code editor.

Now let’s initialize a Checkly CLI project and copy our script from above into it. To save you time, we’ve done this for you already.

Note how we are defining a Checkly multi-step API check, using the appropriate construct:

This is pointing to a xs2a.spec.ts which contains our Playwright spec testing the entire API flow end to end.

Whenever the check fails, Checkly will reach out to us using the linked emailChannel and callChannel:

These are of course examples; Checkly is able to alert on a wide variety of channels reaching from email and SMS, to Pagerduty and OpsGenie, through Slack and MSTeams.

Our check is also inheriting check defaults that are set at project level in our config.checkly.ts:

Note the locations the check will run from, the scheduling strategy runParallel and the frequency param. We’re ensuring our checks are running at high frequency and from multiple locations at once to thoroughly monitor what is an essential, customer-facing flow.

Code-wise everything is ready, but we still need to feed the KOSMA_AUTH_TOKEN environment variable from our Playwright spec into Checkly if we want the check to actually work. We can easily do that with:

We are now ready to actually deploy our check to Checkly:

Logging into our Checkly account, we can see our check is now running as scheduled:

For each call, we can now see detailed reports showing the timing, result and other request details for each request in our check:

Our linked alert channels have been deployed too:

Checkly will now email us and call us on our phone when our open banking flow is broken, allowing us to jump into a detailed report showing which step failed in this complex flow. That’s handy.

Not only may poor API performance and difficulties affect end users, but they can also create concerns with industry standards organizations and regulators. As open banking APIs handle very sensitive data, constantly monitoring these flows is key to data security and user satisfaction.

In this blog post, we provided a detailed guide on using Playwright and Checkly to test and monitor the Klarna Open Banking XS2A API flow. We also showed you how to encrypt responses for security, set up monitoring checks, create alert channels for failure notifications, and deploy the check to Checkly for regular monitoring. To get you started, we've set up this GitHub repo.

By combining Checkly and Playwright, you can ensure your open banking flow is functioning correctly and be alerted promptly when issues arise.

Give Checkly a try today and experience seamless API flow testing and monitoring.

Monitoring an Open Banking Flow With Playwright & Checkly

Detect

Communicate

Resolve

Monitoring as Code

Developers

Resources

Community

Monitoring an Open Banking Flow With Playwright & Checkly