API-enabled architecture: 3 approaches to IT modernization for banks

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.