The arrival of PSD2 in 2018 will open up transaction processing to third-party payment service providers (TPP), and has been well documented as a potential threat to the banks’ dominance in the space.
James Buckley, head of Europe at Finacle – a universal banking application developed by Infosys – says the banks’ only option now is to collaborate more closely with their prospective third-party rivals.
“Banks are finding they are under real threat," he says. "In the low-interest environment, they are not making money, and are losing some of their business to niche players. The best way to attack is to bring the fintechs into their orbit and extend their capabilities. PSD2 is triggering this change.”
Although PSD2 might well be the catalyst for closer incumbent and fintech collaboration, managing the relationship between bank and third party is a tricky process. There is a balancing act between implementing PSD2, and complying with privacy and data security rules, especially as these are still subject to change.
|
Lu Zurawski, |
Lu Zurawski, solutions practice lead, consumer payments EMEA, at payments solutions provider ACI Worldwide, says: “The EU is introducing the general data protection regulation (GDPR) in 2018, the same year as PSD2 will come into action.
"The GDPR is aimed at giving customers control over their own data, recognizing customers' rights to privacy and to prevent – or at least better deal with – data breaches. The data belongs with the individual; they are giving a company the licence to use their data when they enter into a contract with them.”
While this seems relatively clean cut, the problems lie with the cross-over in the two regulations, and where exact details have not been clearly defined.
David Hamilton, CEO of account-aggregation provider eWise, says: “The PSD2 regulatory technical standards (RTS) mandates access as a compliance requirement. As long as the TPP connects to the bank in the right way they should have access to the end-user data on a non-discriminatory basis.
"The data available should be no different to what is accessed by a customer through their online banking platform.”
While the RTS states that the banks should not provide sensitive data, it does not define what exactly sensitive data is. This leaves it open to a range of interpretations, and gives banks that are reluctant to hand over their customer’s details a possible excuse.
Hamilton says: “The banks can say they have to interpret this in order to still comply with privacy laws. Sensitive data could be the transaction description, and they may decide to start redacting or masking data. For those that are reluctant to start sharing data, masking is a less-risky method than redacting data.”
Further, not implementing and observing the GDPR processes correctly could be a costly experience. Banks that do not comply with data privacy face a heavy fine, but this does not make avoiding PSD2 a safer, or more cost-effective, alternative.
“The GDPR comes with a penalty of 4% of turnover if a company is not adhering with data protection rules,” says ACI Worldwide's Zurawski.
“A company may say they are tempted to wait instead on implementing PSD2, and ensure they are getting GDPR right first. However, one banker has said that if they don’t implement PSD2 they cannot do business, so both are equally important. It is going to be difficult for banks trying to juggle both regulations at the same time.”
Further complexity comes from the messaging channels used to transfer data and payments from accounts to the TPP.
|
|
David Hamilton, eWise |
Hamilton at eWise says: “The PSD2 RTS for Access-2-Accounts [the part of PSD2 that provisions for third parties to gain direct access to bank accounts] is principles based rather than standards based, and to this end we expect the industry will see significant differences in the communication interfaces implemented by the account servicing payment service providers.
"While the RTS stated there would be access to accounts, it is up to the banks to define what the interface will look like and the technology used.”
This then poses the question of what the messaging channel will be. While ISO 20022, the standard used for Europe-wide Sepa payments, is being positioned as the default option, there is actually no firm requirement for this to be the case.
Hamilton says: “ISO 20022 is not the final standard for components and messages. It is possible banks across Europe could come up with their own propriety communications channel, but they would still need to provide it publicly so a third party can get access.”
With PSD2 supposed to create a level playing field for institutions of all sizes, and break the monopoly on payments held by the banks, having more options might facilitate this.
Zurawski says that in this circumstance, the standard might not be as necessary as some would believe.
“Although larger retailers and much of the payments industry is pushing for standards, I’m not entirely sure that the adoption of ISO 20022 matters to all the new entrants and fintechs looking at the new opportunities offered by PSD2," he says. "New payment service providers will deliver online services to retailers and platform businesses that do not particularly care about what an ISO 20022 standard message looks like."
He adds: “These businesses expect very simple connections, accessed by modern APIs and manipulated by developers that do not need to have deep knowledge of payments flows. The standards issue becomes more relevant for larger wholesale business operations closer to traditional clearing and settlement networks.”