Screen Scraping vs. API — 10 Questions to understand the differences

1. Why would companies want to access my bank data? 🤔

Most of us have the utmost trust in traditional banks to be the safe custodians of our money & personal data. However, the banks’ digital approach is still reactive, transaction-based and needs to move towards a more valuable, proactive and personalised approach across multiple channels, products and services.

Therefore, we often turn to new service providers, sometimes on our smartphone, who access our bank data and leverage tech + data capabilities to provide real-time services in better, cheaper & simpler way, for example:

  • Payment Services — one-click shop, split bills with friends;
  • Money Management — spending tracker, savings plan, automated invoicing;
  • Loan advice — calculate real-time affordability for instant loans & mortgage decisions etc.

2. I wonder how these providers access my bank data? 🏦

You give permission to access your data on your service provider’s application (app or website). They let you select your bank and after a few steps, they start accessing your data using one of the two popular methods: Screen Scraping or the bank’s dedicated interfaces (i.e. APIs).

3. What are Screen Scraping & API? English, please.

Screen Scraping is a data-access method that logs into your bank using your personal banking username and password as if they were you!

An Application Programming Interface (API) is your bank’s own dedicated interface that allows you to share data without sharing your bank credentials and most importantly allow you to control what data is shared and for how long. You remain in control.

4. How do I know if I’m giving permission to a Screen Scraper or an API-enabled provider? 🔐

By understanding how you are asked for bank data permission.

To enable data access via Screen Scraping, service providers will direct you to a screen that looks like your bank’s one ⚠️ (but the domain is clearly not) and asks you to share your bank login details.

To enable data access via the bank’s dedicated API, services need your “informed consent”. You are informed about the level of data requested before you are transferred to your bank website to log in and provide permission. This time you are actually on your bank’s real website! The giveaway is, you are NOT asked to share your bank credentials with anyone ✅ — Winning! 🏆

5. How much control do I have over these access methods? 🔍

With Screen Scraping, you don’t have much oversight, control or transparency

Services have unlimited access to your bank account. They will be able to access it as often as they want, read whatever they want and share with whomever they want (using your login details). You will have no direct method to view or cancel permission via your online banking or their app.

With APIs, you have greater oversight, control and transparency

Your bank ensures service providers can access only the information you decide and only for the time period you decide. You will be able to discontinue or cancel permission via the bank app or website. You and your bank can control the identities of services that access your data.

6. I’m worried, what about data security? 👤 🔑

With Screen Scraping, you are very right to be worried because you are handing away personal banking credentials for unlimited access to your accounts. In case of a breach, hackers get access to your bank credentials, as a result, your entire bank account! If you are concerned, the only thing you can do is change your password!

With APIs, when you give consent service providers receive an access token. In case of a breach, you or your bank or your provider can revoke access and the token is invalidated. Easy! 😎

Also, it is about common sense. Screen Scraping needs your username and passwords. Isn’t the first rule of data security — “don’t share any passwords with anyone…especially bank passwords”?

7. I’m convinced which is better for me 🎯 What about service providers?

When service providers use Screen Scraping they are often using unreliable and insecure techniques, because:

  • Screen scraping runs on image processing, data is not accurate
  • Data access cannot be done frequently, most of the time it is an overnight process
  • Storing consumer credentials can be risky, especially when unencrypted

When service providers use dedicated bank APIs, it guarantees reliability and speed:

  • Data is received almost real-time
  • Data is accurately sent via direct bank channels in digital format
  • No user credentials are stored

However, there is a high dependency on the banks’ API reliability… and we are getting there!

8. What about the regulatory oversight over these two methods? 🛡️

Screen Scraping is not regulated, anyone can launch a Screen Scraping app so you are not sure who are you dealing with.

Accessing banking information or initiating payment via API are regulated activities so someone will always check the service party is a legitimate company.

9. What’s triggering this debate now? 🔦

Concerns around data privacy — especially sensitive data. The European Commission mandates the banks to create dedicated interfaces (APIs) and prohibits the use of the Screen Scraping technique from September 2019. This is seconded by FCA — the UK regulator who thinks data sharing must happen over dedicated bank APIs and therefore, should not require Screen Scraping by service providers.

Also, the General Data Protection Regulation (GDPR) states that sensitive data should be managed in a certain way but once a consumer gives away bank credentials, the screen scraper has unlimited access to all banking data, sensitive and not! What does the ICO think about it?

10. What is the key takeaway from this debate? 🎭

Who does data belong to — banks, fin-techs, regulators? Nope, it rightly belongs to the users and they should decide who to share it with, easily and securely without having to hand over their online banking credentials to anyone.

The end goal should be empowering innovation in a secure way to make financial services better and cheaper for everyone.