---

As I mentioned in my last post, the journey to Open Banking has been long and full of challenges for most banks in Europe.

One of the main reasons it took so long to define the Regulatory Technical Standards (RTS) is the challenge around technology and the development of the necessary application programming interfaces (APIs) required for the data exchange between service providers.

Here are some of the lessons we learnt as we helped banks navigate their challenges in the technology space:

Legacy integration (batch vs. real time)

Open Banking needs real-time access to and publishing of data hosted in core systems of records (e.g. core banking and payments). Therefore, it is important to understand the legacy systems integration landscape and associated dependencies. Most legacy banking systems were designed around batch processes, whereas Open Banking demands a much more resilient system with 24/7 data availability. Banks might have to consider a decoupled architecture to address real-time data access needs and to reduce risk.

Right-sizing the infrastructure

Understanding the use cases and the associated data volumes is important for the right-sizing of the technology infrastructure. Infrastructure capacity sizing is dependent on anticipated network traffic and consumer uptake. Banks should not model their future API volumes and procure infrastructure assuming full customer uptake. Instead estimate no more than 10 percent uptake by existing customers in the first year of operations.

API management tools

Successful API management incorporates key factors such as API discoverability and publishing, API access control, API ownership and ease of integration with core systems. Building well-defined and discoverable APIs with a robust management lifecycle and clear ownership is important to promoting a culture of reuse. Choosing a modern and automated API management platform with complementary technology stack (microservices, containers, identity management, data stores, DevOps, etc.) will help ensure strategic alignment across various stakeholders and build efficiency.

Developer-first technology

The developer is the new customer and developer portals are the new channel. A developer-first mindset is very important, so banks need to focus on best-in-class capabilities to draw quality developers. Providing technology for self-service onboarding, top-notch API documentation, an easy-to-use registration process, community management, a test sandbox and first-class support are some of the key features desired by developers. Continue to gather developer community feedback and improve the developer portal.

Balancing security concerns

The strong customer authentication (SCA) requirement for Open Banking also creates a double-edged sword with regard to security. While it could increase the security for customer data, many of the implemented solutions may negatively impact the customer journey and discourage adoption. Banks and other service providers need to implement digital SCA solutions to help reduce friction and encourage customer adoption.

Managing new data

Open Banking allows organizations to access and consume new data sources and promote new data-driven interactions across the ecosystem. Banks aspiring to be data recipients will need to consider suitable strategies for external data ingestion and data management which are compliant with local data-privacy laws. This will involve setting up data stores, building data identification and categorization algorithms, setting up machine-learning capabilities, providing data-audit mechanisms, and integrating this data into digital customer propositions.

Ultimately, Open Banking will evolve beyond compliance, so banks need to be flexible and innovative when it comes to their digital transformation.

In my next post, I will delve into the key considerations and lessons learnt about the right governance and operating models for Open Banking.