Many companies in the euro zone only have few months left to meet the timeline for EU Regulation 260/2012 of the Single Euro Payments Area (SEPA). All the more pressing are the nagging questions for many SEPA project managers: Are you still able to meet the deadline for all the requirements in the narrow time interval remaining? At what point should you begin and where should you stop? And if that was not enough – What alternatives are there for executing payments after 01 February 2014 if your SEPA project is not going to be finished?
Despite the EU regulation and the ensuing regulations for many participants many questions remain unanswered – just months before the final end date. SEPA is not simply an IT project – rather the conditions and implications go far deeper into the existing business processes than was previously thought. In addition to the opportunities which a single payment area presents, there remain the voices of critics and multiple open questions for which there are insufficient responses to date.
An inglorious example would probably be the never-ending debate about direct debits (SEPA Direct Debit). However, let us stay with the perspective of formats for now, as there are probably as many similar question marks are on the faces of the participants for this topic.
Europe, and what comes next?
Five years into the SEPA effort, not a lot is left of the original idea of a unified format for cross-border payments. What was intended at the outset to become a universal format for most all banks across Europe has instead become a mirage along the way.
National forums have put nearly all format specifications that were defined by the European Payments Council (EPC) in question and have gone so far as to set up their own style definitions as well. For example, the SEPA formats in Germany and Austria differ from the EPC requirements, and each other, and therefore must be implemented separately in the format trees of the ERP systems, or be handled with specific format parameters.
On top of this, the next step is the end of existing national payment formats for cross-border payments into the non-EUR area. The EU regulation says that from February 2014 onwards, these payments are also to be delivered to the bank in ISO 20022 format. The question is, What variant of the format are you referring to? Here, companies are spoiled for choice. The first option is the pure ISO 20022 format, which is only accepted by a small number of banks. As an alternative, the CGI format supported by SWIFT has been in use for a while. But again, this format is supported only by a few large banks. -Thus the question remains, What about the rest of the format variants? Which formats can and will numerous small and medium sized companies select to execute their payments in the future? And, as a complicating factor, will their ERP systems support these new formats, or is individual development required?
Complexity versus flexibility
Overall, there are no satisfactory answers to these questions. Rather, the subject becomes more complicated by the fact that the ISO formats continue to expand. No longer is there such a thing as a single a stable, valid format, instead, it requires constant monitoring and maintenance by IT managers of the ERP systems. The much-quoted desire to have flexibility and global reachability for banks will most likely come at the price of increased complexity in payments.
The goal that must be achieved, and frankly the future of customer-friendly payment formats depends on simplicity. The client must be able to handle his payment traffic free from technical requirements and constraints. Only if this can be done, will one be able to avoid further complexity that none of the protagonists may have in focus.
If this can be achieved, all of the involved parties will have the opportunity to exchange payments quickly, efficiently, at high speed and with low effort. Innovative B2B payment players like Traxpay, are already making this possible. Traxpay’s real-time financial transactions platform supports SEPA, ISO 20022, and more.