Can rich data solve the SEPA Instant sanctions issue?

Aside from faster, cheaper, better transactions, instant payments are helping millions of previously underbanked people around the world to participate in the payment ecosystem.

They enhance financial inclusion, strengthen business relationships, and help workers access wages ahead of payday via earned wage access schemes.

Around 79 countries now have an instant payment system. Many more are on the horizon. The challenge for the payments industry is to now extend the benefits of instant payments across borders.

But making systems that have been designed, developed, deployed, and governed in isolation interoperable is easier said than done, particularly given the nuances of regulations, such as sanctions screening.

Instant payments are instant. That means there is no time to manually review transactions. They must be processed straight-through or rejected.

That’s a problem when you consider that as many as 95% of payments for people who share the same—or similar—name as a sanctioned individual are rejected as false positives.

The EU has sought to address this problem by introducing a streamlined SEPA Instant sanctions approach in the instant payments regulation. While this approach has its merits, it has significant restrictions as EU banks will still need to screen against non-EU lists.

Slow and steady

When processing an ACH or traditional SEPA payment, a bank might encounter a transaction that appears linked to a sanctioned individual.

When this happens, the bank will usually take some time to review the transaction.

They may ask for more information from the payer, to check if they are indeed on a sanctions or fraud list and release the transaction afterward if everything is okay.

If everything is indeed fine, and it turns out the individual shares a name similar to someone on a sanctions list but does not feature themselves, we have a false positive—a transaction that is being flagged by fraud or sanction systems but isn’t associated with a sanctioned individual.

False positives are best avoided, but they are manageable for slow or domestic payments. It gets a bit trickier for fast ones.

A lot of banks don’t do much sanction screening for domestic instant payments because they assume that other banks are part of the same KYC (Know Your Customer) regimes.

This varies from bank to bank, but the impact is somewhat limited.

The trouble starts when we want to make a cross-border instant payment. For example, from a European country to the US.

Because banks screen not only against European fraud and sanctions lists but also against other lists (a very important one being the United States OFAC list), they must still undergo a sanctions screening process for international payments.

If you want to do dollar transactions, even if you’re not regulated in the US, you better screen against OFAC. And most banks do.

So, if you’re unfortunate to have a name that is like someone who’s on a sanctions list, your bank doesn’t have time within those 10 seconds to analyze your transaction. Your bank will simply reject it. That means, with the current rules, you can’t make cross-border instant payments.

We are essentially creating a new class of individuals who can’t fully participate in instant payments because their names resemble those of someone on a sanctions list.

And of course, you have some groups of the population that are disproportionately affected by that.

Boxed out

Consider a hypothetical transaction involving someone called Muhammad Ali.

Now, the person that will spring to most people’s minds is the late heavyweight boxer, Muhammad Ali, an international superstar and human rights activist. But there are some 72,000 people named Muhammad Ali on LinkedIn alone.

Muhammed Ali also happens to be the name of several individuals listed on the OFAC list (as well as a terrorist on the FBI’s most wanted list who hijacked an airplane in 1985.)

Now, if any of the 72,000 Muhammad Alis on LinkedIn make a cross-border payment from the EU to the US, they will be screened against the OFAC sanctions list. OFAC will immediately raise a red flag because Muhammad Ali, the sanctioned individual, is featured.

In a slow ACH payment, the bank will take some time to review the transaction. They will ask for more information to make sure that the Muhammad Ali in question is not Muhammad Ali, on the sanctions list. When it turns out they’re not, the bank will release the transaction.

But in an instant payment that must be completed in 10 seconds or less, the transaction cannot be processed.

There isn’t enough time to review the information properly, so the instant payment is rejected. And with that, we have a subclass of at least 72,000 people who do not have access to a payment method prioritized by the G20.

ISO 20022 and the role of rich data

This is where rich, structured ISO 20022 data comes in.

If we look at the OFAC list and our friend Muhammad, we see that he’s not just Muhammad Ali, but Muhammed Ijaz Hammedi Ali who was born in Pakistan on the 13th of June,1964.

This information is readily available and stored in the OFAC lists.

In slow transactions, you go back and ask for a little bit more information. But we don’t have time to do that with instant payments.

So, if you’re a bank with a customer whose name is similar to someone on the OFAC list or some other sanctions list that’s making it difficult to do transactions, you could ask that client for authorization to send more information.

For example, you could ask your customer for their place and date of birth, a passport number, or other miscellaneous identifying characteristics that the receiving bank could use.

That way, the bank can say “Okay, this is Muhammad Ali from London, not the one on the OFAC list. I know this because the place and date of birth are different, and so is the passport number.”

By using rich data in this way – by attaching additional identifiable data to these payments – we could avoid a lot of false positives.

This ultimately leads to a better payment experience.

But more importantly, it avoids creating a class of people who will be financially excluded in an increasingly instant world.

It’s not watertight, of course.

As a payer, you might not necessarily have all the information needed to make a payment.

But it could solve at least 50% of the problem, and it is, of course, better than nothing. At least whenever the debtor side of the payer is someone that seems like there’s someone on this sanctions list.

How do we do this?

We need regulators to start looking at this and start exploring the ability to use this rich ISO 20022 data. Not just in international payments, but also in interoperable, instant payments. That way, banks can more efficiently and in a more automated fashion, do their sanction screening in a way that drives down the number of rejected transactions.

If we apply that same process to the non-instant variety of payments, it also drives down costs. There is less manual workload, which again will help deliver the G20 development goal.

We have ISO 20022. We can transmit this rich payment data. Let’s start using what we’ve built to more efficiently screen for sanctions.

Get everything you need to know about SEPA Instant in our ultimate guide