Karen Braithwaite, Head of Transactional Banking at Barclays:
Hello everybody, and welcome to our session today on the important topic of ISO 20022. My name is Karen Braithwaite and I'm the Head of Transactional Banking at Barclays. I'm also delighted to share with you that we're joined by three experts who are going to guide us through this next hour together.
Those are James Southgate; he's a Senior Manager of the RTGS Renewal Programme for the Bank of England. Joining him, also from the Bank of England, we have Liz Leather, who is a policy analyst. And from Barclays, we have Ross Jones, who is the Head of High Value Payments for Corporate Banking.
The reason we're here today is because our industry is at the start of a significant journey that will result in a migration to data-rich payment formatting. That will mean that we'll see significantly increased amounts of valuable data that can be sent and received. It truly is a once in a generation change and the implications are far reaching for you our clients, the service providers such as Barclays and for the operators of key settlement systems such as Bank of England.
During the session today, James, Ross and Liz will discuss ISO 20022 and how this industry change to data-rich payment formatting can result in significant benefits to corporates and, really importantly, how you should be thinking about readiness for that. Specifically, they're going to share with us the what, the when and the why of what we need to do.
We would like this session to be as interactive as possible, so we will be opening up to Q&A at the end. But, you can submit your questions in the live chat box below the slides on your screen throughout the session today and we'll pick them up at the end, and respond to as many as we can. I've also been asked to remind you that live captions, which basically means subtitles, are also available to you and can be accessed through the screen. So we have a lot to go through today. So straightaway, I am going to hand over to James. James, thank you very much for joining us.
James Southgate, Senior Manager at the Bank of England:
Thanks Karen, and thank you very much for inviting us to your webinar. It's a really great opportunity for us to be able to talk directly and receive questions from those who participate in CHAPS via Barclays. We've done a series of webinars both for financial institutions and for corporates.
We'll use this next half hour, really, Liz and I, to run you through a) give you an introduction of what RTGS is. I'm sure that's not necessarily a familiar acronym. And then what ISO 20022 is. And I'm sure you might know what ISO is, but not necessarily 20022. So we'll run through that and really, what we want to do is give you an idea of what benefits there will be for the industry, including you as corporates, and how we look to ensure that that will happen. And we'll also run you through the key timelines. This is for us, the Bank of England, in respect of its Renewal Programme and the introduction of ISO into CHAPS. Obviously, it’s worth saying at the same time that Pay.UK is looking to introduce ISO 20022 in its New Payments Architecture and the dates for those aren't confirmed yet. But I think it's fair to say we expect it to come pretty hot on the heels of the RTGS Renewal Programme. And then we've got some actions for you to take away, and some things for you to consider as part of helping you get ready. And Ross actually will cover a little bit more in terms of what Barclays is doing there to help you with that.
So very brief introduction: RTGS is the Bank’s real-time gross settlement service. It was one of the first central banks to introduce such a system. So everything was settled real-time in a transaction-by-transaction basis. The system now is 25 years old. We celebrated that a couple of months ago, albeit with some operators that are younger than the system now. We recognise that now is the time to replace it. Although it served us very well, it's a relatively inflexible system. And in particular, with a lot of the wider changes in the payments landscape – in particular the emergence of challenger banks, fintechs, other types of payment service provider – it's not really meeting our needs in terms of flexibility. So bearing in mind that wider landscape change, we have decided to renew this system. And at the same time, we will be switching the language that the system uses from the current SWIFT MT messaging, with which some of you might be familiar, to ISO 20022.
Now, in some ways we've got no choice because for the payments world as a whole, SWIFT is switching off MT messaging. It intends to switch it off for payments in November 2025. So those are the 100, 200, 900 series messages. The other ones, including treasury management, are still live beyond that. But actually there's more to that than just having to do it. There is a world of opportunity. And I've got a slide, very briefly, which covers the financial markets payment infrastructure. I won't go through that now. This just emphasises how RTGS is at the heart. And as well as processing CHAPS payments, it also deals with the retail clearings and with CREST. But really, what it's useful to do, I think, in this webinar is really push to why we are moving to ISO 20022 in terms of seeing it as a good thing, and a good thing for the broader payments ecosystem and everyone involved in it. So I'll hand over now to Liz, who will go through some of the detail on ISO 20022 and CHAPS.
Liz Leather, Bank of England Policy Analyst:
Thank you very much James, and good afternoon everybody. ISO 20022. Well, I'll just start with what is ISO? ISO is a global, non-governmental organisation where they bring experts together with 165 members of national standards bodies. And they look at standards for everything from car seats to, in this case, payment messaging. And ISO 20022 is really about creating a new standard for financial services messaging language. And it’s maintained under the ISO governance and under the ISO 20022 registration authorities. And it's really talking about a single standardised approach. And this is something that is global almost. We're talking methodology, the process and the repository of the information, and it can be applied to all financial standards initiatives.
The building block of ISO 20022 is syntax-agnostic and it's using a machine-readable and human-readable language – which is XML – Extensible Markup language. And this is a language that can tag data and send it through the system really fast. Now, why this is fantastic is because if you think about 20 or 30 years ago, data had to be small and light to be carried around a system. Nowadays we can send so much more data and, if you're sending lots more data, it can be structured as well in order to be useful. And this means you can then tag it and categorise it into systems. And we know already that there are many enterprise resource planning systems that also use XML so they can be interoperable with these types of payment messaging.
The other focus on this particular language is that there is an increased focus on use of APIs. These are application programming interfaces. The analogy I really like to use is it’s as if you're sitting in a restaurant and the waiter is your API. He basically asks you for your order, takes your order back to the kitchen and comes back with what you requested. It's the long arm that reaches into this categorised data and pulls out the information that you really want to know.
So, the last piece about ISO 20022 is that the financial services community is able to propose changes to existing and additional messages, making it adaptable. So, you can make recommendations and they will be considered. So therefore the actual standard becomes flexible. I referred to structured and categorised data, and with that becomes improved analytics. You can reach in, you can compare, you can analyse. Being able to compare, to analyse, means that you can have improved straight through processing because there's less need for manual intervention. You're having much more data, and therefore that means that much more information is being carried. So less truncation of, “oh, what did that message really mean?”
We then have the flexibility of the standard. I've already talked about the fact that you can make recommendations, that you can ask for improvements and so on. More flexibility and the better level of the data means there's more competition and innovation amongst using the data. We talked about more data, more specific data. That plays really well into the compliance and regulation arena where you need to be able to categorise and send specific data through the system, and it helps with fraud and compliance. When you have more data, when it's being used on a global basis, you have improved harmonisation across global payment systems and you have greater interoperability between the two, and that leads to a higher resilience.
Just move on to the next slide, this really shows some of the enhanced data that is going to be available through the ISO 20022 payment messages. You have a purpose code – what the payment is actually being made for. You have a legal entity identifier. That is the legal code for the corporation or company that the payment is being made to. You have remittance data – what the actual payment is for. And that is going to have a lot more information available in it. You have structured addresses – so no more free format. And you also have an extended character set. A nice example of this is that you now can use the app – so you can send email contact information.
I'm going to move across this slide quite quickly because this talks about some of the particular pieces that I've already talked about – about structured data and form and so on – to really get through to some more examples which will show in colour how this enhanced data can help. This particular example shows the old SWIFT MT103, which is just a customer credit payment on the left. And on the right, what an enhanced message would look like. You may not see these in your particular systems in the same way, so I'll just talk about them in an overview.
On the left, you have two fields: one for the recipient details and one for the remittance information. You can already see they're small, unstructured, some of the data is truncated and it might not make much sense. On the right-hand side, you can see the recipient is already split out into the name and the legal entity identifier. So a clear separation of the name and the legal entity identifier, and then clear separation of that from the address, which is fully structured. You then have a purpose code, and you have remittance data and then you have licence – split up from the free format field in a separate field.
Particular uses of this ¬– and we're coming back to remember that long arm reaching in and picking out the data that you want – let's say, for example, you want to search for a payment by a country and you looked at the recipient details. In this case, we're looking for Iran. You looked in it and you might pick out ten payments that might have Iran in them. It might be the Sino-Iran Fund in Gloucestershire, the Iranian Art Fund in London, or, for example, this payment in Iran. So you might pick out ten payments. Whereas in the future payment, you will be able to, say, search for country ‘Iran’, in ‘address’. It's completely separate, and therefore that saves you time when you're going through your analytics.
If I move on to a second example, which is perhaps more applicable to you as corporates yourselves, whereas the previous one talked about analytics. So this is talking about the remittance field. And on the left again, we have the customer credit payment, and on the right we have the future ISO 20022 message. On the left – the remittance information – previously you could only have four lines, 35 characters long. And I've just filled that with invoice numbers. Going forward in the future, you will have the same amount of free format information. However, you will also be able to have many, many lines that will describe the different invoices that the particular payment will be paying against, and also identifying information about the invoices as well. So, although this shows a very top view with 20 invoices, actually underneath in the data, you will have a lot more data about the specific invoices that are being paid. And again, you can use APIs and computers to search in and match off those invoices going forward.
So a lot more data, a lot more structure, a lot more capabilities for you. The last one plays into something that we have been doing with an external organisation in terms of market guidance. So this is where we've been identifying particular use cases for this enhanced data. And one particular one that we've come across is property transactions. And this will just give you a flavour of what the capability of enhanced data can do. And we are looking at other use cases. So once again, looking on the left hand side, we've got the remittance information – very small, four lines long, 35 characters each time. And on the right-hand side, we have the new. So property transactions are something that's of particular interest due to the fact that for a retail customer it's one of the biggest payments that they make in their life. There has been, I think about five years ago, something like one in 300 property transactions were fraudulent. And so looking at solving some of those issues is a very good idea. And then putting those through the systems can end up in holdups, and I'll just go through that in particular detail now.
So going forward into the future, you can put a ‘property’ purpose code onto the payment. And that will help prioritise the payment. It can also identify the payment in terms of for a bank who might say, “oh, this is a large payment coming from a retail customer, we should halt that payment.” So by putting a purpose code on, it can also say, “okay, we can send this straight through.” So, improved straight through processing, and it doesn't end up with a retail customer worrying about their impending property falling through.
The second one you have is the legal entity identifier. So this is where solicitors can actually apply for a legal entity identifier and you can place this into the payment message as well. So many fraudulent payment transactions in the past have been where a fraudster has come between someone trying to buy a property and the solicitors. And they've pretended to be the solicitors and said, “oh, no, our payment details have changed, send the payment to me now.” With a legal entity identifier you can cross-check that and make sure you're actually going to a bona fide organisation. You have the separation of the name and address as before. And in the remittance details you have more information, for example, advice of why the payment doesn't match the pre-agreed payment, exchange of security identifiers and a lot more structured remittance data that you can add in.
And lastly, you can also put in contact information, as we've said before. I've said already this has come out of our market guidance work that we have been doing, and that property piece was actually something that has been an initial piece of work to identify use cases. And we are looking in 2021 and 2022 at more cases where we can codify the best practice in using enhanced data so that people can benefit from real world analytics, from straight through processing and so on. And we will continue to publish information about that, and also publications through this year and the next. I'm now going to hand on to James to talk about our international cooperation with regards to the enhanced data.
Great, thanks for that Liz. So I think one of the key things we need to be very clear on is that we are trying to implement ISO 20022 in a harmonised way. It's an interesting standard because technically it creates a framework and provides a data dictionary. But actually there's been a lot of work to ensure that what we will require in a credit message as the CHAPS payments system operator, and what we can process will be very, very similar, near identical basically to what the ECB will do with TARGET2 and what can be done at the clearing house or in Fedwire. And there are various bits of guidance to ensure that we are aligned with that.
The key thing I want to draw out here is that, first of all, on the domestic side, as I mentioned earlier, Pay UK will introduce ISO 20022 when it launches its new payments architecture which will ultimately replace Faster Payments and Bacs. As we've developed our schemes and technical guidance, we've worked with them very closely. Indeed, we have shared resources working on the technical guidance so that when the UK comes to introduce the NPA, the pacs.008 credit message, which is essentially the thing that replaces the MT103, they will be almost identical. And what I mean by almost identical is that if you put a message through one system, it can be processed by the other system. So a payment that should have gone through CHAPS, could actually go through Faster Payments or whatever replaces it, the NPA, and vice versa. There will be some slightly different elements because there are things like priority codes that we have in CHAPS because we're a high value system, and the NPA will have whatever replaces service user numbers in the future.
So those are just two small examples where the schemes operate slightly differently. But all the core data around the payment, that can all go through either system, and it should be processed the same. So you'll also have the same capability with retail payments going forward where typically the restrictions are even greater at present. Obviously, Bacs, for instance, is still on Standard 18, which was designed in 1968. So there's a vast amount of additional information that you'll be able to send if you want.
Then in terms of the international side, there are two bits of guidance that we're following in the way we specified our ISO messages. The first is what's called HVPS+. So the high value payment systems, the major ones internationally, have got together effectively to ensure that we're all putting the same requirements and same specifications in our pacs, so our payments and camt – which is account management messages – and then additionally the CBPR+ guidance. So we're making sure we’re aligned with that. CBPR+ is effectively when SWIFT moves its correspondent network over to ISO, which it will do in November 2022, it will ensure that it's fully compatible with that.
So if, for instance, you send a message to Barclays at the moment using SWIFT, they can take that information and then put it into the pacs.008 message either for CHAPS or indeed for the Pay.UK systems. So we make sure that there's no truncation or any issues there.
And then lastly, there are a few areas ¬– where I don't like the word ‘gold-plated,’ but let's be clear, our scheme works in some specific ways – and there are some things that we're adding in, for instance, that you'll be able to put a specific time on a payment if you want it to settle at a particular point, or indeed a point at which it can be bumped up to being an urgent payment if it hasn't settled yet. And we have things like purpose codes and the like, which the direct participants use to manage their liquidity. Sorry, not purpose codes. I mean, urge priority codes. We'll have purpose codes as well.
In terms of the timescale for the CHAPS migration. So we've completed phase one, which is basically about getting all the materials together and all the technical specifications for how CHAPS will work under the ISO network. So that's all available and that's already available on our website, and for those who are familiar with SWIFT, on their MyStandards portal. Phase two, then, is the ‘like-for-like go live.’ So in essentially almost to the day 12 months, we will switch the CHAPS network from the SWIFT MT Network to the SWIFT MX Network, which is what they used to for transmission of ISO messages. At that point, that will be just a straight like-for-like transition from MT to ISO. So at that point, no additional information will flow, or will be able to flow, in the ISO messages.
So actually as a client, you are highly unlikely to see any change at that point. What really is the key phase is 2.1. Because, between those two phases we hope SWIFT will switch on its correspondent banking network in ISO and that's key for us to be able to get messages cross-border. Around about 40% of CHAPS traffic has a cross-border leg either in or out or both ends, and so we need to wait for that to happen. And then once that's live, we will then enable enhanced data. So that's where you can add all these tags and add all this structure in. We will only require people to send as much data as they currently do, at first. But of course, you could be receiving payments from anywhere in the world. And obviously, if Barclays receives the payment on your behalf, they will want to transmit that information on to you. So you need to be ready to start receiving additional data, and data in this more structured format.
Then phase three, again, is probably pretty silent to the outside world, but it's important for us as the bank because this is when we're moving our core ledger over from our existing system to the new system. And again, that shouldn't be that visible to you. Although, it is a massive stepped change in terms of our processing capability and flexibility going forwards.
And then lastly, we have the ‘mature phase’, and this is when we will start to require some additional data over time. Albeit, it will be very slow. So in particular, from Spring 2024, we are looking to mandate purpose codes for housing transactions – so that we can prioritise them in the event of operational disruption. And also, we will require LEIs for any payments that are just between financial institutions. So again, shouldn't generally affect you. Those are in the pacs.009 messages that replace the MT202s. Obviously financial institutions are already very used to using LEIs, they use it in an awful lot of regulatory reporting and the like. And then probably the key one that will affect the wider ecosystem is once SWIFT switches off the MT standard for payments messaging, we will look to mandate the use of structured data.
There are unstructured options in the ISO messages as they stand – again for compatibility with MT whilst the world switches over. But we do want to move to the world of people using those structured addresses where each line is tagged with town address, etc. Likewise, we'd look to use structured remittance data going forward. Again, that gives you much more flexibility in terms of the amount of information. And obviously this tagging – the idea is that it should really help people with their own reconciliation when they’re receiving this additional information. So this is where I almost hand over to Liz.
Nope, one more slide to go, sorry. In terms of the international adoption timeline – you might already be familiar with ISO and saying, “well, what's the big fuss? Why? Why? Surely the software will already cope with it?” One thing to really watch out for is that currently the countries and financial market infrastructures that use ISO are using quite a dated version of it. So version two, version three, which dates from about 10 to 12 years ago. So the Bank of England, the ECB, Pay.UK, Fedwire, TCH, and SWIFT – all those that are moving over the next couple of years will be moving onto version 8/2019 of the pacs messages. This is a more up-to-date version. Large amounts of the model are the same, but there have been some key differences introduced in those versions since. So that's a particular area to watch out for.
As I said, SWIFT will be dual running with MT and ISO between November 2022 and November 2025. We move in, as I've described, and the ECB will move TARGET2 roughly the same time as SWIFT switches it on. And then Fedwire and CHIPS – we’re hoping for an announcement fairly soon on the revised timetable, but at the earliest it's expected to be late 2023. And indeed, they might push that a little bit later. Some of you may be aware that the Fed is really focusing on getting its FedNow – effectively its equivalent of Faster Payments for the US – launched before then moving back to focus on ISO adoption more broadly.
Slide 18 just has some detail of the different types of enhanced data and when we're looking to make them mandatory. This is a very long timescale. You see it goes out to 2026 or beyond – it just gives you an idea of the future pipeline that we're thinking of in terms of when we will mandate things versus encourage them. But I would use that slide, you can take that slide away and digest it. So I'll just pass over to Liz now for the final slide on what we kind of think the actions for you are, what we would encourage you to do.
Thank you James. So James has just talked the last few minutes, and I'm really going to strongly emphasise some of the things that he has already said. You are going to be able to receive enhanced data pretty soon, February 2023, and we would strongly encourage you to consider how you plan to make use of that enhanced data. So we particularly were talking structured addresses, structured remittance data, legal entity identifiers and purpose codes. I will emphasise again when CHAPS first moves in February 2023, it will still be an optional to send enhanced data. So we're not going to require you to send it, but it's still going to be possible for you to receive it.
So yourselves, corporates, you should be prepared to receive that enhanced data and consider how you might process it. Taking that one step further, we recommend that you speak to your direct participant, Barclays, today, but some of you might be multi-banked, so your other direct participants, to discuss how you might receive that enhanced data. And those of you that are already got ISO 20022 compatible software, you should review your version capabilities, as James has already said, and consider updating it to version 8/2019 – in line with the standard that the Bank of England, ECB, Fed etc. are going to be implementing. Please speak to your software vendors.
Corporates that are looking at sending enhanced data, speak to Barclays as to how to go about this or your other direct participants. And as James said, towards the end we will be mandating the sending of certain enhanced data, and this is for everybody to reap the benefits of the enhanced data, some of the examples we've gone through already, in due course. But that's likely not before 2024 and it's going to be gradual. So, please think about the points that we have discussed already. You have time, but it's good to be prepared. So on that basis, I'm going to hand on to Ross to talk from the Barclays perspective. Thank you.
Ross Jones, Head of High Value Payments for Corporate Banking at Barclays:
Okay, thanks James, thanks Liz. Liz, you've done a great job of talking about some of the benefits of this big change, and I think I’m going to reinforce some of those through my slide. So I work in product management, and I'm one of many on the Barclay side who are deep in the weeds working through the details of this very important migration ¬– not just in the UK, but really internationally – and changing how we receive and how we send information related to payments.
I want to go back, first of all, to what James was saying at the start, very much around the why. There are many, many different payment schemes across the world. The vast majority of them are working on legacy formats. You know, as mentioned, that some of these are 25 years old. The Bacs Standard 18 was mentioned – 1968 that format was developed. And ultimately, the need in the payment industry ¬– when we're looking at the true originators and the beneficiaries – ultimately the corporates and the businesses who were looking to send a greater level of information and receive a greater level of information to improve the reconciliation – the current standards just aren't cut out, aren’t right for business. They're not strong enough. They're not data rich enough. They don't allow sufficient amounts of information to be carried throughout the payment chain.
And that's what this ISO migration does. It changes it. It turns things on its head, and it really remedies these challenges. We'll have a global standard, eventually across all the payment schemes, that will be rich in information and structure. And that structure piece is very, very important. Because it's all very well being able to send lots of information, but if everyone is sending that information in a different field in the payment message, then it doesn't really achieve the goal of moving towards a much more frictionless payment industry. Which again, is going to be a very nice by-product of this – things will become much more streamlined and much more efficient.
I think one of the big pluses, as well, is it's bank agnostic. So many of you dialled in today. I'm sure many of you are multi-banked. You have relationships with many banks across the world, and the way that you interface with these banks will likely be very different. With the market infrastructures moving towards this standard message format, the banks have no choice. And especially when you bring to bear the fact that SWIFT is changing ¬– the way the banks message cross-border – it's not something the banks will back out of. So they have to make the changes in the interbank space. And ultimately what the next step is making these benefits realised to the true users of the payments.
So the way that you interface to the banks will be consistent in the sense that regardless of whether you're making a payment to the UK, India or Thailand, the format is going to be the same. Yes, there are going to be different restrictions in terms of what information is required in Thailand versus Russia versus India. But the fields and the format are going to be exactly the same, regardless of where you make the payment. And equally, on the inbound side, you can expect to receive a similar level of information regardless of where the receipt is coming in from. So in terms of a setting up rules for reconciliation, It's much easier.
A lot has been spoken about in terms of the amount of information that can be sent. We talked a lot about structure, but we've got structured creditor information, debtor information, which means on the bank side we're able to scan for AML and for compliance concerns much quicker. It makes STP numbers higher, which means the speed at which the payment gets from A to B increases.
But equally on the reconciliation side, that we've all touched upon so far, this extra information can be used to automate reconciliations. So Liz's example was an excellent one. You've got a remitter of funds sending one payment that covers 100 invoices, so the receiver of that information, can work to build a role within their back office to automate that reconciliation. So the matching is on a straight-through basis. This allows corporates to spend far more time on their core business rather than having to investigate funds and payments which have gone missing or that they simply can't reconcile because the information has been truncated or translated in a poor way.
From a fraud perspective, again, this has been touched upon, I think it was with the Iranian example being able to appropriately scan. But we've seen a lot of demand on the corporate side for a greater level of information, or the ability to send more information in the payments they receive, so the corporates can do their own scanning and AML and fraud checks. This is going to be significantly improved. And the addition of the LEI is a further complement to being able to make sure that you are remitting funds to who you think you're remitting funds to.
Again, a number of you in the audience today, like I mentioned in terms of being multi-banked, likely operate complex treasury structures as well. Maybe you have a virtual account platform or maybe even have a payment warehouse whereby all your payments are centralised through your various different branches and entities across the world. With the introduction of, or wider adoption of, the ISO message format, it brings in ultimate debtor and ultimate creditor fields as well. So this is a great complement to those complex structures, virtual accounts structures, these types of things, in terms of being able to identify who the true originator is of the payment or who the ultimate creditor is. These are fields which simply don't exist in cross-border payments today. They certainly don't exist in many of the domestic schemes either.
From a cost perspective, one of the interesting things around the use of the purpose of payment code, is if you are a multinational or a large parent corporate and you have a payment warehouse who was making payments on behalf of a number of different entities – they could be making payments for utilities, for example, or supplies – whereby today, simply due to the complex nature of your business, you don't know that you have 10 or maybe 15 different suppliers of the same product. By using the purpose of payment code, it's easier to identify where there's opportunities to gain economies of scale, potentially tighten the number of suppliers or even negotiate improved terms. It's these types of use cases which are definitely going to come up over the next few years as we see an increased use of these new fields. It will be very interesting on the bank side to see where we can step in and provide some extra level of insight.
You know, a lot of our time on the product side at the moment is working through the details in terms of how we get through the migration, in terms of being able to change our message format and send and receive everything that's required by the payment schemes. The next phase is making everything that we want to make available through to the ultimate sender and receiver in terms of being able to remit extra information on receiver. But then the third part of this then is us being able to analyse the data and see if we can drive levels of insight that can, number one, increase efficiencies for our customers, potentially offer some insights in terms of how they can change their behaviour, or just generally provide a greater level of information that could help them with their operating model or some of the decisions in their business.
In terms of that extra payment remittance information, I think there's 9,000 characters and maybe 150, 160 different fields. I think it's fair to say that a lot of that won't be used. But, over the coming years we will be able to see which of those fields is used the most and how much information is being carried forward. And then it's on us, and equally it's on you because you get this information as well, in terms of being able to dig into that detail and use that data for more useful purposes.
And then the last one, you know Liz and James have spoken a lot about the benefits, I've covered some too. But ultimately, this is around making payments more frictionless ¬– whether that's on the origination side, or particularly on the beneficiary side – and allowing corporates to focus on their core business and not have to worry about the payment business because it'll be much more straightforward – whether you're making an international payment or a domestic payment, or whether you pay in funds to Russia or receive funds from India. The aim is to make it much more straightforward. The word interoperable has been used a number of times and we talk about a payment format being interoperable across all the schemes. That's exactly where we're headed to.
So in terms of the key considerations, and again, some of these have been touched on already. But, you know, these types of webinars run by banks, and we're very honoured to do one with the Bank of England today, but they start sharing information and get you thinking about the considerations which you need to take into account.
But in terms of the next steps, I would very much encourage you to speak with your banks, and understand from them what you can expect from them in terms of communication plans, in terms of what changes they can see down the line, in terms of your format information requirements. But equally, I would use it as an opportunity to say to them, “this is what I would like to receive. This is information I would like to send or receive.” And give the use cases because working in product myself, that type of information is really invaluable, and it helps us to build solutions which are really fit for purpose for our customers.
Those questions that I mentioned for your bankers, stand very true with your vendors as well. Whether it's TMS, CRP or any other back-office systems that are generating payments or receiving information, you need to understand from your vendors what their readiness plan is. So what is their plan in terms of making sure that they're able to send and receive this format and this extra level of information? So what's their timeframes, and equally, are there any specifics that you would like to ask them? Use it as an opportunity to really push the boundaries and not only be ready, but look to talk to get the most of the opportunities.
And I think that's where building understanding comes in as well because these webinars are great, speaking with your banks and your vendors, great. Do your own due diligence, dig into the topic and lean on your advisers. And really look at your operating model and look at where you could benefit from extra information, or, on your supply chain, where could there be benefits in terms of sending this extra information. And capitalise and be ready. Look to really get to be able to take advantage of those opportunities at the earliest point.
And the last one is really sort of an awareness item. And James mentioned the significant amount of work that the Bank of England is doing in terms of upgrading their infrastructures, huge system changes. And with these, they're not alone – a number of the market infrastructures are doing the same. They're updating their infrastructures, they're updating their operating model and their settlement windows as well. And I think it's the complement of improved message formats, new infrastructures, wider settlement windows, that's a real complement, and are going to put us on a very positive trajectory towards real-time treasury management.
And I think in terms of in terms of making this a success, I think to realise the true benefits of this, we really need end-to-end adoption. So, corporates all on board, whether it's on the sending or receiving side. Banks are obviously heavily committed to this ¬– multi-year projects, big resources. But we all want to make this a success because there are big benefits to be realised. It's on us in banks to raise awareness and work with our customers to make sure we are ready. But like I say, use this as an opportunity to ask for what you want and what you need, and we can work together to make this a success. I've covered a lot, and on that, I'm going to hand it back to the Karen and she's going to open it up to Q&A.
So Ross, James and Liz, thank you so much for really bringing this topic to life for us today, and I'm sure that the conversation will continue. We've had a number of really excellent questions. I'm going to start to run through those and play them back to you all so those of you that can't see the questions will know what has been asked. If there's anything that we don't have the time to get through today, we will absolutely make sure that we respond to you as part of the recording that we'll send out.
The first question that we had come in is really excellent. Ross, I'm going to direct this to you, if I may. And this is a question about will ISO 20022 replace the current Bacs and SWIFT payment processes? If you're able to give us a response to that, that would be great. Thank you.
Sure. So, like we've all mentioned so far, a lot of the changes at the moment is in the bank space. So it's how we send and receive information to the relevant payment schemes, whether that's Bank of England, TARGET2 for Europe, Fed for US dollars or eventually Bacs as well, for which I don't think the date is finalised yet, but it's probably likely going to be maybe two, two plus years' time. So that's where it starts. And then the next evolution of that is working out – okay, so we change the way that we integrate, how we exchange messages with the infrastructures – what are the requirements on our customers? So, what's the extra layer of information that we require on the sending side and what's the extra level of information that our clients can expect to receive on the inbound side? And that's what we are working through at the moment.
So what I would say in terms of information, or the changes on the corporate side in terms of what you need to do at the moment, there's no change. However, as we work through the details of what's required in these market infrastructures, we'll be working very closely with our customers to make sure that we give them full sight of what's coming, and work with them to make sure that they're ready for the changes.
Thanks, Ross. That's really excellent, I appreciate that. I'm going to stay with you, if I may, because we have a couple of questions around channels and Barclays.net in particular. And the first was around – so are the payments going to be processed through Bartleys.net? And then there was also a follow up question, if you wouldn't mind covering this as well, which was – when would our payment platform be updated to manage the new payment structure? Thank you.
Okay, sure. No problem. So on the Barclays.net, for those non-Barclays customers who are dialling in today, this is one of our electronic banking platforms, and this is one of the ways which our customers can initiate payments and receive information related to their payments. So payments will continue to be processed through this electronic banking platform. And this is one of a number of channels which payments can be initiated to us. And as we work through the changes as a result of this format change, we are going to need to make changes to all of our payment channels like any banks would, whether that's electronic banking, file gateway and of course SWIFT as well, as we move on to XML over MT.
In terms of the payment platform, I think it's fair to say that every bank is going to need to update their payments platform. There’re so many if, buts, and maybes there. We are maybe 12 to 18 months into this programme. And like James said, this is like a five to six year plus programme. I won't share any details in terms of what we're doing on our platform, but you can have confidence when I say that we are direct to a number of major payment schemes and we are 100% committed to making sure that we're ready.
Ross, thank you, very diplomatic and thank you very much for that. So, James, can I just check that you can hear me because we have a number of questions coming in, that I think it'd be great for you to cover?
Excellent. Thank you very much. The first one I wanted to ask you is around legal entity identifiers, the LEIs. And the question is around, will it be compulsory to use the LEI for ISO 20022 payments or is it optional?
Yes, so a different story at different times, really. Initially, it's entirely optional. So when we go live with enhanced data, February 2023, that's entirely optional. Spring 2024 is when we'll introduce them for the FI-to-FI transactions. And as I said, the FIs should be pretty familiar now with LEIs, they're used widely in reporting and risk management.
Our intention, our view is certainly the LEIs are a good thing. They enable you to consistently identify any single company within the world. And, certainly when you're dealing with a large multinational, it will also be very clear whether you're paying the subsidiary or a branch or something like that.
So we think that LEIs are a good idea and we are keen to push further for them, potentially into the corporate space in due course. What we need to slightly temper our enthusiasm with is the fact that the LEI infrastructure is – I wouldn't say it's nascent now – it's beyond that. But there's still, I think, further work generally to promote LEIs as a useful tool, and clearly that's not just in payments. And it's working, we're working with GLEIF, which is the entity that looks after the LEI on both how it may become cheaper to acquire LEIs, but also around the governance around them as well. So in the long term, our intention is to use them more broadly, but in the shorter term, we need to be realistic.
James, thank you, that's really helpful, and great to clarify that point. I'm going to stay with you, if I may because I think there's been another really excellent question that's come in, which is around do you see any area of concern when CHAPS like-for-like comes in, meeting the concurrent migration of CBPR+? So do you have any concerns or challenges we should be considering there?
Yeah, we do. And it's one we've always known we'll always have. So the issue we've got is that SWIFT will switch on their network in November 2022, and that will effectively mean that enhanced data can flow cross-border. It can start to at least. Obviously we are not moving to enhanced data until I think it's two and a half. I think it's something like 10 or 11 weeks in between where we can still only process like-for-like.
Now the obvious question was why don’t you all move on the same weekend; it would have been easier. We did look at that option and we concluded that basically the financial system wouldn't be up on Monday if that was the case, because it would just be too difficult for everyone to move all of their systems, the ECB, us, SWIFT, the Fed. The requisite implementation wasn't doable over a weekend. So we've had to stagger it slightly.
What we're going to do, and there will be some broader communications coming out, including via your direct participants in due course, is we're going to set out some clear guidance on what happens in those intervening three months, because effectively, if someone sends a sterling payment into the UK with enhanced data, we won't be able to get that enhanced data for that short period through CHAPS. So what we're going to do, or what it looks like we're going to do, we still need to get everyone to agree to it among the CHAPS participants, but the intention is that we will have some consistent communications that discourages people from sending enhanced data for sterling payments until February. But where they do, there will be a consistent truncation methodology, which effectively is consistent with one of the tools that SWIFT will offer everyone to pair down an enhanced message down to a like-for-like message, [inaudible] data as part of that. Then if for any reason the receiver thinks actually I need to see some of that extra information, there'll be a process by which they can go back and ask the sender for that additional information, but that obviously is a manual process.
So the best thing is to encourage people who are sending sterling payments into the UK not to send enhanced data in the first place. And there will be a whole load of communication about that in due course. As I say, I think we're always going to end up with this one way or the other, we just can't do the whole world in one weekend. But there will be more information on that soon.
James, excellent answer, thank you so much. Very challenging questions, so I appreciate that. And we have had many questions come in. We do, unfortunately, have a finite period of time. So I'm going to take the last question to Ross and then I promise you we will make sure that we come back to you with any remaining questions that we haven't been able to cover off today.
So, Ross, we do have a question around SWIFT and whether it will be the responsibility of SWIFT to take care of message conversion in the case of international payments, given that different countries have different timelines to migrate their payments to ISO 20022? Thank you.
That's a really good question. So SWIFT have recognised this. They've implemented something called the transaction manager platform, which is their tool that is going to essentially aid this migration. So banks will be able to set up the way that they want to receive messages. So if a bank is not ready to be able to receive an ISO message then they can continue to receive the MT message, that is the legacy format message. Banks can continue to send MT format as well until November 2025. It's at that point then that SWIFT will turn off that legacy format. But obviously, if the bank is connected to a market infrastructure, whether it's the Bank of England or whether it's any of the other real-time gross settlement systems run by different countries, they will have to abide by the rules and the format restrictions by those marketing structures. So if a bank is connected in Australia to the Australian Central Bank, and they have a date for the changes taking place in November 2024, they will need to be ready. But there are a number of different steps being put in place to make sure that we can continue supporting payments as we do today as we migrate from the old format over to the new format for the next three to four years.
Ross, thank you very much and another great answer to a great question and unfortunately, as I mentioned, we have run out of time today.
I do want to thank all of the presenters today. So James, Liz, Ross, thank you for a really engaging session and thank you to each and every one of you, our clients, who have joined this session with us today. This is a topic that I know is going to continue to be of great interest. We're planning to run more of these kinds of sessions.