SEPA instituted some real game changers in the payments world. The IBAN and ISO 20022 XML standards, for example, promote efficiencies in streamlining payment processing. Using an IBAN as the account number standard allows both payment service providers (PSPs) and payment service users (PSUs) to avoid errors that can occur with data input. All of the hidden validation checks in the IBAN, as well as the identification of the bank owning the specific account contained within the IBAN itself, help to promote efficiencies in payment processing, ensuring proper capture of beneficiary details as well as proper payment routing.
Likewise, there are substantial benefits tied to the use of ISO 20022 in the industry. This institution of a universal format for messaging radically streamlines payment processing. PSUs such as corporates can leverage the same file format to send messages for payments of various types to their banks. All of their SEPA payments, regardless of the country to which the payments are being routed, can all be sent via ISO 20022. The use of one uniform file format drives down the cost of having to maintain country-specific formats. Technically speaking, the tool also lends itself to scalability. It is easier to accommodate additional required elements in an XML structure than with other traditional messaging format types.
A phenomenon took place with both of these standards, the IBAN and ISO 20022, being adopted beyond the SEPA zone. Very quickly, after the EPC devised the IBAN as the account number standard for SEPA payments, we witnessed the adoption of IBAN as the account number standard for payments outside of the SEPA countries like Brazil, Turkey and the United Arab Emirates.
Additionally, a trend emerged in leveraging ISO 20022 for more payment types, not simply for SEPA payments. Corporate treasurers are increasingly using ISO 20022 for payment instructions being routed into various payment systems. There are real benefits – the PSU no longer has to maintain multiple formats for payment instructions and processes are more streamlined and efficient as a result of adopting one payment format. Certainly, this is an example of the industry catching up with the innovations that technology has made possible. Looking ahead to 2016 and beyond, PSPs in SEPA non-euro countries are already planning on adopting ISO 20022 for domestic non-euro payments as well. The combined actions of both PSPs and PSUs are making ISO 20022 use more widespread.
The increased use of ISO 20022 is also opening up innovations in real-time payments. Now, clearing systems see the possibilities of real-time payments happening with the advance of innovations like ISO 20022. It will be interesting to see how legislation will combine with market drivers in fundamentally changing the way payments are made today. From this perspective, one can see how SEPA helped lay the groundwork for some great innovations yet to be realised in the payments industry.
Looking Ahead to SEPA 2016
Considering SEPA 2016, we see that there has been much work done already in terms of adoption. Because SEPA 2014 required foundational work, much of the heavy lifting for SEPA has already taken place. Also considering that SEPA will still confine itself to euro payments only, even in the non-euro countries, the universe of payments to tackle is even narrower.
There are still three factors that will need to be addressed. First, all of the niche products in the SEPA euro countries which represented less than 10% of the total market share that did not have to comply with SEPA in 2014 now have to comply with SEPA by 1 February 2016. Second, there are still the payments to address in the SEPA non-euro countries which have to comply with SEPA by 31 October 2016. Third, the ‘IBAN only’ rule becomes effective by 1 February 2016. For the PSU, this should not imply too much work, relatively speaking, as the foundational work done for SEPA 2014 will only mean scaling for more countries and payment types in 2016. However, there is some discrete preparation that PSPs will have to undertake for the ‘IBAN-only’ rule. This rule implies more than just scaling to accommodate more markets and payment types, it requires an intentional enrichment of the payment message that the PSP receives from the PSU. Critical to this goal is payment data, specifically IBAN to SWIFT/BIC information, which PSPs will need to integrate into their existing payment processes.
There are still benefits for both the PSU as well as the PSP. For the PSU, it means that there is less information to gather. Very simply, the PSU is responsible to provide the IBAN only. That IBAN itself, which is a variation of a bank identifier and account number, indicates the institution owning the account. There is no reason for the PSU to provide the routing instruction, the SWIFT/ BIC in this case. That information is already implied in the IBAN and is now the responsibility for the PSP to derive.
The Timeliness of ‘IBAN-only’ for Real-time Payments
The ‘IBAN only’ rule fits very well into a world where the use of online payment systems is becoming more prevalent. Online payment system product offerings are proving to be a differentiator in the market for financial institutions. PSUs are demanding an easier way to initiate payment instructions. A user having to submit only an IBAN instead of having to provide both a bank code and account number separately can reduce their payment setup experience by one click. The reduction of data input certainly reduces confusion for the PSU. There is no need to determine what a SWIFT/BIC is or which SWIFT/BIC goes with which IBAN. Considering that many banks own multiple SWIFT/BIC assignments, determining which SWIFT/BIC to use for IBAN payments is not easy. Arguably, this task should not be left to the PSU. Furthermore, reducing the number of clicks is a key measure in improving user experience (UX). On the minds of every product manager in many financial institutions is how to improve UX. The number of clicks, the average time per session, the SLAs in place, etc. are all important factors in measuring the value of online product offerings.
What about the benefit of the ‘IBAN only’ rule to the PSP? One can say that the burden to ensure proper routing categorically shifts to the PSP. After all, now the bank has only the IBAN as a starting point to determine routing. They are responsible to enrich the payment instruction with a SWIFT/BIC, using the IBAN alone to derive this. While this does put the pressure on the PSP, it does not radically alter existing processes. ‘IBAN only’ also alleviates any concerns around accepting or not accepting the routing instructions from the PSU. Concern for overriding routing instructions that PSUs provide should go away. If the PSP can ensure that they have a reliable approach to this type of payment enrichment, they can add value to their payment offerings by increasing efficiencies in payment processing, reducing payment rejections and avoiding misrouted payments. Considering this in a world of faster payments, every step to shorten the payment setup process becomes even more important. PSPs are calculating the amount of time from setup to process in milliseconds. If the PSU can submit less information for a payment instruction, it will fit very well into a real-time payments world where reducing time is most important.
By Sarkis Akmakjian, Senior Director Product Management, Accuity