SEPA - A road less travelled

SEPA as simple it may sound as a concept, is increasingly becoming complex at strategic and technical level both for banks as well as corporates. And understandingly so, as it’s not an easy ask for any organization to convert or update its legacy system to something which is quite different and new. The rather strict deadline this time by the ECB and the historically lethargic behavior of few banks and corporate regarding this initiative has made things even more worse.

And now, with the deadline looming so close, things are becoming even more challenging and rather riskier as the probability of banks taking extreme or missteps is becoming stronger.

Both at the bank level and at the organizational level, things have gathered speed and various projects are underway to implement SEPA with in time.

Let us discuss few of the issues which have been experienced so far from the organizational side:

To start with, for a payment message to be eligible for SEPA, it has to stick to few general defined set of criteria such as:

1. Payment is in EURO currency
2. Payment is made with in the countries falling under SEPA region
3. Payment is non urgent
4. Both the sides have IBAN in account field
5. Charges are shared
6. Clearing code is SWIFT

If these checks are positive for any payment, it should be made in XML ISO 20022 format.

This is the core logic which is being set up at the architecture level for most of the institutions. And the work is being done mostly using the following two approaches:

1.  Banks converting, repairing and enriching the payments which they currently receive from their customers into ISO format based on the SEPA criteria
2. Organizations themselves are putting this process at their end for the banks with which they share high volumes

For the 1^st case discussed above, though a lot banks have been providing this service of enrichment for their customers but it is not being seen as a permanent or long term approach as the requirement for all the SEPA payments to be XML format will become a mandate in the near future. Currently this approach is being strongly advocated by the PSD but it’s not a mandate to be implemented along-side the SEPA deadline of 1^st Feb 2014. And this push by the PSD for the approach no. 2 is because of the obvious reason that to make the processes seamless and would not create any manual interference and issues which is one of the visions of SEPA. Moreover banks would also prefer this approach as this will save them a lot of operational issues which they might encounter during the enrichment process.

But all said and done, this is definitely not going to be an easiest approach because of the technical level mismatches which might exist in the payments processing systems of companies and banks.

And the success of this integration would depend largely on how flexible the systems of banks are when any issue arises because of that gap.

For the first approach, the minimum or the least which a bank expects from the businesses making payments is IBAN which is ironically the biggest challenge also as till now many organizations have not been able to fully convert their accounts to IBAN format for Euro payments. But the serious organizations should not face this issue for a very long term.

For the second approach where the organizations have implemented the XML or SEPA processor at their end, few  of the issues which have been encountered so far have been discussed below:

When the banks or for the matter of fact any institution, who have their system strongly knitted into their legacy logics and syntaxes are required to move to a new way of doing things, they are bound to throw some surprises. To be specific, banks which have been executing the payments earlier in the older format such as paymul, MT  platform have now need to execute the payments in XML format. But the transition is not that easy. Even though at during the phases of requirements gathering till testing, most of the scenarios are covered, there could be few misses which can cause a lot of issues.

Batch Failure:

One of the issues which is being encountered regularly during this migration is batch failure of transactions. Since non urgent payments are sent in batches via fileact, the syntax is not verified by SWIFT as they do for MT messages.

And in few scenarios what is seen is that even if one transaction has an incorrect or undesirable data, this could lead to failure of whole bunch of transactions in that batch. And this becomes a lot of pain for businesses as it affects their day to day operations. And these incorrect data scenarios varies from bank to bank. Few of them are:

Batch failure due to a Special characters: With SEPA in place, the way banks read the payment details which are sent the messages, is getting impacted. One of the banks, after moving on to XML format started rejecting the whole batch of payments even if one payment in that batch contained a special character which was unreadable by the bank’s system.

Batch failure due to incorrect structure : Since the XML format lays a lot of emphasis on the structure, there have been issues where the whole batch was seen to rejected by one bank, when one of the transactions from that batch had wrong structure

Batch failure due to incorrect debitor account: Though rarest of scenarios, there were few scenarios observed,  where the banks were rejected a whole batch because of one transactions carrying incorrect debitor account information.

Batch failure due to incorrect currency: Similar to the above issue but this time wrong currency in a transaction of a batch leading to whole batch failure

Inability to process two formats in parallel: This functionality is the real test of the flexibility which can be offered by the payments product of a bank. Since many organizations are in a process of converting their accounts in IBAN and are also working to implement the SEPA platforms in their system, it may so happen that the payments received by a bank in XML format but are not consisting of IBAN. And since banks would have also moved to the SEPA format in their system, it might become difficult for them to process XML payment without IBAN which is a mandatory requirement for a payment to be called as SEPA. This issue was recently encountered even though these scenarios were tested during the project phase. And  because of this issue, many payments worth millions which were without IBAN were rejected by few banks. Hence it can be said that SEPA being the most advanced form of electronic payments in the region would also expect the most advanced system to function efficiently.

Inconsistency between production and test environment: Every project before going live must go through various layers of testing to ensure that all or most of the scenarios have been tested and the results are in line with the expectations. These phases of testing are done in the test environment of the banks which is considered to be the replica of production and can be trusted. But things can go haywire if the production does not behave in the manner how test environment had performed. And this was one of the issues which was encountered during a recent SEPA implementation with one of the banks. Because of this issue, the whole project was roll backed and business had to suffer a lot of problems with their live payments.

These were few of the challenges which have been experienced so far while implementing SEPA logic in the enterprise payments product of this organization. More issues are expected to be encountered as we move forward and especially when SEPA would be a mandatory requirement for all the non urgent Euro payments after 1^st Feb 2014. The only suggestions for the banks and organization for this: Look before we leap.

 Thanks !!