The Treasury Update Podcast by Strategic Treasurer

Episode 277

Updating ISO 20022: Exploring New Formats, Data, and Benefits

In today’s podcast, we are joined by Roman Müller, Chief Client Officer at Fides, to discuss ISO 20022’s changes in payment and statement formats. We’ll discuss the updated address requirements, the extension of the November 2025 deadline, and the need for structured and unstructured data. Listen in to learn more!


Craig Jeffery, Strategic Treasurer

Craig - Headshot


Roman Müller, Fides

Craig - Headshot

Subscribe to the Treasury Update Podcast on your favorite app!

The Treasury Update Podcast on Spotify
The Treasury Update Podcast on iTunes
Episode Transcription - Episode # 277: Updating ISO 20022: Exploring New Formats, Data, and Benefits

Announcer  00:04

Welcome to the Treasury Update Podcast presented by Strategic Treasurer, your source for interesting treasury news, analysis, and insights in your car, at the gym, or wherever you decide to tune in.


Craig Jeffery  00:18

Welcome to the Treasury Update Podcast. This is Craig Jeffery. Today’s episode is on ISO 20022 changes and initiatives that are going on. I am joined by Roman Müller from Fides. Roman, welcome to the Treasury Update Podcast.


Roman Müller  00:34

Thanks for having me.


Craig Jeffery  00:35

Good to have you joined from from Switzerland. I guess as we start talking about a format or a structure like ISO 20 Oh, 22. Maybe you could give us an overview of what that is, and what some of the key initiatives are just to frame the rest of our discussion?


Roman Müller  00:54

Absolutely, I think it’s a good start. So ISO 20022 is a standard. It’s an international standard by the ISO organization. And it’s widely used. And within that standard, we have several artifacts we will be using in our professional day to day life, be it on the banking side be it on the corporate side consuming and sending data to banks. So in general, ISO 20022, it’s nothing new. It’s a hot topic at the moment a lot is going on. But it’s nothing new. We have been migrate to ISO for almost 20 years now. But the pace is picking up. And there’s a lot of initiatives going on, mainly on the Swift side with CBPR plus, that’s the cross border payments and reporting plus initiative, then on the market side, so all the clearing and settlement system, high value payment systems, they’re migrating also on to ISO. And then overall the progress you see on on the CGI and market standardization towards ISO 20022 away from the old standards, again, very much, much focused on the Swift side with the MT standard. So there’s a lot going on and it’s it’s a lot of fun to talk about and helping corporates maneuver around the migration activities.


Craig Jeffery  02:25

So Roman, just covering a few of those items, you know, the market side use, you mentioned high value payments, they might be a wire system in a particular country or a real time gross settlement system that the names all track to urgent payments, high value payments, wire systems. Is there anything else that you’d add to that?


Roman Müller  02:45

No, that’s correct. So mainly, that’s the systems we see main activities, I mean, a couple of providers already migrated. And now that the clearing settlement system is on ISO, and others are still following. I mean, the list is, is very extensive. So it comes from Europe over to the to North America to APEC. So everywhere you have a lot of activities with those providers, but mainly, you’re absolutely correct. This is on the settlement side, and mainly on the high value payments.


Craig Jeffery  03:18

And for those who are not always into payment formats or messaging formats, you mentioned moving from the SWIFT MT, or message type to the ISO 20022. So how would you describe the difference in those types of formats besides old and new?


Roman Müller  03:37

I mean, the main difference, of course, is before it was a proprietary format created by Swift. And this now is really an international standard, also in use by Swift, but also in use with other participants in the financial networks. And it’s all about the richness of the data, or the availability of putting data in a message or an instruction, which you can receive or sent to a counterpart. It’s all about the possibilities of enriching data. And that’s the main driver. It’s all about, you know, the cross border interoperability between institutions, that you have a very limited way of transporting information data to one another. And with the ISO standard, you have an incredible amount of options, so called tags to transport information. And of course, that corresponds way more with the world today where a lot of additional information is needed. Almost every country needs like payment purpose information or tax information related to any cross border payment. So all that really is only really supported by the ISO standard and in the MT world, it just, it just has an end to what information you can actually populate. So I would highlight that as the main change, so it helps really, for straight through processing quality of information. It also helps, of course, for AML and KYC purposes, the more you are structured on the data side, the easier it is to implement that worldwide among all the players operating with the same data.


Craig Jeffery  05:29

You know, we may be familiar on the corporate side with things like an MT101 or an MT940, MT101 being like a wire transfer format. An MT940 is prior day information reporting, those are some of the standards that people may be used to. And you know, as you talked about the more enriched data, the requirements for countries may require additional information for payments to go through. So they add it. And the old formats are very limited. You can’t just add stuff. And so you’re saying the richness of ISO 20022 allows you to add that as these changes go on, it’s a much more flexible, standard and enriched format. And I think with all those changes, it’s sometimes we don’t recognize how important that is what you what you just said how important that is, and adapting to the world around us.


Roman Müller  06:17

Absolutely, that’s key.


Craig Jeffery  06:18

And Roman, you may think I’m trying to extend our entire podcast into just the overview. But there was one other thing you mentioned CGI-MP, the overall market standardization, can you give us the definition of the acronym?


Roman Müller  06:32

So yeah, that’s CGI-MP, it’s mainly used around the team that is formed for the market practice group. So basically, you have the ISO, an international standard that has been used, I mean, you have, you know, of other ISO standards, not to 20022, but 27001, in regards of certification of companies. But here, you have the ISO standard. And then standardization is one thing, you have a big big paper and all a lot of possibilities. But mapping this actually in the in the real world to say, you know, and into the usage or, or the possibility to use it. That is the common global implementation market practice group. So that’s a work group getting together, a lot of people, all specialists renowned in our market, and they really focus on okay, this is the standard, this is what we want to achieve. Now, what is our guideline for all those operating in our segment, and how to do that. So it’s a guideline, and it’s best practice, and even the use case adaption on how to use, for example, the PAIN one version 3.1, version nine, also on the camp, so the account cash account management, formatting. So all that is really a use case and helping others to understand how to adopt to these formats.


Craig Jeffery  08:11

That’s excellent. So the I know, there’s a lot of comments about, you know, the beautiful thing about standards is there are so many of them. But this CGI, you know, market practices designed to make it so that people are adopting it in a very similar way in a standard way. That’s excellent. Yeah. And so you also mentioned two other two other phrases for those who are not as familiar with the language. You mentioned CAMT, CAMT for cash management, that’s the coding for the XML implementation of ISO 20002 standard for reporting, and PAIN for payment instructions. This is awesome. So glad to be talking to you about this. Now, let’s get into the some of the details of the ISO 20022 changes. Maybe you can tell us what are some of those, those areas, and you talked about enriched information, but let’s let’s get into that.


Roman Müller  09:04

Yeah, let’s get into that. And I think the focus should be now really, on the corporate side. I mean, we know that a lot is happening on the interbank side, and there is direct or indirect indirect feedback or impact for a corporate, but mainly on the corporate side. As you mentioned before the CAMT, so the reporting we have nowadays, on an intraday or an end of day reporting, that is really switching from the MT940 942. Again, we hear the MT standard and it’s going to be substituted by the ISO standard which will be the CAMT53 for the end of day and CAMT52 for the intraday, I mean, it is something as mentioned, you know, since 20 years we are on the ISO migration. So a lot of banks have not adopted the CAMT5253 But now with having all you know the market systems migrating and changing into ISO, the demand is there that in a consequence that end to end, you would need to adopt to ISO and that, of course includes also the reporting side, your daily statements you will be receiving  Besides the statement side, of course, then the payment side, many corporates still use an MT101 through an agent, forwarding agent to do their payment initiation. Usually that is in use for treasury payments, higher volume, urgent payments, that is common practice at the moment. And that will also be migrated to the ISO standard. So this part is on the payment. Then you also have a payment section, which would be the regular AP payments, HR related payments. Mostly corporates are already on ISO, usually it’s the PAIN1 one version three. But here, we still see a lot of domestic implementations, domestic formats. And that will also consequently, move completely away to ISO.  Timeline, that’s another topic.


Craig Jeffery  11:16

I have a question.  When you talked about moving end to end, is that, I’ll give two options, because I’m I’m not sure exactly what you meant.  One was, is end to end, you know, information is provided in the ISO 20022 standards and payment instructions are also in ISO 20022 standard, or is it that once it’s in this enriched format, it stays in that enriched format through the processing systems or something else?


Roman Müller  11:41

No, no, it’s really the best case is that once the initiating part is on the enriched version data, then to transport and to enter the information, which is needed, maybe in the in the ultimate beneficiary, which is needed, maybe on the interbank interbank side, if there’s an intermediate bank, so it’s very important that all that information can be transported, end to end. And In consequence, when you look at that, that would mean that really from the initiating side, to the very last bit of the information processing, back and forth between all institution, it has to be like one standard. And that standard can be only ISO 20022.


Craig Jeffery  12:28

Right. I guess if you go from an enriched standard to an older standard, you might lose information or value.


Roman Müller  12:34



Craig Jeffery  12:35

And there’s extra transfers. Yeah. So So Roman, you’ve you’ve talked about some of the benefits, and you know, being able to support things like new payment requirements, information that goes through there.  Is there more information about those benefits? Are there is there? Is there anything else on the benefit side that a corporate treasury or payments professional would want to know?


Roman Müller  12:59

Yeah, so as mentioned, enriched data, I think that’s the main topic, it really helps you. I mean, imagine with enriched data, what you can do, you can drill down, you can do reporting, you can do analyzes, in a way, way better option than done now, on a limited format. You have, of course, in regards of compliance and regulation requirements, just a possibility to comply with those requirements. Or you can add all the information needed. Compliance team will love ISO, because it has so much data, and so much standardization, that screening and any checks you wouldn’t apply would be way easier. And it has way more flexibility than then the MT standard. So let’s say we have an initiative and we realize one of the use cases we have with the on the interbank side or with the corporate side, it’s easier to implement it into the standard. It’s already there. And you don’t need to change the MT again to add a field or something which the systems cannot read. So the flexibility is also very important. And lastly, I think competition and innovation based on XML is also very helpful, because with the richness also, you support a lot of fintechs to do additional services for corporates, but also for banks, on the data available.


Craig Jeffery  14:27

Summarize it in perhaps a slightly different ways that the the old formats are inflexible, you can’t make changes. The newer formats allow for more adaptability over time, and more information and better information supports the underlying systems. Is that accurate?


Roman Müller  14:46

Yep, very accurate.


Craig Jeffery  14:47

Okay. Excellent. That was a great explanation. This idea of the structure to address is usually we don’t have a lot of conversations about formats, though payment people and messaging people do like that. I’d love to get into some of the details about the structure address, what is it? What’s it about? And what does that mean for the corporate payments and information personnel?


Roman Müller  15:11

Yeah, that’s a very interesting topic. And there’s been a lot of questions also coming my way from corporate side about this requirement. At the moment, since we operate, mostly, we talk about the MT101 structure or maybe an MT103, which at the moment is to standard for the interbank payment transfer. The address usually is unstructured. So you have in the MT standard, you have like four lines, you can add to your account, like for example, as an ordering customer, and there you put in your address. And as you know, there’s a lot of different ways to populate an address and how an address is actually populated. Depending on the market, you are country you operate. So wait to switch to ISO. And ISO offers two options, basically, you can do the populate address in an unstructured way. Or you can do it in a structured.  Unstructured means it’s just a couple of lines, and they just, the tag is like address line address line address line like that. But if you want and coming back to the benefits mentioned, if you want to really take advantage of ISO, and you want to use that to automate processes to improve straight through processing, then you need structured data. So the postal address of a beneficiary or an in an ordering customer, if that is provided unstructured, it doesn’t help on that point. So to automate things, it should be structured and the requirement was clear under the ISO initiative, you know, CBPR plus, to provide a structured address by the end of the so called coexist coexistence phase. So that is the phase where banks really can only sent their packs 008, that’s the interbank substitute message for an MT103. Only then, and the requirement was clear, it had to be a structured address. And that generated quite some noise, because it’s, from a requirement perspective, almost impossible to comply with that if you look at all the markets, and all the players involved in all the countries, instead of having a full structured address, there’s different options now. And also, the timeline has stretched, which is very important for the corporate, instead of just having the need to only allow the structured option, which you can imagine has quite an impact on the bank systems, but also the initiates initiating site for corporate, because they need to also structure the data on their end. So what changes now is that there is still the option if you have the capabilities to send only structured address data. But then also, from November 25 on, the hybrid approach is supported. But still until November 26, you also have the unstructured option, still supported.  By end or November 26, we then switch to only two options. Either you have a fully structured address provided, or you still go with the hybrid option. So that’s important for the corporate to know, at what point the bank will also switch to a certain option in their systems. And they may or will have requirements to anyone initiating an instruction to comply, of course, what they need to provide in their system sending that out. So it’s very important to understand.  It’s not as critical the timeline, as it showed, like early this year. So we, or the timeline was estimate, but it’s still there. And it’s still gonna be activity also for the corporate, very much depending on its banking partners, what their requirements will be and when they will be switching their systems.


Craig Jeffery  19:27

Yeah, I guess some of those for the corporates may last as much as about three years from now the time of this recording.


Roman Müller  19:33

Let’s see hope for the best for all of our clients, I would say.


Craig Jeffery  19:38

It’s in this this coexistence phase of the older formats and the newer formats being supported. You said something that I just want to make sure that all of the payment professionals and treasury professional understand.  A new format, that there may be requirements.  Whether it’s in whether it was in an old or new format, there may be additional information that needs to be sent. It’s not just having the format, but you have to have it in the underlying system. So you have to fields to capture that. So it’s it’s, it’s about formats, but it’s also about the underlying information.


Roman Müller  20:09

Absolutely. So the static data corporates have in their system. At one point, you know, they need to look at, how is the data available in my system? And how can it, can it be populated when sending it over? Do I have an intermediate like, you know, like a service provider like Fides who can convert or map the data according to a bank requirements? Or do I already need to change on my side? So these kind of questions are most important for a corporate as soon as we know, you know, what their banks will do.


Craig Jeffery  20:46

So what should corporations, corporate payments, professionals, corporate treasury professionals, what should they be doing to get ready for this?


Roman Müller  20:56

I mean, most important is, of course, understand your banking landscape and understand your bank’s plan. This doesn’t only relate to the address part, but overall, the plan of the banks on the ISO migration part think that’s most important? What is my bank planning? When do they have fixed deadlines? When do they keep the decision open to the corporate, some banks will keep on accepting empty one on even over the deadline, and they will fit find forms for corporates to still sent the old formats. Some other banks will have a hard cut. So it’s really important. What are my banks plans? And and how do they support me as a corporate? Or how do they enforce their requirements, which they need to comply with when they send data to other systems in the market infrastructure? And then secondly, as mentioned, understand your data.  If you understand the requirements, and that means your whole ecosystem, not only banks, but your ERP, TMS provider, data aggregator, if you have in place, then understand your data and understand their capabilities to support you to support the bank’s requirements. And that’s, I mean, the most important, really understand then the suppliers vendors, as mentioned, like the ERP TMS provides other day plans to day support a new version, can we switch bank by bank account by account? Like these kinds of plannings are most important.


Craig Jeffery  22:35

One of your comments here about what is the bank doing when when all the required changes? Will they allow something after the fact? It also makes me wonder like, how will they support if you don’t send enough information? The bank is gonna have to set up some other place where you add information somewhere, if you’re not sending it and it’s required. That’ll be really, though sounds like really good conversations to have.


Roman Müller  22:56

Yeah, I mean, imagine, yeah, you would need to enter additional data in the bank portal. But it could be, you know, even that some banks will be quite strict, and they will just reject the message. And they tell you, it’s not what we expect. I mean, if you look at the address, maybe coming back to that structured address, the requirements really vary from country to country. And it’s a very interesting topic. I mean, if you’re sending a payment, let’s say, from the debtor or creditor in the US, then the mandatory fields are different than the mandatory fields, for example, in Switzerland, there’s really market by market, there are differences and imagine as a multinational, corporate, you need to know that and you need to manage that in your system. So at one point, you probably need to see where do you operate, and then see the common ground, let’s say have the mandatory information on the addresses, be it on the debtor or creditor side? And then understand which countries for example, have like very specific mandatory field requirements you need to comply with and you need to deliver to your banking partner? I think that some activity definitely that will happen for a corporate, but luckily, there is us right, Craig, so we can support them.


Craig Jeffery  24:22

Maybe we could just take a moment to if you could give a a quick overview about Fides and your some of your background.


Roman Müller  24:31

Yeah, sure. So Fides Treasury Services we are leading multi banking provider, mainly focusing on corporates and servicing corporates, and doing this since many, many years.  Multi banking has been part of the Fides business in the 80s. We started in the 80s on the reporting side, but that has been growing since.  We have over 3000 customers servicing and have different systems operating. So basically, we operate clients for pure straight through processing, clients for pure connectivity services. So they’re outsourcing their bank connectivity to us. But we also have a lot of services around enriching data, transferring data, conversion services. So all that and of course, aggregating the data, harmonizing the data to the clients. And my role in Fides is as chief client officer.  I’m part of the executive management of the company. And as the title says, it’s all about the client and which I believe is always the best course in my department. So we are delivering a project onboarding services for new and existing multibank clients of Fides, also servicing all operational requests within the client services team on a day to day level. And in addition, the product management is also part of my department, where the whole ownership on all our products and services is and where we ensure that new products and enhancements will be delivered to get together with the Fides technical teams.


Craig Jeffery  26:18

We’re hearing a lot of terms, we talked about PAIN as a payment instruction. Let’s go through the codes and numbers. So PAIN.001.001.09. What does that mean and where we’ll be used?


Roman Müller  26:32

Yeah, so PAIN is the payment initiation, short for payment initiation. It’s used worldwide. It’s really used for corporates, for any AP HR related, so regular payment flows is usually in a PAIN. So it’s a bulk payment message usually can consist of one to multiple 1000s of transactions, and the numbers at the end, the 09, that’s the versioning of the PAIN. So the CGI market practice group or the ISO group, they will always develop and enhance the standard. And the versioning, it started at the version one then went into version two, version three. So at the moment, what you see amongst corporates, usually, and I would say probably 90%. They’re all using version three, which has been in effect for I think, 15, almost 15 years.  You also see still some implementations with the version two, which was released a couple of years earlier. And in between, then version 4, 5, 6, 7, 8, they all came but they never went into the market. And now this version nine has a clear stand into the market and the professionals because it’s going to be fixed by Swift, that it’s the standard to be used for the relay payment initiation. So the substitute for MT101. And also CGI-MP has a clear focus that this is now going to be the market version, which should be widely adopted and get into use amongst all the professionals.  The version nine is going to be the one that is really supporting all the initiatives going around really ensuring and and, again, focus on the quality and richness of data to really ensure that all of those use cases we have in the payment world that they can be implemented and reflected in that version.


Craig Jeffery  28:58

So you had mentioned the bulk payments, like in the US like ACH or low value payments. And then you mentioned MT101, so those are like wire or high value payments. So nine will cover or does cover everything more gracefully.


Roman Müller  29:15

Yep. And ultimately, the goal is that this version nine will cover everything. But be honest, I mean, at the moment when you look at the US, ACH payments, you still have the option to do ACH domestic format or you go into a PAIN one version three at the moment. The availability of the PAIN one version nine, some countries some banks already support it for corporates, but I mean widely and I can also tell that from a live view from our onboarding activities we have with our clients. At the moment every single client is still onboarded on PAIN one version three when we do that.  But we expect that in the coming month, latest years, you know, the version nine will be the one standard, mainly new implementations will be done. And at one point, banks will also want to migrate to the version nine for the corporates. But dear corporates, don’t worry, I expect that the both versions version three and nine that the coexistence will last many years. So there’s no urgency to migrate as of now, unless there is a use case where you need to provide data that can be only provided or accepted by your bank in the version nine. I mean, then it’s really a client focused approach to say, I want this, I want the migration, I want this new version, but it’s not requested or induced by the bank itself.


Craig Jeffery  30:56

Yeah, great points, Roman. So people might be using today the PAIN 001.03, and they’re moving to the PAIN 001.09 for more enhancements, a more resilient format.


Roman Müller  31:15

Yeah, to really support some of the cases and some of the new requirements that are already here, but may also come in future. So it’s, it’s a future proof version, I would say. But of course, the CGI, the market practice, and overall progress will be that there will be a version 10, 11, 12. But I guess market utilization will be really heavily focused now on the version nine.


Craig Jeffery  31:43

I guess it can only go up to 99 because there’s only two positions, right?


Roman Müller  31:47

Yeah. And then probably we’ll just have data databases talking to each other. Right? And no more any formats.


Craig Jeffery  31:59

Roman, could you give us a little more detail on CBPR plus?  Particularly from the corporate perspective, there’s this entire world of banking messages that is sort of like in the cloud behind the behind the curtain that goes on, but there’s a there’s enough of that that’s exposed to corporates that it would be great to know.


Roman Müller  32:20

Absolutely, yeah, so CBPR plus, the cross border payments and reporting plus any initiative by Swift, it’s really focusing on the interbank messaging. So debit to credit bank. And the main focus there is of course, the migration from the MT103, that’s the existing standard, to the PAC008, which again is an ISO standard for for interbank messaging. And here for a corporate, of course, the impact is not direct.  Corporate is not sending directly from transferred.  Corporate is, is initiating his payment with a different format, or different type of message. But depending on the bank sending to the other bank, again, we have the enriched data requirements on the PAC’s level, which has way more capabilities for transporting data than an MT103. And from that perspective, banks may have requirements to the payment initiating part. So the corporate to populate that additional data they need. Now for for a standard payment case, which doesn’t need any specific regulatory reporting or any other specific information, you may transport the message the same way you do now, no additional requirements. But when it comes to certain market requirements, you as a corporate may also have to add information that is needed by the bank to send to PAC008. So there might be not like a direct request to corporates. But maybe the bank will come up and say, look for this kind of payment type you’re doing with us, you need to either add the data to the existing form it or most likely if the format is now an MT101, you need to switch to ISO. So that’s one part that’s going to happen. And if you look at the initiating side from a corporate, usually that is for treasury urgent high value payments, they’re using an MT101. It’s either sent if they have an old corporate bank over their corporate banks, which is not targeted in any way by the CBPR plus initiative. But if the corporate uses a forwarding agent, like Fides or one of the major transaction banks, then they sent the instruction and usually that’s also an MT101 to that forwarding agent who then sends the information to the debit agent, so the debit bank.  And with that case, this will also be migrated and needs to be migrated is also part of CVPR plus.  That means by November 25 as a forwarding agent, you need to send a PAIN one, version nine, a specific variant of that PAIN to the debit bank to initiate the payment, which will then result in a PAC008 to the credit bank. So, here you see already the concept of really end to end ISO support to ensure that the data that is needed from an in sending or receiving side is really transported. So there we definitely see some direct impact. If a bank says MT101 will not be supported anymore, by November 25, maybe even earlier, then we and others will need to look at the options the banks provide, and most likely will migrate their payment initiation flow to PAIN one version nine under the relay case, or it will be just integrated in a regular payment flow the client already has over a proprietary channel non Swift or on file act, and with just a flagging of an urgent payment to ensure the processing and the cutoff times are still met, although the channel does change.


Craig Jeffery  36:39

Tell me if this is also right. This is related to what you said like if a company initiates a payment they send let’s say they can create an MT101 format, they send it to a processing agent.  When that message goes between banks, right? So it’s the company to the bank, and then it’s going to the other bank, that message would probably get converted, you know, last year whatever, to an MT103. So it goes from MT101 to an MT103 and settles and then the high value payment or wire hits the other party’s account in that other country.


Roman Müller  37:15

Correct, yep.


Craig Jeffery  37:16

But so the messaging that happens behind the scenes that the corporations have may not know about is who knows about an MT103. You don’t have to know that. But that’s changing the background transfers are changing from the old style format, let’s say through Swift, for one example, to an XML or an ISO 20022 standard called PACS, PACS.008. So that whole back end system is upgrading to, to support enriched format.


Roman Müller  37:44



Craig Jeffery  37:45

And then in the future, the company side would would send the PAIN.001 version nine, let’s say to do a wire, that goes to the, makes its way to the bank. And when the banks communicate, they would communicate with a PACS.008. So there’s the the what the corporation does, and then what the I don’t know if you call market infrastructure participants like Swift or central banks, but also everybody who’s in that internal sphere is upgrading to the ISO 20022 to make a better, a better payment, backbone or messaging protocol.


Roman Müller  38:24



Craig Jeffery  38:26

Any any other news from the field?  We talked about structured address changes, we covered some other items that are happening in the ISO 20022 world. Anything else we need to know about these changes, about about banks and connecting with them?


Roman Müller  38:44

To latest news, I mean, the most important is about the structure the address. So the changes to ease a bit the pressure overall in the market, that’s very important. Then, of course, the activities around the activation of the new request for transfer relay case. So by November, Swift grants the possibility to already do that in the new PAIN one version nine option. But what we see and this is really news from talking to several banks about their plans, nobody is an early adopter, so, or very few. Let’s say that.  Even like to tier one banks, it will be 24, 25 when this will be activated. And the detailed plan on when migration happens is not yet there. And also talking to some banks where they even say that they won’t be ready by November 25, they will seek alternative options to still support like the old formats. I expect that as we see now with destructured address with pushing that hybrid option further down the line and even the unstructured to be supported until November 26. I believe we will see still some additional movement on the timeline, some will not be ready. And I mean, you cannot cut off banks from from the SWIFT network. So there will be options to still follow up on that format. But in consequence, at one point, you know, it’s clear where the target goes, it will happen, but probably not as fast as people think, like read all the topics, you know, five years ago, everybody said, payments will be on the blockchain. I don’t think they are at the moment. So it’s probably slower. But if you look at the benefits and overall goals within the harmonization and standardization, I think I know where we are going, but probably just takes a bit more time than in the beginning people thought or wanted to achieve.


Craig Jeffery  40:52

So Roman any any final words or thoughts?


Roman Müller  40:55

For the corporates, really understand the plans, understand what banks support and and what will what will be your need? Understand your systems, talk to your providers, talk to specialists like Strategic Treasurer, to Fides. They can help you understand that timeline will change most likely.


Craig Jeffery  41:18

Roman, thanks so much for your time today. Your comments, and I really appreciate you joining me on this podcast.


Roman Müller  41:23

You’re welcome. Thanks a lot for having me.


Announcer  41:28

You’ve reached the end of another episode of the Treasury Update Podcast. Be sure to follow Strategic Treasurer on LinkedIn. Just search for Strategic Treasurer. This podcast is provided for informational purposes only, and statements made by Strategic Treasurer LLC on this podcast are not intended as legal, business, consulting, or tax advice. For more information, visit and bookmark

Related Resources

Guide to Excellence in Treasury eBook
Guide to Excellence in Treasury eBook With insights covering everything from important steps for the new treasurer to leading practices for securing resources, overcoming blind spots, staff development, metrics, technology, working capital, and more, the Guide to Excellence in Treasury eBook offers strategies and fine-tuned approaches to major areas of challenge for treasurers.
Session 44 - Coffee Break Sessions
What is ISO 20022? Coffee Break Session Host Alexa Cook catches up with Strategic Treasurer’s Managing Partner, Craig Jeffery, to discuss what ISO20022 is, how it’s pronounced, and how it has impacted the treasury world. Listen in and learn a little bit about ISO20022.