Clearings - Its groundhog day

Welcome back to bitesize Payments were we discuss their history, how they work and of course who does what.  In this episode we're discussing Clearings.

Clearings what are they?  Well, they are sometimes called rails, schemes or the last mile either way there are a lot and I mean a lot, as I have mentioned before there is a clearing for every type of payment – RTGS, IP etc for every country.  Not only that but they are different in every country even though they do effectively the same thing.  

The first clearing was probably the format defined by Western Union in 1872 for what we now call wires.  When we have electronic payments methods, we need these standards as we discussed in a previous episode.

When I said a lot how many is a lot.  Well there are 195 countries in the world with electronic payment, there are ACHs, IP, hi value, Cards – credit and debit, x border etc so for the sake of argument at least 7 formats so there are up wards of 1,365 different file formats….  So a lot :-) 

Today I am joined by Heike from Unifits and ex Vocalink etc to help me explain them, here we go….

Payments Industry Insights

History of Payments

Payment System Explained

Corporate Payments Strategy

Payment Regulations Impact

ISO20022 Standard

Digital Payments Evolution

CBDC Advancements

Cryptocurrency in Payments

Financial Technology Education

Transcript

SPEAKER_02: 0:00

Welcome back there listeners to Bite Size Payments, where we discuss their history, how they work, and of course, who does what. In this episode, we're going to talk about clearings, or you might have heard them called schemas, or rails, or even the last mile. And of course, because it's payments, a lot of these things mean effectively the same thing. Clearings, yeah, okay, that's the most exciting thing in the world. but they are extraordinarily important. Getting them wrong, bad things happen. However, they're kind of a pain in the neck, let's be honest. A lot of them were designed a long time ago by a country to do a very specific thing, to do a very specific job for a payment type. And we keep maintaining them and we keep creating new ones. So let's get into it and talk a little bit more about Clearings, how they work, a little of their history and food as well. Here we go. Clearings. What are they? Well, sometimes they're called rails, sometimes they're called schema. You'll probably hear them called the last mile. Frankly, either way, there's a lot, and I mean a lot. As I've mentioned before, there is a clearing for every type of payment, an RTGS payment, an immediate payment, and do you know what? That's true in every country. Not only is it that they're in every country, they're different in every country, and guess what? They effectively do exactly the same thing. Today, I'm joined by my friend Heike from Unifitz and Exfocalink, et cetera, et cetera, here to try and help me understand and explain clearings. Welcome, Heike.

SPEAKER_00: 2:08

Hi, Paul. Good to be here.

SPEAKER_02: 2:11

Heike, it's great to have you here. You really are a rock star. As far as I can find out, probably the first clearing was probably defined by Western Union in 1872, let that sink in for a second, for what we now called wires. When we have electronic payment methods, we need to have standards, otherwise we get in a real mess, and we've discussed that in previous episodes. And when I say a lot, how many is a lot? Well, This isn't exactly correct, but you'll get the gist of where I'm going. There's 195 countries in the world with electronic payments. There are ACHs, there are immediate payments, there's high value, there's cards, there's credit, there's debit, there's cross border, et cetera, et cetera. And for the sake of the argument, there's approximately seven formats if you just had one of those in every country. And that's not quite true either. But if you just did 195 countries, seven formats, guess what? That's 1,365 different file formats. So when I say a lot, I mean a lot. Now, before we even thought about ISO 2002, which we will come back to, we had clearings. And guess what? They were handcrafted in documents and, frankly, very, very long documents. documents indeed, they were really huge volumes. And each of these rule books for the formats, they actually contained the description of the formats and the rules, and they were defined by the country for their own country. And by and large, they did not care what other countries did, even if they were doing exactly the same thing. But Heike, why are they so complex?

SPEAKER_00: 4:00

Well, they can be complex. But really, I think it's just there are so many of them. There are so many options and depending on what they are trying to do. And of course, they're different. Yes. And they have different rules. So in Europe, there's a complex set of rules also defined in the SEPA area, which is the single euro payment area. It's a regulation which standardized electronic payments in euro to make cross-border payments within Europe as easy as domestic ones. So SIPA has detailed rules for credit transfer, direct debits, and card payments. And these include technical standards, business rules, but also compliance requirements. And this started like in December 2005 and was introduced with the payment service directive in 2007. So we are quite a while back.

SPEAKER_02: 5:03

Okay, before we dive into clearings, I think we need to step back a little bit. So we do need to talk about a typical payment flow because otherwise a clearing kind of doesn't make sense. Can you try and walk us through a payment flow?

SPEAKER_00: 5:20

Yes, sure. So make it quite simple. Say I want to send today about 100 euros from my bank account to your bank account. So I have the basic information. So Heike wants to pay 100 euros to Paul. So we know which accounts, we know how much we want to pay, what currency, and when I want to pay it. So with this information, I can go to the bank. So I'm the end user, I'm the stakeholder, but it could be also a corporate or even a third party. So I could send my son to say, pay that money. behalf of mine so this information is going then to my bank so then the bank has to do something with this information they have the instruction and they need to process my instruction so but before that they have to check to have a sufficient funds are the account details correct and everything what actually is needed to the banks to know his customer around this then they have to check. When then the bank system are happy with all the details, they then generate the payment or the message in that appropriate form and the format as is defined and send it onwards with the payment method as it is required. After this, the central bank or the payment processor who actually defined these formats will accept the process of this type of payment. In my case, it's a credit transfer from my account to Paul's account. And with this, the sending bank must also ensure that the payment message respects the set of rules. And for example, one rule could be the name has to be 30 characters, alpha characters. there has to be one address line to identify, is it really Paul? Then in certain cases, they say, well, I have additional information, so I need 45 alphanumeric characters in line 31, et cetera, et cetera. You get my, so there are really defined rules. And if this is not correct, so if the message I'm sending is not respecting these rules, it will be rejected. And it will be told from the central bank audit processor that the payment failed. And you see, I'm skipping over a lot of details, but you get the gist of what's happening here.

SPEAKER_02: 8:08

Yeah, and I think it's, you know, this format itself, that's the actual clearing, if you will, or the rail or the scheme, which all these terms kind of sort of mean the same thing. But the best way to think about it is they are a file format that the message has to send the payment and the rules about what they can do and what they contain. In some clearing types, there is also logic that needs to be defined. But at the very least, There is a happy flow, it goes through and is paid out. There is an unhappy flow where the message is rejected and needs to be returned to the initiator as a rejected payment. So that's the simple version, but there is a series of logic actually contained within these messages that isn't quite as simple as the way I've just defined it. Heike, can you give us a bit more context here?

SPEAKER_00: 9:06

Well, As you said, simple payment flows like immediate payments are quite simple. If the message is formatted correctly, then it goes through Happy Flow, as you just mentioned. And it's paid, or if it's not, it's rejected. You just said that. But most of us know also another payment type, direct debit. And they are, for the processing, far more complex. So I think, Paul, you have a direct debit. If you have a mobile phone, everybody has a direct debit. So before actually money is being transferred from one, like my account, to my mobile provider, I need a contract. And that's the example for the corporate to allow them to take out the money. It's also called a mandate. And when I... my bill is ready, the corporate sends the request with the mandate again in the correct format to his bank. So to the corporate's bank, to my mobile provider bank. The mobile provider bank is then taking this instruction and send it to my bank. And then my bank starts again. They are checking in the first instance, is there existing mandate? If not, They have to check, did Heike actually agree that money is being taken out of her account? Then the bank checks also, well, even if she is allowed, would give us the green light to take money, is there enough money on the account? So only after that, the bank actually says, well, now I can debit this account either today or even later if there is an agreed direct debit date. After this checks, my bank has to go back to the corporate banks and confirms, yeah, we took out the money according to the direct debit you sent me. Next step is then the corporate bank receives this information and only after that they receives the amount they can credit the corporate. And you can see it's a quite complex process and we are not even into regulations and rules behind there. So I think that's quite a good example how complex payment can be.

SPEAKER_02: 11:38

Yeah, and I think you've done a great job of outlining it, but there is the devil's in the detail here, as they say. But all these formats and these rules are defined in the rulebook. So let's talk about that in a minute. Okay, so let's talk about rule books. You probably heard about rule books, but these rule books are written for each of the payment type by the country or region that wants to implement them, i.e. high value payments in France or mass payments in the UK. And they are typically defined by the central infrastructure that runs that payment type. So rule books here are really, really key.

SPEAKER_00: 12:35

Yes, you're right. These are the key. The rule books are defined the comprehensive set of rules, the standards, the procedures, and also the guidelines that govern the operation of a specific payment system or a scheme. And these rules are essential for ensuring consistency, efficiency, security, but also legal compliance, which are in the processing of the electronic payments. Typical payment rule books may cover a wide range of toppings, including participation rules. So the criteria for an institution could be a bank, a payment service provider to join and participate in this payment system, including eligibility, technical capabilities and compliance standards. So quite of a not payment related requirement. Then transaction types. Well, yes, I need to detail in description which type of transaction I'm supporting with this payment system, such as credit transfer, or which I just mentioned direct debits, and real-time payments. So these are clearly defined. And then the last point, which is really important also, technical standards. Specification for the technical infrastructure. which includes the data format, like ISO 20022, the communication protocols, so how do I communicate, security standards to make sure that the payments are secure, and sometimes also interoperability requirements, how different systems can talk to each other. And you see, these technical standards are quite important. Otherwise, your payments won't go through. We have them also operational procedure, details processing for how to initiate, to process, to clear and settle the transaction, including the timeframes, batching requirements, if we are talking about bulk, and handling of exceptions. We also have all the compliance regulation requirements, guidelines to ensure compliance with the relevant laws and regulations, such as anti-monitoring lowering, or counter-terrorism financing, data protection laws, but also quite important, consumer-protecting regulations, and as well as what to do with these dispute resolutions and chargebacks, fees and pricing, change management, and so on and so on. You see, there is a lot going in these rule books.

SPEAKER_02: 15:26

Oh, yeah. Yeah, they absolutely do. Dispute resolution and chargebacks. Wow. They could be a whole podcast in their own right. But the key thing here is while they're doing very, very similar things, they are invariably subtly different. And there's lots of rules and options, even pre ISO 20022. And they were all handcrafted. And of course, the payments that actually consume them at the bank were also, by and large, handcrafted too. So while there is a logic to all of this, it's complex. And every bank who wants to support that country's payment type needs to support and code all of these formats and the logic around that rulebook. That's a lot of work. And that's why the testing of these clearings is so utterly time consuming. Typically, So in the region of 60% of the project is just consumed with the testing of each one of these clearings. Now, if you're a large international bank, you can spend all of your time just testing them. So you have to make decisions upon which payment types in which country you're going to support. So if you operate in many countries, the numbers just escalate and escalate and they go up and up and up. And of course, they don't stand still either, do they?

SPEAKER_00: 16:52

No. And typically they are updated every year or so. So they may be subtle and small changes, but they are required that all of the banks using that payment types need to be retested. They retest their systems to make sure that it works correctly. And this is a never ending circle.

SPEAKER_02: 17:17

It is indeed. It's a bit like the painting of the fourth bridge. By the time you get to the end of the fourth bridge, you have to go back to the beginning and start all over again. I mean, it really is a huge drain on the key resources. And frankly, they need to understand the actual changes and, of course, what they mean for the bank itself and, of course, what it means for their clients.

UNKNOWN: 17:45

Thank you.

SPEAKER_02: 17:54

So most of the clearings currently in place were defined pre-ISO 20022. But now that we have ISO 20022, is this all fixed? Is it all cured?

SPEAKER_00: 18:06

Well, this is now the way nearing is defined, I have to say, so that we have structure rules that we can understand from a machine point of view. But ISO is a toolkit that allows to define the rules as is in a structured way. So before, I would always say the different formats in different countries were different languages. So on one side you have Greek, on the other side you have Spanish. Now, at least you talk English, but with different dialects. So you know that Australians have a completely different dialect as the British English or the Americans. So I see that what ISO 2002 is doing for standards. But at some point, I would hope that the ISO 22 will replace all the older rule books and allow us to work in a more machine readable way. Certainly, that's the trend, as I just said, just with different dialects.

SPEAKER_02: 19:09

Yeah, yeah, that's a good way of putting it. But that does not mean that everyone will use the same rules. And it does not mean that they don't need to be tested, right?

SPEAKER_00: 19:22

Indeed. While ISO 22 helps these systems need to be tested and checked, not only that, but given that we have that added power of ISO more complex and rules are being added because you have more options now with these new standards.

SPEAKER_02: 19:42

Yeah. And now that we have so much change going on and being compliant with these new clearings is a real, roadblocker for change. I know that you've been working on trying to address some of this. Can you outline how that works a little bit?

SPEAKER_00: 20:01

Well, typical banks have used more and more resources to manually check these systems or reuse generic testing tool scripts to manually test them, but that exponentially getting worse and more expensive. Having payment-specific tools, which are only focusing on the payments that set the checks, the clearing for all the possible options and keep them evergreen is our goal.

SPEAKER_02: 20:36

That sounds pretty cool. But it's also the fact that there are only so many folk in the bank that understand these key payment changes. And typically, banks want those people key teams in front of their businesses, not internally focused. Anyway, very few payment clearings get actually retired. And so we just have more and more. And while we need these new ones and we need ISOs, 2002's help, there is still a lot to do. And nobody, and I mean, nobody wants an issue in the payment flow. Heike, are there any other points you'd really like to add in here?

SPEAKER_00: 21:14

Well, understandable what you just said, that banks want the experts in front of their business. But I think it pays off to train people and keep the knowledge in-house. So you expand it internally. And furthermore, it does make sense for banks to invest upfront, while in the relevant resources, like payment-specific testing tools. It might look expensive at the beginning, But the projects in the long run pay off. It supports the whole team. And as we said before, especially every time you need to retest your system, regression testing is the word. But in my words, it's Groundhog Day. It's over and over.

SPEAKER_02: 22:09

Heike, what is Groundhog Day in German?

SPEAKER_00: 22:13

In German, it's called So that means every day in the morning, the groundhog is greeting you. So it's coming over and over every day the same thing.

SPEAKER_02: 22:26

That's a very, very good way of putting it. And the truth of the matter is, It's very difficult to win. You can only just be okay. Heike, thank you so very much for your expertise and walking us through this. It's an absolute pleasure as ever to chat to you. Thanks so very much.

SPEAKER_00: 22:56

You're welcome.

SPEAKER_02: 23:04

Well, there you go. Clearings. A really fiddly technical bit of our industry. They've got a lot of history, arguably too much history. We need to maintain them and it's very distracting. A lot of time and energy is taken to make sure that we test them correctly, get them right. Nobody wants payments to go badly and effectively the real work is making sure that the testing of the clearings are doing what they're supposed to do. However, It often means that the key people are not focused externally, unfortunately focused internally, trying to get the work done. And at times, quite often, we see that the entirety of the workload is outsourced to a different country or third party anyway to get them done. Not sure that really helps. It's kind of putting lipstick on a pig. Anyway, clearings, really important. Hope you enjoyed it. If you did, please let me know. If there are any things you'd like me to discuss, please email me. And you know what? Yeah, ask a friend. Take care. Cheers for now.