Technology in a Post-SEPA Age
Over the next two to three years, banks’ payment services face their largest ever technology challenge. This rather sweeping statement may have been said about the euro or Y2K but now it is being used to describe the introduction of the single euro payments area (SEPA). Banks must adapt their payments systems to enable customers to make euro credit transfers using a single standard message from January 2008. While such hyperbole might be dismissed as scaremongering by over-eager consultants, it is the banks’ own technologists – and heads of payments services – that are daunted at the scale of the changes that SEPA will herald.
In fact, SEPA represents two technology challenges, the combined cost of which will force banks to reconsider their future role in the payments market. The first challenge is that of ‘reachability’, i.e. putting together the clearing and settlement network to ensure a bank can send SEPA credit transfers to and receive SEPA credit transfers from any counterparty. Early movers will be able to offer payments services across Europe, while defending their own established markets from new entrants, thus achieving significant competitive advantage. But this requires banks to overlay existing clearing infrastructures with SEPA-specific arrangements, then – once legacy instruments disappear and local ACHs consolidate in four to five years’ time – collapse these arrangements into a single streamlined network.
The second challenge, and perhaps SEPA’s real significance, lies in the fact that the launch of the SEPA credit transfer is the first mandatory use of the XML-based ISO 20022 message format developed by banks with UN CEFACT TBG5, the UN standards organisation for financial services. Corporates are keen to exploit XML’s potential as a flexible, universal message protocol across the supply chain, SWIFT has created a new series of XML-based message types (carrying the MX prefix), and banks already use XML messages to facilitate automated exceptions and investigations via SWIFTNet. But today’s interbank payment traffic is almost exclusively carried by the same FIN-based MT messages introduced by SWIFT over 30 years ago that banks’ current systems were originally designed to process. To fully utilise the XML messages, banks’ payments platforms will have to be replaced or re-engineered; a long-term process that will require interim stages and a multi-year investment programme.
In short, SEPA requires banks to adopt a new technology that will pave the way for greater functionality, efficiency and competition, but it will also mean thinner margins. Banks that have already begun to make the necessary technology and infrastructure investments to support the delivery of differentiated payment services across Europe will command a greater share of the single payments market, leaving slim pickings and stark choices for the rest.
However, SEPA is only the first wave; SWIFT intends to begin retiring MT messages in favour of MX messages from 2012. This shift will hasten a clearer distinction between banks that see European payments as a strategic part of their business, banks that will only invest as much as is necessary to offer a basic service and banks that will decide to outsource.
Why will XML be a tipping point for the payments market? XML messages carry more data than MT messages and can offer richer functionality, higher levels of STP and more efficient routing between systems. But because banks’ systems were built to handle leaner, lighter MT messages, they must be adapted to utilise the extra data and new fields. The ISO 20022 message standard includes more than 900 fields and existing systems (from payment initiation to back-office to reporting) need to adjust to the increased data load.
The migration to XML will initially require use of translation tools that enable banks to process the new data-rich message types while simultaneously adapting their systems to utilise the data carried by the XML messages, thereby bringing new levels of functionality to clients. For example, SEPA requires banks to transmit detailed remittance data to the end user, but this cannot be done without major change to back-office systems. And the greater the number of legacy systems involved in a banks’ payment infrastructure the greater the XML migration challenge. Given the wide variations in Europe’s national direct debit schemes, it is perhaps a source of relief that delays to the Payments Services Directive mean that banks will not have to introduce the SEPA direct debit instrument at the same time as the SEPA credit transfer.
Rather than a big bang approach in which all banks and their clients can fully utilise SEPA credit transfers from January 2008, the advances in functionality will filter out to the market in line with each bank’s ability to adapt systems to the new message types, itself a function of a specific set of business drivers. However, SWIFT’s own timetable for retiring MT messages means there is little time to ponder the migration process.
Based on a clear understanding of revenue objectives and client priorities, banks are considering whether future payment volumes can justify new investment as profit margins continue to fall. For many banks that are not already processing high volumes, the choice is between an investment strategy to secure new business and outsourcing.
When assessing outsourcing partners, banks should look not only for the scale, expertise and infrastructure to process payments, but also the technology and service capabilities to support a flexible service offering. This must include well-defined on-boarding processes, a flexible platform that can facilitate a range of services and exploit new technologies, high-volume processing to support competitive pricing, and strong problem-solving and customer service capabilities. An increasingly important factor is resilience. While much of the banks’ investment in payments systems is aimed at delivering to clients, regulatory pressures are continually raising the bar in terms of performance, availability and resilience.
For a bank’s payments infrastructure to respond to multiple threats to business continuity, investment is required to ensure that there is no one ‘single point of failure’ in the payments process. For example, it is not sufficient to have back-up capabilities in place that can seamlessly take responsibility for critical processes; these must be located sufficiently remotely from the main operating site to ensure they are not impacted by the same power outage or terrorist attack.
At present, there are two broad options for banks looking to outsource payments. In the full outsourcing model, the client bank ‘white labels’ the services of the payments services provider and utilises its full infrastructure while retaining control of its client relationships. This involves a great deal of integration between the systems of the client bank and the payments services provider, but does replace the need for virtually any future separate investment in payments infrastructure.
An alternative is the extension of the common practice in which banks leverage their partners’ clearing and settlement arrangements, e.g. via third-party CLS or ACH memberships outside home markets. Certainly, for banks that would rather avoid the time and cost of maintaining multiple clearing and settlement networks during the upcoming period of uncertainty in which SEPA and local instruments will be used in parallel, access to the clearing infrastructure of a high-volume payments bank has considerable appeal as it enables the bank to direct budget to where it is most effective, i.e. delivering differentiated services to target clients.
While this approach can minimise the cost of the clearing infrastructure required for SEPA, it will not deliver to clients the full functionality available from the XML message formats unless the outsourcing provider and the client bank can both support the range of fields utilised in the ISO 20022 message standard. As such, banks must decide on the kind of payments service they wish to provide to their target clients and make partnership arrangements accordingly.
Of course, SEPA and XML are far from the only industry-wide changes requiring technology investment by banks. European banks that are currently direct members of national RTGS clearings must either invest in migration to TARGET2 or establish alternative means of routing high-value payments. Because TARGET2 uses an established technology infrastructure, migration is less complex than SEPA, but it does offer a pause for reflection for banks that may wish to reconsider whether the ongoing infrastructure and liquidity investment required to participate in an EU-wide RTGS is consistent with their growth plans and client requirements.
In addition, anti-money laundering and counter-terrorism measures (e.g. OFAC checks) across multiple jurisdictions will continue to oblige banks to enhance KYC and risk management capabilities, while the UK’s faster payments initiative demonstrates that investment is still required in national as well as regional payment infrastructures.
The global payments market is moving to a more standardised, streamlined environment and SEPA’s XML-based pan-European message formats are just the first wave. The technology investment required to deliver differentiated services in this market is substantial given the changes required to fully utilise the potential of XML messages. Moreover, the wafer-thin margins that banks will be able to charge for core payments services mean that only high-volume payments providers can be profitable in the long run. Partnering with large-scale providers that are able to make the necessary ongoing investments in a flexible payments platform may be the most effective way to deliver a premium payment service in the future.