[Case Study] Open Banking: Solving the Financial Data Challenge for Fintech Applications

Problem Statement

A financial technology (fintech) company is building a Personal Financial Management (PFM) mobile application that helps customers analyze spending patterns, visualize cash flow, and receive personalized financial advice. The success of the app depends on its ability to access accurate and up-to-date financial data from customers’ banks.

How can the fintech company securely and efficiently retrieve financial data from multiple banks while maintaining customer trust, regulatory compliance, and scalability?

This is the problem that Open Banking aims to solve.

What is Open Banking?

Open Banking is a regulatory framework that enables consumers to securely authorize third-party providers to access their financial data through standardized APIs. Rather than customers manually sharing account information or credentials, Open Banking allows them to grant explicit consent for specific financial data to be shared with approved third parties.

Traditionally, banks have kept customer profile information and financial transaction data within their closed systems. The European Union first introduced Open Banking regulations in 2015, enabling secure data sharing between financial institutions and fintech companies.

While many countries have since adopted Open Banking frameworks, Canada has not yet fully implemented the Open Banking framework (also known as Consumer-Driven Banking framework). However, the Canadian federal government has continued to advance its Open Banking initiative, making it increasingly likely that Canadian consumers and businesses will benefit from standardized Open Banking capabilities in the near future. For fintech companies, Open Banking creates a secure and scalable mechanism to access customer-authorized financial data while reducing reliance on legacy integration methods.

What is Screen Scraping?

Before Open Banking, fintech companies often relied on a workaround known as screen scraping to retrieve financial data.

Screen scraping is an automated process that mimics human interaction with digital apps, such as online banking app. Customers provide their online banking credentials to a fintech provider, which then uses automated scripts or bots to log into the banking apps, navigate through pages, and extract the required information.

Figure 1. Conceptual architecture of screen scraping

1. Bot is scripted to log into financial institute’s online banking app and scrape the data.

2. The scraped data is stored in a data store managed by fintech.

3. Fintech app will use the data in the data store to fulfill its functions.

While screen scraping enabled fintech innovation before Open Banking became available, it introduces significant concerns in security, performance, and stability.

Security

Screen scraping requires customers to share their online banking credentials with a third party. Once credentials are shared, customers lose visibility and control over how those credentials are stored, protected, and used. Although the intention may be to retrieve only specific financial information, there is limited control over what data may be accessed. Additionally, fintech providers become responsible for securely storing highly sensitive banking credentials. If the provider encounters a security breach, customer credentials may be compromised.

Performance

Screen scraping bots interact with online banking apps exactly as a customer would. To keep financial information current, bots may repeatedly log into banking apps throughout the day to retrieve updated account balances and transaction history. At scale, thousands of automated sessions can generate significant load on the apps. This additional traffic consumes infrastructure resources intended for customers and may negatively impact the performance of online banking services.

Stability

Screen scraping solutions are highly dependent on the design and structure of banking apps. Bots are programmed to locate and extract information based on specific page layouts, HTML structures, field names, and authentication flows. Even minor changes to a bank’s website, such as relocating information, introducing additional security steps, modifying transaction layouts, or implementing new multi-factor authentication mechanisms, can cause scraping scripts to fail. As banking apps evolve, screen scraping solutions require continuous maintenance and adaptation, making them operationally fragile.

How Does Open Banking Solve Screen Scraping?

Open Banking addresses the limitations of screen scraping by replacing it with secure API-based data sharing.

Rather than providing banking credentials to fintech companies, customers authenticate directly with their bank and explicitly authorize which data may be shared. The bank then exposes approved information through secure APIs that can be consumed by authorized third parties.

This approach provides several advantages:

• Customers retain control of their banking credentials.

• Data sharing is governed through explicit customer consent.

• Financial institutions can expose only the information that has been authorized.

• Fintech companies no longer need to manage fragile scraping solutions.

• Banks eliminate the unnecessary load caused by automated bots interacting with online banking apps.

A typical Open Banking interaction follows this sequence:

1. The customer selects their financial institution within the fintech app.

2. The customer is redirected to the bank’s authentication experience.

3. The customer authenticates directly with the bank.

4. The customer grants consent to share specific financial information.

5. The bank issues authorization to the approved third party.

6. The fintech app retrieves authorized financial data through secure APIs.

This model significantly improves security, transparency, and reliability compared to screen scraping.

The Role of Aggregators

Assuming banks expose Open Banking APIs, does the fintech app need to integrate directly with each bank?

While direct integration is possible, it introduces significant complexity and scalability challenges. Every bank may have unique onboarding processes, API implementations, security requirements, operational procedures, and support models.

To simplify integration, many fintech companies rely on aggregators.

Aggregators act as intermediary providers between financial institutions and consumers of financial data. They establish and maintain integrations with numerous banks, allowing fintech companies to integrate once and access data from many institutions through a single platform. Examples of aggregators include Plaid, Flinks and Yodlee.

By abstracting bank-specific integrations, aggregators accelerate development, reduce operational complexity, and simplify ongoing maintenance.

Financial Data Exchange (FDX) Standard

One challenge with Open Banking is ensuring consistency across financial institutions.

Without standardization, every bank could define different API structures, data formats, security models, and consent processes. This would significantly increase integration complexity for fintech providers.

To address this challenge, the industry has adopted the Financial Data Exchange (FDX) standard. The core principles of FDX framework are:

• Control: Users grant, modify and revoke the access to financial data at any time.

• Access: Users share their financial data to fintech apps they choose.

• Transparency: Users can see how their financial data is used.

• Traceability: All data movements are clearly captured.

• Security: Data is shared and transferred securely.

FDX defines the standards on user permission, secure token exchange, financial data structure and more to achieve greater interoperability between banks, aggregators and fintech providers and reduce implementation effort and integration risk.

Proposed Solution Architecture

The objective of this case study is to provision financial data from financial institutions into a fintech app.

The proposed solution architecture leverages an aggregator to abstract integrations with financial institutions while providing a centralized Open Banking capability within the fintech ecosystem.

Figure 2. Conceptual architecture with aggregators

1. Open Banking domain service is the single point of integration to aggregators.

2. Financial institutes implement APIs to expose their financial data to aggregators.

3. Once retrieved, Open Banking domain service securely stores the data.

4. Fintech app utilizes the Open Banking domain service to get the financial data from the internal data store.

There are number of key architecture components to be considered.

Open Banking Domain Service

Create a dedicated Open Banking domain service that centralizes Open Banking business capabilities and aggregator integrations.

This service should:

• Act as the single point of integration for financial data access

• Encapsulate aggregator-specific implementations

• Abstract banking integrations from clients

• Enforce consistent security, auditing, and governance controls

This approach promotes loose coupling and simplifies future changes, including migration between aggregators.

Authentication and Authorization

Establish secure authentication between the fintech app and aggregator services.

For example, Flinks provides client secrets that must be securely managed and protected. They should never be embedded within apps and should instead be stored and managed using secret management solutions.

Authentication and authorization should follow industry standards and best practices.

Consent and Preference Management

Customer consent and preference are foundational principles of Open Banking. Consents and preferences must be well managed to control:

• Which financial institutions are authorized

• Which accounts may be accessed

• What data may be retrieved

• How long consent remains valid

Fintech app should allow customers to update preference or revoke consent at any time.

Data Transmission and Storage

Financial data should be protected both in transit and at rest using strong encryption. In addition, data retention policies should align with regulatory and business requirements.

FDX Compliance

Where applicable, align Open Banking integrations with the FDX standard to promote interoperability, consistency, and future regulatory readiness.

PCI Compliance

If the solution stores or processes payment card information (PCI), including credit card numbers, expiration dates, or security codes, it must adhere to applicable PCI DSS requirements. Appropriate controls should be implemented to securely store, process, and manage payment-related information.

Closing Thoughts

Open Banking represents a significant evolution in how financial data is shared between financial institutions and fintech providers.

By replacing screen scraping with secure API-based integrations, Open Banking improves security, scalability, transparency, and customer control. Combined with industry standards such as FDX and supported by aggregators, organizations can accelerate innovation while reducing integration complexity.

As Canada progresses toward a regulated Consumer-Driven Banking framework, organizations that continue to rely on screen scraping will increasingly need to modernize their integration strategies. Investing in Open Banking’s foundational building blocks, such as FDX API, consent and preference management, and modern authentication and authorization today will better position fintech companies to adapt and improve speed to market as the framework continues to mature.