The importance of API Testing in Open Banking

Listen on the go!

UK’s Competition and Markets Authority (CMA), after a market study, issued a statement that the nine biggest banks (CMA9) allow authorized startups and third-party providers (TPPs) access to their data. 

The Open Banking Implementation Entity (OBIE) was created to help with this. OBIE’s mission is to collaborate with the UK’s top banks and building societies to promote competition, open up personal data, and provide an individual with a vendor option. 

Why and what is Open Banking? 

Open Banking means the bank’s ability to share financial data with third parties with the customer’s permission. Third parties will access the customer’s financial information, including transaction history, how they interact with banks, businesses used, and spending habits. 

FinTech’s can utilize APIs to connect their services to financial data, thanks to Open Banking. With the consumer’s cooperation, Open Banking marked a move from a closed data model to an open one, in which data can be shared across different stakeholders in the banking ecosystem. 

Banks can provide clients more control over their financial data by allowing them to connect to other regulated providers. Third-party money management software, such as Intuit, can display all transaction details and balances in one place. It will also pave the way for a plethora of fintech innovations. 

It is thus important to understand the business drivers behind the advent of Open Banking. 

Business drivers behind the advent of Open Banking 

The critical business drivers behind the advent of Open Banking are: 

  • Co-innovation with third parties to expand their service offerings 
  • Creation of intuitive and frictionless customer journeys 
  • Pursuing new business models and revenue streams 
  • Accelerated growth and expansion into new markets 
  • Increase market speed without introducing additional risk 
  • Competing with Fintech challengers and the big banks 

While we’ve seen the business drivers behind the advent of Open Banking, it is imperative to understand the key requirements and implementation of Open Banking. 

Open Banking Key Requirements and Implementation: 

An API is an application programming interface that works to connect an application to the web and other APIs. In essence, it is the brain of the connected world and is a set of tools/protocols/standards and code.  

The use of APIs is fundamental to the concept of the Open Banking and Payment Services Directive (PSD2). The requests for services and products which can deliver multichannel customers and provide relationships to these customers need significant development in the Open API sector.  

The API Platform’s primary function is to publish and secure APIs. The Platform is described as a layer that communicates with bank middleware. 


Challenges of API-based infrastructure 

Communication between the various components of Open Banking will be accomplished through an ‘API’-based infrastructure that includes numerous hardware and software components.  

End-to-end testing of these complex infrastructures will be difficult, time-consuming, and error-prone, resulting in higher costs, longer onboarding times, and a danger to reputation. 


Testing Considerations

Potential Areas  


Testing considerations  

  • A robust approach to validate conformance of security, digital performance, and operational OBIE (Open Banking Implementation Entity) requirements.
  • An appropriate Test Environment Strategy to enable end to end tests with TPP’s using ‘Production like’ environments.
  • Adequate test coverage of different payment types across retail and business customers.


  • Physical mobile devices to validate web to mobile/mobile to web /mobile to mobile redirection.
  • Data mapping to ensure correct data is exposed to target OB fields
  • Functional tests to validate for consent, AIS, PIS, confirmation of Funds, access dashboards API
  • End to end customer journeys tests which align with the Open banking [OB] customer experience guidelines


  • Comprehensive tests to MI and reporting solution to generate periodic reports for FCA (including PSD transaction information, fraud/operational & risk assessment, Complaints, etc.)
  • Comprehensive tests of event driven notification to FCA (AIS/PIS denial, major operation/security incidents, etc.)


Develop Tests to validate:

  • Electronic payments initiated by the payer are covered under the SCA solution and the customer experience is consistent across all journeys and channels.
  • Dynamic linking to electronic remote payment transactions
  • Fraud rules implemented consistently across channels

Open Banking Sample Scenario: 

Cus1 and Cus2 are two individuals who want to register for HSBC PSD2 and avail themselves of its services. But they have different customer statuses in HSBC existing e-banking system. The details of both are mentioned below:  

 Payment initiation service: 

Cus1 is an existing customer of HSBC and is already using the current BOV e-banking channel. Cus1 has a 6-digit numeric unique user ID and a physical VASCO device. Cus1 wants to make a payment from PayPal (TPP) using his HSBC account.  
-Sample API requests: GET-Payment ID, Payment Product etc. 

 Account information service: 

Cus2 is an existing HSBC customer but has not registered for current BOV e-banking channel access. Cus2 wants to inquire about his account details using Mint (TPP) for his HSBC accounts. 

-Sample API requests: GET-accounts, balances etc. 

Sample GET-Account API Request:

“id” : “80a64003-3649-44b1-8931-cf665bbf6d36”,
“name” : “v1_accounts”,
“request” : {
“url” : “/v1/accounts?withBalance=false”,
“method” : “GET”,
“headers” : {
“X-Request-ID” : {
“matches” : “.+”

Sample GET-Account API Response:

“response” : {“status” : 200,”body” : “{\”accounts\”:[{\”resourceId\”:\”HGlNA7CqT8sjd_1aV2v2LI\”,\”iban\”:\”DE38760700240320465700\”,\”currency\”:\”EUR\”,\”name\”:\”max.musterman\”,\”displayName\”:\”mock displayname\”,\”product\”:\”Cash24\”,\”cashAccountType\”:\”CASH\”,\”status\”:\”enabled\”,”}}}]}”, “headers” : { “vary” : [ “Origin”, “Access-Control-Request-Method”, “Access-Control-Request-Headers” ],”x-request-id” : “70a7346e-e769-4c4b-8326-ceb6b785e07c”, “content-type” : “application/json”, “date” : “Tue, 07 Jul 2020 08:08:14 GMT”,”x-robots-tag” : “none”,
“set-cookie” : “SRVNAME=17984ba812b2bfa7d54e249e16048ab4; path=/; HttpOnly; Secure”,”cache-control” : “private” }

Sample HTTP Status Codes: 

Status Code       Message  Description 
200  OK  Response to a successful REST API action. The HTTP method can be GET, POST, PUT or DELETE.  
201  Created  The request has been fulfilled, and a resource was created. A URI for the created resource is returned in the Location Header.  
202  Accepted   The request has been accepted for processing, but processing is not yet complete.  
400  Bad Request  The request is malformed, such as a message body format error.  
401  Unauthorized   Wrong or no authentication ID/password provided.  

API Testing: This test ensures an API is working as functionally designed and gracefully handles failures by responding with the desired status codes. 

The API’s are tested with single requests and through collection runners via the Postman tool to validate the consent. 

Integration Testing: Ensures that all the integration touchpoints are validated correctly to uncover any bottlenecks irrespective of the complexity of the application and technologies involved. 

Communication/integration between different components in the system, i.e. PSU > TPP (AIS/PIS) > ASPSP touch points are validated. 

Data Validation: In a banking ecosystem, several types of data can be accessed through an interface. This can include customer or account information, deposit data, loan information, transaction details, and real-time or end-of-day batch process details. Thorough validation should be performed on the input data, including:  

  • Data type validation  
  • Field length validation  
  • Data validation in the response body.  

Performance Testing:  Performance testing helps to determine a system’s and application’s limitations under expected loads. It also helps fine-tune the application to make sure it is stable, scalable, and performs consistently as expected with optimal resource utilization. PT ensures the application runs in optimal conditions by considering factors like response time, scalability, downtime, and infrastructure costs.  

Outcomes of performance testing include: 

  • The response time of each transaction in the application 
  • Network delay between the client request and server response 
  • Limitations due to hardware like CPU maximization, network bottlenecks, memory limitation, etc. 

 Security Testing: 

Authentication and authorization are especially important in banking APIs. Testers should ensure multi-factor authentication is performed before authorizing APIs to perform desired functions.    

Compliance Testing: 

Testing the processes for onboarding TPPs before they are permitted to integrate with the FI’s APIs and Define clear internal standards for creating audit trails and reporting procedures that consider the FI’s activities and that of their TPP partners. 


Cigniti’s Testing approaches outlined above bring many benefits, as we have seen based on our own experiences, i.e. Web Services Validator utility for automated Test Data Generation for SOAP and RESTful Services.  

Cigniti’s utilities and best practices help shrink the test execution cycle. Service virtualization is used to simulate request patterns and data parser for both JSON & XML requests and Open API Accelerators with pre-written test scenarios and checklists. We possess test accelerators and other reusable test artefacts consisting of end-to-end test scenarios and checklists for major open banking APIs functionalities. 

Cigniti’s Solution Alignment with Open Banking Ecosystem validation coverage includes Functionalities, API Security, API Performance and API automation. Our value proportions include Omnichannel coverage cutting across all validation areas in the complex Open API ecosystem and adherence to industry standards and Open API compliance and guidelines. 

Our comprehensive validation solution is based on cutting-edge technology, best practices, and accelerators that add significant value in terms of effort, cost, user experience, increased market reach, and demographics. 

Need help? Contact our Banking and API Testing experts to learn more about the importance of API testing in Open Banking. 


  • Ramji Suman Rentapalli

    Suman has 10+ years of experience in quality assurance with special focus on Digital Banking. Within Cigniti, Suman is part of BFSI CoE team that leads enhancing domain competency and solution developments.

Leave a Reply

Your email address will not be published. Required fields are marked *