UK banks have to do quite a bit of work to support SEPA. Furthermore, they have some options which go beyond “complying” with SEPA to exploit it. To explain this we have broken this article into four parts:

  • What’s SEPA?
  • What do UK banks have to do as a minimum?
  • What are the banking systems and operations challenge this represents?
  • What does SEPA solution architecture look like?
  • What are some of the opportunities presented by SEPA?

What’s SEPA

SEPA stands for Single Euro Payments Area and is a desired condition, at least desired by European Union politicians and leaders. The underlying aspiration is to make Europe a single market and SEPA is intended to address one of the inhibitors to that end, namely the difficulty in making cross border payments within the EU.

The current condition is that to make a low value electronic payment within most European countries costs a few cents (e.g. via a credit transfer or a direct debit). The same value payment, in the same currency, (e.g. 90 euros between Spain and Germany) but across a national border costs many euros, hundreds of times more expensive.

This is because the low value inter bank payment systems are unique to each country and thoroughly incompatible. (See “How can we make substantial cost reductions to Europe’s payments”.) Frustrated by the lack of “natural” or “market driven” solutions to this problem the European Union has decided to legislate to force some innovation.

The intent of the SEPA legislation is to oblige every bank to make it as cheap and easy to make a cross border credit transfer/direct debit as an in country credit transfer/direct debit. The European legislation embodying this intent is the Payment Systems Directive (PSD), which also legislates about various other payments related ideas. This in turn has to be incorporated into the legal and regulatory frameworks of each member country. In the UK this will be incorporated into FSA rules.

What do UK banks have to do as a minimum?

Surely they don’t have to do anything as they are sterling based? Wrong!

Just because the UK economy is non-euro based does not mean it escapes (neither do Sweden, Denmark nor the new accession countries). This is because the Payment Services Directive, FATF and SWIFT changes mean a UK bank ought to consider SEPA “while it is under the bonnet”. (The exchange rate issue does create some complexities that the euro countries do not have).

The impression we at HBW have is that for a UK bank, the bank should consider offering its customers:

  1. an ability to make a direct euro credit, at UK domestic credit prices to any country in the EU. (The FX rates, fees and associated margins are not specified).
  2. an ability to receive and process a direct debit claim in euros from any country in the EU; again the FX, fees, rate and margins are not specified.

Both of these options will be available by January 2008 from other banks.

Additionally, under what is called the SEPA Cards Framework (SCF) there is a drive to standardise the interface between Merchants and Merchant Acquirer (click here for an explanation of what a merchant acquirer is).

The issue that is bothering the European Payments Council is that the interface between Merchant and Merchant Acquirer (e.g. message and file formats) is standardised in each EU country but there is generally a different standard in each country. This means that the market for Merchant Acquiring Services is limited to each country, contrary to the single market idea.

What exactly is to happen and by when is not yet clear but it is likely to require major change to the Merchants’ and Merchant Acquirers’ systems. HBW will watch this space and provide an update when more is known. The rest of the article is dedicated to the more clearly defined Credit Transfer and Direct Debit schemes.

What are the Banking Systems and Operations Challenges that this represents?

The diagram below illustrates the typical systems architecture for a UK bank today.


sepa diag1


The points the diagram illustrates are:

    i) The SWIFT based world of CHAPS and currency payments is message based, mainly real time and highly manual in nature (hence the dotted line around the CHAPS and currency boxes showing human operational activity).
    ii) The domestic low value payments world is file based, batch based, usually tightly tied into the domestic accounting systems because of clearing cycles with very little human intervention.
    iii) The domestic low value payments are not connected into the currency accounting systems and so currency accounts (i.e. a bank account denominated in something other than sterling) usually do not have direct debits, standing orders or credit tranfers (other than those credits based on SWIFT payments via correspondent banks).

The practical implications of SEPA given this architecture boil down to

    1. From the domestic accounts and the euro accounts a cheap mechanism has to be found for processing euro credit transfers to other EU banks. One solution might be just to cut the price of SWIFT euro credit transfers. This however is unappealing given the manually intensive (i.e. expensive) nature of current SWIFT payments. Furthermore, the SWIFT payment service is generally “better” than that required by SEPA including advices and a same day capability. For Domestic payments the cost of processing is reduced by having much of the data relating to the payment already stored, (e.g. Standing order Mandates databases or Credit Transfer Mandates) set up and maintained by users themselves via internet or telephone banking.
    2. Receive and process euro direct debit mandates and claims from other European banks against both sterling and euro accounts. This is fundamentally new technology in several senses.

    • The bulk of UK banks do not have a capability to process and store direct debit mandates against currency accounts.
    • The direct debit systems for sterling accounts cannot process payments in anything other than sterling. Furthermore they are based on different cycle times to those suggested for SEPA.

The result of these changes could be quite major IT spend.

Another important feature of SEPA is that of “reach”, i.e. that a payment can be made from or to any European country.

It is unlikely that most UK banks will develop bilateral relationships with a payment provider in each country so they are going to look to someone to be their prime provider of SEPA payment services. It could be another bank or it could be a new figure emerging on the European payments stage, the PE-ACH. (This stands for Pan European – Automated Clearing House).

In either case a UK bank is going to have to develop a new strategic relationship to fulfil its payment obligations.

If a UK bank has subsidiary bank in a euro zone country (e.g. Ireland, Spain or France) and that bank runs on a common software platform with the UK parent then there is additional work that needs to be carried out.

What does the SEPA solution architecture look like?

It is not at all clear what will happen. At HBW we believe the solution will look like the diagram below.


sepa diag2


The key requirement is reach; i.e. getting to all European countries from a particular bank. The main elements are likely to be:

    (i) A Central European ACH, probably based on the EBA STEP operation. This will offer services as a central switch to both individual banks or country based ACH’s.
    (ii) Country based ACH’s will probably develop an option that would allow banks to re-use some of the existing software and interfaces that they already have to the country based ACH; e.g. VOCA in the UK.
    (iii) Individual banks will have to choose whether to interface directly to a Central European switch or to a local ACH which in turn connects to the Central European ACH, or a mixture. For example a UK bank with European subsidiaries may choose to plug into a number of local ACH’s.

What are some of the opportunities presented by SEPA?

Payments volumes are growing and cross border payment volumes particularly so. In addition to the payment fee income, banks make money out of the closely connected services such as:

  • Electronic Banking Services
  • Current Account Balances
  • Overdraft Facilities

For most commercial banks, these services are the core part of the relationship with their customers and so finding ways of winning market share for these services (or avoiding share loss) is very important to them.

If a bank has a good SEPA offering then it could be attractive to UK companies with European subsidiaries; for example enabling them to centralise their supplier payments and payroll processing to cut costs and improve cash management.

Similarly, UK banks with US subsidiaries can sell a better payments solution to their US corporate customers who need to make payments in Europe.

Finally, UK banks with European subsidiaries may be able to save costs by consolidating their European payment operations and systems.

The converse of these opportunities is that a UK bank may lose market share to other UK (or European) banks who offer a better SEPA service.

European subsidiaries of a UK bank

The European subsidiary of a UK bank will have to behave like any bank within the eurozone. What SEPA means for these banks is firstly, as for UK banks, they must provide:

    1. an ability to CT by January 2008
    2. an ability to receive a DD claim by January 2008

They must also provide a direct debit origination service that allows a Direct Debit originator to create direct debit mandates according to SEPA scheme rules. These will almost certainly be different to those they currently use (days in the cycle, file formats, liabilities in the event of a claim rejection etc.).

Furthermore, euro country, banks have to migrate the bulk of their direct debits and credit transfers off their domestic schemes to the new SEPA schemes by the end of 2010. (The UK can continue with BACS indefinitely.)

This migration is a big challenge for Direct Debit originators and high volume corporate payers such as Payroll Agencies. If the European subsidiary of a UK bank has these types of customer, it will be the bank’s responsibility to persuade them to change their (the corporate’s) systems to the new formats.