Concerning the differences between two-wheelers and the need for multi-lane highways
A bicycle path is only meant for bicycles. That seems obvious enough - the clue is in the name. What happens however if one day someone drives along the path on a motorbike? Nobody really cares enough to try to stop them. Why? Because the motorbike also has two wheels, and given that not many cyclists have discovered this particular path yet, the risk of a serious accident seems small. An observant onlooker might say: "Yeah, but that's not a bicycle", however someone might argue that the traffic authorities only determined that a vehicle must have two wheels in order to use this path. Nobody told the motorcyclist that they were not allowed to add some additional extras to the bicycle, such as a motor for example.
The situation for Single Euro Payments Area () transactions is broadly comparable. The general idea is that payment transactions are processed based on a common set of data to be exchanged in a common syntax; i.e. the data formats. The data formats are detailed in the implementation guidelines, released by the European Payments Council (), with regard to the Credit Transfer () and Direct Debit (SDD) Rulebooks (see 'related links' below). The data formats are binding for the exchange of payments between payment service providers () that are and / or SDD Scheme participants. The use of the data formats in the customer-to-bank communication is recommended by the yet not made mandatory. The data formats do not constitute an exclusive European standard. Rather, the data formats are based on the global ISO 20022 message standards developed by the International Organization for Standardization (ISO).
It is expected that there should be a common understanding on the use and interpretation of the ISO 20022 message standards, as specified in the implementation guidelines (i.e. only bicycles are allowed on this path). This is however, not the case. The market reality today is that multiple specifications based on the implementation guidelines are in use, which has resulted in subtle (and sometimes not so subtle) differences in the application of the standard. The bicycle path is increasingly populated also by motorcycles and other types of vehicles which only very remotely resemble what is commonly considered a bicycle.
Insufficient attention is being paid to the fact that a wide variety of message formats are currently being used in the -to- domain, despite the fact that the has clearly defined the inter- format. If this were to continue to be the case as migration continues to gain momentum, there would be major risks to efficiency, interoperability and competition. So far however, many and clearing and settlement mechanisms (CSMs)1 have not been able to resist the urge to adjust these when implementing their own solutions.
Vision versus reality
Why is that? The role of the in defining the data formats involves identifying all necessary data elements for making payments, as defined in the Scheme Rulebooks within the global ISO 20022 message standard. These 'core' data elements are indicated by yellow shading in the 's implementation guidelines, released with respect to the and SDD Schemes. To allow communities of banks participating in the Schemes to provide additional optional services (AOS) based on the schemes, the has also identified data elements within the global standard that can be used for this purpose. These data elements are indicated by white shading in the implementation guidelines.
The implementation guidelines could therefore be regarded as a framework rather than as a prescriptive solution which allow a degree of interpretation. As a result, many market participants felt able to take the basic format and modify it - often according to the information included in their former domestic formats. Examples of the types of modifications that have been witnessed include: the interpretation and usage rules of fields in the mask are different; a field that was optional in the Rulebook is made mandatory by that local implementation rule or, in the other extreme, is no longer allowed; or something is added as a file header. Specifications of the ISO 20022 message standards developed by national CSMs also often seem to aim at perpetuating local habits; i.e. differences, rather than embrace harmonisation and therefore competition.
At first sight, this might even look like a positive thing to do if the motivation was to meet existing user needs in, for example, a national community. Maintaining this position of flexibility and variation at the -to- level in the future however, would come at a heavy price - in terms of severely limiting the benefits of enhanced efficiency, cross-border competition between all and more choice for customers. After all, a standard can only deliver competition and enhanced efficiency for the market if implemented in a harmonised and consistent way. At a time when the need to complete the European Union (EU) single market has never been higher up the agenda, it would be a huge irony if the initiative were to result in additional fragmentation rather than the harmonised environment it is meant to be delivering. Indeed, a harmonised outcome is a key contributor to the broader EU agenda as set out in the EU 2020 Strategy and the EU Digital Agenda (see 'related links' below).
As a consequence of the lack of harmonisation, multi-country payment processing at a -to- (or -to-CSM) level currently requires the handling of multiple domestic formats, which effectively replicates the legacy environment where every country had different local rules and formats for their payment process. If this situation were to continue, the upgrade to the open ISO 20022 XML standard framework would therefore add little value to the efficiency and integration of the European payment market.
A global perspective on ISO 20022
Moving briefly away from the European story, let us take a look at what is happening with the ISO 20022 message standards at a global level. In addition to enabling a more streamlined way of processing transactions between , ISO 20022 is fast establishing itself as the 'best of breed' when it comes to simplifying customer connectivity to . As a result, corporate customers are increasingly embracing these message standards.
This tangible success has been brought about through the international collaboration within the Common Global Implementation initiative (CGI), a global industry forum which brings together leading corporate customers, banks, service providers and standard bodies. Created in October 2009, CGI currently includes 47 members and has recently published implementation guidelines covering payments, collections and reporting (note that reporting is not taken care of in the environment!).
The CGI approach to ISO 20022 XML enables the user to benefit from a common business process to improve payment initiation and accounts receivable automation, including reliable transfer of the remittance advice or the remittance advice reference through the banking/ chain. In practice, this means that customers can take their cash management to the next level with help of a single global implementation. Customers are able to make use of a single common global template to send and receive all their payments around the world, including reporting. The concept of 'data overpopulation' allows customers to effectively provide all of their information to the bank/ using ISO 20022 XML, removing the requirement to follow local business rules. Therefore the complexity of the country-rule led payments process, which customers are usually subjected to, is instead pushed on to the bank/ side. The bank/ that is part of the CGI then ensures that only the relevant information is passed to the respective clearing in order to execute the transaction. This delivers a very simple and efficient approach for the customer, facilitating the integration process with banks/, reducing implementation cost and at the same time enabling the customer to switch bank/ easily - between those that are part of the CGI - which is an important benefit from a competition as well as risk management perspective. Whilst the customer-to-bank implementation guidelines (recommended by ) would require customers to follow the business rules and only send the information that is defined therein, the CGI approach, by enabling 'overpopulation', allows the elimination of any requirement on customers to specifically filter the data for such a process.
Additionally, the supporting this initiative see an increased benefit in achieving more global coherence amongst payment systems standards and formats with a view to aligning around the ISO 20022 XML message standards, as this would simplify their task immensely. This is quite a different approach to that being followed by some European players and communities as described above, which instead see a benefit in a more fragmented and locally flavoured approach to ISO 20022 XML, even in a context.
Let us recall the original objectives - and apply the lessons learnt
Suffice to say that in Europe, as much as at a global level, the true value that can be provided by to their customers lies in a coherent standard approach that leverages the ISO 20022 message standards as much as possible. Therefore should move to the next level, i.e. a situation should be created which allows to process ISO 20022 transactions and enables their customers to access these services in a harmonised way. This would result in more customer choice and competition in the payments market, domestic as well as cross-border, to the benefit of all types of users of all sizes. The initial track record of in this regard leaves room for much improvement. It is expected however, that adoption of the forthcoming 'Regulation Establishing Technical Requirements for Credit Transfers and Direct Debits in Euro' (the Regulation) will set mandatory deadlines for migration to the payment schemes and thereby give new momentum to the market.
So will motorbikes disappear from the bicycle path in the future?
Coming back to our introductory analogy, the question at this point is whether we will manage to get the motorcycles off the bicycle path. In the European context, the answer needs to be a firm 'yes!' In the interests of road safety and traffic management, motorbikes and bicycles cannot be allowed to share the same lane in any great numbers. It is crucial that the supply side wakes up quickly to the need to adopt a much more consistent and harmonised approach to the use of the ISO 20022 message standards in the -to- domain as well as the customer-to- space. Otherwise too would risk frequent traffic accidents and breakdowns.
Ruth Wandhöfer is a member of the Plenary. She also chairs the Information Security Support Group. Michael Steinbach is a member of the Plenary. Matthias Haberkorn is Programme Manager at Equens.
Related articles in this issue:
Related articles in previous issues:
Searching for Enlightenment? The new book 'ISO 20022 For Dummies' has all the answers! ( Newsletter, Issue 8, October 2010)
The Global Data Highway. The ISO 20022 catalogue of financial services messages: a progress report ( Newsletter, Issue 8, October 2010)
Going all the Way. EPC guidelines on customer reporting of SEPA Credit Transfers and SEPA Direct Debits ( Newsletter, Issue 4, October 2009)
Improving the Bottom Line. ISO 20022 meets key corporate expectations ( Newsletter, Issue 3, July 2009)
The Silent Revolution. The impact of ISO 20022 on payments services in general and SEPA in particular ( Newsletter, Issue 3, July 2009)
Take Payments to the Next Level. Benefits of ISO 20022 for bank customers: improved control and increased efficiency ( Newsletter, Issue 3, July 2009)
1In the context, a payment system in the meaning of a 'funds transfer system' is referred to as a 'Clearing and Settlement Mechanism' (CSM). A funds transfer system enables the exchange of funds (money) and messages between two executing a payment transaction. These funds transfer systems can be as well as separate business - public or private - entities (which may or may not be owned by ). CSMs are also referred to as infrastructures.
If you would like to comment on this article, please identify yourself with your first and last name. Your name will appear next to your comment. Email addresses will not be published. Please note that by accessing or contributing to the discussion you agree to abide by the EPC website conditions of use.