How European Banks Can Prepare for SEPA
For most European banks, payments processing has always been the least exciting part of the business – the scullery maid that never gets invited to the high-profile financial services ball. But with the European Central Bank persistently courting the idea of a Single Euro Payments Area (SEPA), what once was a lowly back-office function could be turning into the star of its own Cinderella story.
In response to rising consumer demand and pressure from corporate customers seeking standardization as they centralize their treasuries, the European Union and the European System of Central Banks (Eurosystem) – leaders in a family of regulators that have successfully implemented a single currency where there used to be a dozen – have called for a SEPA that lets customers “make payments throughout the whole area from a single bank account, using a single set of payment instruments.”1
The Eurosystem and the banks have set the stage for consolidation by deciding that the new RTGS system for the euro, TARGET2, will run on a single shared platform. For electronic payments that do not require real-time settlement, the Eurosystem and the European Payments Council (EPC) have already agreed on three possible schemes – the basic Credeuro, a same-day service (Prieuro) for credit transfers, and the pan-European Direct Debit (PEDD).
The Eurosystem is also recommending a “unique standard for electronic payment initiation and reconciliation,”2 implying that banks, customers and payment infrastructures in every eurozone country will have to migrate toward a single, consistent standard. That includes every international player in the European banking market, as well.
The witching hours for those transformations range from 1 January 2008, for the Credeuro, Pieuro and Direct Debit schemes to be available as options, to 2010 for the European-formats-from-one-account implementation.
Given the wide array of national clearing systems, different national practices, disparate legacy IT systems in European financial institutions and stubbornly siloed lines of business within individual banks, getting there won’t be easy. Of particular concern are customer systems, especially those used by small and medium-sized enterprises. But for now, at least, the itinerary seems set; forward-looking banks will be re-examining their current payments processes with an eye towards integrated, straight-through processing systems that add value even as they cut costs.
And there are a lot of costs to cut. The general consensus is that fees levied by the payment systems cover only 10-15 per cent of the actual cost of running that side of the financial services enterprise. The primary cause: Payment processing in back offices, where the major costs are accrued, is fragmented across different lines of business.
Successfully squeezing into that SEPA glass slipper in such a short time frame will require massive programme management and disciplined business plans. Compounding matters are the expectations that all countries will not graduate to the new SEPA standards at the same time, and that all banks and customers are unlikely to change internal applications to meet deadlines. Converters that can translate proprietary and national standards into the new pan-European standards offer an interim solution, but are a short-term patch for a long-term transition that will require parallel processing and interoperability among national and SEPA business practices.
State-of-the-art business integration middleware can act as an intelligent payments director, routing payments through various steps in the transaction cycle and invoking appropriate functionality at each stage. Typical functions might include format validation, credit checks, liquidity allocation and routing to appropriate payment systems. Middleware helps log payments from end-to-end, enabling straight-through processing that can be tracked by all authorized parties.
In addition, the appropriate middleware can help reduce development and maintenance costs by providing basic functions for routing, workflow, queueing, data warehousing, security and system management. The right middleware choice can also help banks preserve their IT investments by interfacing with legacy applications and making it easier to adapt for phased replacements.
The concept of a pan-European clearing house (PE-ACH) also is gathering momentum, but there is much confusion among schemes (defining operating rules, standards, fees), infrastructures, service providers and operators. There should be one PE-ACH infrastructure supporting pan-European schemes, underpinned by compliant service providers and operators in accordance with interoperability rules defined within the SEPA schemes.
Service providers and operators, meanwhile, may want to consider leveraging the latest grid computing technology to cost-effectively optimize resources across SEPA. Grid computing essentially joins separate computers and systems within multiple organizations, permitting them to act as a single system. Tasks and data can be distributed across every computer and storage device in the grid, not just those owned by users, and workload peaks can be offset on demand with the addition of spare capacity. Grid technology can also be leveraged for out-of-region recovery to ensure business continuity.
The answer? Unfortunately, there is no single solution that can be implemented quickly. There are, however, several critical points for banks and regulators alike to consider. Banks should take the opportunity to re-evaluate legacy systems to see if the timing is right for replacement or upgrades. Now is the time, as well, for individual financial institutions to take a second look at their existing back-office payments processes with the idea of taking advantage of the inevitable changeover to reconfigure for increased cost-effectiveness. It makes little sense to execute one set of changes to accommodate SEPA and another later on to streamline the process.
At the same time, banks should be weighing the profitability of continuing to carry out all payment processes for all payment types. By outsourcing some or all payment processes, financial institutions can often reduce costs and free themselves to focus on more profitable products and services.
Component business modelling is one way banks can determine where in the outsourcing spectrum they most comfortably fit. After defining their payments strategy in terms of product segmentation by customer and channel, banks should spend time analyzing their organization, breaking it into components. Components are groups of tightly coupled business activities supported by human resources, information systems and processes, and subject to performance measures. Once components are identified, banks can appraise them for their ability to drive competitive differentiation. Some payments activities may turn out to be dependent for cost reduction on large volume and economies of scale and at the same time offer little competitive opportunity. Those may be prime targets for outsourcing.
For their part, customers may be spurred by SEPA to reconsider their banking relationships. Many companies, for instance, maintain accounts outside their home country solely for the purpose of making local payments economically. Under SEPA, competition can be expected to increase, leading major businesses to reduce the number of banking relationships they have on the local level. Banks will need to develop new payment strategies and services to retain customers and increase revenues in the wake of lost transaction fees.
No matter how banks in the eurozone choose to read it, conversion to a single euro payments system is definitely not a fairytale. It’s factual, probably inevitable and – with the right planning and foresight – potentially profitable. Financial institutions need to start planning for SEPA early and start working with knowledgeable business partners to make sure their payments businesses live happily ever after.
1 “Towards a Single Euro Payments Area,” the Third Progress Report of the European Central Bank, December 2004.
2 ibid.
This article was originally published in IBM’s Building An Edge