Open Banking-Data Sharing Framework For New Age Banks
Problem. Currently, banking end users utilize financial services offered by third-party aggregators by sharing their financial data through a process known as data scraping. This method raises security concerns for banks, poses risks, and, significantly, can lead consumers to violate electronic access agreements.
Solution. Open banking enables end users to securely share their financial data with accredited financial partners and third-party aggregators, all while adhering to their own consent terms. This concept of open banking is characterized by consumer-led decision-making, where end users have the authority to determine and grant consent on how they wish to utilize their financial data in order to access financial services.
Key Metrics.
Consent Conversion Rate: Measuring the percentage of end users who initiate the consent process and successfully completed it, indicating a high level of engagement and trust in the system.
Here is a simple explanation with an example.
In the data sharing framework, users participate in sharing their data through a user dashboard integrated into their digital banking experience. Within the user interface design, we offer a "I consent" button, which users click to submit their consent agreement. Before finalizing their submission, users have the option to choose the specific bank account from which they wish to share transaction data and must also confirm their agreement with the terms and conditions of the consent agreement. For example:
If the total number of people who agreed to provide consent is 20.
and the total number of people who visited the dashboard is 100.
To calculate the Consent Conversion Rate, we used the simple formula of
Consent Conversion Rate = (Number of People Who Agreed to Submit Consent / Total Number of Visitors) x 100
In our example:
Consent Conversion Rate = (20 / 100) x 100 = 20%. This means that out of every 100 visitors to our website, 20% of them agree to provide the consent agreement. This metric helps to understand how effective the requests for consent are and in our case use this metric to improve our strategies for getting users to agree to various actions or requests.
API Reliability: In the realm of services, particularly within the domain of banking digital services, crafting an effective user experience stands as a paramount factor for achieving success. Open banking relies on API-based system communication to swiftly and consistently deliver data to those in need. Consequently, the imperative of monitoring API performance becomes pivotal in this context. API reliability revolves around assessing the availability and dependability of API services, guaranteeing their accessibility precisely when users require them. This entails continuous monitoring to promptly detect and address any unforeseen downtime or interruptions.
(Additional metrics used was , performance Metrics- to measure API response times, latency, and throughput to ensure that data retrieval is efficient and meets user expectations.)
Data Sharing Volume: During the MVP1 phase of open banking, the primary objective was to establish read-only API services for the purpose of transferring data tokens from data providers to data receivers. A critical requirement during this phase was to ensure the uninterrupted availability of these RESTful API services through the API gateway, 24/7.
The Data Out API Calls process involved data receivers (DR) requesting information from data providers (DP). After validating the request, the necessary data tokens containing the required information were retrieved from DP's backend sources and subsequently returned to DR. Therefore, an essential metric for evaluation was the analysis of the volume of API calls for data out, categorized based on specific API services such as accounts, transactions, and payments. This parameter was instrumental in measuring and assessing the system's performance and usage patterns.
Cost Efficiency: The intent to evaluate the cost-effectiveness of operating the Open Banking platform, taking into account infrastructure expenditures, maintenance costs, and the generated value. Among all the metrics tracked, one of the most pivotal for the business was the constant measurement of cost efficiency throughout the entire process of developing the Open Banking framework. This included approximately three design strategy adjustments, vendor changes, modifications in use cases, and evaluations of in-house versus blue label solutions—all aimed at reducing the overall expenses associated with the platform's development.
Results.
1.Proof-Of-Concept/MVP1 Development:
-Developed a Proof-Of-Concept/MVP solution design for the client registration process of data providers and data receivers via a trust authority.
- Implemented a consent lifecycle model which included consent grant, consent management (dashboard and admin portal) and consent expiry.
- Enabled secure data sharing through API microservices, following FDX-Financial graded API standards.
- Implemented OpenID Connect/OAuth 2.0 based Authentication for user security.
- Established user authorization protocols.
- Implemented robust logging and monitoring mechanisms through integrating with existing backend systems.
2.Scalable API-Based Service Architecture:
-Designed a reliable and scalable API-based service architecture.
-Focused on real-time data sharing (read-only) for use cases involving accounts, transactions, and payments.
3. Data Elements Mapping and Assessment:
-Conducted a comprehensive evaluation and data comparison between FDX data elements and those within the Bank's Book of Record(core banking systems for deposits, credit cards, lending and investments).
-Assessed asynchronous data flow pattern and mapped data elements from the backend Book of Record to the frontend retail online banking UIs. Emulated and applied the similar data flow design patterns for open banking ecosystem, evaluated the volume of API service calls for open banking forecasting thus to calculate the performance and scalability of API services. This was accomplished within a challenging 4-week timeframe, primarily due to the intricacies of the banking backend system
-Presented a detailed report to the Open Banking Executive Committee. Focus was to present the current state capabilities to support the open banking pilot program.
4. Top-Level Design Strategy:
-Developed a high-level design strategy to ensure the successful delivery of MVP1.
-Addressed both business-functional and non-functional requirements.
- Accomplished these objectives within the defined timeline constraints.
Lessons learned.
When you embark on projects like this one, characterized by heavy regulation and in the early stages of concept testing, one significant challenge is the inherent uncertainty and associated risks. When confronted with new regulatory frameworks that necessitate changes to the core infrastructure for building a reliable and sustainable model, our approach prioritizes open communication with executives throughout the entire journey.
In the corporate world, the chance to simultaneously learn and apply newfound knowledge is a rare gift. The open banking regulatory framework is a novel concept in Canada, and as a government-sponsored initiative, our project is in its early stages with many moving parts. An undeniable opportunity lay in studying the successful Open Banking blueprint from the UK, which had already implemented this system. However, the real challenge and opportunity of the 'Make in Canada' program was our ability to enhance and learn from past mistakes, then apply those lessons to construct a dependable and scalable system. That was precisely our mission.
Instead of entrusting project responsibilities solely to a isolated group of technical experts, we consciously opt for a collaborative approach. This involves presenting and sharing challenges, technical decisions, and design considerations while transparently elucidating the impact, risks, cost-benefits, and time constraints associated with each design decision. This strategy has proven to be instrumental in our project's success.
Sample dashboard displaying API performance. Source is Opne banking/UK public dashboard build to show the performance metrics.One of the UK government mandate was to be transparent about these metrics and hence the reasoning behind building a public interface.
Sample template of how the consent process look like. The Image source is from google.