The Payments Service Directive (PSD) was originally brought in by the European Union (EU) to update the payments market across the region, opening the market up to more competition and delivering better services for customers. Following on from the initial PSD in 2007, the latest update to the Directive covers many new payment services that have developed in the meantime.
As the Directive states, “Significant areas of the payments market, in particular card, internet and mobile payments, remain fragmented along national borders. Many innovative payment products or services do not fall, entirely or in large part, within the scope of Directive 2007/64/EC.” In other words, the regulatory framework that was brought in for the single euro payments area (SEPA) needed to evolve further.
In response to these changes, banks and financial services providers now have to adapt to a new market and infrastructure for payments. The development of open banking and payments application programming interfaces (APIs) goes hand-in- hand with new processes for routing information between customers, retailers and banks. At the same time, new third party providers (TPPs) can enter the market around payment processing and information services.
The role of open APIs will make processing payments easier on behalf of customers, while the availability of data across accounts from multiple banks in one place should also help customers receive the best potential service. For customers, the ability to get more useful information from their accounts in a way that suits them should be a godsend.
However, for banks, this change is more problematic. The exclusive relationship that previously existed between banks and customers around their account data will be broken.
What will the impact be on core infrastructure?
For years, core banking IT systems have sat in silos. This could be due to different departments running their own applications and infrastructure; for example, mortgage services being hosted on older mainframe apps, while debit and credit card records were on more modern systems. Alternatively, growth through acquisition could lead to multiple sets of customers being hosted in parallel.
Whatever the reason, migration to single platforms was often deferred into the future due to the twin devils of cost and risk. For many customers, this means getting a joined-up picture of their financial situation is difficult even when they have multiple accounts with the same bank. Getting a better experience for the customer is therefore overdue.
At the same time, the growth in the number of channels that customers can use has additional consequences for banks. Rather than a weekly visit to a branch, customers can use online services, phone banking and mobile apps to get information. In the future, these requests can come from third party information providers that a customer authorises to access their account data too.
This growth is not without overhead. Internal banking IT systems will see huge volumes of requests for information alongside transactions, more than they were originally designed for. With new mobile banking applications being developed to ensure better customer service, customers can ask for more data to be delivered to their devices. In building sleek new apps that aim to delight customers, banks can actually cause bottlenecks or poor performance when they don’t take back-end infrastructure into account as well.
Issues like security, redundancy of systems and availability of data will have to be considered alongside the customer experience when designing these new banking services. Any slow or lost transaction requests will have a negative impact on customers. In order to prevent this, banks will have to think about how their new API layers interact with their core banking systems and the data models that are implemented alongside this.
Architecting infrastructure for data, APIs and for core banking system performance
At the most basic level, the API layer to serve the revised Payment Services Directive – PSD2 – will sit on top of a bank’s existing core banking applications and process API calls to and from payment initiative service providers (PISPs) and account information service providers (AISPs). These two new categories of organisation will replace the card schemes in managing requests for payment and for information from customer accounts.
To keep up with customer experience requirements, data around interactions and transactions can be cached so that the results are available to be used. Scaling up this service is also necessary so that core banking applications can run at acceptable levels while API services can also interact with requests from AISPs and PISPs.
This centralisation of data serves two purposes. Firstly, banks will have to implement API layers so they can interact with the AISPs and PISPs around payments. This compliance with PSD2 is necessary and all banks will have to make changes to their infrastructure deployments.
Secondly, there are opportunities to make use of all the customer data created by the daily transactions taking place. Where customers have more than one account, the information can be pooled together by banks to run analytics and to help develop better customer service interactions. This internal focus can then be taken further by bringing in external market data for inclusion in analytics programmes.
The role for data here involves looking at how banks can compete with AISPs when it comes to customer experience. Getting a better picture of customer preferences and requirements can help retain the trusted relationship that previously existed, when the bank was the only organisation able to access information on a customer’s account. By consolidating data internally and carrying out analytics on transactions, banks can get a more up to date picture of customer activity compared to that which third party AISPs can access.
This analytics activity can happen in parallel to the transactions being processed. The operational data can be analysed in near real time by streaming data into a separate instance, so that there is no impact on the bank’s core applications and their operational performance.
This ability to run analytics can provide the difference between having a customer’s data and knowing their preferences. For customers with multiple accounts at the bank, information from different accounts can be combined to spot trends that are developing over time. By creating more insight into what customers really want from the bank, the service can provide more value in comparison to forthcoming PISP competitors.
Looking ahead – PSD2 should be about more than compliance
The impact from PSD2 promises to be significant. For a technical specification on how the payments sector should operate, it will have long-term effects on the wider banking sector. It will also offer opportunities for both existing banks and new start-ups to improve customer experience around financial decisions.
With a relatively short timeframe to the compliance deadline, banking IT teams will need to think hard about how they can comply with the new rules on payments and account data, while also defending their current position around customer experience. If they don’t go through these planning exercises now and concentrate only on compliance, then opportunities to better serve customers will be missed.
A US study, based on the quick service restaurant chain Chick-fil-A, offers conflicting evidence on whether a TMS is the best option when upgrading from Excel-based forecasting.
The EU's updated Payment Services Directive (PSD2) is expected to heighten competition among the banks, open markets to non-banking challengers and foster vigorous innovation across the financial sector.
The geopolitical shocks of 2016 saw businesses understandably concerned about how the new reality of resurgent economic nationalism might affect cross-border trade and capital flows. Yet as this article explains, there’s no need for overreaction.
Banks which start to prepare now for the region to join the move to immediate payments can secure a major competitive advantage.