It’s now less than six months until the Payment Services Directive 2 will come into effect. With national legislation in each of the 28 countries currently in the European Union due by January 13, many banks and financial institutions are currently preparing how to be compliant. For teams preparing for PSD2, there’s a determination to get changes made and infrastructure in place, as well as a sense of trepidation at how the wider market will evolve.
For many banking IT teams, PSD2 represents a challenge and an opportunity. The challenge will come from other banks and fintech suppliers being able to get access to valuable data that was previously held by banks alone. However, the opportunity can be found in preparing for the future. For teams that have gone through mergers, acquisitions and new service launches, the resultant spread of customer data leads to varying quality and inconsistency across different silos of IT infrastructure. This has been a perennial problem for years.
Sourcing budget and support to deal with this spread of customer data has been difficult in the past. After all, what is the ROI on fixing something that already works effectively? However, these silos do have an impact on customer experience. PSD2 effectively forces those banks that have not brought customer data together to do so.
How to build PSD2 compliance and support for APIs alongside traditional banking apps
At its heart, PSD2 shifts the model for processing payments from one based on merchant acquirers and payment processors over to one that uses application programming interfaces (APIs) to directly connect banks, retailers and customers. By putting a secure framework in place, retailers can be paid faster and customers can have greater control over their money.
At least, that is the theory. Alongside this, there is now room for new market entrants to disrupt the payments market through using data in innovative ways. By meeting customer needs more efficiently using data, Account Information Service Providers (AISPs) and Payment Initiation Service Providers (PISPs) can insert themselves into the value chain. For banks, AISPs represent a potential threat to their existing relationships with customers.
Support for API implementations is mandated for any organisation that hosts current accounts for customers, so banks don’t have a choice on whether they should open up their APIs. For AISPs, these APIs should provide information from customer accounts once a request is approved; for PISPs, an approved request should lead to instant payment.
One big challenge for bank IT teams is that their central applications were not designed with API access in mind. For legacy applications – often based on mainframes – adding API access directly into these systems would be expensive, risky and involve all sorts of unknown scalability issues. Re-engineering applications with API support is possible, but increasing the amount of hardware infrastructure to provide these capabilities represents an expensive way to add this functionality. It also does not deal with the fact that most customer data is spread across multiple silos associated with different accounts.
To make it easier to support API access, adding the support as part of a data management layer can help. This translates API requests for data into those that can be passed through to the central mainframe application and those that can be supported separately. By storing a cache of information on account details, requests can be fulfilled without having to add more workloads to the central infrastructure. This can reduce the impact on central banking applications around information requests while payment requests can be prioritised.
How often will the availability of APIs lead to customers interacting with their data?
Making it easier to access a service will normally lead customers to use that service more frequently. Previously, customers would have to use paper statements, visit their branch or access an ATM to get their balance. With the growth of Internet banking, this information can be requested whenever a customer is at their PC; with mobile, it can be asked for whenever and wherever it is needed.
The growth in the number of channels that banks support puts more pressure on central applications. However, the availability of APIs will increase the volume of requests further too. Customers will trigger their own requests for data, but also authorise third party AISPs to gather data on their behalf. Each one of these requests will represent more workload for central applications if not considered carefully.
Instead, these requests can be handled by the data management layer. Using cached data in this way can ensure that customers don’t feel any change in service. This can also help banks deal with demand levels that may change quickly. While all banks are preparing for the change in demand on their systems, the teams involved can’t predict how much extra infrastructure they will need to put in. This has an added benefit in terms of resilience - if the mainframe were to go down customer requests could still be served by this data layer as 80% of customer interactions are read-only.
Rather than overspending and then wasting valuable budget on hardware that is not used, bank IT teams are instead looking at how they can scale quickly as well as managing investment costs in linear ways. This approach should ensure that banks can spend on how to support their infrastructure in a fashion that links any expansion directly to demand.
Building support for internal and external data sets
At this point, it is also worth stepping back and questioning the prevailing narrative around PSD2 as a threat to traditional banks. While fintech providers will undoubtedly look at PSD2 as an opportunity to win customers over, there is nothing to stop banks from doing the same. Banks actually have a built-in advantage when it comes to implementing innovative new services around customer data, as they already hold these records internally.
For banks that have customers holding multiple accounts with them, getting insight into behaviour should be a simple next step. Building a Single Customer View or SCV can provide insight into when customers may be receptive to offers or marketing activity, and equally can flag where customers might not be happy as well. A customer account that suddenly starts to get lots of request activity from AISPs should be analysed to ask why, for example.
This SCV can help banks improve their own performance, particularly where data otherwise exists solely for individual teams. However, it can be enriched using external data too. Bringing in data from other banks where customers have multiple accounts can be used to provide a more in-depth overview of finances, while using external data sets can deliver more insight into what customers may really want from their bank as well.
Using analytics on these data sets can show how best to interact with customers, while making this activity work in real time can provide opportunities to improve the customer experience still further. By combining internal and external data sets and using this information in the right ways, banks can get ahead of their competitors when it comes to interacting with customers. More importantly, the need for compliance to be in place will unlock budget that would otherwise be difficult to secure. PSD2 can therefore be a great opportunity for bank IT teams to be innovative.