PSD2 was born with the goal of democratizing the financial services industry in regards to clients’ data. That is, to break up the banks’ hegemony, foster competition, and make it easier for new organizations such as TPPs to enter the market and develop new value propositions that better met users’ needs – many of which were not being served by legacy banks.
This was made possible by APIs and Open Banking technologies, the specifications of which are laid out in PSD2. Under the directive, banks are mandated to provide dedicated interfaces to allow licensed Account Information Service Providers (AISPs) to connect to their databases and retrieve information on their customers if they receive permission from them.
What can be accomplished with this open data? One of the most popular use cases today are PFM, applications that allow you to manage your personal finances better, monitor your bank accounts through a single platform, save money automatically, and plan your finances based on highly personalized analysis.
For sectors like consumer finance, PSD2 has made it easier to access financial data of customers, so institutions can perform more in-depth analysis of loan requests and make better decisions.
Technical compliance vs the “spirit” of PSD2
All of these opportunities sound very exciting, but the reality is that the directive has many gray areas. The most important of which is the (substantial) gap between what qualifies as compliance with PSD2, and what is needed to provide a quality experience to users.
Put simply, PSD2 mandates banks make available less information than that which is needed to be able to service many innovative use cases effectively. This has resulted in certain banks and sometimes entire countries being compliant with the rules of PSD2 but not with it’s “spirit” – which is to enable and foster Open Finance.
For example, consider a PFM application, which generates value for its users by analyzing their financial data and providing a personalized experience.
Under PSD2, an organization that is strictly compliant will provide a very limited amount of data to the application, just the name of the account holder and a small sample of bank statements.
However, to be able to provide value to the user, the PFM needs additional information, such as cards associated with their bank accounts, financial products they have contracted, whether they are in debt, have a mortgage, and others. Without this information, the PFM will have a very limited view of the user’s finances and the value it will be able to provide will be limited too.
Faced with this situation, TPPs must use other connection methods to gather bank account data to be able to provide the same value to users as they did pre-PSD2.
Web scraping is one of them.
What does PSD2 say about web scraping? The directive says that if the services that were offered before the regulation cannot be guaranteed only by connecting to PSD2 APIs, then scraping will continue to be a valid connection, recognized as a “fallback mechanism”.
As we mentioned above, this is the case in many European countries, including Spain. Scraping is still heavily used even though we’re coming up on two years of PSD2 entering into force because it’s the only way to provide the necessary data to service certain value propositions effectively.
So let’s break it down. What types of data can we access via PSD2’s dedicated interfaces and via web scraping?
Dedicated interfaces: PSD2’s dedicated APIs
PSD2 requires that we connect to specific publicly accessible APIs that banks have enabled under the umbrella of the directive. These APIs provide access to a small portion of all potentially available data, and the formatting of said data varies from one bank to another.
This connection can only be established if the interested party is a licensed AISP, and in Spain it is often made through a connection gateway, Redsys, which the banks have chosen to mediate the process as a single access point.
One of the most important advantages of connecting through the dedicated interface is its stability and its speed.
A licensed AISP can connect to multiple bank APIs easily and quickly and access information in a way that is highly reliable.
As we mentioned earlier, the scope of data that is accessible is limited. Currently, we only have access to the name of the account owner and a segment of their bank statements. It’s not possible to read savings data, loans and credit, mortgages, or associated cards. This is because PSD2 doesn’t mandate banks make this information available, so 95% of them simply haven’t.
And there is another issue that impacts UX. The directive mandates that the user inputs their online banking credentials in the bank’s own login screen. This means that this screen needs to be rendered in an iframe or that users must be redirected to it from the prior step of the authentication process. As this screen belongs to the bank, it’s impossible for the TPP to control the design of the interface. This can lead to mismatches between steps of the user’s journey, which impacts conversion rates.
Direct connection: Web & App Scraping
What is web scraping?
Web (or screen) scraping is a common technology that was widely employed by TPPs before PSD2 and dedicated APIs became the default. It follows the same principle as Google’s web crawler bots, which visit pages and scan the information they contain, but applied to the online banking platforms of banks in this case. The system must be set up to identify specific sources of data on the page (buttons, sections, charts with numbers, specific lines of text) and then it simulates the user’s behavior, visiting the relevant pages of the online banking platform and copying the required information.
Scraping allows us to capture any information that is present in the online banking platform (with the exception of GDPR-protected information), we only need to know where that information is stored to be able to retrieve it.
Scraping can be used both on a bank’s regular online banking website and on its mobile banking application.
The biggest advantage scraping has over dedicated interfaces is the breadth and depth of data that is available. Some examples:
- Credit and debit card data
- Associated savings’ accounts and loans
- Information on contracted financial products and services
- Access to more historical data
- Additional personal information
Given that scraping is not a dedicated connection system, it is less stable than banks’ APIs. If the bank makes a change to its online banking platform, such as changing the color or the position of certain buttons, or the text of certain menu items, the system will stop working because the bot will not be able to locate the information it is looking for. This means that scraping requires more maintenance than dedicated interfaces.
Unnax’s hybrid connection system
Faced with this, at Unnax we have dedicated ourselves to getting to know our clients and their needs very well in order to offer them exactly what they need. That is why we have opted for a hybrid connection model, using the two possible channels and all their possible variants depending on the needs of the client’s specific use case. These are:
API connection (dedicated interface):
- Redys gateway
- Banks’ dedicated APIs
Direct connection (scraping):
- Connection via the online banking website
- Connection via the online banking app
Our primary concern when building our aggregation service was offering more complete data.
Depending on the requirements of the client’s use case, we can use one channel or another. For simple use cases that only need a small amount of statements and the account owner’s name, we use the dedicated interface, while for use cases that demand information on financial products, cards, loans, and more we use the direct connection.
We are also able to combine the two channels, obtaining certain types of data from one source and others from the alternate one.
According to our Head of Product, Ben Cotte “We have taken the time to understand the use case and flow of each bank and to refine it to the maximum in order not only to be able to offer the same quality of service as before, but also guarantee that the client continues to have an optimal user experience, with an agile and responsive user journey.
This is what differentiates us in the market, both on a the visual level, with our widgets and UX, as well as at the level of depth of the data and the logic behind it to offer the exact data at the right time. “
Do you want to satisfy your customers’ expectations with personalized financial services? Start here.