SEPA Integration at the Corporate Level

The payments industry can prove very frustrating for
corporations, especially for those doing business internationally. Sending
cross-border payments has traditionally been a slow and expensive process, so
the initial reaction to the single euro payments area (SEPA) project should have
been very positive.

SEPA promised simplified, cheap and fast
payments in the euro currency throughout its 32 European member states. In
theory, it should have been a gateway for efficiency projects as it consolidated
payment streams and liquidity management into one location, facilitating the
creation of payment service centres (SSCs), or payment factories. Instead of
using multiple banks in the different countries SEPA offered the possibility of
only one bank connection for euro payments.

A mandatory
implementation date for SEPA was seen as unnecessary. The thinking was that the
changes would happen by themselves and the old systems would fade away. So what

At the corporate level, especially at large corporations,
SEPA received no more than a lukewarm welcome. Companies recognised some of the
benefits with SEPA, especially regarding centralisation of payments, but they
also knew that in order to take full advantage of them a much bigger commitment
was required than just becoming SEPA compliant. That meant high development

The first set of questions related to whether or not SEPA
would actually become a reality. Without an end date, by which all euro
transactions had to be SEPA compliant, and without a firm decision on the actual
SEPA standard, it was just not prudent for corporations to change their payment
systems and processes. Instead corporates adopted a ‘wait-and-see’ approach.
While the conditions remained unclear it was just too risky for corporations to
begin costly projects for SEPA, especially in a post-financial crisis
environment from 2008 onwards where cost cutting was still high of the

Necessary Steps

The next set of concerns related
to the existing payment systems and what needed to be done simply to comply with
SEPA. Its three main elements – international bank account number (IBAN), bank
identifier code (BIC) and the ISO 20022 XML format – were clear and needed to be
addressed. The main focus was on obtaining, managing and storing the IBAN and
BIC information, especially related to existing systems capacity.

Other questions focused on the remittance information. With only 140
characters available in a SEPA payment the practice of combining the information
from multiple invoices into a single payment was not possible. For a corporation
that normally combines the information from 50 to 100 invoices in one payment
this restriction threatened to cause problems and higher costs, despite the low
transaction cost for a SEPA payment.

With SEPA direct debits (SDDs)
there were concerns regarding the uncertainty of management and storage of the
SDD mandates. It was unclear whether existing mandates would be valid and if a
corporation would be allowed to outsource the management and storage to a third
party, or if a storage facility had to be created on site.

The bottom
line at the corporate level was: How much needed to be done and when, and how
much would it cost?

Mandatory Requirements Spur Action

Given all the uncertainties it was clear that implementation work would not
start until there were actual legal requirements to do so. In effect, mandatory
SEPA compliance demands became the starting point for most SEPA projects. A
prime example of such a demand can be found in Finland.

Finland had,
as the first nation out of the 32 SEPA countries, decided that all euro payments
within the country had to be processed in the SEPA format by 31 October 2011,
after which date the old payment formats would no longer be valid. The short
timeframe created a sense of urgency among corporations in either becoming
SEPA-compliant or facing the risk of interruptions of certain payroll payments.

When working towards compliance, but not attempting a complete
overhaul of the payment structure, the focus will be on upgrading current
systems and processes. Mapping the current set-up is crucial and will highlight
which systems need to be updated or replaced. The level of effort and cost of
updating current systems and bank software varies from one corporate to another.

Depending on the counterparty bank, a payment system update for SEPA
compliance can be as simple as downloading new software and providing new
security readers. Training of operational staff is, in these cases, fairly
simple as the systems are familiar and the updates usually only includes extra
features. In other cases becoming SEPA-compliant may be more complicated and
require more resources. It all depends on the corresponding payments provider
and what kinds of systems are being used.

What is important to
remember is that even if the actual update is fairly simple, setting up travel
arrangements, meetings, software updates, training sessions and test runs all
take time. Scheduling these events and finding times suitable to all
participants can prove to be a big challenge, something that can make projects
take longer than expected. This potential needs to be included in the

Besides updating existing payment systems a SEPA project
also needs to address the data and the format on the internal systems. This can
prove to be more complicated as the work may involve more and bigger customer
relationship management (CRM) systems and other storage facilities. Conversion
of existing account numbers to IBAN can usually be provided by most banks, but
then on an account-by-account basis. For a corporation with thousands of
vendor/customer/employee account numbers this can be a much more challenging
task. Using an external conversion service can be an option but this can be
expensive and not necessarily 100% accurate.

A big challenge for
corporations is the ISO 20022 XML format. To convert current systems and data
requires extensive IT resources. Due to the complexity of these tasks initial
pre-studies have indicated the implementations could be quite expensive. Many
corporations use internal billing between different departments and it is not
always clear which department should be responsible for the cost, either to the
internal IT department or to an external IT provider.

At the time
SEPA costs may not have been budgeted for, which lead to further uncertainty as
to the best course of action. Corporate senior management may not want to take
the cost described in a pre-study and may instead suggest other, less expensive,
solutions. To further research alternative solutions requires additional time,
extending the life of the project.

Challenges Remain

first thing that comes to mind on a SEPA project is that there are a number of
challenges to overcome. SEPA could – and should – be a fantastic product that
facilitates efficiencies, cost savings and economic development in the region.
The main obstacle before the decision of hard end-dates was the general
uncertainty surrounding the entire project. There were also uncertainties
regarding the limited space for remittance information, additions like
Additional Optimal Service 2 (AOS2) watering down the standard, and questions
regarding changing BIC information requirements.

These factors made
decision making at the senior level of corporations very difficult; hence the
resulting ‘wait-and-see’ approach. Once the hard end-dates were decided there
was a relatively short time frame in which corporations had to achieve
compliance. There did not appear to be enough time to make a major overhaul of
the payment systems, necessary to develop payment service centres or payment
factories that could fully benefit from SEPA. At the end, on the corporate
level, the focus was on how much needed to be done and how much would it cost,
especially when just aiming to be compliant without seeing any clear benefits. 


Related reading