Luckymodena

Full Version: ISO 20022 and Centralisation: Going Beyond SEPA Payments in Europe
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
ISO 20022 and Centralisation: Going Beyond SEPA Payments in Europe
Jérôme Cavaliero, UniCredit - 25 Sep 2013
Is the single euro payments area (SEPA) composed solely of legal constraints - as some companies may complain? Perhaps not: the ISO 20022 standard, which concerns European payment means such as SEPA credit transfers and direct debits (SCTs/SDDs) and the XML syntax, create an international standard to help corporates better organise their workflow - particularly in terms of payments.

At first sight the ISO 20022 standard and centralisation might not appear a natural match. The first is a financial industry standard, the second a workflow organisation scheme within corporates. This following will attempt to illustrate how this norm can generate significant gains for users when accompanied by an evolution of payment management.

Benefits of Using ISO 20022

The ISO 20022 standard provides a method to develop well-structured financial messages in the five areas of cards, foreign exchange (FX), payments, securities and trade services. More than 300 ISO referenced messages exist which help unify all existing standards. ISO 20022 uses the extensible markup language (XML) standard, which allows easy reading by a large number of softwares - not only in a financial environment - and quick upgrades.

Several messages exist; they are called business areas, such as:

•Securities trades (setr).
•Securities settlement (sese).
•Trade services management (tmst).
In the payments industry four such messages are used; the first three of them between banks and their customers:

•Payment initiation (pain).
•Cash management (camt).
•Account management (acmt).
•Payment clearing and settlement (pacs).
Heading Towards Payment Centralisation

We now have in our hands a unified international standard, as the first step towards homogenous use beyond purely domestic corporate operations. The first use that comes to mind is obviously for SEPA payment services - it allows a first level of centralisation as, theoretically, any third party payment in the SEPA zone can be issued from a single account.

A further three major stages of centralisation can be introduced within organisations:

•Placing common resources within a shared service centre (SSC): Other departments in addition to accounting or treasury may then be impacted.
•Centralising payment flows: Payment files are created locally but go through a payment hub, controlled by central treasury before payments are initiated on local accounts (some already call this a payment factory).
•Centralising payments via a payment factory, where everything is managed centrally: This would include files creation, payment workflows, orders sent to banks to initiate payments on accounts held by the bank in for paying-on-behalf-of (POBO) the group’s other entities.
There are many advantages to such organisations:

•A homogeneous way of working at group level, which lowers risks linked to the use of various payment and signature means in each structure or country.
•Better management of workflows.
•Improved management of payment dates and reduction of working capital.
•Harmonised and reduced banking fees.
•Better liquidity management at group level.
Such centralisation is only achievable through the use of ISO 20022 messages (possibly an honourable mention should also go to the Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT) but that standard was never adopted by enough companies and payment factories to become a common service). ISO 20022 messaging allows the initiation from a central and unique point ‘on behalf of…’ messages such as SEPA credit transfers (SCTs), cross-border payments, intra-company payments or even domestic specific ones such as for Virement Commercial in France. Collections can also be considered, thanks to SEPA direct debit (SDD). Some banks already offer such services, or are preparing to launch a major offering.

Offering Quality Reporting

This is an important issue - initiating and sending payment orders remain ‘simple’ operations to process, insofar as any international bank should eventually be able to offer such services. Major challenges lie, however, in offering quality reporting that will allow easy and automated reconciliation.

Central treasury must receive, without delay, detailed and reliable information on:

•How their order is being handled, via payment status reports.
•Rejected and/or unpaid operations.
•Account reporting;
Nevertheless, there is a genuine risk that a reporting message may be truncated at some point by a bank when going through its information systems, so the integrity of the information is then no longer assured. This issue certainly occurs in case of POBOs as the payment factory must impact the current accounts of the group companies and cannot afford time-consuming manual reconciliation.

In such cases, banks should already offer payment system risk PSR policy (pain.002) or unpaid items files (camt.054); although relatively few have yet developed camt.053 account reporting (camt.052 for intraday account reporting). To take France as an example, local Comité Français d'Organisation et de Normalisation Bancaires (CFONB) format was adapted to suit SEPA reporting needs on domestic accounts, SWIFT MT940 (or MT942 for Intraday) being used for reporting on the other accounts. When using SWIFT messaging it will be necessary to check if the account holding bank enriches the messages and correctly transmits useful information.

Future Benefits

Obviously setting up such services and processes is not without its risks.

First, it appears very complicated to bridge between a unique international standard and a completely homogeneous format accepted by thousands of banks. Indeed, if we take the SCT as an example, several steps occur between the ISO standard and the format accepted by the banks, among which are:

•European Payments Council (EPC) rulebooks.
•National banking communities’ implementation guides.
In addition, each bank’s processing organisation may potentially alter the information integrity and then not answer its customer needs, for example on the processing aspect : a cross border bulk payment request in XML pain format is split into MT101 messages at back office level and can only be reported per payment and not as batchbooking.

We can now not only imagine but actually perceive the looming benefits for organizations that centrally initiate their payments. The combination of multi-banking communication protocols such as SWIFTNet for Corporates and an international ISO 20022 standard represent true steps ahead for a more efficient workflow management and convert the constraints of moving to SEPA into opportunities. However, only deep and lasting cooperation between corporates and their banks will ensure the success of such projects.
Reference URL's