Steps to a Successful SDD Migration
The long-awaited European Central Bank (ECB) announcement in December 2010 of a proposed end-date for mandatory migration to the single euro payments area (SEPA) has made many treasurers sit up and take notice. Companies who previously had to develop a business case for migration now face an easier task in presenting a compliance project.
The proposed timeline for migration to SEPA credit transfers (SCTs) is a 12-month window following regulatory approval; SEPA Direct Debit (SDD) allows a 24-month window. This means that, at the latest, SCTs could become mandatory by 1 February 2013 and SDDs by 1 February 2014 at the latest.
Up until now, the SDD, for which mandate management complicates the process, has seen the lowest adoption rate. Currently only 0.07% of direct debits sent in the SEPA region are SDDs.
To add to the complexity, there are two SDD schemes: the core scheme, which can be used to pay both consumers and businesses and the business-to-business (B2B) scheme, for business customers only. The latter requires the payer’s bank to ensure the collection is authorised by checking the collection against mandate information.
Unlike the core scheme, refunds are not allowed on these transactions. The B2B scheme stipulates shorter submission deadlines to ensure reliable cash flow to businesses. Instead of the five-day deadline for the initial message and two days for recurring messages, the B2B deadline is only one day before payment. This difference will force companies to modify their internal deadlines to minimise the disruption to their cash flow. However, while 3909 euro area banks adhere to the core scheme, only 3381 adhere to the B2B scheme.
A number of steps are necessary for achieving a successful SDD migration project: aligning departments within a company, establishing the mandate management process and overcoming the technical challenges inherent in sending XML messages. Banks need to be ready to support their customers at operational, IT, sales and project management level.
One country that is leading the way in SEPA migration is Belgium. The country’s small size and relatively compact banking system has allowed it to push forward SCTs, which have reached 33% adoption [by volume] compared with a euro area average of 10%. Belgium is currently dominating SDD coverage too – nearly a third of core SDDs, and 80% of B2B SDDs, sent in the euro area are initiated through a Belgian bank via EBA Clearing. Since 1 November 2010, all Belgian banks have been reachable via the core SDD scheme, with 99% reachable via the B2B scheme.
It is likely that mid-sized companies, with their lower transaction volumes and majority domestic payments, will find the SDD migration process less complex than corporates. Geographical coverage also plays a major part – the migration process will be complex for a pan-European operation, which will need to decide from which country to lead the process and how to centralise information.
The first practical step towards migrating to SDDs is for a company to analyse the impact that the migration will have on its systems and applications. Without this analysis, a company will be creating problems for later stages of the project. Communication between a company’s IT, commercial, operational and project departments is key to achieving good visibility of the migration requirements. Although it would be preferable to have a single individual on the implementing company’s side who combines all the necessary expertise, this is difficult to achieve in practice.
Banks advice on the different parts of the migration process can be invaluable. For example, ING has a product specialist who co-ordinates the migration. IT specialists are available to offer advice on the testing of file formats, while a payment and cash management consultant supports the commercial side of the process. An implementation team will support companies through the migration process. There is also a customer service team that follows the process after implementation to ensure the new process is running properly. Bank advice on adapting company processes will be on a case-by-case basis due to the amount of variation in existing processes and systems, and depends on the extent to which firms can handle the required data.
The next step is to update the company’s database to use Bank Identifier Codes (BICs) and International Bank Account Numbers (IBANs). In Belgium, where mandate management has moved from being the debtor’s bank to the creditor’s responsibility, companies will also need to gather the electronic data relating to their existing mandates from the debtor bank, before checking it is current and complete to allow translation to XML format and collect the relevant reporting information for integration with their enterprise resource planning (ERP) system.
The company needs to decide whether to manage mandates internally or use an external provider. If a company chooses to manage the process in-house, it needs to put in place a strategy for the conversion, the dematerialisation and archiving of new and existing mandates. It is also legally obliged to inform their customers of the change from local direct debits.
Due to the higher complexity and volume of their mandates, large corporates are likely to outsource the mandate conversion and management process. Conversely, mid-sized companies are more likely to develop their mandate management process internally, using their ERP system if it offers live mandate management capability. This level of functionality appears to be sufficient at this time. Some ERP systems do not yet offer this capability, however, forcing these companies to consider alternative solutions.
There is also the issue of whether to move directly to using XML formats or convert mandates from local formats upon receipt. If the mandates are to be converted, the company also needs to decide whether to manage the conversion process internally or use an external provider.
Managing B2B mandates adds complexity to the process because B2B mandates need to be confirmed by the payer with their own bank. Companies must factor the time B2B mandate approval takes into their payment cycle.
Using XML correctly is a challenging part of the SDD migration process. A company needs to allow sufficient time to understand the payment formats and file structure and content. ING offers its clients XML file content and structure checking, including an online validation tool for the company to upload its XML file.
One issue that can cause difficulty is sending an initial SDDs instruction. When a company sets up a new SDD, it needs to send a specific type of message called a ‘first’ to initiate the payment. If the first is successfully executed, a recurrent message can be set up, and no further action needs to be taken. However, if, as is common, the first message is not successfully executed, the sender will receive one of a number of possible ‘R’ error messages. One type of R message is a ‘reject’, which will occur before the settlement date. This means that the company needs to send a new ‘first’.
A major challenge here is that some accounting systems won’t accept a second ‘first’ sent for the same transaction. This is an example of an issue that needs to be flagged early in the SDD migration planning process. Otherwise, there is the potential for a company to send a large number of payment messages without the facility to resend them. One solution to this particular issue is to convert the second ‘first’ manually in cases where the initial ‘first’ failed. For a medium-sized company, the volumes are manageable enough to do this manually. However, corporates find such a workaround much more difficult and time-consuming.
A bank needs to inform the company that it needs to initiate another first – otherwise the payment will be rejected again. The bank can only intervene to fix a message if it has prior agreement from the payee. For example, some ING customers have been able to send a first but not recurrent messages, which are incorrectly formatted as firsts. ING automatically converts the type of transactions when necessary, changing recurrent messages to firsts and vice-versa, but only where it has customer approval.
ING offers a tool that converts the messages with the same reference number in recurrence. ING retains one first in its current format and converts any subsequent first for the same transaction. This allows the file to be executed and the bank to fix the transaction subsequently.
Some debtor banks in Belgium have experienced problems processing first and recurrent messages sent by the creditor bank at the same time, with the same due date, same mandate reference and same debtor account could affect companies’ cash flow. For one of its customers, ING is currently splitting the payment file, sending the first messages one day ahead of its recurrent messages to ensure that it can process the whole file, before sending the recurrent messages the next day. This problem is likely to be solved by the end of 2011, with the solution varying from bank to bank.
There are other reasons for error messages that also need to be taken into consideration. Companies need to be able to differentiate between different ‘R’ messages: ‘reject’ and ‘return’ and the reason for each, in order to be able to anticipate the reaction. Clearly this is only possible if the creditor’s bank provides the necessary information. The differences between the two are as follows:
SDD migration is still a learning process, even in Belgium, which is leading the way in SDD adoption. Banks can offer assistance to companies struggling to get to grips with what needs to be done from a technical and regulatory perspective, and some offer tools to ease the process. Sufficient preparation and investing in a dedicated project team on the company side will simplify the process in the long run – in time for the mandatory end dates.
To read more from ING, please visit their gtnews microsite.