The problem: payments fail

It might sound surprising, but account-to-account payments (in other words, bank transfers) can also encounter failures. When you make only a couple of monthly payments, it’s rare to see when a bank is down or when one of your payments returns a false positive in AML checks. However, as your transaction volume grows, you start to realize that not everything is as smooth as it seems.

For example, if you made a payment for one of your clients, but their bank experiences downtime at that exact moment, your payment will be rejected.

The result of this situation: 

  1. The money has not arrived at the destination
  2. Your client is unhappy and contacts your support center 
  3. You probably don’t have too much information about why the payment failed
  4. Someone in the operations team will send the payment again, hoping the bank of destination is already working
  5. Your client may be frustrated at this point because their expectations were not met

For the support and operations teams of the companies we serve, all these unreleased operations become issues to address. Depending on the case, they may need to notify the end user about a problem with the money transfer. Afterward, they must explore an alternative way to send the money, incurring additional costs and investing time to resolve the incident.

We all know, a money issue is one of the worst problems you can have with your clients. So, we asked ourselves a question:

How could we avoid or at least reduce the frustrations and extra work that comes with a transfer that does not arrive on time?

Analysis and Research

Devengo works mainly with instant payments through the STC-INST scheme, which facilitates this kind of account-to-account payments at the European level. Currently, 99.06% of our payments are instant.

What happens when an instant payment fails? The scheme provides guidance to the SCT INST scheme participants about the codes to be used to report specific transfer issues. You can review the errors list in their current Guidance On Reason Codes For SCT Inst R-transactions. In this way, the entity that sends the payment (Devengo, for example) will have back the necessary information to know what error the payment caused and how to solve it, depending on its nature.

Retriable errors
The most common errors in Devengo operations, based on their nature (retriable or not)

Upon analyzing the most common errors in our daily operations, we found a significant number of errors for which the STC INST error guide advises the originator to retry the payment. More than 50% of erroneous payments are recoverable within a reasonable time, which can result in a satisfactory payment. 

It’s important to mention that not all the errors we process are retriable. There are a good number of them that are unsolvable problems and in which the solution is not within our reach. Some examples of these types of errors are: 

  • Blocked accounts by the destination bank 
  • Closed accounts by their owners
  • Accounts that due to legal circumstances are restricted from sending or receiving money, etc.

Then, what kind of payments are retriable?

As the European Payment Council illustrates in the SCT-INST scheme rulebook, there are various stakeholders involved in account-to-account payments, which means payments can fail for various main actors: 

Four Corner model
The Four Corner Model gives an overview of the relationships and interactions between the main actors

Depending on the actor that is having issues, the errors can be:

  • Accidental connectivity issues with the destination bank or the clearing house
  • Scheduled maintenance with the destination bank or the clearing house
  • Technical issues with the systems of the Originator itself 

To date, in all these cases, Devengo has been returning the error directly to our users with a specific error type, “ERR-0005” which means that the payment is “recoverable”.  Our intention with this type of error was to be transparent with our clients and let them know they have the possibility of retrying the payment by themselves through the API.

On the other hand, for the last year, we have been testing and doing manual retries of these types of rejected payments. The main goal of the tests was to know when to retry a payment based on its specific error so that it would be successful on the first retry. Now, we have a clear solution.

Other retriable errors

Taking a deeper look at our data, we discovered another set of errors that were worth investigating further. These circumstances usually have to do with the fact that the beneficiary cannot currently receive an instant payment in their IBAN.

As you can check in the Test Data section from our doc site, in all these cases, Devengo has been returning the error directly to our users with a specific error type, “ERR-0001” which means that the beneficiary’s account is “blocked”.

Although these accounts are indeed blocked from receiving instant payments, we have carried out tests in which we have discovered that if we manually send these payments as regular SEPA (traditional transfers) the money is sent without problems.

Product solution: Smart Retry System

Retry cycle
Lifecycle of payment with retries capability

After researching and gathering substantial evidence from the retry tests carried out over the last year, we decided to develop our system of payment retries.

Devengo’s Smart Retry System instantly analyzes the error types returned by banks or clearinghouses. If they are retriable, the payment enters our system until it is successfully sent. 

The Smart Retry System is intelligent enough not to retry payments if we identify that the clearing house or the destination bank is down, waiting until all the stakeholders implicit in the money transfer are restored. 

We also determined a limit on the number of retry attempts per payment to ensure the efficiency of the system, not allowing the charge of an excessive fee per payment.

You can see all the system details on our documentation page.

The policies:

We have a set of policies based on the type of error returned in the initial payment. We use all available information to determine when to retry a payment.

We cover two kinds of policies:

  • Retry with the same scheme (SCT-Inst)
  • Retry from SCT-Inst to SCT regular

In some cases, the retry can occur within a second of receiving the error, while in others, we may wait for an hour. We take external information into account, such as whether the bank is scheduled for planned downtime, for example, to decide when to retry instantly. 

Lastly, we analyze errors based on the destination IBAN and intelligently consider shifting the payment from instant to regular to ensure successful delivery.

How does the Retry System affect the payments:

From now on, a payment made with Devengo can be categorized as:

  • A simple payment, like all the ones that have been made until now through our API, and the majority (more than 99%) will continue to be so.
  • A payment with retries. These payments are essentially composed of the initial payment that returned an error and the subsequent retry attempts. In most cases, a single retry will bring the payment to its final state.
Webhook request
Setting up a webhook to receive events of retried payments

Launch and Results

In September and October, we conducted a progressive roll-out of the system among all our clients, reaching 100% of them without any incidents during the launch. 

To understand the impact of this development, we have to clarify that Devengo fails very rarely, our deliverability ratio average this year is close to 99%. In these two months that we have had the Smart Retry System active (and remember that it has not been working at 100% during this time) the deliverability ratio has been improved from 99.30% to 99.39%. 

Our deliverability ratio improved by 0.09% thanks to the Smart Retry System

Does that seem little to you? Consider your clients when they contact you to find out why they haven’t received the money. For these clients at that moment, your company’s error rate is 100%. That is why we think the Smart Retry System is imperative to our product, and we believe in making this type of effort to be more successful in sending payments. For us, it’s worth it.

The Smart Entry System represents one of our recent advancements aimed at enhancing our performance in this domain. Over the last year, our operations team has been at the forefront of an ongoing process of learning and rigorous testing, resulting in substantial improvements. Our efforts have led to an impressive increase in the delivery ratio by more than 1.5 points and a modest but remarkable gain in the instant ratio to 0.05.

We hope to continue researching and testing new possible solutions to continue increasing the success of our clients.