Opinion: Irina Tsyganok, Lloyds Banking Group

Open Banking Engineering Lead at Lloyds Banking Group spoke with Open Banking Expo Magazine on API’S, Open Banking and all the technical jargon in-between.

 

Open Banking is an unprecedented disruptor in the financial industry, at the core of which lie data sharing and customer-centricity. Both concepts are complex, requiring a multitude of considerations, and both are enabled by technology.

The regulatory requirement to share customer data is rapidly transforming both the language and the mindset of the financial industry. For the first time, a product built by the bank is described in technological terms, such as APIs, response times, data security and integrity, performance. And for the first time, the consumers of the Open Banking are tech-savvy disruptors and start-ups, known as third-party providers (TPPs), as opposed to individuals who hold accounts with the bank.

This shift to a technology-first approach is unprecedented in the financial industry. Technological literacy is becoming essential for all stakeholders, particularly for the non-technical audience.

Data-sharing, the first core objective of Open Banking, is made possible via APIs. API, the main product of Open Banking, stands for Application Programming Interface. This official definition although understood by developers, is no more than a bunch of words to a non-technical audience.

However, understanding the product is fundamental to achieving the second core objective of Open Banking – customer-centricity.

Moreover, APIs and API economy have become central to already disrupted industries, such as robotics, commerce and the Internet of Things. Consequently, understanding what APIs are, how they work and how they are consumed is essential not just for technical development teams, but also for product and business teams, who work to turn these mysterious units of code into sources of real customer and business value.

So, what is the best way to navigate the world of APIs? The first step is to recognise that there are multiple types of APIs. The Open Banking value proposition is comprised predominantly of ‘REST’ (representational state transfer) APIs.

Other technical jargon essential to understand is the language used to describe helper components and data flow through the APIs. These are: API specification, request, response, and database.

A great analogy used to explain REST APIs and the data flow through main components of the system is that of a restaurant. Imagine the waiter as the API, and you are asking for service. This makes you the API consumer. The menu is API documentation, which explains what services the API can provide. The kitchen represents a database, that holds particular type of data. The data is a selection of ingredients, which were bought by the buyer following directions from the chef. These ingredients are selected, prepared and processed before they become a meal on the menu.

The customer has no access to the kitchen, their only way of getting anything is to communicate with the waiter. In the technical world this method of communication is referred to as an API call.

The meal brought to the customer by the waiter represents a response to an API call. The length of the time it took for the meal to reach a customer’s table from the moment of the order being placed is known as the length of response.

The same restaurant analogy can be used to refer to customer-centricity. What would ensure that a customer in our restaurant receives the best possible experience? It can be an array of factors – a variety of ingredients, availability of meals, accuracy of response – i.e. the waiter serves the orders to the right customers; and of course, the speed of response – hungry customers do not like to wait on their orders longer than is absolutely necessary.

In addition to the main function of serving meals or data, it is important to provide a pleasant interior for the customers to enjoy their meals. In Open Banking, this interior is represented by a developer portal. It is important that the portal provides a clean, user-friendly interface via which consumers of our data can easily find what they need and know how to place the order.

Other important considerations in customer-centricity are data security and integrity. Just as you wouldn’t want to serve nuts to customers with severe nut allergies, Open Banking providers must take extra care to serve the right data in response to authorised requests.

Finally, it is important to ensure that the number of orders rejected by consumers is kept to an absolute minimum. Whenever a meal is returned, reasons for the return need to be carefully considered, and improvements made to avoid similar mistakes going forward, both in the context of the kitchen and when serving financial customer data.

Understanding the main data flow through API and Open Banking ecosystems improves teams’ ability to create better customer experiences and helps identify changes that result in highest customer value being created.

Implementing Open Banking is like launching a new restaurant – the providers are facing challenges of ensuring data integrity and security, speed and accuracy of API responses while building a clean and intuitive user interface via which the data is exposed. This ensures a solid and safe foundation for creating great customer experiences.

And while development teams are playing roles of restaurant buyers, chefs and maintenance workers, product and business teams have a more impactful role to play in creating user value. To do this successfully, all teams need to share a thorough understanding of the main value proposition of the business and communicate in a language that is understood by everyone.

The disruption brought by Open Banking brings down the divide between technical and business teams. In the new world, API is the product, the customer is king, and technology is the common language for all.