Financial firms prepare to be tested by an Open Banking software future
By Jason English
May 7, 2019
5 min read
Banker’s hours? That cliche will soon be retired. We now demand nothing less than 24/7 direct application-layer access to banking services that put customer experience at the front of the line, every time. What is Open Banking, why does it matter, and how do we test it?
The global financial industry is hurtling toward a future state of Open Banking. The banks that succeed here will revolutionize their own service interface, exposing API-level controls so third-party apps and new fintech services can look up accounts, move funds, and confirm transactions without even visiting the bank’s branch, website, or mobile app.
But are banks, and the new startups leaning on them to support their businesses, ready to be tested by this Open Banking transformation?
What is Open Banking and why does it matter?
Open Banking is the shift to the use of open APIs in the financial industry, that open the door to new development and innovation to benefit both business and the consumer.
A customer-centric transformation to Open Banking APIs
Customer-centric transformation happens in every industry, so banks should embrace this overdue change as an opportunity to step up with even better services, and showcase the speed, reliability, and funding options that make them special.
Open Banking has already taken hold in Asia and Africa, where customers leapfrogged much of the middle tier of online banking and jumped straight to common adoption of mobile micro-credit and payment apps like WePay. If banks underserve a market, who can blame customers for finding a better way?
A regulatory mandate for openness
Governments are also pushing for Open Banking, on behalf of their citizens. After new PSD2 regulations went into effect in 2018 in Europe, several large US institutions such as Citi, Wells Fargo, and Visa followed suit and are getting in on the act.
It would be easy to interpret such initiatives as a competitive challenge to the hegemony of the world’s largest banks. Open Banking provides the ability for new startups to disintermediate the customer experience, and offer slicker new commercial apps and fintech for mobile payments, micro-loans, credit, investment, insurance, and more.
Like Europe’s GDPR privacy mandate, this initiative will likely be a leading indicator for financial industry guidelines and regulations that the United States adopts. Citizens want more openness among banks to put more choices and better services in the hands of banking customers with greater ease.
The API-based bank opportunity
Banks have traditionally been among the largest buyers of software and technology services, and at the same time, among the slowest to change. If anything, the Open Banking movement has brought a resurgence to API-based integration activity, as the services we once expected of banks will start to live in a set of APIs.
In essence, the bank’s API becomes the product.
But before a bank can open itself up to developers at a Mint, Venmo, or Square — or any future fintech startup, their API access needs to be proven to function properly under stress before it becomes part of the customer experience.
Testing APIs is critical here, so banks should eliminate any hurdles to agile testing, including complex processes such as providing a ‘wall of code specs’ for developers and testers to decipher, and an indistinct method of customer authentication using tools like OAuth, and a constellation of other user verification methods.
Well-designed and documented APIs must be offered in a transparent way that works faithfully for validation purposes, but masks private (PII) information so unauthorized service providers and developers never need access to private data.
How to conquer the complexities of Open Banking APIs
APIs are mature technology, but they are still far from standardized. There are vendor tools for API management and integration, open source API specifications like Swagger or Scala, and API libraries that are specific to underlying business systems.
What happens if a development team changes some aspect of an API and breaks all of the services that depend on it? It’s apparent we can’t take success for granted over time, and that is of course a critical business concern.
Managing open source in Open Banking
Open Banking by nature leverages open source code and components, offering both quality positives and negatives.
- Pros: On the positive side, open source puts cool capabilities, like containers, and continuous integration tools, like Jenkins, in the hands of developers to accelerate builds and delivery. The best open source is battle-tested by a global community, often more rigorously than commercial software over time.
- Cons: On the negative side, open source can bring along an incredible amount of borrowed code and different versions of downloaded components, coming from repositories that are not always updated to patch new vulnerabilities. This isn’t a science experiment, it is a business-class problem, so who can banks call on if things aren’t working right?
To address this challenge, banks will need to raise awareness that API testing isn’t only a pre-delivery event, it is a continuous customer journey validation process, requiring enterprise-class testing and simulation.
Managing the business risk of evolving APIs
As you advance from single API unit testing with open source tools like Postman, you will realize the need for testing interactions of multiple APIs and applications across multi-system workflows. To evolve your testing into sophisticated scenario-based testing, you can use a tool like Parasoft SOAtest, which can headlessly exercise a workflow that crosses multiple service APIs, with or without a client UI for testing.
Enabling the testing of data and services
The last step to ensuring success in a 24/7 Open Banking world, is making API services and data available for testing around the clock, without constraints by all partners. Sounds impossible, right? Obviously, we don’t want to burden our live banking services with routine dev/test abuse, so what can we do here?
We’ve often seen the idea of regulatory sandboxes used in the context of private enterprises working with governmental bodies to design and legally test out a given business use case within the context of emerging laws.
For Open Banking, this sandbox means setting up a virtual environment for developers to work within as they prototype and test their services against the bank’s APIs and stateful datasets, without impacting the real environment where ongoing customer transactions are conducted.
The APIs, services, and data can be modeled from definitions, or captured and played back from live services and data, much like a DVR records television programs, into a virtual service using a service virtualization solution like Parasoft Virtualize in conjunction with test data tools.
In this case, a virtual environment is better than the real one for development and testing, as virtualized data can even be simulated to respond statefully as if a customer’s session is maintained, as well as populated with exceptions to represent edge conditions, spikes, or failures that would be nearly impossible to reproduce and test against the real world systems.
The Intellyx Take
Open the vault. Let the world have a look inside, but do it safely.
In modern testing terms, that means we are exercising bank software without a screen, headlessly at the API layer. We are leveraging both proprietary and open source software, with the safety of enterprise-class testing. We are simulating services and underlying test data to prevent private data from leaking into the wrong hands.
The financial sector is ripe for a new round of technology disruption that puts customers first, ultimately giving them choice and control over how they interact with banks. In the approaching new normal of an Open Banking world, the API is the product. Firms that take ownership of a quality API development and test experience for service partners will be ideally positioned to realize competitive success.