Phillip Bowkley, Head of International Corporate Banking Business at Barclays:
Welcome to Barclays’ ISO 20022 webinar for our international banks and the payment service provider clients. I hope you're all well and keeping safe.
My name Phillip Bowkley and I'm Head of International Corporate Banking Business at Barclays. I have responsibility for the corporate banking client franchise for our international corporate clients, financial institutions and the international corporate bank teams across the UK, Europe, Asia PAC, Middle East and the Americas.
Before we start, I'd like to mention a couple of housekeeping points. Firstly, subtitles captioning is available on the feed for those who find that useful. And there's a Q&A box under the video feed, and I do encourage you to ask questions through that mechanism. We'll look to answer as many of those questions as we can with our experts at the end of the webinar.
So the payments industry is at the start of a significant and really exciting journey that will result in a transformation to data-rich payment formatting, significantly increasing the amounts of valuable data that can be sent and received. In the past, banks have been constrained by interbank formats, which have restricted the amount of data that their customers can pass through the central clearing systems. Finally, SWIFT and the world's payment schemes are coming together to provide an improved client experience through the migration into the data-rich ISO 20022 payment format.
Over the coming years, we'll be working towards an end state that will see one of the biggest changes in the payments arena in a generation. And this transformation will commence in the interbank space, but will eventually offer huge benefits to our corporate customers and their business models and their propositions.
Now, I have to confess I'm not an expert on ISO 20022. So I'm pleased to be joined by three people who can rightly claim to be real subject matter experts on the subject. Firstly, we've got James Southgate. James is a Senior Manager on the Bank of England's Real-Time Gross Settlement, or RTGS, Renewal Program. His responsibilities include implementing ISO 20022 messaging in RTGS and CHAPS, and designing improvements to liquidity-savings mechanisms. He's worked closely with Pay.UK to design a harmonised pacs.008 common credit message, or CCM, for use across both CHAPS and new payments architecture.
He's joined by his colleague, Liz Leather who's a policy analyst working at the Bank of England, specifically looking at how the bank should implement ISO 20022 from a policy perspective, i.e. makes best use of its capabilities for our RTGS and CHAPS services. I'm also joined by one of my colleagues from Barclays – Maarten Lossie. Maarten heads a team of product managers with global responsibility for clearing and indirect access solutions that enable our banks, broker dealers and fintech clients to provide payment services to their underlying clients. And Maarten is also a member of the BAFT Payments Committee.
James and Maarten and Liz will discuss the what, the when and the why of ISO 20022 format migration, including a vision for the target end state of the payments infrastructure globally, the rationale for migration to ISO 20022, and the key changes and benefits for the industry and our clients. They will also discuss the Bank of England requirements covering what new data is mandatory, how this will be enforced and importantly how can we help drive towards best practice.
So, with that, I'm going to hand over to James and Liz now to introduce in more detail their roles at Bank of England, and talk more about the RTGS Renewal Programme, and how Bank of England is approaching the challenge and also how they're collaborating with their international counterparts. So James and Liz over to you. Thank you.
James Southgate, Senior Manager at the Bank of England:
Great. Thanks very much, Phillip. And I'd just like to say thank you for inviting us along to this webinar. It's a great opportunity for us to reach out directly to the indirects in CHAPS, and in particular for us to outline what it means for you as an indirect. In particular, at the end of our 25-minute slot, we've got a slide which has some useful actions and takeaways for you.
In this 25-minute session we'll give just a brief overview of what the Bank of England's RTGS service is and why we are renewing it, which is a wider project than just the move over to ISO 20022. But nevertheless, what ISO 20022 is, what we see as being the benefits of moving from MT to ISO 20022, some of the work on market guidance – and indeed, related to that in the international space in particular, there's work going on at the PMPG at the moment on guidance for cross-border transactions – the key timelines for us in the UK, and then those key actions for you to take forward.
So as an introduction, the Bank of England was one of the first systems to adopt a true real time gross settlement service rather than using deferred nets. As you might be aware, Canada is only just now starting to move on to a real time gross settlement service. Our system is 25 years old, as of now. It's generally been very resilient and reliable, but it reflects the structure that was in place at the time and, in particular, a world where everyone went to a few large clearing banks and that was it. And certainly not the world we're seeing now of as well as the established clearing banks, new payment providers wanting to come in, people wanting to move to cloud-based systems, and we've got to remember as well that one of the key drivers for us is the fact that SWIFT itself will be moving off the MT standard – looking to retire that in November 2025. So, we want a system that is ISO 20022 based from the very outset.
So, to give a brief picture of what RTGS does. Effectively it’s at the heart of the sterling payments landscape, rather than the UK payments landscape, in this context. But, importantly RTGS is the system that sits at the bank that settles each of the CHAPS high-value payments on an individual real-time basis. And we have 35 direct participants in CHAPS now and they then have relationships with we think around about 5,000 indirect participants across the globe.
In addition, RTGS is also the system that does the cash leg of the settlement in CREST for the UK security settlement system, particularly for UK government bonds and equities. And it also settles the UK sterling domestic clearings as well. So it does the UK domestic clearing for Visa, it does the UK's LINK ATM network, Faster Payments solution, BACS – which is its old school ACH – and now the image clearing system, which has replaced the paper check and credit system that was in place previously.
I'll now hand over to Liz who will give an overview of ISO 20022, and how we are implementing that for CHAPS in particular. Over to your Liz.
Liz Leather, Bank of England Policy Analyst:
Thank you very much James.
So, ISO 20022 is a new messaging standard for CHAPS. And, just taking it back 20 or 30 years… Messages were built to be small, so that they could be sent across the network. These days, messages can be huge and using this kind of knowledge and using the fact that, if you can send a lot of data, then you can send a lot of information about why the payment is going, how the payment is going, what is it for, then you need some kind of structure and some kind of standardisation around that.
Now the ISO organisation is a global organisation made up of 165 members of national standards boards. And they do everything – or ISO covers everything – from baby car seats to payment messages, and its experts getting together to agree a standard.
We say it's a new messaging standard for CHAPS, but ISO 20022 has been around for a few years and already some countries have already moved to a version of ISO 20022. I'm talking specifically Switzerland, China, India and Japan. Over the next few years, many, many more countries will be moving to ISO 20022. And given that it's got a single standardised approach of methodology, process and repository, it's built using a programming language – XML – which is machine readable, human readable, and can be used to really categorise data. So nest data, which can be sent easily across networks. It is absolutely ideal for integration into other systems, for example enterprise resource systems, which are already built using XML.
I talked already about the fact that we are going to be sending lots of data around the system. And there'll be an increased focus on use within APIs. For those of you who are not as technologically focused, these are application programming interfaces. And the analogy I like to use is if you're in a restaurant and you want to order some food, the waiter is the API. He comes, he asks for your order, he takes your order to the kitchen and he comes back with your food. So this is exactly the same. You make a request and the waiter being the API will go away and get that data for you.
The other particular thing about ISO 20022 is that the financial service community are able to propose changes to existing additional messages, making the standard completely flexible and adaptable. I talked about lots of data, I talked about structured data, I talked about nested data. And all of this, along with the APIs, leads to improved analytics. It leads to flexibility. So if you are able to influence a standard, then the standard responds to progress over the future, to progression of events. You can use the data in ways for compliance and regulation in terms of fraud, and so on. I'm going to come onto that a bit later on in the examples that I give.
There is the transmission of enriched data – we keep talking about this more structured, more data, but that really leads on to the improved straight-through processing. Because if you know where it's come from, where it's going, who it's for, and you don't have to stop the process in order to say, “well, something doesn't look right”, then immediately you have a faster structure of payments moving through the system. So, more flexibility means more competition and innovation.
The APIs, the application programming interface we talked about pulling out the data, these can lead to all sorts of interesting benefits and so on, which for the future could be very interesting. And moving on from that, you have improved harmonisation across global payment systems. So for example, we talked about SWIFT moving, we talked about the ECB moving, and so on and so forth. And therefore one direct message sent, in one particular place, will be readable in another place. And this leads to higher interoperability and higher resilience between all the different payment systems.
I talked about more data. More specifically, there'll be enhanced data within CHAPS for using the ISO 20022 standard. And these are particularly purpose codes. What the payment is actually for, a legal entity identifier, who the payment is going through, and who they actually are. Remittance data, more structured remittance data – so more fields. And we'll see a bit more in an example later on.
Structured addresses – no more free format, you will have different boxes for the different parts of the addresses and extended character set. So the ability for now, for example, to put an email into the system for contact information. So really moving with the times.
This slide I'm going to move on from, because already I've talked about the benefits of structured data. And in the next couple of slides we're really going to pull out these examples through some real illustrations. So for some of you, this will be very familiar.
SWIFT MT103, the old world, and this is a customer credit payment. And we have two fields here that would appear on a SWIFT MT103. And these boxes are almost exactly as they would appear on the payment in terms of size. So you have field 59 recipient details, and you have field 70 remittance information. As you can see from the actual information contained in there, it's a little bit unstructured, it's truncated, and it's almost falling out the box. And indeed field 70 is actually only four lines of 35 characters.
In the right hand side, you can see from our future ISO 20022 message that you're going to have a lot more structure. You have the name and a legal entity identifier. So clear separation of the name, the legal identity identifier, and the address. And the address is fully structured. You have a purpose code, so what the payment is for, and then you have the remittance data, a much larger field in order to put in something that actually makes sense.
Some clear advantages from this are there's less stopping of the data to say, well, what does that mean in remittance information? You also have, for example, and taking address as one of the clearer ones, if you were having to look for a payment that was going to a particular country and you wanted to search for that in recipient details, you might pull out lots of different information. So this one, for example, is Iran. You might be pulling out the Sino-Iran Institute in Gloucestershire, for example, or the Iranian Fund in Paris, but you might not particularly pick up – whereas you could in the new world – that the actual country is Iran. So you would get less false positives, let's say ten on the left and you get the one return on the right. So, this is another example, and this might be for some of your customers, or it might be something for yourselves as well, but it illustrates this quite nicely.
I've said already in the remittance field that previously you would only have four lines of 35 characters. And in it I've managed to fit about 8 invoice payment descriptors. In the new field, I fitted 20 payment descriptors. And I have also put some context around what the payment is for. And I've also managed to put some contact information because of the enhanced character set. And this is just one example of the advantages for corporates. There'll be enhanced cash management, enhanced reconciliation of invoices, and the list goes on from the amount of enhanced data and the ways in which you can use it.
The last example came out of some of the market guidance that we worked on. I'll come to this a bit later on. And this is a specific UK example, but it just gives an example of what you could apply this to.
So, in the previous SWIFT MT103 world, as the customer credit payment, again, I'm talking about the remittance information. You only have four lines of field with 35 characters ability each line. And, the data is cut off again, and you cannot keep much information in it. Now here in the UK, there is an example that perhaps about five years ago one in 300 property payments was fraudulent. And quite a lot of the time that is fraudulent people getting in between the person paying for their house and the solicitors who would receive the payment and then on-pay it to the representative of the vendors of the property.
So, as part of the market guidance, a use case was evolved where potentially the enhanced data could help. For example, we have a purpose code at the top, which would say UK residential property purchase. And by identifying that, for retail customers, this is probably the biggest payment they've made in their life, but also it's one of those payments that looks very strange for someone to be moving such a large amount of money around the system. So often, they can be flagged and stopped in terms of movement. And obviously from a retail customer’s perspective, that is quite worrying because often they have very short timescales in which to complete the purchase of their property. So by putting in a purpose code, it means that you can really identify, "oh, it's a UK residential property payment”, okay, we will let this payment move through much more quickly.
Secondly, we have the name and the legal entity identifier. So, this can be cross-checked to make sure that the actual solicitors or company actually exists. And companies are encouraged to apply for legal entity identifiers over the next few years if they don't have them already. Because these will be part of some of the mandatory requests that we're asking for data, but also, in this particular case, it really helps identify that that particular corporate or company exists and it's not a fraudulent person who's trying to siphon off the money into their account.
Following down to the remittance data, again, it's larger, you can put in identity checks from the solicitor's point of view, you can have advice where the payment doesn't match the group pre-agreed payment, the customer in the UK to often send a pound to make sure the payment goes in the right direction, and so on. I will stress again that this is just a possibility, and this is not yet what we have asked or mandated the market to do.
But then it comes nicely onto the market guidance that we've been working on with an external company whereby we have been identifying several use situations whereby structures of payments would benefit from guidance on how to use the enhanced data from the ISO 20022 payment, in order to really benefit from its capabilities. So, for example, we've just seen a property payment just then whereby using purpose codes, LEIs and so on you can really address some of the potential problems in the market. We have published already our initial guidance on the property guide, and we'll be looking at several other use cases going forward in 2021 and 2022.
I will now handover to James to talk about our international corporation.
Brilliant, thanks. So, in terms of our domestic and international cooperation, obviously one key question is how are you ensuring that what SWIFT specifies for its cross-border network is going to be compatible with CHAPS, going to be compatible with Fedwire and even here in the UK as well?
Phillip mentioned the common credit message. So, we will effectively have a very similar – not absolutely identical because there are slightly different elements to our schemes – but a near-identical pacs.008 credit message between us, as operators of CHAPS, and Pay.UK who operates the new payments architecture that will replace both the domestic Faster Payment system in the UK, which currently operates on a modified version of ISO 8583, and then in due course BACS, which operates on its own proprietary standard – Standard 18, which I think actually dates from 1968.
Importantly, from an international perspective, we've made sure that the CHAPS schemas are compatible with two different pieces of guidance. So the first one is the HVPS+ guidance, and this has been put together by a collection of the largest high value payment system operators internationally. This includes us, ECB, Swiss, Fedwire and CHIPS. It also includes BOJ-NET, who are already on ISO, but they will upgrade their version in due course so that we're all on a common version.
So that's the market infrastructure side. But then, very importantly, is the CBPR+ guidance. CBPR+ is the name for the cross-border, or rather, correspondent network. So when any one bank is just messaging another bank on SWIFT. We've made sure that we're aligned with the CBPR+ guidance so that when you send a message to Barclays to then be on processed through CHAPS, you don't end up with any truncation issues or things like that. There is some specific UK guidance around and this is where it comes to the Bank of England requirements.
I don't really like the phrase ‘gold plated’, but to be clear, every HVPS system operates in a slightly different way. So there are things like priority codes for CHAPS payments, so that you can choose where they fit in the queue, if any CHAPS payments are queuing. So those are the added things where we'll have some specific requirements around that.
But the key thing is that if you put a message in via CBPR+, that can be translated fully across in the CHAPS message that's then generated by Barclays without the loss of any data. And indeed if that was then to go on to a high value payment system in another country, certainly for the major HVPS operators, if there is any change of currency, there shouldn't be any truncation further down the chain.
Someone asked me how we made sure that that was really true. We did literally sit in SWIFT's offices back in April 2019 in New York, round the table for three days, we went line by line through our draft schemas, made sure that we're all interpreting things the same way, and made an agreement for how we interpret it if we'd come to a different conclusion. So, we have looked at that very carefully.
The next slide is around what are our timelines specifically for CHAPS. So, we've already completed our phase one. And this is about producing all the documentation, all the artefacts that are necessary for CHAPS direct participants and indeed the wider community to understand both the technical schema and our policy around inclusion of certain information. That information is available on our website. The easiest way to find it is just to Google search for Bank of England ISO 20022 because that will lead you to the home page and then there is technical information available.
The next key phase is almost a year to the day. And that is when we cut over from the SWIFT MT network, which carries the MT messages, to the SWIFT MX network, which supports ISO messaging. And because of the way the CHAPS network is designed, all of the direct participants move over one weekend. And in order to a) ensure that we hit this timeline of June 2022, but also to make sure that we don't concentrate too much execution risk in a single weekend, we will move over network from MT to MX, but the messages will effectively remain the same.
Therefore from your perspective, as an indirect, I suspect you will see very little, because you will still be sending and receiving the same data to and from Barclays. Indeed, we recognise that we can't go live with any enhancements until CBPR+ itself goes live, which is expected to be in November 2022.
So, between phase 2 and 2.1, SWIFT CBPR+ should go live. The ECB is also going live at roughly the same time. And then from February 2023, we will move to our enhanced schema. So we will allow this additional information to be sent for within any CHAPS payment messages. There is no requirement to start using any of the enhanced data from day one. That is entirely optional. The minimum requirement is just on a like-for-like basis. However, you may start to receive, obviously, Barclays may start to receive as the DP, and then it may forward on to you if the payment is ultimately for you, any enhanced data that has either come from another CHAPS direct participant, or indeed may have come from another CBPR+ member who sent it to their different correspondent, who's then forwarded it on to Barclays.
So the key date for the indirects is this February 2023 date, as what you receive may change, and what you can send will change.
Phase three is more an internal-facing element for the bank, because that is when we undertake our core ledger change. We've changed the messaging side at the front end, but the backend core ledger changes. And that is really about changing the way we process payments and making it easier for new participants to onboard and the like.
And that is an ISO native system. If you happen to be a reserves account holder, so not a member of the payment schemes but a reserves account holder in our TGS – and there may be a few of you out there, if you've got a UK branch or subsidiary – that is the point by which you will have to have switched to MX statements. So, when we send you a daily statement for your reserves accounts, that will need to move from an MT950 to a camt.053 over the MX network. There's going to be separate communications about that directly from us, so, don't worry about that and we are planning something over the next couple of months.
Then the next key date is the mature phase. So once we've done all the technical changes and given people a window to prepare themselves to send and receive enhanced ISO data, we will start to mandate some of the enhanced data in specific transactions. The first ones that we'll mandate are purpose codes and LEIs for payments between financial institutions. So the pacs.009 messages that replace the MT 202s. We'll also mandate purpose codes for the UK domestic property transactions so we can prioritise them in the event that there's any operational disruption.
That mandation only applies to UK domestic transactions at this point, because we recognise that the broader correspondent banking network is on a dual-running period effectively between November 2022 and November 2025 of MT and MX. So recognise that some people may still be using MT at that point further down the chain, and won't be able to instruct or include the purpose code or LEI necessarily. But we are looking at then mandating the use of structured addresses and remittance data, and potentially making that a more technical mandation from November 2025, or, indeed, whenever SWIFT switches off the MT network for the 1, 2 and 900 series messages – we recognise that that needs to happen first.
So, in terms of where we are versus the international timelines: we go live for like-for-like in June 2022, and then February 2023 SWIFT is moving CBPR+, it's enabling ISO from November 2022. The ECB moves TARGET2 in November 2022 and I think Australia moves at the same time, or very broadly the same time. Fedwire and CHIPS, they are currently expected to move in late 2023. At the moment there isn't any formal date, because the Fed is reviewing timelines in light of COVID, but also in light of the fact that they're prioritising the go live of their FedNow faster payment system. There should be an announcement from them fairly soon, over the next few months, but the best estimate is probably late 2023, that may slip into 2024. But it means that there's a lot of international infrastructures all moving over.
The key thing to note is we're all moving over to the same, newer version than those that are already implemented elsewhere. I think Japan and Switzerland have indicated that they will be updating to the version 8/2019 in due course. But they will separately announce that.
And then just for a little bit more information, this is more for a takeaway. This is the enhanced data that we'll be requiring and when we'll be requiring it. It's a very long time scale, to be absolutely clear. This is looking at not only Spring 24, but November 2025, and then beyond that as well. Ultimately we are looking to make these particular elements mandatory for both receiving and sending in CHAPS, and that will downflow into requirements for indirect participants. But the timelines are very long and we are going to take a very gradual process to this. We recognise that over the next couple of years we really need to get people to focus on the ISO implementation first, before we start requiring certain elements of additional data.
So I'll just pass now on to Liz for the actions to take away.
Thank you very much, James. So James has quite strongly outlined that there is a long-ish timeline, but we are strongly encouraging you, as indirect participants, to consider how you would plan to move to and might make use of the enhanced data, because when CHAPS moves to enhanced messaging in February 2023, it will still be optional to send enhanced data, but many participants will be receiving enhanced data, and they could be passing them on to you. So you have the opportunity to start considering how you'll process it and how you might benefit from it in some of the ways that we've discussed already.
Going forward from that, we suggest that you speak to your direct participant, or even direct participants, because some of you might have multiple relationships. So speak to Barclays, speak to your other direct participants, and discuss how you might receive this enhanced data.
And then those of you who are already have ISO 20022 compatible software, so James talked about Japan and so on, please review the version capability and consider updating to the version 8/2019 in line with that which is going to be implemented in the next few years with the Bank of England, ECB, Fed and SWIFT, etc. So please speak to your software vendors.
Those of you who are interested in sending enhanced data, speak to your direct participants, speak to Barclays as to how to go about this.
And once again, we'll reinforce the message that it is a long timescale, and we will be mandating the sending of certain enhanced data in CHAPS payments in due course, but not before 2024. And then it will likely be gradual as well.
Thank you very much for listening and now we're going to pass on to Maarten, to talk more about directly how this affects you.
Maarten Lossie, Head of FIG Payments at Barclays:
Thank you Liz. Thank you James. Hi everybody.
I'd like to very briefly share a few comments around how Barclays is doing with regards to ISO 20022. So, to make two key points. The first is that of course, a few practical notes. So when it comes to payments, that is migration to pacs.008 and pacs.009, and when it comes to receipts – that's about your ability to receive or consume a pacs.008 or pacs.009 message when you need to credit your underlying customer, or when it comes to balance and transactional reporting to consume camt.52, 53 and/or 54 messages.
So Barclays is along the path to make sure that we're ready to support you with processing payments in a new format and to send you payments in a new format as well. A key thing to think about is, if that isn't on your radar already, is the SWIFT Transactional Management Platform. When we worked on this topic a number of years ago, the big thing to consider of course is how we handle translation and truncation. So, the translation from the old to the new format and truncation to deal with the fact that the new format can carry a lot more data.
A lot of banks around the world struggled with that topic and SWIFT stepped up through their frictionless payment strategy and introduced the transaction management platform, which is due to go live in November 2022. That platform is quite critical because it means that any bank around the world can send an MT message and we can decide to receive it in ISO 20022. And likewise, our counterparts can opt to receive an MT or in ISO 20022, as per their preference. So, taking that problem away from the industry and resolving it in the central place is very beneficial.
Now, with regards to guidance. An important note to make is that Barclays is not going to reinvent the wheel, as I would suspect all the other banks around the world are keen not to do the same work twice. So our view is to base your work on the CBPR+ standards, and we will then focus our guidance on three specific topics.
The first is any country-specific requirements. So, any of the requirements that James and Liz talked about today with regards to the UK, those are the types of requirements we will be focusing on to customise in our guidance to you. The other, of course, is straight through processing. So you know, very straightforward things, such as please use a BIC or national clearing code to identify the benebank or, in the new language, the creditor agents. And best practice. So, even though the LEI might not be mandatory for foreign banks on day one, it's still good practice to already start to use those data elements, and over time they will become mandatory as James and Liz explained.
There's also an element of education here. So, we obviously have a large group of people working on this topic, and we can share our knowledge on this topic, but I would encourage you to also look at the SWIFTSmart online training courses and the courses that SWIFT is rolling out around the world on this topic. There's also a range of industry bodies and forms that you can use to your benefit. There's a lot to learn about this topic.
And I would say, especially for foreign banks, Barclays has correspondence around the world that we need to learn from when it comes to their local market infrastructure. And likewise, we'd be very keen to share what we know about the UK and European markets in particular. So this is very much an industry change and we’re keen to work with you as we go through this.
Then there are a number of considerations to share, specifically around the timeline. So it isn't just about November 2022 and November 2025. There are also the country-specific requirements to consider. But, in some cases, there are other changes around the world. So for a UK domestic bank, that might be Faster Payments and BACS, but there might be your scarce project resources, specifically the payment experts side, might be pulled into working on Fedwire CHIPS. So identifying when to do what change in this global landscape, as we change to this new format, is quite important.
From a project point of view, I'd like to share our experience to say that although it is a change of format in the payments landscape, this touches every part of Barclays, and likely of your organisation. So think about your treasury departments, your liquidity products, your debt products, FX settlements, trade products, everybody, all these departments, ultimately move money at the end of the day. How they initiate those movements of funds it all relates to a particular format.
Then there is, from a knowledge perspective, I talked a little bit about the industry resources that are available. I would also add to that, that the amount of change going on, both from a geographical perspective and in each country, is so significant that it's quite difficult to keep track of everything that's going on. So building up a model in your project environment to deal with these changing environments is quite critical, we found in our experience.
And then there's the data strategy.
An important thing to remember is that if you want to issue payments with a structured detail, you're going to have to source that from somewhere. So it might have an impact on how your KYC customer data is stored in your core customer system. So, this change could range from your core customer systems, your channels, how you provide MI, how you generate invoices, those are a range of systems that will be impacted due to the change in data strategy.
There's a lot more to say about this topic, but hopefully this gives you some sort of background and framework to think about, and we'd be very happy to exchange ideas about this topic. So please do get in contact with me directly or with your relationship director to expand on the topic. And with that, I’ll hand over to Phil.
Great, thank you Maarten. And thank you to James and Liz as well. Some fantastic content.
We've covered a lot of ground, and not surprisingly it's prompted some really good, interesting questions from the audience. So maybe I'll start James and Liz with you.
Will the enhanced data requirements that will become mandatory in the Spring of 2024, be a requirement on UK FIs only, or will there also be a requirement on FIs outside of the UK?
Thanks, Phil. So, effectively we will not make anything technically mandated, i.e. we will not reject messages at this point that don't contain the information. And that goes back to the fact that we are still on a dual-running period for those that are sending messages via CBPR+.
So, there will be a rule requiring the direct participants to do it, and to encourage the indirects to it. But it won't be a hard and fast rule at that point. But the point we'd move on to that is after SWIFT have closed down the MT surface. So, no mandation at that point, but strongly encouraged not least because it will become mandatory at a later point.
Thanks. Very clear, James, thank you.
Maarten, I think this one's for you. So, clearly in your role, you're talking to a number of other banks and financial institution clients of ours and counterparts. In those conversations, what are you finding are the biggest of stumbling blocks in this project for financial institutions, for PSPs, that you've noticed so far in those conversations?
Over the last nine months, we've had a lot of conversations. I think the biggest stumbling block, at first, was around the misconception, you know, changing a format doesn't sound so big, but when you think about the ramifications for a wider organisation, it balloons quite quickly. I think some organisations knew that when we started those discussions nine months ago, and others are catching up at this point.
I think we're crossing that hurdle now. So it's more well-known within the institutions I speak to. But I would also say that creates a need to establish quite a large project. So in the investment rounds that people will go through this year, that will be an interesting discussion to keep an eye on.
And I think you raised a good point and some of the actions that you and Liz talked about, definitely highlight the need for institutions to be out in front of this, and have well-established programmes that are fully funded.
And a follow on question, maybe I'll ask it to you and to James. Clearly as clients and organisations start to really get to grips with this subject, it's complex, it's technical, people are going to have a lot of quite detailed questions. Where have you found the best sources of data or information are to help people as they plan and get into the technical design and sort of planning of the project? James, maybe I'll start off with you?
Yeah. So there are a good few places that it's worth looking to. I think Maarten mentioned earlier, one of the key things is you've got to get out of the MT mindset and into the ISO mindset, and actually out of the MT dictionary and the terms used and into the ISO 20022 data dictionary. So it is things like creditor, ultimate creditor, debtor, which all map across, but it's getting used to that.
So, if you really want to know the basics of ISO 20022 and how it works, I think it's still available on the SWIFT website. They actually did an ‘ISO 20022 for Dummies' by the corporation that does those ‘dummies’ series. I think it’s still available for download. But then in particular, the SWIFTSmart stuff that Maarten suggested.
We've also published a lot of material over the course of us announcing our move to ISO. Some of our early documents from 2018 take you through what ISO is since we've done it, and what we're looking for in terms of benefits and how it might work better. But there's a lot of documentation available on our website.
There is also, if you want to look at the CHAPS schemas separately, you are able to sign up for those on MyStandards. We will accept indirect participants if they want to sign up to our group. You can do that via your MyStandards login. You can search for Bank of England CHAPS in there, and then send a request to us. Obviously, do remember that those are the CHAPS schemas for the DPs. They're not the schemers for IPs to use, and because of course you’re not directly sending a CHAPS payment, you're sending a CBPR+ payment. And that obviously is the other key resource I think. Again, both of those things are available on MyStandards.
So I think those are the key things. We've also got policy documents. The other thing just to bear in mind as well, potentially, if you're thinking about the future, is the CPMI – the Committee on Payments and Market Infrastructure – which is run by the Bank of International Settlements, has done a report on cross-border payments, and indeed some of the challenges that there are with cross-border payments that we're all very familiar with, but they have broken down some of the actions that they see as the way to resolve some of the frictions that exist. There's one on enhanced data in ISO 20022. There's also use of standardised reference information. And indeed, actually the LEI is picked out as one of those things.
So although we in the UK are probably leading the charge a little bit by saying, “right, we're going to start mandating it from 2024 onwards”, and other central banks haven't done that yet, I wouldn't be too surprised if further down the line or, indeed, fairly soon they start setting dates for mandation. Again, that's likely to be after 2025. But it's worth reading through that report in terms of the actions suggested because I think there will be things coming out of there which are all around sharing more data to help resolve some of the issues.
So I think those are my key resources. But I don't know if Maarten wanted to add anything to that?
James, I would say that you very eloquently summarised it, but it's absolutely that. There is a daunting amount of information available and you can quite easily get lost in it. Your suggestion about ‘ISO 20022 for Dummies' is a good starting point. It certainly was from me. And yes, you can build on from there as you get along.
Great. Thank you both. Time for maybe just a couple of other questions that have come through.
So one to James, I think. Do you anticipate that other central banks will introduce requirements on the use of the legal entity identifier, or LEI, in their respective market infrastructures, and are you seeing that through the conversations you're having with other central banks internationally?
Yeah. LEIs I think so, and that's also spurred on by the CPMI work. No one has given a firm date yet, but I think that is coming. I think the other one that's going to come as well in due course, or again, we're leading the charge, is structured addresses. That’s really beneficial including, as Liz mentioned, particularly when you're trying to do your sanctions, AML fraud screening, it massively helps in terms of reducing false positives and improving accuracy.
I know the example payment we used, which wasn't a real payment, was one to run, but, it's a great case of something where it should actually be raising all kinds of alarms, but there may be a valid payment in this. And sifting those in amongst all the false positives is the real challenge and one of the big things where I think that will help in the future.
So I do expect that to come you know, 2025 onwards. So yes, worth doing the work now, if you can fit it in before go live.
And Maarten, last question to you, and I think this might a bit of a call to action as well. So what is your view from the conversations you are having on how far progressed banks and payments service providers are, based on the conversations you've had to date?
I think most banks that we talked to are quite far along now. I think there's especially the larger banks and those banks that service other financial institutions. They of course have a commercial interest in getting ready for this change.
But it's difficult for us to track how the industry is doing, and we're quite keen to get the view of how our clients are progressing, how they're doing and how we could help them. So I think that's indeed a bit of a call to arms.
It would be very beneficial for us to hear from you, to see how you're doing.
Great. Thank you, Maarten.
So we're out of time now. So I think it's just for me to say thank you to our speakers, James, Liz and Maarten, I think some really fantastic content and perspectives there.
And also thank you to you, our audience today, for taking the time to tune in. This is, as I said at the start, one of the biggest changes, if not the biggest change to happen, to the payments industry in a generation. I hope you found this session useful in further refining and testing your thinking around ISO 20022 migration and the projects you've got underway. And I think, really importantly, help you think about, as Liz talked about, some of the use cases. And I think the excitement is going to come from some of the ultimate benefits that these changes are going to unlock for us and our clients.
So thank you all very much. And of course, Maarten and the team are available for advice from a Barclays’ perspective. And if you want to discuss any of this in more detail, please go through your relationship team or Maarten's team. So thank you very much.