Considerations in the RFP Process for SEPA Services

The migration to the single euro payments area (SEPA) began at the end of January 2008, when the countdown clock first began ticking for legacy domestic euro clearing systems and processes. In March 2012 this year, the European Commission (EC) at last gave payment systems providers (PSPs) and users in corporate treasurers, banks and elsewhere clarity on when this countdown would finally end. Regulation 260/2012 was introduced in response to a demand from businesses, governments and banks for an end date (or, more accurately, the beginning of SEPA) for the migration process to finish and it set a 1 February 2014 completion date for eurozone countries and 2016 for non-euro European Economic Area (EEA) states. The ruling enforces the transfer of bulk, euro payments and affects the vast majority of credit transfers and direct debits and their local equivalents, introducing harmonised SEPA solutions, with certain exceptions for ‘niche’ instruments such as local tax payments merely extending the deadline.

To be clear, all these types of payments in the eurozone must be replaced with SEPA-compliant clearing by 1 February 2014, with non-eurozone countries, such as the UK and Sweden and niche payments, getting a reprieve until 31 October 2016. Specifically, the regulation also imposes technical requirements on users and providers of euro payment services, such that by 2016 all bulk payments can be made only with Internal Bank Account Numbers (IBAN) data – not Bank Identifier Codes (BICs) – and they must use the mandatory modern ISO 20022 messaging format.

The implication is that anyone making payments in euro across and into the SEPA zone will be affected, from the systems they use to the stationery that they send to their customers, citizens and suppliers. At a minimum, businesses will be impacted in the following areas:

• Business systems: for example, enterprise resource planning (ERP), customer relationship management (CRM), accounting, payments solutions, etc.
• Processes: for example, customer acquisition, payment exception, data validation.
• Customer interfaces: for example, websites, the branch office counter, customer support, etc.
• Payment services and providers: for example, credit transfers, banks, clearing mechanisms.

Corporations must therefore consider two things before starting a SEPA compliance request for proposal (RFP) process:

1. How big is the scope of the project.
2. How much time long do you have to select a payments provider, before joining the end of a long queue of similar companies and government departments all waiting for compliance assistance as the deadline nears?

In order to  have tested systems and processes and be compliant by 1 February 2014, most corporations should have already initiated projects this year or, at the very least, be sending out and RFP right now.

Precursors

Before a corporation can start to select a provider it is important that they know the scope of the SEPA compliance project they are trying to achieve. It may in some cases be possible to complete a number of components internally so articulating what is in internal requirement and what is requested externally is vital to ensure that nothing is missed.

A checklist of questions and activities to be resolved before engaging external companies is listed below:

1. In which countries does the business operate and to which nations and from where does it make euro payments? Treasurers should consider which lines of business are affected.
2. On which systems do those lines of business rely?
3. Who are the stakeholders for payments for those businesses?
4. Which deadlines affect which operations? (e.g. February 2014 Vs February 2016).
5. Is the business need merely to comply or is consolidation of euro payment accounts desired to achieve extra efficiency benefits?
6. Is the business case based on business-continuity only, or on expected return on investment through streamlining and centralisation efforts, such as the establishment of a shared service centre (SSC)?
7. Is the project aimed to be a single cut-over date or will it be phased in by country, line of business or by business system?
8. Have you investigated your banks or PSPs services relating to SEPA migration?
9. Through which business systems does the payment information flow: website, line of business, payments/treasury, bank interface?
10. In what bank account formats are you currently initiating euro payments from each payment system,? For example using Basic Bank Account Numbers (BBANs), IBANs with BIC, or IBAN only processes.
11. Which payment file formats are you currently using with your PSPs: local format (e.g. ClieOp in the Netherlands), non-country-specific (e.g. XLS, CSV, MT103 and iDoc) or standardised ISO 20022 as desired
12. What percentage of your receivables are direct debit collections?
13. Are your direct debit mandates stored in electronic format?
14. Which processes are affected by the change including: customer acquisition, payment initiation, payment exception, reconciliation, dispute resolution, etc.

When you know the answers to these questions, you can start to scope the RFP.

Project Description

Once the above questions have been answered, it is then possible to scope the RFP and identify which organisations might be able to help achieve compliance via outsourced PSP offerings or technology solutions. The following sections assist in identifying the project plan so that responding providers understand what components the treasury requires.

Scope 
As previously said, articulating the scope is probably the most vital part of the RFP. It is important that the overall size of the problem should be discussed, including the countries covered by operations, the volumes of payments made and the number of banking relationships. If a corporation has a complicated legal structure, this may also be relevant. It is also important to outline the high-level goals on a spectrum of achieving simple compliance to a complete payments system overhaul: is it necessary just to do the minimum to comply or is rationalisation of euro accounts and payment systems also necessary? In the latter case, this is a more demanding goal, both of internal and external resources and should be undertaken as soon as possible to ensure completion before the mandatory deadline.

Requirements
Organisations should consider which parts of the SEPA compliance project are out of scope for external contractors, for example updating customer-facing stationery is normally an internal activity but it would be possible to outsource it. In some cases the business will not have decided on whether a single component is part of the RFP and wishes to understand how providers must help. In this instance the requester should make this clear as an optional requirement, such as whether the service provider will contact customers to obtain IBAN data or whether the business plans to do it itself.

Potential benefits
There are potential benefits from SEPA which should not be overlooked although time-constraints may mean that these cannot be realised before the end of the migration. Some organisations have made the migration to SEPA profitable, or at least cost-neutral by optimising their use of payment services, consolidating their accounts and relationships and centralising payment functions. This generally tends to be part of a bigger project and a number of businesses have taken advantage of SEPA as a reason to do this. For information on how Levi Strauss did this as part of a SEPA migration, a case study can be found here.

List of providers
A corporation should take advice from its existing banks and PSPs, software providers and consultants to make up a full list of its partners. In addition, it should be open to extending that list if one of its partners can make a good case for inclusion.

Key Components of an RFP

Any RFP must understand that a single supplier may not be able to fulfil the needs of a corporation on its own and as an example, banks have partnered with organisations for expert services such as bank account data validation and conversion or direct debit mandate management. The latter is a particular challenge for certain corporate treasuries.

The following section describes sections of an RFP and includes SEPA specific notes.

• When and how to respond: This is vital for both requester and responder. These should be worked back from a scheduled ‘go live’ date sufficiently in advance of the deadline to ensure availability of resource.
• Timescales: The desired timescales for implementation must take into account exception and transition processes and should consider contingency planning.
• Area: The requester must know which areas help is needed in.
• Software: Any line of business systems must be compliant. The only provider may be the independent software vendor (ISV) itself.
• Hardware and infrastructure: Any centralisation may have implications on computing and network resources. Find out.
• Payment services: Banks and other PSP services required must be described in detail. This should describe the necessary payment and collections for each line of business.
• Data services: Data validation and conversion of existing databases should be outlined here. The location and format of the data is key to removing the potential for payment failure via poor data hygiene.
• Conversion of legacy payment files formats: The payment files currently in use and their sources will give responders an ability to assess how to migrate across to the mandatory SEPA ISO20022 format required by the Regulation.
• Support and consultancy: As part of the project, how does a responder plan to engage prior to and after the ‘go live’?

Assessment Criteria

It is important that corporations know how they are going to assess each of the above components. For example, assessing bank relationships based on country coverage may be unnecessary if centralisation of payment services is also required. It is important that partial responses must be allowed as few responders will be able to address all areas.

It is also important that assessment delivers integrity to the payment processes or failure will result. For example, when converting data from domestic to IBAN format, 100% conversion is of little value if stringent validation is not also done, resulting in errors within the IBAN data. In this case, assessment should include the percentage of accounts known to be good; using test data to assess this may be a way of determining this integrity.

Evaluation

The final thing to consider as part of a SEPA RFP is how it will be evaluated. Completeness of responses must be assessed; this is likely to include consideration of country variations for the migration such as file formats, existing practices and use of additional optional services (AOS) provided to aid compatibility with previous versions and how direct debit mandates can be migrated.

Individual assessments of responses may be easy to make, but with a multi-part project with potentially more than one provider this may prove more difficult. The requester should consider the following approaches:

• Dividing up the areas of capability and choosing the winners, then rationalising based on the number.
• Selecting a single provider, if there is one, which can provide or manage all the capabilities.
• Selecting a best-fit provider and then engaging with individual experts where necessary.

In many cases a corporation may also rely on its banking partners to provide some of these services or recommend suppliers. Only by understanding the scope of the project and business goals and treasury priorities can a reliable choice be made, both for the short term to ensure SEPA compliance and to meet any longer term strategic objectives, which could reduce costs and streamline processes and banking relationships.

Conclusion

There are less than 500 days to the end of the SEPA migration window: a business which wishes to choose between providers must start that process immediately or be faced with a resource-restricted list or a timescale which does not fit their goals. By doing the preparation and investigation work up-front it can reduce the length of the project. This must be balanced, however, against the urgency of the impending deadline.

Comments are closed.