PSD2 and how to personalize our customers’ user experience

The entry into force of the European Union’s PSD2 directive opened up the opportunity to develop a whole new market on the foundations of open banking. Based on data provided by banks, third-party APIs that offer new solutions, and the ability for customers to choose which data to share with which services, this market is the basis for customer experience personalization. With the PSD2, banks change ecosystems.

The PSD2 has managed to develop a perfect environment for new ideas to emerge as a result of reading the needs of customers. Usually through APIs, they enhance the user experience by enabling smoother navigation, more interesting and easy-to-understand services, and banked systems that meet their needs in a more precise and personalized manner. All because data was “opened up.”

That’s how the API ecosystem thrived

APIs have been on the market for some time. BBVA API_Market was launched in 2016, two years before the PSD2 was effectively implemented and BBVA Open4U had been launched in 2014, but there is no doubt that this directive has significantly boosted the world of Application Programming Interfaces. Approval in the European Parliament opened the door for the API ecosystem to develop in its entirety.

Until then, banked services did not have a legal mechanism for customers to approve the use of third-party solutions, so any banking relationship was established between two players: the bank and the customer. Although for years there was innovation, usually in interfaces and security, there was little dynamism in the search for new services.

Everything changed with the PSD2. Now, banks and customers can surround themselves with a group of code providers to implement new services between themselves and with other agents. And all this is fed by data that shows what users need. The relationship, which until now had two nodes, went on to have three, where one of them was a whole market of companies aimed at designing digital bridge-services.

Just as it happened decades earlier with open source, or in the early 2000s with urban labs, which were permeable to the arrival of new ideas, the APIs market reached maturity and took off in a few months. This is mainly due to the presence of the new node: developers, armed with data.

Developers with access to test environments look for customers

Developers, either as freelancers or through specialized companies, have boosted the API market once the PSD2 door opened. Thanks to working environments such as BBVA API_Market’s Developer Center, these professionals find a large number of means with which to design solutions that interest the end customer. A toolkit.

API developers do not work for API markets, but rather to solve real end-customer problems, albeit they feed on both the banking-arranged kit and the details of business banking life, which in turn help build better solutions. It is a symbiotic agreement that benefits both parties because, together, they are able to increase and customize the customer’s interactions.

Consequently, development environments function as group work hubs, question resolution forums and idea accelerators, building the perfect breeding ground for a Darwinian competition with a single goal: to satisfy the customer, to make their life easier. That is why it was essential to make the PSD1 more flexible: the new version increases supply and competitiveness.

The job of developers is to locate unmet needs of banking customers, who understand better than anyone the needs of both end users and companies looking to turn their services into banked services, thus adding a fourth node to the diagram: companies that are both banking customers and banked service providers for customers who also use banks.

Customers always have a need

Armed with the development kits from the API markets, which seek banking integration, API developers are the ones who build open banking to solve needs. So, when developers realized that business clients had difficulty integrating and analyzing the AEB43 standard, they designed Business Accounts.

Another business need, long demanded by car dealers and sales companies, was the possibility that end customers could receive real-time simulations of the loan conditions which would be signed during the purchase. The solution was Auto Loan, the API that displays this information without leaving the sales platform.

Similarly, when internal accounting records needed to be converted into a system of banked customer accounts with which to operate, Accounts was designed. This API makes it possible to create customer accounts classified as “white-label accounts” using BBVA’s infrastructure. In turn, this provides confidence in the security system.

As shown by the examples, these three scenarios present specific and different challenges and needs. This is because APIs are typically designed as standalone modules that solve a specific issue. Not all customers have the same requirements and objectives, so very demand-oriented programming interfaces are customized.

The PSD2, the second stone in the API world

Without the PSD2, this was noticeably more complicated because it required banks to design each of the solutions generically. Less detailed, they brought much less value to the end customer, who was only partially satisfied with their conditions or who could not find a secure technical solution.

Once the door is opened to APIs, end users can transfer data to developers and other agents. The latter, leveraging their competitiveness and technical kits from markets such as BBVA API_Market, now do have the ability to develop APIs capable of facing a problem, starting from the basis of data-driven knowledge.

Are you interested in financial APIs? Discover all the APIs we can offer you at BBVA