26 November 2012
XML: the key ingredient for truly standardised SEPA data formats
Ruth Wandhöfer is Head of Regulatory & Market Strategy at Citi Transaction Services. In this blog post she discusses how local variations in SEPA data formats form a threat to market harmonisation.
The major barrier preventing SEPA from becoming a reality lies in the different data formats that are in place to process payments across different national clearing systems. A barrier that can only be lifted when banks across the SEPA region start adopting the harmonised SEPA XML message standards en masse.
At this moment in time, a widespread adoption of XML message standards is far from being a reality. In fact, banks across Europe still use domestic payment formats in addition to SEPA. At the same time banks may still resort to conversion tools to convert data from existing formats to the SEPA message standards that are specified by the European Payments Council (EPC) for SEPA Credit Transfer (SCT) and SEPA Direct Debit (SDD).
Risks for market harmonisation
The data formats specified by the EPC are based on the global ISO 20022 message standards. These standards were leveraged to create a common denominator for SEPA transactions across Europe. The SEPA rulebooks for credit transfers and direct debits are however open to implementation variations, given the fact that optional fields run alongside mandatory ones. In addition, there is the possibility for individual providers or countries to define Additional Optional Services (AOS) outside the rulebooks.
Whilst these potential variances may bring some added value for clients, they should be handled in a way that does not threaten the interoperability between payment services providers (PSP’s) in SEPA.
The need for XML
For a successful migration to SEPA, it’s key that banks in the Euro zone properly introduce XML into their systems. Up to now, some banks are still resorting to conversion solutions as opposed to having full internal XML capabilities. Some country infrastructures tend to facilitate this process, which hopefully should become redundant by 2014 when Euro zone PSPs/banks will have to have implemented XML themselves.
If a PSP/bank doesn’t implement XML capabilities, instances could occur where optional fields populated by a client on an XML SEPA payment instruction cannot be processed in a structured manner, given the fact that the optional fields usually go beyond domestic message data sets. This would go against the benefits supposedly derived from SEPA, which allow clients to transfer more information in a structured way.
IT infrastructure in place
Migrating to an XML focused infrastructure is quite expensive, but embedded XML capabilities are crucial to shift the existing national and pan-European clearing systems from a fragmented system to a SEPA harmonised structure. While some countries have proper migration programmes in place to get the right IT infrastructure, others have already migrated. There are also still some late movers who need to improve migration efforts.
A good example of a country that took the migration to XML very seriously is Finland. The Finnish banks have already moved to XML. On the corporate side XML capabilities are also in place, facilitated by software solutions in some instances. As a SEPA market, Finland has also embedded specific features (AOS) for national SEPA transactions, which shows that in spite of the harmonisation objective local variations are still considered to be important.
More views and information on SEPA data formats can be found in Ruth Wandhöfer’s editorial in the October issue of the EPC Newsletter: ‘ISO 20022 Message Standards: Too Many Flavours’.