For SEPA and Beyond, the Key is Integration
It’s not quite so fashionable to talk about the single euro payments area (SEPA) these days. As we near the end of 2010, aren’t we all wishing the rules and solutions were all defined and implemented, and that all transactions were processed as SEPA Credit Transfers (SCT) or SEPA Direct Debits (SDD), as appropriate? Of course there are many reasons for this, such as a spate of mergers and acquisitions (M&As) following the 2008 crisis, lack of an enforced end-date and, of course, the simple fact that modernising payments processing is in fact incredibly difficult.
Much of the SEPA focus to date has been on bank compliance and the effect of the new rules on banks and payment processors, but the industry has been less focused on delivering the value proposition to corporate clients or consumers. In fact, the overarching Payment Services Directive (PSD) is primarily aimed at regulating the banks and processors in the payments industry. However, one must also question the basic business case of SEPA, because the ideation did not include all affected participants in the payment value chain.
By summer 2010, some 30 months after the SCT start date, about 9% of payments within the EU were processed as SEPA transactions. Although an improvement of about 5% in the past year, the low usage appears to be a result of a disconnection between the technical compliance with SEPA for processing and the delivery of SEPA products to clients (who are not mandated to use SEPA solutions).
Although the PSD is forcing regulatory change, the ability of banks and national payments associations to define and implement the required business and technology models has been challenging. In part this is clearly due to the shifting sands of processing rules, standards and fee structures, but there is still a fundamental challenge that banks (and corporate treasuries) face: integration of proprietary and standard data formats among legacy and modern systems.
To make SEPA a universal reality, banks must look beyond SEPA as a compliance initiative and think more about the future of payments processing and the demands of internal operations groups and external clients. This perspective allows banks to focus on broader modernisation of which SEPA is a part, rather than working toward SEPA alone.
Outside the broader issues affecting the payments industry, ongoing integration and standards implementation is one of the largest technical challenges. Payments by nature are a transaction type with a lifecycle spanning multiple internal processing steps and applications. There are applications for delivery channels, compliance screening, account posting, settlement instructions, transaction routing and foreign exchange (FX), to name but a few. Rebuilding these infrastructures that evolved over many years takes a significant amount of development effort to implement and manage.
Payments hubs are still often discussed as a solution, but the reality is that, even after several years of industry discussion, few banks have implemented a payments hub to address SEPA. A hub is still valuable as banks strive for efficiency and cost savings. A hub can help centralise common elements of processing to break down the silos and simplify operations. However, the effort involved to implement a hub strategy is considerable and can make these projects very daunting and costly (especially if no existing payments application is replaced and there are no resulting cost reductions). Whether the modernisation strategy is to enhance the workflow among legacy applications, or implementing a hub to centrally manage payments, integration of applications and the accommodation of changing formats (even in a SEPA world) is a fundamental challenge.
A complementary approach gaining industry momentum is to create a modern, consistent architecture framework to surround legacy systems with new processes and services, enabling the gradual replacement of legacy formats and systems. This framework should support interoperability with multiple technology platforms, and the new standards being developed for payments and banking. Initiatives from bodies such as the International Organisation for Standards (ISO) with the ISO 20022 models, and Banking Industry Architecture Network (BIAN) are firmly aimed at supporting interoperability to streamline processing and improve efficiency. Such a framework is a means of managing the flow of SEPA transactions between new and legacy components, enabling banks to start on a technology renewal path in a phased approach, with or without a hub.
The topic of payments system integration has in the past usually dwelled on topics such as real time or batch requirements, message queue interfaces and, of course, support for payment standards. All these are very important in any payments integration project, whether to support implementation of a new payment system, or the renewal of infrastructure technology. If one listens to financial institutions wrestling with payments modernisation, a recurring theme appears in discussions about integration: simplifying the ‘plumbing’ and the need to know more about what is happening in the environment between the applications.
With the techniques offered using service-oriented architecture (SOA), it is possible to develop reusable services or components to simplify the amount of custom engineering required to implement an integration framework. The goal is to provide the right balance between a flexible toolset and the need to have pre-built payments integration components that streamline the development effort. Using an enterprise service bus (ESB) architecture model, banks can create reusable services for common payments integration functions, such as transformation, audit trail and business activity monitoring (BAM). The result is reduced complexity of solution and integration costs, and the ability to centrally monitor activity ‘between the applications’ for the lifecycle of the transaction.
The value of ISO 20022 is much more than ‘just another payments format’. Payments vendors recognise the architectural benefits of ISO 20022 in the design of their payments applications. Leading integration software products also allow for integration among internal systems but also to SWIFT. Top solutions bear the SWIFT Ready Financial EAI label for an enterprise-wide integration capability. These solutions should also be XML and ISO 20022-capable. The combination of ISO 20022 functionality and its use in central payments product development means that the technology is generally available today for deployment in virtually any geography, therefore enabling the implementation of an XML bus in banks and corporate treasuries for payments and cash reporting. Ideally, the goals of such projects should not merely to be to achieve ‘SEPA compliance’ but to further develop an architecture for efficiency and the future of payments processing, of which SEPA rules are just a component.
What is the benefit of an approach like this? Banks can embark on a broader payments technology renewal programme, yet also retain the flexibility to adapt to future rule changes mandated by SEPA and the PSD. Regular changes in format definitions must be expected, so ongoing management and implementation of this will be a challenge. Banks will need a process and mechanism in place for updates, just as they do for SWIFT formats today. Any banks that have implemented SEPA format requirements through hard coding will experience maintenance challenges in the near future. What is needed is a solution that allows rapid adoption and deployment of a message pack to ensure compliance with the new rules.
Furthermore, a ‘big bang’ wholesale replacement of payment processing applications is no longer required. Because the integration framework uses common message flows and universal data structures, transaction flows can be developed and implemented in phases as new systems and payment schemes become available and old applications are retired. This benefit applies to SEPA initiatives and more importantly broader payments activities because of the universal nature of XML and ISO 20022. This includes the ability to use these techniques in countries outside Europe because ISO 20022 has an intrinsic value in any region.
In conclusion, the combination of disruptive economic market conditions in the banking sector, ambiguity about the customer value of SEPA, the sheer complexity of the undertaking, and the lack of a defined end-date for compliance have all conspired to disrupt harmonisation of payments. Implementing XML integration frameworks is a strategy that allows banks and treasuries to build for the future, but it is still a considerable effort that banks are hesitant to embark on. However two events may well drive greater adoption: the ability smoothly to manage and deploy anticipated SEPA format changes and the setting of a hard deadline for SEPA compliance.