Screen scraping: a balancing act for banks

APIs vs. screen scraping

With the introduction of PSD2, it has become possible for non-banks to initiate payments and retrieve transaction data, after a customer’s consent. This enables TTPs to develop innovative services such as money management apps. Banks were steered to develop APIs to give TPPs with a PSD2 license controlled and safe access to their customers’ bank accounts. However, due to various reasons (e.g., migration costs, lack of internal expertise and the unrestricted amount of data that can be collected), the practice of screen scraping is still continuing.

Screen scraping is a technology by which a customer provides its banking app login credentials to a TPP. The TPP then sends a software robot to the bank’s app or website to log-in on behalf of the customer and retrieve data and/or initiative a payment. Banks have less control over the data retrieved, which may go beyond account data regulated under PSD2 and may include any customer data available. While with an API, banks have greater control to share only the necessary data for the TTP’s service and customers do not need to share any credentials with TPPs.

Banks must pick their battles

On the one hand, banks benefit from enabling TPP’s to access their customers’ data and providing innovative services. Some banks may also practice screen scraping themselves. On the other hand, banks may want to be in greater control of knowing who is logging in to their bank accounts and don’t want to share more data with TPPs than needed. Data is the new oil and banks might not want to give it away too easily. Next to that, even though customers must give their consent to TPP’s, they might not always be aware of what they consent to. If personal data is shared unintentionally, this could hamper customers’ trust in banks.

As long as screen scraping remains common practice, banks should define a strategy to get control over it. We identified three types of strategies:

• A passive strategy tackles the problem by appealing to scrapers and customers: state on your website discontent with being scraped and inform consumers which TPPs rely on scraping and its potential security concerns.
• A proactive strategy impedes screen scraping and makes it more expensive. The methods differ in their complexity, effectiveness and negative impact on the website’s User Experience. Two examples are utilizing CAPTCHAs or deploying “honeytraps”.
• An external software strategy, where banks can utilize external software to detect screen scraping bots. According to a Capgemini study, the top-3 external anti-bot services score above average on major criteria, where only one has experience in banking.

What’s next? A cat-and-mouse game.

Each screen scraping prevention strategy comes with its own benefits and concerns. But before banks start thinking about which one to implement, they should first and foremost earn the right to do so, by having a PSD2 API that is on-par with market standards and meets local requirements. The next step is to assess current measures taken to prevent screen scraping. From there, it is needed to assess the channels and data sources where it is desirable to start preventing screen scraping, as well as identifying certain parties that might be prevented for using the approach. Once a strategy is chosen and implemented, the cat-and-mouse game starts. TPPs may look to overcome measures taken by banks to block screen scraping – hence it is necessary to build an organizational capability with the ability to respond to counter measures initiated by TPPs. Combining this technical capability with legal and regulatory affairs will be vital.

Find out more

• Read the blog ‘Everyone is Banking’ and ‘ here.
• Watch the video series ‘Banking Insights’ here.

Do you want to continue this conversation to learn more on the latest developments in Open Banking and how banks can respond to stay relevant? Get in contact with our experts here.