Brankas has helped banks across Southeast Asia launch new digital solutions for their customers, with a focus on Open Banking technologies. Across the region, banks are creating and launching Open Banking products, including APIs for direct payments, account data, and even account opening and loan origination. Even without a regulatory requirement, banks see commercial value in Open Banking: a new way to attract, retain, and monetize customers, and a fast, secure way to partner with startups.
Not all banks are starting from the same place in their Open Banking journey: a large Indonesian bank will have a separate IT architecture and unique challenges compared to a new digital-only bank. The Brankas team has created a basic Open Banking Readiness Framework to describe the various technology and process changes that banks adopt as they implement Open Banking. We hope that with this standardization framework, bank leaders will be better equipped to make Open Banking a success at their respective institutions.
The Open Banking Readiness Framework
Open Banking Readiness is defined on a spectrum from Level 1 (traditional infrastructure) to Level 5 (Open Banking enabled). The following is Brankas’ collective view and definition of Open Banking Readiness Framework, as a way to map out the Open Banking Journey and help bank executives understand more concretely where they stand on their journey.
We first define “Readiness” in this article from a technology perspective; as architecting, developing and deploying an Open Banking technology stack is first and foremost a software system design exercise. In later editions, we will focus more on the non-technical aspects of the Open Banking journey, such as UX design, end-user experience and more.
|
Level 1 |
Level 2 |
Level 3 |
Level 4 |
Level 5 |
| API Architecture |
Monolith architecture, No API gateway, Limited internal APIs |
Internal API Gateway in use. External gateway deployed. Some APIs registered. |
All API services routed through Internal/External API gateways. |
Gateways are also load balancers directing traffic to horizontally-scaled deployments. |
Internal and external API gateways. Clustered deployments with Orchestration layer |
| API Services |
Point-to-point integrations with external partners |
Basic metadata APIs, e.g. FX, interest rates |
Limited API services, transaction-oriented API definitions |
Main API services available, aligned with PSD2 and international standards |
Advanced product APIs e.g., Account opening, eKYC; API lifecycle mgmt. |
| Developer Experience |
Direct contacts and requests only, no public documentation, advertisement or contact form |
Limited developer portal; no self onboarding |
Published API docs, advertisement of availability, contact us form. Manual approval for testing access |
Self serve developer portal and testing environment |
Sandbox and live environments with dummy data and accounts; Use cases by activity, industry, user type; Notification framework |
| Metrics and Monitoring |
n/a |
Logs maintained, not searchable or accessible. |
Metrics not yet in place, rely on customer service to spot bugs (no real-time monitoring) Logging for retention purposes, minimally accessible. |
Limited use of API gateway monitoring features with short/med retention. Searchable interface for recent historical logs. |
Real-time monitoring and alerting with always-available log filtering/reporting. Retention via downsampling and/or archiving |
We define the stages in terms of the four rows / categories in this table. They are laid out as follows:
- API Architecture pertains to the overall strategy for designing, implementing, deploying and managing API components
- API Services pertains to the types of transactions or use cases that can be enabled through the APIs
- Developer Experience refers to the onboarding journey of API users, the access points and the ease of integration with an organization’s Open Banking APIs
- Metrics and Monitoring refers to the available methods for monitoring API traffic and evaluating the success of a particular API service using different parameters, such as number API requests per day, average response times, error rate, etc
Level One
The Open Banking journey typically starts with a “traditional” banking architecture, characterized by monolithic or siloed legacy systems. In this stage, APIs are limited and are mostly for internal use. Data sharing with external partners is performed through point-to-point, or one-to-one integrations, while onboarding is done through direct partnerships with the bank. This can be difficult and costly to manage over the long run, as the number of partners and requests increase.
Moreover, a monolithic architecture makes scaling challenging (modifying one element affects the performance of the entire application; and legacy systems often do not have built-in API capabilities), and inefficient in terms of time and cost. Automated metrics and monitoring are difficult at this point; third party API partners may choose to track performance manually.
Level Two
At this stage, a bank begins to make use of API Gateways, for both internal and external applications. The API Gateway serves as the single point of connection between API users and the bank’s backend business layers, facilitating all requests between them. With the API Gateways in place, banks are able to define security protocols and determine who gets to access what services through an authentication module. This may also signify that the bank is beginning to revamp their internal infrastructure in such a way that it takes speed, efficiency and security into account, in what may be the early stages of transitioning to a microservices architecture.
External “read only” APIs may be available for basic metadata retrieval such as foreign exchange, interest rates, and branch locations. The bank may have a developer portal, but developer onboarding is likely a manual process. The typical onboarding process involves meeting with the Bank’s API team and signing a partnership agreement, requesting for documentation, manual testing and integration, and an approval process to go-live. Monitoring logs are maintained, but mainly for archival / retention purposes and not yet searchable or accessible.
Level Three
By this stage, all API services are routed through internal and external gateways. Available API services are data-centric and based on common activities, and do not cover every use case yet. API definitions are transaction-oriented as opposed to user-oriented. API documentations are published, advertised, and can be viewed by the public. However, users still need to go through a manual approval process before they can gain access to testing the APIs. Logging is in place, mainly for archival / retention purposes, and is minimally accessible.
Metrics are not yet available, however, users are able to report bugs through customer service.
Level Four
Banks at earlier stages of the Open Banking journey focus on getting basic external API services available: client facing APIs, API management, and developer portal. At Level 4, the bank’s backend API architecture has been restructured for scalability. Load balancing is implemented, directing traffic to make processing requests more efficient. API services are available for most typical use cases, but more advanced API services like account opening are not available yet.
At this stage, API definitions should be aligned with international standards (e.g., ISO 20022, BIAN, PSD2). The developer portal is now fully self-service with a comprehensive testing environment. Additional security protocols are implemented, such as oAuth2 Authentication and a non-SMS 2FA.
API monitoring uses a limited set of API gateway features with short to medium retention, and logs are accessible through a searchable interface for up to 24 hours. API metrics tracking still relies on Quality Assurance and Customer Service teams to spot bugs, as no real-time alerting / early warnings are available yet.
Level Five
At this stage, the bank has achieved an “optimal” Open Banking architecture; their Open Banking platform is ready and equipped for the needs of a third party user. All the required services are orchestrated in a meaningful and timely manner through an API orchestration layer.
The bank is running an automated pipeline with complete API lifecycle management, clustered deployments in a domain-driven design, and vertical teams. API products now include “advanced” use cases such as Account Opening, and eKYC. Third party applications are now an additional onboarding channel, as customers are able to perform account opening and eKYC completely within the third party application. The bank has a fully self-serve developer portal, which includes:
- API Documentation and References that are dynamically updated
- Sandbox and live environments with dummy data and accounts that end users can use for testing
- Use cases sorted by activity, industry, and user type
- Admin panel with real-time monitoring logs, metrics and alerting for business intelligence and data management
- Notification system
In addition to the developer portal, banks have a native mobile application to support PISPs (Payment Initiation Service Providers), AISPs (Account Information Service Providers) and international payments. In terms of security, oAuth2 Authentication and non-SMS 2FA are implemented.
Connect with Brankas Today
Brankas is bringing Open Banking to Southeast Asia. Our vision is to make modern financial services available to everyone. We have carefully designed an extensive and efficient program that will help financial institutions elevate their Open Banking Technology Readiness.
Reach out to our team of Open Banking experts who can help you determine the right path to take.
Back
