Whatever it is that causes a transaction to be delayed, it is unwelcome. Some will say it is a matter for IT to fix, others will claim it is a business problem. The fact is, it is both. Treasury Today spoke to one ‘techie’ who sees both sides.

There are many components to a transaction that can cause it to be rejected somewhere along the road. The list of technical causes for failure is long, exacerbated by a catalogue of other intervening variables, not least being simple human error. Regardless of the reason, every delay has a corporate cost in terms of money, time, resources and even reputation. For treasurers, prevention is most definitely better than a cure.

This is something known only too well by Arne Thomessen, Principal Expert, Finance LoB, Itelligence Nordic. He is a ‘techie’ with a business focus. From his experience, he knows that the transactional process lacks transparency and, as such, has first-hand experience of the consequences when the system fails. Whilst he hopes that new solutions such as SWIFT gpi payment tracking will enable monitoring of the whole transactional process, interruptions will still occur.

Having worked with SAP software for almost 30 years, he has seen many integrations between numerous generations of SAP’s ERP, various business partners (purchasing, sales, financial and so on), and a wide range of applications. His experience around corporate-to-bank connectivity has exposed him to payment scenarios where SAP has been integrated with in-house banking set-ups using EDIFACT and SWIFT MT messaging, and a range of proprietary formats used by different banks and countries.

In more recent years he has focused his attention on solutions based on the ISO 20022 XML data interchange standard. This started with the implementation of SEPA (2014 and 2016). More recently, this work has been augmented by the challenge of migrating old formats to Common Global Implementation (CGI), an initiative to make a common/international ‘template’ and rules for usage of ISO 20022.

Open for discussion

What this adds up to is a wealth of experience and knowledge when it comes to understanding why certain transactions fail or are delayed. Current status is ‘good but not great’. “Things are moving in the right direction,” says Thomessen. So they should, he adds, recalling how, when undertaking his first corporate-to-bank EDIFACT integration some 20 years ago, “banks were for us, on the corporate side, a ‘closed world’”.

Indeed, having previously worked on customer-to-supplier integrations, he was more used to an open atmosphere, where both parties contributed towards optimising the solution. “But with banks, whenever you asked a ‘difficult’ question, they would just put up a wall, saying it was classified information.” Today, he feels banks are a lot more open to discussion. “Now we’re asking questions and we’re getting much better answers; they even ask us for our input.”

Banks have clearly shown more willingness to improve technologically. Not before time too. Some of the bigger banks have been running mainframe core systems for decades. Whilst it is a major risk (and cost) to replace these, modernisation is happening, with cloud now in progress, says Thomessen.

Despite ‘going in the right direction’, Thomessen believes all participants in the transaction chain still have “a way to go”. He is nonetheless “hopeful”, citing as “one area of great improvement” the arrival of ISO 20022 standards, notably with SEPA. With SEPA being based on ISO’s technical standard, XML, momentum was certainly given to progress in the European payments space.

But SEPA is regional, so not even this has removed transactional delays and failures for some organisations. For Thomessen, it’s not the numbers of rejections that matters so much – it is after all a question of managing by exception – but the pain these rejections inflict.

“In large organisations, IT departments are the right people to solve the technical issues but they tend not to be consulted until the business has been fighting rejections for some time,” he notes. This reveals one of the main roots of transaction failure: poor interdepartmental communication. This can be especially challenging in the largest organisations.

It may be that the issue stems from a shared services centre on the other side of the globe, but if there is no clarity around who is handling transaction processing, or who to report problems to, then the fix is difficult. “It means that when a rejection occurs, there can be a lot of confusion between the payer, the bank, and the beneficiary. This can go on sometimes for weeks or months before the issue and all the facts are reported to IT.” It’s this lag that can make transaction rejections so costly in so many ways.

Another common reason for rejection noted by Thomessen sits at the heart of the issue: failure to properly maintain master data. Of particular concern in this respect is the stringency of AML rules – and ever-changing watchlists – in most countries, where it is vital within the payments process to clearly identify and validate the parties involved.

Avoiding rejection is made harder because different jurisdictions have different rules on what is acceptable both in terms of data presentation and content. Indeed, it is not unheard of for a transaction to fall foul of certain authorities because sensitive key words or phrases have been detected in payments fields, even if they are used in all innocence.

“From my own experience I know that a missing country code in the payers address details, for example, has been enough for transactions to be rejected, even though all other address details were correct.” Paying attention to these small details is, he warns, “very important”.

More than data

There are situations where it is not enough just to have clean and watchlist-compliant data, observes Thomessen. For some international payments, adherence to ISO 20022 end-to-end is still not yet possible. A corporate may think they are initiating an ISO-based payment he says, but old formats still persist between the banks and these can frustrate the best of corporate intentions.

If, for example, a beneficiary has a long name, the variation in the number of characters permitted for messaging by different banks will likely see that name being truncated. Although in most countries truncation can be accommodated to a greater or lesser degree, certain jurisdictions, notably China, require the beneficiary name to be complete. Truncation will cause failure if the beneficiary bank is not able to recognise that name in its systems.

“This kind of issue will be solved in the coming years, but for now it’s still quite painful,” comments Thomessen. Until solutions are delivered, such causes of transaction failure may be solved by process discipline, he suggests. Payments to China or Russia, for example, have certain regulatory requirements which must be fully adhered to. Following the rules usually means success, but then every participant has to know and understand the rules. Not all do.

“There is a learning curve as the requirements across different jurisdictions can be rather complex,” notes Thomessen. For treasurers, it’s a matter of establishing the facts for each transaction scenario, and building good working relationships with their IT department, ensuring the right processes are in place in the first instance. After that, it’s a question of educating the rest of the business to be disciplined in their approach to transactions, prevention being considerably more effective and less costly than cure.