Mandating ISO 20022 enhanced data in CHAPS
1: Executive summary
This policy statement and consultation provides further clarification on our previously published mandatory requirements for enhanced data coming into effect from 2025 (Section 4 and Section 5). It also seeks views on our proposals for expanding the mandatory requirements for enhanced data in CHAPS payments from 2027 (Section 6). It reiterates the Bank of England’s (the Bank) role in facilitating and working with the payments industry to realise the potential benefits of ISO 20022 enhanced data, such as improved efficiency, payment prioritisation, and prevention of financial crime (Section 2). Finally, it signposts how the Change Management Framework for technical updates to the RTGS and CHAPS ISO 20022 schemas has been aligned to support global harmonisation (Section 3).
This statement was originally published on 12 April 2024 and updated on 4 September 2024. The September updates mainly relate to our revised timeline for mandating Structured Remittance following consultation feedback (the remaining changes are minor drafting amendments for clarity).
1.1: Mandatory requirements coming into effect from 2025
The Bank set out its initial mandatory requirements for ISO 20022 enhanced data for CHAPS in both the Bank’s 2020 Policy statement: Implementing ISO 20022 Enhanced Data in CHAPS and 2022 Additional Guidance: Detail on Mandating ISO 20022 Enhanced Data in CHAPS. Further implementation detail beyond the Additional Guidance is available for CHAPS Direct Participants (DPs) through our Enhanced Data Working Group. This update reflects the outcome of our ongoing international and market/participant dialogue since then, particularly for structured addresses (including new requirements for ‘hybrid’ structured addresses).
Following the move of Transition State 3 (core ledger and settlement engine) of the Bank’s RTGS Renewal Programme, the Bank will defer the mandated adoption of ISO 20022 enhanced data from November 2024 to 1 May 2025, in line with industry feedback for the need to maintain a sufficient time period between these two milestones.
We have previously committed to providing at least 18 months’ notice in advance of expanding our mandatory requirements for enhanced data. Therefore, this statement does not expand our previously published mandatory requirements for enhanced data prior to the end of 2025. This 18-month notice period applies only to policy expansions on mandating enhanced data for CHAPS payments; it does not apply to MyStandards schema changes – the timelines for which are aligned internationally, and which are governed by the change management process.
The mandatory enhanced data requirements from 2025 are:
1. Purpose Codes and Legal Entity Identifiers (LEIs): From 1 May 2025, the Bank will mandate the:
- use of Purpose Codes for CHAPS payments between financial institutions, and for property transactions; and
- the inclusion of LEIs for CHAPS payments between financial institutions.
Both of the above enhanced data requirements for 2025 are only mandatory for channels that are within the control of each CHAPS DP. (Please see Section 4 for further detail on message types.)
2. Structured Remittance: from November 2027, the Bank will mandate that:
- any remittance data included in a pacs.008 must be structured, unless there exists no appropriate structured remittance field for any of the remittance data; and
- the pacs.009 COV underlying customer credit transaction must include any structured remittance provided in the underlying pacs.008.
(Whether this applies to all channels will be confirmed alongside our full consultation response in November 2024. This webpage has been updated before our full consultation response because DPs required the earliest possible notice on this change to (previously) November 2025 requirements for structured remittance.)
- The Bank will continue to align with international standards, to enable ‘hybrid’ addresses (ie up to two lines of the unstructured ‘AddressLine’ element with at least Town Name and Country in structured form) from November 2025.
- From November 2026, CHAPS payments containing fully unstructured addresses will be rejected by the CHAPS validation library, in line with international standards being updated at the same time. DPs therefore must structure addresses in hybrid form, at a minimum. (These requirements for structured addresses apply across all payment initiation channels, because CBPR+ and HVPS+ implementations also intend to reject fully unstructured addresses from November 2026.)
1.2: Proposed policy positions from 2027 for consultation
The Bank is planning the following expansions of its mandatory requirements on enhanced data in CHAPS payments from November 2027.
- Including all initiation channels within the scope of enhanced data requirements from November 2027.
- Mandating the inclusion of Purpose Codes for all CHAPS payments from November 2027.
CHAPS DPs should consider the actions required to meet these requirements from November 2027, engaging with vendors as appropriate.
If respondents identify barriers to meeting both requirements by November 2027, they should respond to the consultation questions in Section 6 on the actions that need to be taken to overcome the barriers and the time taken to address them.
Please indicate in your response if you believe any of the proposals in this consultation are likely to impact persons who share protected characteristics under the Equality Act 2010, and if so, please explain which groups and what the impact on such groups might be.
Please respond to this consultation by 26 July 2024 to RTGSCHAPScomms@bankofengland.co.uk. The Bank will publish its response to this consultation.
The Bank had considered expanding the requirements to include LEIs beyond CHAPS payments between financial institutions. However, reflecting the current levels of broader LEI registration, the Bank has decided not to make this change at this time.
Any material changes going forward will be updated on this webpage, noting the date of the updated version, and accompanied by a notification to CHAPS DPs.
1.3: Who should read this policy statement and respond to this consultation?
- Payment Service Providers (PSPs) who are current or prospective CHAPS DPs or indirect participants.
- Users who make or are otherwise responsible or involved in the initiating or processing of CHAPS payments.
- Technology vendors who provide financial institutions or corporates with solutions for initiating, processing, or reconciling CHAPS payment messages.
- Any other stakeholder, such as trade associations, industry groups and regulatory bodies with an interest in the future of UK payments.
2: The Bank’s role in realising the benefits of ISO 20022 enhanced data
In June 2023, the CHAPS high-value payment system successfully migrated to the ISO 20022 payments messaging standard. In line with industry feedback, the Bank’s strategic intention for the implementation of ISO 20022 for CHAPS payments goes beyond the minimum technical implementation of the emerging messaging standard.
The Bank recognises that the industry is making a significant investment to implement the new enhanced data standards. Consistently enriching and structuring ISO 20022 enhanced data for CHAPS payments will help the industry to achieve the intended benefits arising from this significant investment. These intended benefits for industry include global harmonisation, improved payment prioritisation, improved straight-through processing (both increasing resilience and lowering cost of payments), greater information and analysis capabilities, and improved fraud prevention.
An Enhanced Data Working Group (EDWG) has met monthly since 2023, to support a cohesive implementation of ISO 20022 enhanced data for CHAPS payments. The EDWG takes an advisory role in relation to the Bank, and its membership is made up of CHAPS DPs. The Bank has at times refined the granular detail (while maintaining our high-level policy aims), following the discussion of certain workstreams at EDWG. The Bank will continue to publish material refinements, as captured in the Updated Requirements in Section 4.
In considering how the Bank can influence the fuller realisation of the benefits of the richer data standard, we recognise the extent of change in the UK payments industry at this time. The Bank fully appreciates the need to balance potential benefits that come from having an ambitious timetable for enhanced data for CHAPS payments with the delivery of key internal, customer-facing, and regulatory payment programmes among many CHAPS DPs. The Bank is keen to prioritise the enhancement of ISO 20022 data where the potential benefit of its widespread usage is greatest relative to the burden of implementation.
Network benefits for those along the payment chain – including PSPs and end-users – are contingent on the data contained within the payments being sufficiently rich and high quality. A key hurdle in realising the benefits of the richer data across the industry is an asymmetry between those incurring the burden and those deriving the benefit. The burden of including high-quality enhanced data falls on the sending bank, while the benefit largely accrues to the other side of the payment chain. In line with industry feedback, the Bank as the payment system operator of CHAPS intends to play an active role in raising the quantity and quality of enhanced ISO 20022 data provided within CHAPS payments.
The Bank is engaging with the industry to deliver this goal:
- Through its operation of the RTGS and CHAPS services, the Bank sets technical requirements for its ISO 20022 messages to ensure CHAPS payments include the defined and validated data required to be successfully processed.
- Following feedback received as part of the original 2020 policy consultation, the Bank, in its role as the operator of the CHAPS payment system, will mandate the use of certain enhanced data to set a minimum expectation for the use of additional enhanced ISO 20022 data following technical implementation. To ensure these policy requirements are proportionate, our policy requirements will initially be mandated through the existing CHAPS assurance process (ie CHAPS DP self-attestation and remediation plans for instances of non-compliance), rather than through the technical rejection of payments – except for the technical rejection of unstructured addresses from November 2026, where the Bank is aligning with international standards.
- The Bank will also work with other authorities, market infrastructures and representative groups to catalyse the development of a standardised approach to best practice for using ISO 20022 enhanced data within CHAPS payments. While the development of this guidance will ultimately be for the market to determine, the Bank recognises that it has the potential to play a useful co-ordinating role and is happy to collaborate with other groups in this role, subject to industry demand and priorities.
Through a combination of this activity, the Bank aims to promote and maintain a culture of high-quality, rich data.
3: International harmonisation and change management
A significant proportion of CHAPS payments are cross-border. Consequently, fully realising the benefits of the implementation of ISO 20022 in CHAPS requires a global harmonisation of messaging standards.
We are working with international counterparts on programmes of global alignment, playing a leading role in global programmes to standardise global messaging standards and co-ordinate on harmonised international best practice, working with other central banks and authorities, market infrastructures and private sector participants.
The Bank is actively contributing to global leadership on payment messaging standards. We aim to drive forward harmonisation on the implementation of technical standards and market practices, both as part of the international change agenda, and through aligning future CHAPS implementations with emerging global harmonised approaches in other jurisdictions.
3.1: Harmonised requirements for cross-border payments
As part of the G20 cross-border payments programme, the Bank for International Settlements’ (BIS) Committee on Payments and Market Infrastructures (CPMI) and the private sector global Payments Market Practice Group (PMPG) created a joint taskforce to establish harmonised data requirements of cross-border ISO 20022 messages.
The Harmonised ISO 20022 data requirements for enhancing cross-border payments – final report was published by the BIS in October 2023, setting an end-2027 timeline for global adoption.
The Bank welcomed the harmonised requirements, and committed to aligning the CHAPS ISO 20022 message usage guidelines with the requirements by end-2025 (in the few cases where these are not already aligned).
3.2: Alignment with HVPS+
The Bank is an active participant of HVPS+ , a group of market infrastructures and financial institutions that aims to define best practices for ISO 20022 implementation across high-value payment system operators. HVPS+ publishes message templates and ‘Message Usage Guidelines’ and supports market infrastructure initiatives, such as the recently published Payments Interoperability Charter.
The Charter aims to foster support from MIs to an agreed set of objectives and principles designed to enable evolution and interoperability, including maintaining live implementations aligned to one of the two most recent HVPS+ collections. In this context, ‘interoperability’ means minimising friction in the movement of payments across borders, and domestically, including translation without truncation.
HVPS+ is also working through taskforces to consider the implementation of CPMI requirements, ISO 20022 base message upgrades and further harmonisation with the CBPR+ group, in order to propose change requests and plan strategic global upgrades.
HVPS+ has recently formalised its change management framework to align with the timelines of the CBPR+ maintenance process, and to provide predictability and stability to the publication of Usage Guidelines. As part of the Bank’s policy to align with global updates, we will be aligning CHAPS schemas with changes made to HVPS+ Usage Guidelines, and actively monitoring alignment with CBPR+ Usage Guidelines.
In order to maintain alignment, we have set out our Change Management Framework for our own ISO 20022 implementation, which closely aligns with the HVPS+ and CBPR+ change management processes.
3.3: Change Management Framework for CHAPS and RTGS ISO 20022 implementation
To facilitate changes to the Bank’s ISO 20022 implementation in CHAPS and RTGS, the Bank will co-ordinate an annual change management process. The Bank has designed its process and timelines to align as closely as possible to the HVPS+ change management and Swift’s CBPR+ timelines, to reflect their changes (as appropriate) in our implementation each year and maintain interoperability. Updated CHAPS/RTGS schemas and technical guidance are currently planned to go live on the same third weekend of November as CBPR+ and HVPS+ market infrastructure implementations each year.
All changes will be managed through a Change Request (CR) process, in which the Bank will evaluate and progress CRs according to a set of guiding principles. Where necessary, the Bank will also submit certain CRs to HVPS+ for inclusion in their process and development of Usage Guidelines.
As of March 2024, the following changes are planned for inclusion in upcoming CHAPS and RTGS ISO 20022 message schema implementations:
November 2025:
- Introduction of hybrid addresses.
- Inclusion of CPMI cross-border data model requirements for payments travelling cross-border through CHAPS (depending on HVPS+ inclusion and an interoperability assessment).
- Clarifications, some potential minor enhancements, and bug fixes.
November 2026:
- Retirement of unstructured addresses.
Further changes made by HVPS+ and CBPR+ through the change process will also be incorporated in November 2025 and November 2026.
We have published all information and detail on the Change Management Framework, including the timeline and key dates, the change request form and instructions for submitting a change request to the Bank.
4: Update: Mandatory requirements coming into effect from 2025
Further background and detail on these mandatory requirements for ISO 20022 enhanced data for CHAPS can be read in the Bank’s 2020 Policy statement: Implementing ISO 20022 Enhanced Data in CHAPS and 2022 Additional Guidance: Detail on Mandating ISO 20022 Enhanced Data in CHAPS. More detailed information is shared with CHAPS DPs through the Enhanced Data Working Group.
4.1: Purpose Codes
From 1 May 2025, the Bank will mandate the use of Purpose Codes for all payments between financial institutions, and for property transactions, as set out since our 2020 policy statement. This requirement applies to payments made via a channel controlled by the DP until our proposed expansion to all channels from November 2027.
The Bank continues to encourage the inclusion of Purpose Codes for all CHAPS payments where possible prior to this date.
4.1.1: The standardised international Purpose Code List
In line with the CPMI harmonisation requirements, CHAPS will continue to accept all Purpose Codes on the international External Code Set.
4.1.2: The recommended UK Purpose Code List
The Bank and Pay.UK have previously jointly developed a recommended UK Purpose Code List, as a subset of the international External Code Set. The Bank encourages the use of the UK Purpose Code List for UK-originated CHAPS payments; and CHAPS DPs should only use the wider External Code Set for initiation channels in their control when there is a specific need to send a code with an overseas payment that is not on the UK list. The Bank will keep the recommended UK Purpose Code List under review and will update the list periodically as the international External Code Set and UK payment patterns change, following appropriate industry engagement.
The Bank will continue to support relevant industry groups developing guidance for the consistent usage of Purpose Codes.
4.1.3: The benefits of Purpose Codes
As fed back by the UK industry, the consistent use of Purpose Codes has the potential to realise several benefits, summarised in our Purpose Code Consultation Response (Paragraph A20).
Respondents to our consultation specifically drew out the benefits of Purpose Codes in:
- prioritising payments;
- financial crime risk and fraud prevention;
- new and innovative payment services and improving credit decisions;
- efficient reconciliation;
- exception processing;
- market intelligence;
- identifying vulnerable consumers; and
- providing more information to payees and payers about the payments they make and receive.
Respondents also noted that our mandatory requirements were necessary to ensure a sufficient uptake of Purpose Codes. The Bank agrees with those respondents who are concerned that without the mandatory element there is a risk that the quality and completeness of Purpose Code data included within CHAPS payments will not be sufficient to realise the intended benefits. Similarly, a number of respondents noted that the ‘OTHR’ Purpose Code should not be included in the UK recommended list, because its broad scope risks reducing the overall data quality and completeness from Purpose Codes.
Purpose Codes benefit spotlight: payment prioritisation
Background
In recent years, the UK financial authorities have prioritised enhancements in operational resilience.
The Cross Market Operational Resilience Group (CMORG) sponsored Payments Exercise in 2019 identified a need for a sector-wide agreed definition of ‘critical’ payments due to varying interpretations across the industry.
In response:
- In April 2022, CMORG endorsed an industry-developed prioritisation framework for wholesale payments.
- In April 2023, CMORG – and UK Finance’s Payments Product and Services Board – endorsed an industry-developed prioritisation framework for retail payments.
Benefits of a common prioritisation framework
The industry working groups expected the following benefits to be realised through the use of a common prioritisation framework:
- It will facilitate more informed decision-making and incident management actions during payment outages affecting the UK Financial Sector.
- A common understanding of payment criticality could ensure a more co-ordinated response across sending and receiving payment service providers, particularly where there is a need for payments rerouting.
- It could save effort and time during the recovery process, as it may not be possible to resume processing all payments simultaneously.
- Industry messaging in instances of an outage can be aligned to commonly agreed priorities for enhanced awareness among clients and consumers.
ISO 20022 Purpose Codes as a solution
A key finding of the industry working groups was the fact that PSPs have only limited abilities to identify critical payments on the old MT payment messaging standards. The new ISO 20022 messaging standard’s Purpose Code field, if used consistently, offers PSPs a more effective and direct ability to identify critical payments. The prioritisation framework for retail payments maps the identified critical payments to their closest Purpose Codes. Industry members of EDWG expressed that they would prefer that Purpose Codes are mandated for all CHAPS payments (rather than another subset) in order to comprehensively and reliably identify critical payments.
4.1.4: Financial institutions
For the purposes of the first stage of mandating enhanced data from 1 May 2025, payments between financial institutions are defined as:
- all pacs.009 CORE CHAPS payment messages; or
- a pacs.008 CHAPS payment message where both the effective ultimate debtor and effective ultimate creditor are PRA-authorised deposit-takers or broker-dealers, or Financial Market Infrastructures supervised by the Bank of England.
The ‘effective ultimate debtor’ is either:
- the debtor, where there is no earlier party from which an amount of money is due (and therefore no ultimate debtor is populated), or
- the ultimate debtor, where there is an earlier party before the debtor from which an amount of money is due.
The ‘effective ultimate creditor’ is either:
- the creditor, where there is no further party to which an amount of money is due (and therefore no ultimate creditor is populated), or
- the ultimate creditor, where there is an additional party after the creditor to which an amount of money is due.
The inclusion of pacs.008 payment messages between financial institutions is intended to mitigate the risk of users circumventing our enhanced data requirements by using pacs.008 messages when pacs.009 messages would otherwise have been used.
Ultimate debtor/ultimate creditor is an optional data element in ISO 20022 payment messages, which must only be used if the given payment scenario satisfies conditions of an ‘on-behalf-of’ transaction. In all other scenarios, this data element must be absent. Duplication of the debtor/creditor details in the ultimate party elements is not allowed and is considered an incorrect practice. For more information, please see ‘Ultimate Parties’ in the PMPG Document Centre.
We have always been clear about our intent to expand these requirements over time, and our encouragement for the use of all enhanced data where possible. Therefore, the Bank has encouraged CHAPS DPs to future-proof their enhanced data implementations by not hard-coding in exclusionary logic. This risk has also informed our future policy proposal to expand the requirement for Purpose Codes to all CHAPS payments from November 2027.
4.1.5: Property Purpose Codes
From 1 May 2025, the Purpose Codes most directly related to property payments will be mandated:
- HLRP: Property Loan Repayment.
- HLST: Property Loan Settlement.
- PLDS: Property Loan Disbursement.
- PDEP: Property Deposit.
- PCOM: Property Completion Payment.
- PLRF: Property Loan Refinancing.
Please see the UK recommended Purpose Code List for details on these codes.
4.1.6: Who must provide the Purpose Code
The Bank has not set expectations on who must provide the Purpose Code or whether this can be derived by CHAPS DPs (as suggested by some responses to our Purpose Code consultation). Generally, we expect the originator of the payment to be closest to the payment’s purpose and therefore able to provide the highest quality data (in line with the ISO 20022 definition), but we have not set this as a requirement. As stated in our Purpose Code Consultation Response, while we are aware of the benefits of consistent usage, we recognise that the way CHAPS DPs implement Purpose Codes in their customer channels is in the competitive space. Ultimately, the requirements for mandating data quality standards fall on CHAPS DPs as the organisation submitting payment messages to CHAPS. It will be for each CHAPS DP to decide what data they will provide on behalf of their customers, and what they will require from them, to achieve the high standards of data completeness and quality the Bank is expecting.
4.1.7: Purpose codes in pacs.004 return messages
Where a purpose code was included in the original message being returned, the Bank encourages but will not mandate DPs to include this purpose code within the pacs.004 Original Transaction Reference. (A Return Reason Code from the separate External Code Set has always been technically mandated to settle a pacs.004 return, as per our pacs.004 schema.)
4.1.8: Purpose codes in pacs.009 COV messages
Feedback from EDWG has noted that the benefits of enhanced data in the pacs.009 cover (pacs.009 COV) message derive from enriching the Underlying Customer Credit Transfer, rather than entering the same Purpose Code for all pacs.009 COV messages.
One of the key benefits of the ISO 20022 standard is that it is open to change requests with broad policy support.
Therefore, the Bank is engaging with the ISO 20022 Payments Standards Evaluation Group on the potential for adding a Purpose Code field to the Underlying Customer Credit Transfer block of the pacs.009 COV message.
If this change request is implemented, the Bank intends to mandate the inclusion of a Purpose Code within the pacs.009 COV underlying customer credit transaction where one was entered in the pacs.008 from November 2027. This remains subject to international timelines for change releases.
4.2: LEIs
From 1 May 2025, the Bank will mandate the use of LEIs for all payments between financial institutions, as set out since our 2020 policy statement. This requirement applies to payments made via a channel controlled by the DP until our proposed expansion to all channels from November 2027.
The Bank continues to encourage the inclusion of LEIs for all CHAPS payments where possible prior to this date.
It remains the Bank’s vision to widen the LEI requirement to all CHAPS payments over time. The Bank will provide industry with at least 18 months’ notice in advance of extending any further mandatory requirements for LEIs.
The Bank is not expanding mandatory requirements for LEIs at this stage.
This recognises the need for the wider adoption of the LEI before it becomes proportionate to expand our requirements for including the LEI in CHAPS payments.
4.2.1: The benefits of LEIs
The Bank encourages all CHAPS DPs to start using LEIs as early as possible, once the DP can send enhanced data, in order to ensure that the benefits of the ISO 20022 payment messaging standard can be realised across the payments industry as soon as possible.
Consistent and wide usage of LEIs will support improved resolution planning, financial crime detection, sanctions screening, customer due diligence, and innovation in products and services.
As the use of LEIs increases, the Bank will engage with industry on the best path for widening the LEI requirement to all CHAPS payments, for example, by sector or by size of institution. In choosing the path, the Bank is aiming to maximise the benefit from enhanced data while minimising the burden on reporting.
4.2.2: Validation Agent model
The Bank encourages all DPs to consider the Global Legal Entity Identifier Foundation’s (GLEIF) Validation Agent model, and – more generally – checking whether customers already possess LEI(s) during on-boarding. This reflects the growing importance of the LEI in global developments in financial transparency.
4.2.3: Who must provide the LEI
The Bank as the operator of the CHAPS payment system sets out the high standards of data completeness and quality the Bank is expecting. It is for each CHAPS DP to implement its own processes to meet our standards. Generally, we expect the originator of the payment to be closest to knowing the particular legal entity that the payment is intended for and therefore able to provide the highest quality data, but we have not set this as a requirement. We encourage DPs to enrich their internal customer databases with LEIs, both to help meet our CHAPS requirements and for the wider benefits for financial transparency. As well as asking for LEIs from the originator, DPs can look up LEIs on the free global database at GLEIF. Ultimately, the requirements for mandating data quality standards falls on CHAPS DPs as the organisation submitting payment messages to CHAPS.
CHAPS Indirect Access Providers are reminded that it is already an obligation of the CHAPS Reference Manual that:
- 37.4 Each CHAPS Indirect Access Provider shall maintain as a minimum the following information regarding its Indirect Participants: legal name, LEI, SWIFT BIC, business model, ultimate beneficial owner – if applicable – and understanding of why each Indirect Participant requires access to the CHAPS System.
4.2.4: Updating LEI information
GLEIF’s Challenge functionality is open to all who wish to update any of the information in an LEI record. The Bank expects DPs to keep all of their LEIs up to date and accurately reflecting their organisational structure.
4.2.5: Multiple agents in a payment chain
In addition to Creditors and Debtors, where there are multiple agents in payments between financial institutions, the Bank expects LEIs to be populated for all financial institution agents, given that most institutions that make these payments already possess LEIs. This policy reflects the original creation of the LEI to identify counterparties, in response to the 2007–08 financial crisis.
In response to EDWG feedback, to future-proof this policy in the case of longer, cross-border payment chains, the following exemptions apply:
- DPs do not need to provide LEIs for any intermediary agents after the immediate next agent the DP is sending the payment to for whom LEIs were not already provided. The Bank has engaged with CHAPS DPs to finalise a list of LEIs for the entity within each CHAPS DP’s organisation which has direct access to CHAPS. This enables sending DPs to populate the LEI for the immediate next agent (receiving DP) in CHAPS.
- DPs do not need to provide LEIs for previous agents or the initiating party for whom LEIs were not already provided.
Where these LEIs were already provided, DPs must include them. These exemptions only apply to agents and the initiating party, and do not apply to the effective ultimate debtor and effective ultimate creditor. The Bank still expects DPs to clearly communicate CHAPS enhanced data requirements to their agents.
4.2.6: LEIs in pacs.004 return messages
From November 2027, the Bank will mandate DPs to include all LEIs in the pacs.004 return message outside the Original Transaction Reference where our policy applies, ie: for all financial institutions, except for (i) intermediary agents after the immediate next agent, or (ii) where LEIs were not provided for previous agents.
Where LEIs were included in the original message being returned, the Bank encourages but will not mandate DPs to include these LEIs within the pacs.004 Original Transaction Reference.
4.2.7: LEIs in pacs.009 COV messages
Feedback from DPs has noted that the benefits of enhanced data in the pacs.009 COV message derive from enriching the Underlying Customer Credit Transfer.
Furthermore, some DPs did not interpret the pacs.009 COV message within scope of our 2024 requirements and will require more time to build their capabilities for including enhanced data in the pacs.009 COV messages. The Bank continues to encourage any DPs to contact us as soon as possible if they need any clarification on our policy intent, at RTGSCHAPScomms@bankofengland.co.uk.
Therefore, from November 2027, the Bank intends to mandate the inclusion of both:
- All LEIs in the pacs.009 COV Underlying Customer Credit Transfer where entered in the pacs.008.
- All LEIs in the pacs.009 COV outside the Underlying Customer Credit Transfer where our policy applies, ie: for all financial institutions, except for (i) intermediary agents after the immediate next agent, or (ii) where LEIs were not provided for previous agents.
4.2.8: Further LEI FAQs
For more detailed questions relating to the LEI itself, please visit GLEIF’s FAQs.
4.3: Structured remittance
From November 2027, the Bank will mandate that any remittance data included in a pacs.008 must be structured, unless there exists no appropriate structured remittance field for any of the remittance data. (Whether this applies to all channels will be confirmed alongside our full consultation response in November. This webpage has been updated before our full consultation response because DPs required the earliest possible notice on this change to (previously) November 2025 requirements for structured remittance.) The Bank has updated this timeline based on broad consultation feedback since April 2024.
Initially, this will be mandated through the CHAPS rulebook, rather than a hard schema validation rule.
From November 2027, the Bank will mandate that the pacs.009 COV underlying customer credit transaction must include any structured remittance provided in the underlying pacs.008.
The Bank will update this policy if structured remittance is added to the pacs.009 CORE.
4.3.1: Pacs.008 Structured Remittance
From November 2027, any remittance data included in a pacs.008 must be structured, unless there exists no appropriate structured remittance field for any of the remittance data.
The Additional Remittance Information field may be used only to complement the structured remittance information.
The Bank has updated this timeline (from the previous 2025) because of broad consultation feedback since April 2024. Respondents requested a delay to allow progress on external dependencies, such as rules on bilateral and multilateral agreements. The Bank will engage closely with DPs on overcoming obstacles within the CHAPS payments community, such as remittance use-case guidance.
4.3.2: Pacs.009 CORE Structured Remittance
There is currently no structured remittance data in the pacs.009 CORE. There is one line of unstructured remittance data. Therefore, any remittance data needed should be entered in the unstructured remittance data field (until such time as the base message fields change).
If structured remittance is added to the pacs.009 CORE message in future, the Bank intends to mirror its mandatory structured remittance requirements for pacs.008 messages for pacs.009 CORE messages, but will give at least 18 months’ notice before doing so.
4.3.3: Pacs.009 COV Structured Remittance
From November 2027, the underlying customer credit transfer block of the pacs.009 COV must structure any remittance data that was structured in the underlying customer credit transfer. (Therefore, we are not mandating DPs to structure any unstructured remittance data in the underlying customer credit transfer.)
There is also one line of unstructured remittance data in the pacs.009 COV outside of the underlying customer credit transfer block – this must not be used for any remittance data that was present in the underlying customer credit transfer, but may be used for any remittance data pertaining only to the pacs.009 COV message itself.
4.3.4: Rulebook mandating of Structured Remittance
The above requirements for structured remittance will be mandated through the CHAPS rulebook initially, rather than through a hard schema validation rule.
This means that, at this initial stage, we will not reject payments where Structured Remittance information is incomplete or incorrectly completed, however we will be monitoring and reporting against the use of Structured Remittance to inform any future policy decision making.
4.3.5: Benefits of Structured Remittance
The Bank has heard from industry and end-users that, of all the enhanced data fields, structured remittance information has the potential to benefit end-users most. Used consistently, structured remittance information will facilitate more efficient reconciliation and other back-office processes, potentially resolving many manual investigations and reconciliations.
Structured remittance information also allows for potentially much more effective integration of payments information into purchasing and analytical systems and applications, enabling the provision of innovative financial products better suited to user needs.
4.3.6: Bilateral and multilateral agreements
In line with HVPS+ and CBPR+, the current CHAPS schemas require that the use of Structured Remittance must be bilaterally or multilaterally agreed.
Some CHAPS DPs may already have in place bilateral agreements, for example, to meet requirements in other jurisdictions.
Should international standards remove the requirement for multilateral agreements from November 2025, the Bank will align the CHAPS schemas with such international standards.
4.3.7: Relevant guidance for structuring Remittance Information
When monitoring the quality of enhanced data submitted, the Bank will expect DPs to be mindful of the relevant domestic and international guidance for that use-case. The Bank will continue to engage with the Payments Market Practice Group (PMPG), industry and other payment system operators on guidance for Structured Remittance Information until and beyond such time that Swift retires MT messaging for payments, which is currently expected to be in November 2025.
4.4: Structured addresses
Where address is included, the Bank encourages fully structured addresses.
The Bank will align our timetable for structured addresses with HVPS+ and CBPR+, such that:
From November 2025, a ‘hybrid’ address will be enabled for all agents and parties where an address can be included, but fully structured addresses will be encouraged.
From November 2026, unstructured addresses will be rejected by the CHAPS message validation (MVAL) library. Hybrid and structured addresses will continue, and fully structured addresses will be encouraged.
Since the June 2018 ISO 20022 consultation paper, the Bank has outlined its intention to align with other operators to mandate the use of Structured Addresses by CHAPS DPs in the CHAPS ISO 20022 payment messages. This is also in line with industry feedback received since the 2018 consultation through multiple engagement fora. Therefore, we are not consulting again on aligning with HVPS+ and CBPR+ on structured address timelines, but we are happy to receive any further feedback alongside your consultation responses.
Overall, the Bank’s policy is that eventually only structured data should be used for addresses and that we should remain aligned with international and domestic market practice.
This approach will enable more efficient screening of payments by PSPs to mitigate financial crime, as well as reducing the processing time and cost of transactions to the industry.
In response to the July 2020 Industry Review (summarised in our 2020 policy statement), respondents agreed that the Bank had a role as the operator of CHAPS to facilitate the enabling of these network benefits as they are often gained by the beneficiary bank.
4.4.1: Definitions of the different levels of structure in addresses
Structured Address
To align with HVPS+ and CBPR+, where a fully structured address is used it must contain a minimum of Town Name and Country. A fully structured address cannot contain the (unstructured) ‘AddressLine’ element.
The Bank encourages fully structured addresses, although we recognise the challenges of converting address data – especially those elements at a more disaggregated level than Town Name – to a fully structured format.
Hybrid Address
A hybrid address must include the Town Name and Country elements, but it will also allow the (unstructured) ‘AddressLine’ element to be included, subject to a maximum of two occurrences, with up to 70 characters permitted within each occurrence.
Other structured elements in addition to Country and Town Name may also be included, eg, Postal Code. Note that data present in structured elements within the Postal Address must not, under any circumstances, be repeated in the (unstructured) ‘AddressLine’ element.
The ‘Structured Postal Address Proposal’ can be read in full at the PMPG Document Centre, and HVPS+ and CBPR+ usage guidelines are expected to be uploaded onto MyStandards by February 2025. CBPR+ has made an advanced draft available on MyStandards that includes the hybrid address.
The Bank will enable hybrid addresses from November 2025.
Unstructured Address
A fully unstructured postal address uses only the Address Line element. Three occurrences of the AddressLine element with up to 35 characters are permitted.
Unstructured addresses can only be used until November 2026, after which they will be technically rejected by CHAPS message validation.
4.4.2: International market guidance on mapping
Please visit the PMPG Document Centre for the most updated documentation from the Payments Market Practice Group, mapping local postal address formats to the fourteen ISO 20022 Structured Address elements.
4.5: Extended character set
CHAPS is aligned with the HVPS+ character set, with the following rules:
All proprietary and Text fields, excluding Name and Address for all actors and Related Remittance Information and Remittance, are limited to the FIN-X-Character set.
Name and Address for all actors and Related Remittance Information and Remittance fields are extended to support the following additional characters: !#$%&'*+-/=?^_`{|}~ "(),:;<>@[\]
Note that ‘><’ is escaped as follows:
< is replaced with <
> is replaced with >
& is replaced with &
E-mail address/Proxy fields are extended to support the following additional characters: !#$%&'*+-/=?^_`{|}~ "(),:;<>@[\]
While the Bank has no plans to extend its character set before 2028 at the earliest, the renewed RTGS system will be capable of supporting wider character sets and we acknowledge that there may be benefits in doing so eventually. For example, this could be to include jurisdiction- or language-specific characters for names. The Bank’s message schemas and Technical Guidance (available on MyStandards) maintain interoperability with MT by requiring DPs to replace any characters not in the FIN-X-Character set with a full stop (.), in line with CBPR+.
We would support extending the existing character sets in accordance with domestic and/or international market requirements following formal industry consultation. The Bank would provide at least 18 months’ notice in advance of any decision to extend the character set.
5: Our assurance process
5.1: Assurance process
With the exception of unstructured addresses (which will be rejected by the CHAPS validation libraries from November 2026), the Bank does not initially intend to reject payments featuring incomplete enhanced data. Instead, the Bank will make the completion of the specified data mandatory through the CHAPS rulebook. This will allow the Bank to review compliance against its rulebook as part of its broader assurance process and consider follow-up actions where there are significant departures from the Bank’s expectations on completing mandatory enhanced fields, for example by not including LEIs where expected or where there are systematic issues with LEIs not being valid or up to date.
The Bank’s broader assurance process is based on CHAPS DP self-certification. The CHAPS DP must self-declare each non-compliance through the Compliance Certificate (as defined in the CHAPS Reference Manual), and provide a remediation plan. For more information on assurance, please see Section 7 of the CHAPS Reference Manual.
The Bank is engaging with CHAPS DPs in 2024 to build an expected picture of compliance with our mandatory requirements. Where DPs cannot comply, there will be an expectation to raise this formally from 1 May 2025 as a non-compliance against the CHAPS rulebook and subsequently report it as part of periodic attestations of compliance by CHAPS DPs’ senior management.
Where a CHAPS DP declares an instance of non-compliance, a remediation plan should be provided to the Bank. The Bank will assess remediation plans on their merits. The Bank will monitor completion of remediation plans, as is the current process for all non-compliances.
In addition to DP self-certification, the Bank will be monitoring the usage of enhanced data for CHAPS more broadly, and how this evolves over time.
5.2: Technical rejection of CHAPS payments due to enhanced data
The Bank’s enhanced data requirements will be initially mandated via the CHAPS rulebook. This means that payments with incomplete or incorrect enhanced data will not be rejected, but will be monitored.
From November 2026, unstructured addresses will be rejected by CHAPS message validation, in line with HVPS+ and CBPR+ timelines.
For the remaining enhanced data requirements, the Bank will not be rejecting payments solely due to incomplete or incorrect enhanced data before end-2028 at the earliest.
As well as rejecting unstructured addresses from November 2026, the Bank intends to move to a model of rejecting payments where other mandatory enhanced data is incomplete or inaccurate in due course. The date for moving to this model will depend on certain external factors such as:
- international progress on transitioning to the full implementation of the ISO 20022 messaging standard, such that payments originating overseas will no longer require the same level of intervention from CHAPS DPs;
- data quality being sufficiently high and trending upwards, such that the financial stability impact of moving to a rejection model is minimal;
- engagement with industry stakeholders, indicating that the industry as a whole is supportive of such a model due to the positive impact on data quality and overall the impact of such a movement is manageable; and
- the approach of other FMIs to ensure the Bank remains as aligned as possible in its approach to compliance.
6: Consultation questions
6.1: Expanding the scope of mandatory requirements to all channels in November 2027
We are planning to expand the scope of our mandatory requirements, as set out in Section 4 of this policy statement, to CHAPS payments originating from all channels from November 2027.
In our 2022 Additional Guidance, we granted a temporary transition period during which the mandatory requirements for enhanced data in CHAPS only apply to payments made via a channel controlled by the DP. This includes data received via online banking, direct file submission from a corporate client, and existing internal data (eg, from an internal CRM solution). In relation to these DP-controlled channels, the DP should ensure that it is gathering the source data required to include mandatory enhanced data. For example, in a corporate banking portal screen, DPs must require enhanced data fields for (at least) the payments in scope of our mandatory requirements. In a file upload, DPs must validate that the enhanced data fields are populated for (at least) the payments in scope of our mandatory requirements.
It is in line with our policy to encourage enhanced data for all CHAPS payments (and indeed may be easier to build technically) for DPs to also enable enhanced data fields for payments not yet in scope of our mandatory requirements.
The Bank would like to end this temporary transition period and apply our mandatory enhanced data requirements (set out in Section 4 of this policy statement) to all channels in November 2027. The Bank recognises that this may be an ambitious timeline for some DPs and there may be some challenges to full adoption in some channels on this timescale, but we agree with historic industry feedback about the importance of mandating to increase the usage of enhanced data. By November 2027, it is expected that other major jurisdictions will have migrated to ISO 20022. End-2027 is also the deadline for market infrastructures to meet the CPMI’s harmonisation requirements for cross-border payments. We also expect that CHAPS DPs will have had time to increase both their usage of enhanced data and their communications to clients on the requirements for CHAPS payments. Applying our requirements to all channels is a necessary step along the way to our published intention to technically reject CHAPS payments with incomplete or incorrect enhanced data in future.
Please consider the actions that need to be taken to meet the mandatory enhanced data requirements for all channels from November 2027, speaking with vendors as appropriate.
Question 1:
Are there any barriers (either in relation to CHAPS DP internal processes or through external dependencies) to CHAPS DPs meeting our mandatory enhanced data requirements (set out in Section 4 of this policy statement) through all of their initiation channels by November 2027? If so:
(a) What specific actions do you and/or the wider industry need to take to overcome these barriers?
(b) How much time do you need to address these barriers?
6.2: Mandating the use of Purpose Codes for all CHAPS payments from November 2027
We are planning to mandate the use of Purpose Codes for all CHAPS payments from November 2027.
The Bank set out in its 2020 policy statement its vision to expand our mandatory requirements for Purpose Codes to all CHAPS payments over time, in order to support their potential benefits for the payments ecosystem (as detailed in the benefits of Purpose Codes section above). During the meetings of our EDWG in 2023 and in DP responses to our Readiness survey, industry experts noted that future expansion would be easier to implement if it covered all CHAPS payments, rather than another subset. This is also in line with our general advice to DPs to future-proof their ISO 20022 enhanced data implementations, in order to best prepare for the uptake of its usage both domestically and internationally.
Please consider the actions that need to be taken to meet this requirement for purpose codes for all CHAPS payments from November 2027, speaking with vendors as appropriate.
Question 2:
Are there any barriers (either in relation to CHAPS DP internal processes or through external dependencies) to CHAPS DPs meeting our requirement for Purpose Codes to be included in all CHAPS payments by November 2027? If so:
(a) What specific actions do you and/or the wider industry need to take to overcome these barriers?
(b) How much time do you need to address these barriers?
Please respond to these consultation questions, including any other feedback on this policy statement, by 26 July 2024 to RTGSCHAPScomms@bankofengland.co.uk.
Please indicate in your response if you believe any of the proposals in this consultation are likely to impact persons who share protected characteristics under the Equality Act 2010, and if so, please explain which groups and what the impact on such groups might be.
7: Summary tables of the above CHAPS ISO 20022 enhanced data requirements for May 2025
These tables summarise the first stage of mandated enhanced data in CHAPS payments via the CHAPS rulebook from May 2025. These tables exactly match the policy set out above in the 2024 Policy Statement: Mandating ISO 20022 enhanced data in CHAPS, in a format requested by the Bank’s Enhanced Data Working Group.
Please note that:
- Tables A and B below refer only to enhanced data mandated in May 2025. The Bank has already mandated further enhanced data for later years which is not included here such as structured addresses and remittance data. For more information, please see the sections above in our 2024 Policy Statement: Mandating ISO 20022 enhanced data in CHAPS.
- The Bank also continues to encourage the inclusion of all enhanced data in all CHAPS payments where possible, to realise the benefits of ISO 20022.
7.1: May 2025 mandated enhanced data table
Table A: Enhanced data required in CHAPS by DPs via the CHAPS rule book for May 2025
This table is only for the mandatory enhanced data requirements coming in at May 2025
Channel | Enhanced Data to be included | Scope | Payment Message | From May 2025 |
---|---|---|---|---|
For all channels within a Direct Participant’s control This includes data received via online banking, direct file submission from a corporate client, and existing internal data (eg, from an internal CRM solution). In these channels, the DP should ensure that it is gathering the source data required to include enhanced data like Purpose Codes and LEIs. | Purpose Code – CHAPS will accept any purpose code in the ISO 20022 External Code Set, but recommends purpose codes from the UK Recommended Purpose Codes. | CHAPS payments between Financial Institutions | All pacs.009 core payment messages. A pacs.008 payment messages where both the ultimate effective debtor (a) and ultimate effective creditor (b) are PRA authorised deposit-takers or broker-dealers, or Financial Market Infrastructures supervised by the Bank of England. | Mandatory to include |
CHAPS payments for property payments | All pacs.008 and pacs.009 core payment messages relating to property transactions. | Mandatory to include | ||
LEI (Legal Entity Identifier) – you can access the free database of all global LEIs at GLEIF. | CHAPS payments between Financial Institutions | All pacs.009 core payment messages. See Table B for detail. A pacs.008 payment message where both the effective ultimate debtor and effective ultimate creditor are PRA authorised deposit-takers or broker-dealers, or Financial Market Infrastructures supervised by the Bank of England. See Table B for detail. | Mandatory to include |
Footnotes
- (a) The ‘effective ultimate debtor’ is either: the debtor, where there is no earlier party from which an amount of money is due (and therefore no ultimate debtor is populated): or the ultimate debtor, where there is an earlier party before the debtor from which an amount of money is due.
- (b) The ‘effective ultimate creditor’ is either: the creditor, where there is no further party to which an amount of money is due (and therefore no ultimate creditor is populated); or the ultimate creditor, where there is an additional party after the creditor to which an amount of money is due.
7.2: LEI requirements table by party/agent
Table B: LEI table by agent from May 2025 for applicable payment, channel, and field within payment
Payment channel within DP’s control | ||
---|---|---|
Party/Agent | pacs.009 core (a) LEI requirements | pacs.008 LEI requirements where both the effective ultimate debtor and effective ultimate creditor are FIs |
Ultimate debtor | n/a field removed from CHAPS pacs.009 | Mandatory where ultimate debtor is populated |
Initiating party | n/a not in pacs.009 | Mandatory where initiating party LEI provided |
Debtor | Mandatory | Mandatory where debtor is the effective ultimate debtor (ie, Ultimate Debtor field is not populated). If Ultimate Debtor field is populated, then Debtor LEI is only mandatory to replicate if already provided. |
Debtor Agent | Mandatory where debtor agent LEI provided | Mandatory where debtor agent LEI provided |
Previous Instructing Agents 1, 2 & 3 | Mandatory where previous instructing agent(s) LEI provided | Mandatory where previous instructing agent(s) LEI provided |
Instructing Agent | Mandatory | Mandatory |
Instructed Agent | Mandatory | Mandatory |
Intermediary Agents 1, 2 & 3 | Mandatory where intermediary agent(s) field populated for next immediate agent only. If not the next immediate agent, only mandatory to replicate LEI if already provided. | Mandatory where intermediary agent(s) field populated for next immediate agent only. If not the next immediate agent, only mandatory to replicate LEI if already provided. |
Creditor Agent | Mandatory where creditor agent field populated for next immediate agent only. If not the next immediate agent, only mandatory to replicate LEI if already provided. | Mandatory for next immediate agent only. If not the next immediate agent, only mandatory to replicate LEI if already provided. |
Creditor | Mandatory | Mandatory where creditor is the effective ultimate creditor (ie, Ultimate Creditor field is not populated). If Ultimate Creditor field is populated, then only mandatory to replicate LEI if already provided. |
Ultimate Creditor | n/a field removed from CHAPS pacs.009 | Mandatory where ultimate creditor is populated |