The introduction of open banking regulations in September 2019 across Europe—through the Second Payments Services Directive known as PSD2—requires that banks enable third party providers to integrate customer account information and payment capabilities, where the customer has consent to do so.
When PSD2 was first introduced, it mandated that banks use an API standard when providing APIs. This meant all major banks created APIs consistently, which made it easier for fintech to integrate APIs into products. In Europe, regulatory technical standards set out guidelines to help banks create their integration patterns. In theory, this meant that banks could choose the technical format to enable the integration. In practice, banks created APIs to meet the required guidelines, with many creating slightly different APIs. This means that fintech needs to integrate individually with each bank to make the app integrations work.
PSD2 was a global turning point in banking and financial systems. There are now 108 countries that have either introduced open banking regulations or are in the process of doing so.
Banks that acted early to implement APIs have seen major advantages. They are able to:
- Manage the customer impacts of COVID-19 via digital engagement, since the digital infrastructure is already in place.
- Widen the products provided by integrating third parties to provide non-competitive products, such as carbon calculators and subscription management services.
- Reach new customer segments via a digital bank offering.
- Manage emerging regulatory requirements, including the General Data Protection Regulation (GDPR) and data privacy legislation, AI and ethics guidelines, and environmental, social governance requirements.
Three approaches to IT modernization
Banks have taken a variety of approaches to update their IT stacks to meet digital requirements. Modernizing often involves building cloud and API capabilities on top of legacy infrastructure in a move towards microservices. Composable approaches allow new features and products to be built while integrating best-in-class external solutions for performance functionalities—like adding observability to the IT stack.
Which approach to use depends on the bank’s willingness to move towards a platform strategy: banks that just want to meet the PSD2 requirements can get away with doing the minimum, but they also risk future-proofing their business. They risk reducing customer engagement as demand for digital interactions increases.
Banks with legacy stacks that want to support API-enabled infrastructures have adopted architectural transformation strategies, including refactoring an application, buying a middleware solution, or ‘lift and shift.’
The UK’s Tandem Bank used a lift and shift strategy to migrate its banking customer data to the cloud. With AWS as a cloud vendor and New Relic for observability, Tandem sped up innovation with emerging technologies to offer new features and product opportunities to customers. Tandem now has full visibility into both its architecture and customer engagements: with a 47% performance increase in the architecture, alongside detailed customer insights on credit card application outcomes.
In the Czech Republic, MONETA used a lift and shift strategy to rapidly introduce new products—something that wasn’t possible with on-premises infrastructure. MONETA took a three-step approach:
- Assess and document all migration risks, including understanding the regulatory responsibilities of moving to cloud-based infrastructure.
- Catalog all current applications to prepare an inventory of location and computing capacity requirements.
- Start the migration in batches by moving applications in groups of 20 at a time, focusing on critical workloads first.
Refactor an application
Thailand’s Bangkok Bank refactored legacy code to keep up with its digital customers. The internet banking architecture had served it well but it hadn’t moved the needle on customer acquisition or engagement. In-house monitoring and observability tools couldn’t provide the performance insights to jump from 1 million users with internet banking to 3 million users with mobile. In a move away from in-house solutions outside of core business areas, the bank’s mobile banking infrastructure, built on top of the existing web application, dramatically increased the number of users and volume of transactions. By refactoring the codebase, Bangkok Bank built out its APIs and integrated external services, like New Relic.
Buy a middleware solution
Part of France’s Société Générale Group, Komerční banka replaced its core banking system with Temenos’ Transact software. Temenos, a Swiss banking middleware provider, offers a digital banking SaaS-managed platform with a regulation-compliant core banking system. For Komerční banka, this core system provided the ability to onboard customers, make deposits with front-end integration, and implement other payment solutions via REST APIs.
What to monitor in a modernized legacy stack
Architects and developer teams within banks often need to demonstrate the business case for modernizing the IT stack and introducing API architecture. Banking-as-a-Service (BaaS) APIs allow banks to monetize core banking services available to fintech and enterprises that want to offer credit cards, digital wallets, and other services. Banks that haven’t leveraged PSD2 to transform their legacy stacks are missing out on preparing for this API-enabled market, estimated to be worth over $25 billion in annual revenue globally by 2026.
Observability demonstrates the business case opportunity by showing how key metrics improved. When establishing any monitoring or observability strategy, before the modernization project begins, create a baseline. Report on metrics against this baseline to demonstrate the customer experience, savings, and velocity improvements introduced. Start with what you want to know:
- What is the customer attrition rate?
- How often do customers transact through bank services, online or mobile?
- How much is spent on new feature creation?
- How long does it take to introduce a new feature?
- How many developers need to work together?
Key to monitoring API-enabled architecture
- API adoption rates: Identify how fast your ecosystem is growing. This can be measured by the number of new applications requesting to integrate with bank APIs or the number of API calls being made over time.
- API usage: Get an idea of what use cases are powered by the APIs to suggest new business opportunities and features. In Europe, banks must provide PSD2-compliant APIs, but providing APIs alone doesn’t mean that they will be used. By looking at the use cases where third parties are building new products or features by integrating your bank’s APIs, you can make a stronger business case for taking a platform approach and opening more APIs that help build your ecosystem. Looking at use cases can also help identify how your APIs are being used to create financially inclusive products and services for the unbanked and underbanked.
- Change requests: Measure how often changes are requested to the service.
- Time to change: How long does it take for requested changes to be made? A well-architected microservice API should make change frequency and change time lower.
- Engagement experience: Measured by Apdex, Web, and non-web transactions. E.g. by the time being spent by users.
- Uptime: Availability of APIs in the tech stack, measured as the percentage of time that APIs are available, usually calculated as a percentage of the year, and usually described in Service Level Agreements such as guarantees for 99.99% uptime—which would allow APIs to be down for a total of 52.66 minutes in a year. Under PSD2, banks must also regularly report incidents that may impact availability. Many banks report quarterly availability statistics on their developer portals.
- Speed: Latency of returning API calls, usually measured as average and maximum latency, as it will impact user experience. Aggregate results can also hide geographic differences and application differences.
- Reliability: Error rate of APIs, monitoring the most and least amount of failures of API calls based on the error status returned helps identify whether the error rates are from poorly documented APIs, malicious activity, or poorly designed APIs.
[“source=newrelic”]
