For those who are not initiated in SEPA or in CSM interoperability lets first dissect the title of this post. You can find a short synopsis here on:
- What is SEPA?
- What is a CSM?
- What is Interoperability?
- The EACHA Interoperability Framework.
Almost 6 years ago (Nov. 2007) my article “Moving Towards a SEPA-compliant Infrastructure” was published by GTNews (PDF here). The article considered the challenges ahead of creating a SEPA-compliant infrastructure and how reachability and interoperability, two fundamental factors in the successful implementation of SEPA, could be achieved. It was written at a time the EPC was still in the middle of the process to establish guidelines and frameworks for SEPA.
Interoperability for SEPA payments refers to the ability for corporates, citizens and financial institutions to systematically and consistently have access to (other) payments institutions and payment processors.
SEPA CSM Interoperability between payment institutions and payment processors as a subset of SEPA interoperability, while not sufficient on its own, is essential for creating a competitive SEPA processing environment and to guarantee SEPA product qualities in case multiple parties are involved in a payment value chain.
From the 2007 article:
In order to achieve interoperability from a technical point of view, common interface specifications are necessary to allow infrastructures to link to each other easily. From a business perspective, interoperability requires common business procedures and standardisation. … Standardisation must therefore be universal and an integral element within the payment service provider-to-payment service provider and payment service provider-to-CSM environment. [Emphasis added JWM]
Reading the article again I asked myself:
- Status: “How far have we come in establishing SEPA CSM interoperability?”
- Lessons learned: “What can we learn from the developments so far?”
- Next steps: “What, if any, is still needed to realise interoperability between payment service providers as well as CSMs?”
Status
While the Payments Services Directive, shared European oversight, Target2 and the introduction of UNIFI 20022 XML are accomplished, not all key architectural elements to create SEPA CSM interoperability, as raised in my 2007 article, can be fully checked off:
- [Check, but not homogeneous enough] The EPC’s SEPA Credit Transfer (SCT) and SEPA Direct Debit (SDD) rulebooks providing for common payment products.
- [Check, but not effectuated] The ECB’s SEPA compliance framework for infrastructure and the EPC’s clearing and settlement mechanism (CSM) framework, which guarantees that CSMs will jointly realise full reach by forming a multi-party PE-ACH.
- [Check, but not widely implemented] EACHA ‘interoperability’ to allow any payment service provider or payment processor to use the same technical conventions exchanging payments with any other party.
Today, we see a lack of interoperability, standards fragmentation – so called “mini SEPA’s” – and gated communities with message sets and interfaces that are different per payment provider causing substantial externalities to all participants in the SEPA including the banks themselves.
As acknowledged by the EPC at the ECB stakeholder-meeting in April 2013, SEPA CSM interoperability is still “work in progress”.
Lessons learned
1) Insufficient level of standardisation leads to lack of interoperability
We have underestimated the dynamics causing all kinds of exceptions to the standards and the harm this is causing to interoperability. In hindsight SEPA has not been ambitious enough in creating a truly common standard or incorporating means to deviate in such a way that interoperability was ensured. The emergence of mini-SEPA’s and the deviating interface descriptions per bank and CSMs have prevented a truly interoperable SEPA from emerging.
The EPC started to recognise the need for interoperability when the ECB – alerted by signals from other market participants like EACHA – started to press for it. By then many decisions on how to create the fabric of SEPA had been made already without taking the interoperability aspects into consideration.
The EPC should have aimed much higher when deciding what should be standardised and what should be left to the market. Unfortunately, if standardisation is done inefficiently it is pretty hard to improve upon.
2) Half-baked interoperability is no interoperability
Effectively, there is no interoperability as long as setting up a link between parties in the SEPA infrastructure asks for a substantial amount of effort. The current level of interoperability is not sufficient enough.
Exchanges of payments between any two parties in a payment value chain need to be covered by legal contracts. Having limited SEPA standardisation to the technical guidelines and frameworks and leaving the legal foundation to the competitive space is hindering interoperability for all.
3) Knowledge asynchrony between stakeholders
The European Commission invited the banks to create the SEPA payments standards. It was the EC’s strong intention that this would be shaped in the interest of all stakeholders. By asking the banks to take the lead the other stakeholders have become dependent on the banks good will to indeed create an open environment in the interest of all.
Payments are complicated stuff and it is difficult for the non-initiated to see the possible drawbacks of often small and rather technical choices. With the misbalance between roles in the standardisation process, the distribution of power and knowledge between the insiders, the banks, and the outsiders, the rest of society, has resulted in an under-representation of the other interests.
As an example: if all stakeholders were aware of its implications an IBAN including a direct bank reference would never have been accepted as this effectively kills any way to create number portability. The routing argument brought forward by banks was pretty weak, as is now recognised in the discussion on the mandatory use of BICs.
What has come out of the standardisation process is arguably more in the interest of the banks than to the other stakeholders. For banks interoperability was not a high priority or seen in their individual or communities interests, for all other stakeholders interoperability is key to their interests. It is my impression that many banks still do not see common interoperability in line with their own company or communities interests.
4) Initial politically motivated choices now limit scope of interoperability
As early as 2006 the ECB recognised in its 4th Progress Report on SEPA and later on in 2007 while outlining the Euro systems’ criteria for the SEPA-compliance of infrastructures processing payments that SEPA CSM interoperability was a prerequisite for a properly functioning SEPA. Since then the underlying message of the ECB has been that reachability (‘all can reach all’) and interoperability (‘all participants use the same technical conventions for realising STP and competitive processing’) are critical requirements in developing the infrastructure for SEPA.
The focus of the ECB has been to propagate interoperability for the traditional CSMs, leaving the banks performing the same function basically out of scope. Excluding parties just because they are called “banks” instead of looking at their roles in the payment value chain as defined in the various frameworks underlying SEPA is wrong. E.g. Banks who run a payments processor role as direct participant of EBA Clearing are in fact CSMs and should be considered as such.
For political reasons – trying to become a non-obtrusive and non-threatening partner in the EPC process – some elements were left out which were originally core to the guiding principles of the EACHA Interoperability Framework, most notably: mandatory receiver capability, using the SEPA CSM topologies and covering all inter-bank exchanges including direct exchanges without the involvement of a third party CSM i.e. payments processor. Without these adaptions the initiative is crippled and the relevance of the EACHA framework limited.
EACHA, while realising the EACHA interoperability framework, has not been able to create the momentum needed with payment institutions or the acceptance by other payments processors to effectively influence the level of interoperability in SEPA.
The payments world is moving on
Since the start of the creation of SEPA much has changed in payments, more change is still to come. The playing field for payments has changed dramatically for the banks that are still channelling large parts of all the payment volumes in our economies.
In the interconnected world we are now seeing established, true interoperability – which can only be based on real end-to-end standardisation – is key to creating as little frictions as possible between the “nodes” in the network. In the dynamic and highly interconnected world payments are a prerequisite for a contribution by any individual person or company to the network (i.e. being the fabric of our society and economy). Growth in interconnectedness and technological advances is challenging all types of payment developments.
If the SEPA infrastructure does not evolve while the rest of the world is changing rapidly and adapting new technologies and concepts it will become a hindrance for development of the EU economies.
New aspects have come up that should be added to the inherent capabilities of the SEPA infrastructure, like high-speed payments, e-mandates, e-invoice, number portability, e-banking etc. Any effort on interoperability will have to incorporate these developments and all parties involved if the underlying payments infrastructure wants to remain relevant in the future. The patch worked SEPA infrastructure, as we know it today without sufficient standardisation and interoperability is not a pleasant starting point to get this adaptation going.
While running for the finish we have allowed ourselves many shortcuts but before we arrive at the finish we see it being relocated again, and now the shortcuts are going to get back on us.
In the long run it is not in the interest of banks to be stuck with a legacy network that in comparison to alternative approaches for payment exchanges will become less competitive and adaptable over time. Business models and technology are going hand in hand in this respect. But a lagging infrastructure is also creating an externality for all the companies and citizens in Europe for they could have had a better service from their banks.
Conclusions
The SEPA is not a level playing field for payment processing and CSM yet; it is not seeing sufficient standardisation and interoperability. Parts of its conception are tilted in favour of the banking communities interests.
The SEPA infrastructure is now established as it is and it is more difficult then ever to create full interoperability. Only a true open standard covering technical and legal interoperability will help to create a competitive market for CSM services by allowing payment service providers to choose the processor or processors that best meet their needs.
We can either accept the facts on the ground or take next steps:
1) Low hanging fruit: ECB, take away the EBA/EACHA divide!
Despite the ECB demanding interoperability for some time EBA Clearing does not allow other CSMs to link while their own direct participants are acting in exactly the same role, as described by the EPC CSM Framework within the EBA network based on Target2 Settlement. EBA in this sense is obstructing interoperability. As long as this divide is not taken away SEPA CSM interoperability will not take off.
2) The kingly way: Realise open standard interoperability by a new market led initiative.
From a logical point of view a market led initiative to create an open standard would be optimal for realising common SEPA CSM interoperability with all the stakeholders heard and listened to. As SEPA has learned us a bank led approach does not safeguard a balanced outcome. I expect the banks will be reluctant to take up the mantel again.
3) The realistic way: Enforce interoperability with mandatory receiver capabilities for all payments processors
The ECB and the European Commission should invoke a mandatory open standard for inter payments processor interoperability – applicable for all parties including “banks” with a CSM-role. Not for the sake of payments processors, but for the sake for us all. The cost of the current lack of SEPA interoperability to society – while not very visible to the average citizen – is high and will be getting higher when new developments in payments cannot be realised as a result of it.
SEPA needs a highly efficient – in cost, in safety, in throughput time, in adaptability – and resilient infrastructure. Interoperability, based on open standard applicable for all, is a prerequisite. The market has not been able to create interoperability; the ECB is now having the ball in their court.
(Disclaimer I was heavily involved in SEPA CSM Interoperability: being the creator of the distributed network based interoperability concept that was used as the starting point for the EACHA interoperability effort, the leader of the taskforce that created the EACHA interoperability framework and the business developer pioneering and establishing the inter-CSM connections that have built up to the EACHA network it is today.)
For further reading on SEPA at Red Planet Dust:
