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 in 2025 and 2026 (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).

1.1: Update: Mandatory requirements coming into effect in 2025 and 2026

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.

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.

1. Including all initiation channels within the scope of enhanced data requirements from November 2027.
2. 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 28 June 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.

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 model payment message sets and ‘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 Usage Guidelines 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.

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 over 2025 and 2026

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

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.

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:

1. HLRP: Property Loan Repayment.
2. HLST: Property Loan Settlement.
3. PLDS: Property Loan Disbursement.
4. PDEP: Property Deposit.
5. PCOM: Property Completion Payment.
6. 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

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

4.3.1: Pacs.008 Structured Remittance

From November 2025, any pacs.008 remittance data included 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 to complement the structured remittance information.

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).

The Bank is aware of a change request to create structured remittance fields in the pacs.009 CORE. If this change request is accepted by HVPS+, the Bank will align its schemas and Technical Guidance.

The Bank expects to mirror the mandatory requirements that apply to pacs.008 messages in any future mandatory requirements on the pacs.009 CORE structured remittance, 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 also consider aligning 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

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.

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

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.

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 28 June 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.