Corporate Bank

Guide to ISO 20022 exceptions and investigations (E&I) migration and case orchestration

corporates/db.com Deutsche Bank

Guide to ISO 20022 exceptions and investigations (E&I) migration and case orchestration

When we published our fifth and final Guide to ISO 20022 in September 2022, we stressed that the transformation was far from completed and that the 'after ISO' period would bring plenty more to discuss. This latest guide explores one of the key upcoming deliverables set to define that era: the transformation of exceptions and investigations (E&I) handling.

From November 2025 and continuing through to 2027, the changeover will introduce dedicated ISO 20022 messages for E&I handling – enabling richer data exchange, greater automation, and faster resolution of any issues. The introduction of new messages will be complemented by Swift's Case Orchestrator, designed to manage and ultimately redefine the end-to-end investigation lifecycle.

Realising these benefits will require significant effort and investment. Financial institutions need to modernise legacy infrastructures, equip staff with the skills to operate in the new E&I environment, and coordinate change management across business, operations, and technology functions. This guide explores the technical details of the transformation while providing a practical roadmap to support the journey.

Published September 2025

Deutsche Bank Editors

Clarissa Dann, Editorial Director, Corporate Bank Marketing, Deutsche Bank Will Monroe, Digital Editorial Marketing Manager, Corporate Bank Marketing, Deutsche Bank

Deutsche Bank Contributors

Main author: Karyna Hutarovich, Business Product Specialist, Deutsche Bank Patrick Beettjer, Product Tribe Lead, Deutsche Bank John Foran, Product Manager, Deutsche Bank Christopher Gardner, ISO 20022 Programme Lead, Deutsche Bank Andreas Gross, Process Re-Engineering Manager, Deutsche Bank Kostiantyn Khoruzhiy, Product Manager, Deutsche Bank Patricia McLoughlin, Senior Programme & Change Execution Director, Deutsche Bank Paula Roels, Head of Swift and Market Infrastructures, Deutsche Bank Laura Sinnott, Operations Lead, Deutsche Bank

Contents

Forewords 4 Executive summary 6 1 The current E&I landscape 7 1.1 Today's payment E&I challenge 7 1.2 The impact of E&I 11 2 Future state vision 12 2.1 Redesigning ISO 20022 E&I messages 14 2.2 Case orchestration 18 3 Technical deep dive 19 3.1 Message portfolio 19 3.1.1 New core E&I messages 21 3.1.2 Cancellation messages 25 3.1.3 Notification messages 27 3.2 Case orchestration layer 29 3.2.1 Connectivity options 29 3.2.2 Key considerations for centralised orchestration 30 4 Timelines 34 4.1 Controlled live 34 4.2 General availability 37 4.3 Full target state 39 5 Implementation considerations 40 5.1 Project setup 41 5.2 Solution strategy 42 5.2.1 Swift GUI solution 42 5.2.2 Vendor solution 43 5.2.3 In-house solution 43 5.3 Solution implementation 43 5.4 Migration planning 48 5.5 Testing and validation 49 5.6 Training and awareness 49 6 Additional resources 50

Foreword

Joanne Hannaford, CIO & CPO, Corporate Bank, Deutsche Bank

The financial industry is in a state of continuous evolution, and a key driver of that change is our unwavering commitment to using technology to solve the industry's most persistent problems. While we have made significant progress in digitising core payments, a stubborn and costly challenge remains: the inefficient process of payments exceptions and investigations (E&I). For decades, this has been a manual, resource-intensive activity and a source of friction for our clients and our operations alike.

As a technology leader and an engineer at heart, I believe this is our moment to fundamentally transform this reality. The industry-wide migration to the ISO 20022 standard is not just a technical upgrade; it is a mandatory, generational shift. The crucial next phase of this transition – the launch of new messages for E&I – is a strategic imperative for every institution. It demands that we think beyond compliance and view it as a crucial business investment.

The cost of inaction – in terms of resource-intensive manual processes, a fragmented data landscape, and missed opportunities for automation – far outweighs the investment required to lead this change. We are not just adopting a new standard; we are building a new technological foundation for the future of payments.

Foreword

Ciaran Byrne, Global Head of Product and Client Solutions, Institutional Cash Management, Deutsche Bank

Building on the foundation that Joanne has described, our ultimate goal is to deliver a superior and more transparent experience for our clients. For them, a smooth, reliable payments process is not a luxury – it is foundational to how they operate their business and manage risk. While the payments landscape has already begun its transition, a critical challenge has remained: the opaque and manual process of managing E&I.

This is precisely the challenge the industry's new ISO 20022 messages for E&I are designed to solve. To truly capitalise on this opportunity, we are working with our industry peers on a complementary solution: the Case Orchestrator. This powerful, centralised capability, developed by Swift in collaboration with the industry, will bring a new level of automation and intelligence to the full lifecycle of investigation cases. As active participants in this initiative, we are focused on ensuring it delivers tangible benefits.

For our clients, this means more than just faster payments and reduced operational risk. It means greater clarity, more precise communication, and the confidence that their transactions are handled with unparalleled speed and efficiency.

To help our clients and the wider industry navigate this complex transition, we have developed this guide as a practical resource. It outlines the future state vision, the ISO 20022 message portfolio, and the key actions needed to implement this change effectively.

This is a journey that we look forward to continuing together.

Executive summary

The E&I handling process has proved a challenge for the financial industry since the 1980s. To this day, it remains one of the most resource-intensive components of payment operations – a result of fragmented processes, inconsistent data structures, and a lack of end-to-end case identification. For end customers, delays in resolving investigations can cause uncertainty, reputational damage, and even operational disruption, particularly when it comes to time-sensitive transactions.

Over the next few years, the industry has a unique opportunity to resolve many of these longstanding and costly inefficiencies. From November 2025, the payments industry begins its ISO 20022 E&I migration, with the launch of a controlled live phase: the first of three phases that are set to be completed by November 2027.

The transition involves introducing dedicated ISO 20022 messages that will support structured, rich data exchanges, enabling higher levels of automation, clearer communication, as well as faster resolutions to upscale the customer experience.

To unlock true end-to-end efficiency, the industry has also developed the Case Orchestrator: a centralised capability – inspired by the Swift Transaction Manager – to oversee the full lifecycle of investigation cases. This approach offers the potential to streamline routing, eliminate unnecessary intermediary steps, and ensure only relevant parties are involved; all while upholding data privacy and access controls.

Though the benefits of the ISO 20022 E&I migration are considerable – from greater automation and clearer communication to faster resolutions and improved customer experience – the scale of the challenge ahead is daunting. This is not simply a technical upgrade or the adoption of new message formats; it requires a fundamental rethink of operating models and workflows. Financial institutions (FIs) will need to modernise legacy infrastructures, commit significant resources, equip staff with the right skills, and – critically – standardise, test, and validate solutions at every stage.

To succeed, this initiative should be treated as more than just another operations project. A smooth transition will require coordinated effort across all functions involved in initiating or handling payment-related inquiries – spanning technology, operations, and business. Institutions aiming to manage this cross-functional change effectively would be well advised to begin preparations at the earliest opportunity.

This guide to ISO 20022 E&I migration and case orchestration is intended as a practical handbook for the industry – a reference point that unpacks the technical details, sets out key milestone dates, and outlines a suggested roadmap for FIs and their clients. We look forward to continuing the conversation as developments progress in the years ahead.

1 The current E&I landscape

The cross-border payments landscape has undergone significant transformation in recent years, driven by a range of initiatives focused on improving the efficiency, transparency and reliability of payment processing. Yet while progress has been made in many areas, others remain underdeveloped – and continue to frustrate customers and impose substantial operational costs on FIs.

One such area is the handling of E&I, where average resolution times of five to eight days and inefficient processes are estimated to cost the financial services industry US$1.6bn annually. This is largely due to a combination of fragmented processes, free-form data, limited visibility and multiple handoffs across the payment chain.

The following section takes a closer look at today's E&I processes to uncover the key contributors to ongoing inefficiencies.

1.1 Today's payment E&I challenge

Payment E&I processes are triggered when a payment cannot be completed or settled as intended – and additional information or a correction is required. When such an exception arises, the payment is flagged for manual review, and an investigation is launched to determine the root cause and what corrective action is needed.

The most common scenarios – forming approximately 90% of all investigations processes – are presented in Figure 1.

While the goal of E&I processes is to resolve the issue and ensure funds are delivered accurately and securely, the process often becomes time-consuming, costly and complex. Among the underlying reasons for this is the current lack of industry-agreed processes.

Figure 1: Most common E&I scenarios today

Request for cancellation

A message is sent to request cancellation of the original payment

Unable to apply

A message is sent when a payment received cannot be applied due to missing or incorrect information

Request for information

A message is sent to request additional information on the original payment

Creditor claims non-receipt

A message is sent to initiate investigation for missing funds

The image shows a diagram illustrating these four common E&I scenarios with payment flows between Debtor, Debtor agent, Intermediary agent, Creditor agent, and Creditor, including both payment messages and E&I messages.

Most investigations are handled through free-format MT messages (e.g. MT199/299) that are exchanged point-to-point – i.e. the request is passed from one bank to another down the payment chain. This introduces challenges for the following reasons:

—Lack of standardisation. The nature of free-format MT messages allows very limited automation – if any – which translates into greater costs, with no end-to-end identification option and no traceability.

—Inconsistent data structure. The unstructured nature of MT messages makes them difficult to interpret or process systematically, increasing the manual workload and the risk of miscommunication.

—No end-to-end case identification. Unlike payments, which can be tracked using the Unique End-to-End Transaction Reference (UETR), investigation cases lack a common identifier across institutions. This absence of traceability makes it difficult to monitor and coordinate cases across the payment chain.

—No centralised tooling for case tracking. There is currently no infrastructure or shared platform that provides visibility into the lifecycle or status of investigation cases, further limiting transparency and control.

—Use of inefficient communication channels. In many cases, investigations are still handled through manual methods such as email or phone calls. These informal channels further increase complexity, reduce auditability, and obscure visibility into case progress.

Figure 2 provides an overview of the MT messages currently used for E&I handling. Among these, the free-format MT199/299 messages remain the most widely adopted, despite their limitations.

Figure 2: Current MT E&I portfolio for payments

MT Message Type	Definition	Usage	Format
MT192/292	Request for cancellation	A message is sent to request cancellation of the original payment	Limited structure
MT195/295	Queries	A message is sent to request information or clarification relating to the underlying payment	Limited structure
MT196/296	Answers	A message is sent to provide a response to a previous query	Limited structure
MT199/299	Free-format message	A message is sent to exchange information for which another message type is not applicable	Unstructured

A typical E&I process in action

Take the case of a corporate client in the United States – the debtor – who sends a cross-border payment to a supplier in Germany (see Figure 3). The payment flows from the corporate's bank (the debtor agent), through a correspondent bank (intermediary agent), and on to the supplier's bank (the creditor agent), before reaching the supplier.

However, when the payment arrives, the supplier's bank flags that a required detail is missing – for example, remittance information – and is unable to apply the funds. It sends a free-format MT199 message to the correspondent bank, requesting clarification. With no context or authority to resolve the issue, the correspondent forwards the query to the corporate's bank, which then contacts the corporate client for the missing information.

The challenge is that each bank in the chain must manually review and pass on the message, even if they add no value to the resolution. This back-and-forth can take days – creating delays, added costs, and poor customer experience.

Figure 3: The traditional investigation process

The image shows a diagram illustrating the traditional investigation process with payment flows between Debtor, Debtor agent, Intermediary agent, Creditor agent, and Creditor, including both underlying payment messages (MT 103) and investigation request/response messages (MT 199).

Note: MT199 is typically used to exchange information related to a previous customer credit transfer message, such as an MT103. In contrast, MT299 is generally used in the context of financial institution credit transfers, for example, MT202.

1.2 The impact of E&I

The investigation process has regularly posed a challenge for the financial industry since the 1980s, remaining one of the most resource-intensive components of payment operations. Fragmented processes and prolonged resolution times create significant workload burdens across multiple teams. These inefficiencies divert skilled resources away from higher-value, revenue-generating activities.

For end customers, delays in resolving investigations can cause uncertainty, reputational damage, or operational disruption – particularly in time-sensitive transactions. According to Swift research, industry players report a 3%+ customer attrition rate due to poor E&I experiences.

These challenges have not gone unnoticed. The industry has made several efforts to introduce greater standardisation and innovation in the handling of investigation cases. Initiatives such as the gpi Stop & Recall Payment (SRP) launched by Swift in 2018, or the gpi Case Resolution launched the following year, introduced rulebooks and centralised handling mechanisms for addressing specific scenarios. However, while well intentioned, these efforts only addressed a limited number of use cases and failed to gain the critical mass required for broader impact. In part, this was due to their voluntary nature, as well as budgetary priorities across the industry.

Streamlining this process offers significant potential to reduce costs and improve client satisfaction. Moreover, the ongoing global migration of cross-border payments to ISO 20022 – a common global language for payment data, enabling faster processing and improved reconciliation – creates a timely and strategic opportunity to revisit and resolve longstanding inefficiencies in E&I processing.

2

Future state vision

With the global migration of cross-border payments to ISO 20022 the financial services industry has taken the opportunity to reimagine E&I processing. Rather than retrofitting legacy practices, the community has committed to designing a new, standards-based framework that reflects today's technological capabilities and data requirements.

A key pillar of this transformation is the introduction of dedicated ISO 20022 messages tailored specifically for E&I scenarios. These messages are designed to support structured, rich data exchanges. This will allow for higher levels of automation, clearer communication, and better alignment with specific use cases – ultimately reducing ambiguity and manual intervention.

In parallel, drawing on the operational success and model of the Swift Transaction Manager – a central orchestration layer launched in May 2023 that maintains a single, authoritative transaction record to manage and validate cross-border payments end to end – the industry has proposed the development of a centralised case-handling capability: the Case Orchestrator.

The Case Orchestrator would also serve as a central orchestration layer, managing the end-to-end lifecycle of investigation cases, based on agreed industry rules. It would streamline routing, reduce unnecessary intermediary steps, and ensure that only relevant parties are involved – while respecting data privacy and access control.

By combining modern message design with centralised orchestration, the future vision aims to significantly reduce the volume of investigations, while enabling faster, more efficient resolution of those remaining. This new approach is expected to improve operational efficiency, lower costs, and enhance the overall customer experience.

The future E&I process in action

Under the proposed new model (see Figure 4), the Case Orchestrator acts as a central orchestration layer. Instead of routing investigations through every party in the chain, it uses smart routing to direct queries straight to the bank best positioned to resolve the issue.

In the example below, the creditor agent identifies a problem and raises a camt.110 message. This is sent to the Case Orchestrator, which determines that the debtor agent is the appropriate party to respond and routes the message directly to them. The debtor agent sends back a response using a camt.111 message, which the Case Orchestrator then forwards to the creditor agent.

Figure 4: Future investigations

[The image shows a diagram of the orchestrated investigations process flow between Debtor, Debtor agent, Intermediary agent, Creditor agent, and Creditor, with the Case Orchestrator in the center managing message routing]

2.1 Redesigning ISO 20022 E&I messages

The ISO 20022 portfolio includes a set of messages designed to support E&I handling, as illustrated in Figure 5. However, these messages – originally developed in the early 2000s – have seen only limited industry adoption. Designed at a time when both technology and operational requirements were significantly different, they reflect a user-centric model focused on manual intervention rather than the automated, machine-to-machine communication that characterises today's payment environment. In response to these limitations, the global community reached consensus that future standards for E&I handling must be redefined.

Figure 5: Legacy ISO 20022 E&I messages

ISO 20022 message	Supported use case
camt.026	Unable to apply
camt.027	Claim non receipt
camt.028	Additional payment information
camt.032	Cancel case assignment
camt.035	Other investigation
camt.036	Debit authorisation response
camt.037	Debit authorisation request
camt.038	Case status report request
camt.039	Case status report
camt.087	Request to modify payment

The new standards are expected to support full end-to-end automation, feature an adaptable design, and serve as a foundation for both traditional message-based and API-based communication. Alignment with the existing ISO 20022 pacs message family was also a key design consideration, helping to ensure consistency, interoperability and clarity across the payment lifecycle. As a result, the legacy message set was deemed no longer fit for purpose and has been redesigned from the ground up to meet modern operational, technological and business needs.

The newly defined ISO 20022 'base' messages for E&I – the Investigation Request Message camt.110 and the Investigation Response Message camt.111 – were developed to reflect the updated requirements. These messages introduce several key innovations designed to streamline communication, reduce manual handling and improve traceability across the case lifecycle:

1. End-to-End Investigation Reference (EIR). Each investigation is assigned a unique end-to-end reference, enabling all related information exchanges to be linked and tracked consistently across all parties. This ensures complete visibility and traceability throughout the lifecycle of the case – supporting transparency, auditability, and effective case orchestration.

2. Structured Investigation Type/Subtype. Unlike the original ISO 20022 E&I messages, the new camt.110 and camt.111 messages follow a structured question-and-answer model. This model allows for a broad range of investigation types and subtypes within a unified message format (see Figure 6). By embedding specific codes, the messages clearly identify the nature of the investigation, enabling faster and more accurate internal routing.

Point of attention: RQDA

The RQDA (sub)type involves a structured exchange using a camt.110 to request debit authorisation, and a camt.111 to respond, for example, by granting the requested authorisation.

Note that camt.111 cannot be sent proactively – it must follow a prior camt.110. Only the account-servicing institution may initiate the request. If an account owner cannot apply a payment, they must return it using a pacs.004, rather than sending unsolicited debit authority.

Investigation types that were originally envisioned as distinct messages – such as Request Debit Authorisation (RQDA), Request Value Adjustment (RQVA), Request Use of Funds (RQUF), and Request Related To Charges (RQCH) – will initially be grouped under a general category 'Other' (OTHR) for the first release of the Case Orchestrator. However, differentiation will still be possible via the 'subtype' data element – allowing flexibility while maintaining a clean message structure. These cases may be re-evaluated in the future for possible separation into distinct investigation types.

3. Investigation Data. The new message structure includes a dedicated investigations data block, which captures the core details of the request. It specifies both the reason for the inquiry and the data to be investigated, using either predefined codes or free-text, as illustrated in Figure 7.

Figure 7: E&I message extract

CAMT.110 (Question)

• Investigation Request
  • Requestor Investigation ID
  • EIR
  • Investigation Type
  • Investigation Sub Type
  • Underlying Instrument
  • Underlying
    • Initiation
    • Interbank
    • Account
    • Other
• Investigation Data
  • Sequence
  • Reason Code
  • Reason Sub Type Code
  • Additional Request Data
    • Request Narrative

CAMT.111 (Answer)

• Investigation Response
  • Responder Investigation ID
  • Investigation Status
  • Investigation Data
    • Orig Investigation Sequence
    • Orig Reason Code
    • Response Data
      • Transaction Data
      • Response Narrative
• Original Investigation Request
  • Requestor Investigation ID
  • EIR
  • Investigation Type
  • Investigation Sub Type
  • Underlying Instrument

Point of attention: CPMI ISO 20022 data harmonisation requirements

CPMI minimum data requirement #1 recommends the use of ISO 20022 messages that are appropriately aligned with the relevant business function. Market infrastructures that have implemented earlier ISO 20022 messages for E&I – such as camt.026 – are encouraged to transition to the updated message set (camt.110/camt.111) before the end of 2027 to align with these harmonisation goals.

Where E&I is handled outside the market infrastructure (e.g. via Swift), adoption of the new ISO 20022 messages is not expected unless explicitly driven by market demand.

2.2 Case orchestration

The implementation of structured ISO 20022 messages for E&I is expected to significantly enhance processing efficiency through standardised formatting, and the use of EIR and clearly defined codes. However, message structure alone is not sufficient to fully streamline industry-wide handling.

To enable true end-to-end efficiency, the industry has called for the introduction of centralised case orchestration – a function that will be delivered by Swift, building on the successful model of the Transaction Manager and leveraging insights from the Tracker, the central Swift service that records, monitors, and distributes status information related to payments and investigations. Formally referred to as the 'gpi Tracker', its scope has been expanded beyond payment tracking to include case orchestration and associated services. All ISO 20022 E&I messages and related notifications are exchanged via the Tracker, ensuring consistent visibility and control across the transaction lifecycle.

Under this model, E&I messages will be directed to a central orchestration engine for data enrichment and smart routing, allowing cases to be sent directly to the party best positioned to resolve them. In many scenarios, this will eliminate the need for intermediaries to act as passive relays, reducing unnecessary workload and delays.

For example, an Unable to Apply Payment (UTAP) request can be routed directly from the creditor agent to the debtor agent, bypassing intermediaries that have no role in resolution. This reduces friction, avoids redundant communication and accelerates time to resolution. In specific use cases, the central engine will also generate an automatic response to investigation requests, thus helping to reduce manual workload (see Section 3.2.2.2).

The orchestration framework is governed by an industry-agreed rulebook, which defines how messages should be structured, routed and processed. This rulebook is a foundational component of the solution and should be carefully understood and adhered to in implementation efforts. This rulebook is available to registered users via the Swift platform, and a link to the document is included in the reference section of this guide.

Point of attention: Message addressing from November 2026

As of November 2026, all ISO 20022 E&I messages – camt.110, camt.111, camt.056, camt.029, as well as trck.003 and trck.005 – must be exchanged via the Case Orchestrator BIC (TRCKCHZZ), regardless of whether the case qualifies for smart routing. This represents a change in practice for cancellation messages (camt.056 and camt.029), which are currently exchanged either bilaterally (e.g. under Cross-Border Payments and Reporting Plus (CBPR+)) or centrally under gpi SRP. Unlike the former gpi Services, which operated on an opt-in basis, this mandated model establishes the Case Orchestrator as the new normal across the ecosystem, and the 'gpi' prefix is therefore removed from both the Tracker BIC and the Stop & Recall service. Going forward, all ISO 20022 cancellation messages must be routed through the orchestrator, and the Business Application Header (BAH) must reflect TRCKCHZZ as the sender (BAH From) or receiver (BAH To) accordingly.

3

Technical deep dive

The following chapter provides a detailed overview of the two key components driving the transformation in E&I handling: the newly defined ISO 20022 messages and the central orchestration layer (see Figure 8).

Figure 8: The E&I framework

[The image shows a diagram of the E&I framework with Case management at the top, and two columns below: Data model (listing camt.110, camt.111, trck.003, trck.005, camt.056, camt.029) and Central orchestration (showing Case Orchestrator and SRP)]

3.1 Message portfolio

The E&I transformation introduces a new set of ISO 20022 messages, as illustrated in Figure 9. This includes the following messages:

—Core E&I messages: —camt.110 – Initiates an investigation request —camt.111 – Responds to an investigation request

—Cancellation messages: —camt.056 – Requests the cancellation or recall of a payment —camt.029 – Provides the response to a cancellation request

While the core E&I messages were designed from the outset to work with the Case Orchestrator, the cancellation messages were introduced earlier as part of the CBPR+ message portfolio. As a result, the camt.056 and camt.029 messages will need to be adapted to follow the same logic – and are not being formally incorporated into the core E&I message portfolio. As part of this transition, they will, however, be orchestrated through the same framework that governs E&I processing and will operate in line with the logic used for SRP services.

A key change is that participants will need to update message addressing: instead of routing messages directly to the next agent in the payment chain, all messages must now be sent to the central orchestration engine (Case Orchestrator), which is accessible via the Tracker BIC (TRCKCHZZ). This enables the orchestration layer to apply smart routing and centralised handling logic to cancellation cases as well.

In addition, the following notification messages will be introduced to deliver real-time updates on key actions taken during the investigation process – such as confirmation of delivery or status changes:

—trck.003 – Tracker Alert Notification —trck.005 – Tracker Investigation Status Notification

Figure 9: CBPR+ SR 2024 ISO 20022 message portfolio

[The image shows a detailed table of the CBPR+ SR 2024 ISO 20022 message portfolio, organized by business areas including Payments initiation (pain.xxx), Payments clearing and settlement (pacs.xxx), and Cash management (camt.xxx), with MT equivalents listed for each message type]

3.1.1 New core E&I messages

The core investigation request and response messages – camt.110 and camt.111 – are designed to be exchanged in a sequential, request-response pattern. A camt.111 message must always be issued in response to a preceding camt.110 – it cannot be sent independently. Conversely, a camt.110 shall never be used as a notification; it is strictly a request message for which a camt.111 response is always expected.

The following points summarise the key characteristics of the messages structure:

3.1.1.1 Message structure

Similar to ISO 20022 messages used in the payments domain, E&I messages consist of two main parts:

—BAH. The BAH is essential for message routing and orchestration.

—Payload composition. The payload is structured into two main components:

—Investigation data/investigation response. Contains the details of the inquiry, including the questions being raised.

—Investigation request component/original investigation request component. Holds key references and contextual data needed to initiate or respond to the case.

3.1.1.2 References

Investigation messages use a set of structured references (see Figure 11), each serving a specific purpose in the end-to-end-process:

—Message Identification. A point-to-point reference used to uniquely identify the message itself.

—Requestor Investigation Identification. A unique reference assigned by the requestor to identify the investigation case from their perspective.

Point of attention: Usage of the EIR

The EIR is a mandatory universally unique identifier (UUID v4). It is used to link all messages related to a specific investigation and concerning an underlying transaction or account-related activity (e.g. a payment or a statement entry). It may be generated either by the requestor or by the Swift Case Orchestrator (e.g. when using GUI).

To ensure proper orchestration, all messages in the same investigation thread – both requests and response – must carry the same EIR.

Like the UETR in payments, the EIR must not be reused across unrelated investigations. However, it may be reused across related cases tied to the same underlying value. For example, a CCNR (CreditorClaimNonReceipt) request may lead to a follow-up CONR (CoverCreditorClaimNon-Receipt) if funds are later found to be stuck in the cover leg.

—Responder Investigation Identification. A unique reference assigned by the responder to track the investigation case within their system.

—EIR. A globally unique reference that links all messages and responses related to a single investigation case across the entire chain.

—Underlying UETR. The UETR of the original payment, enabling linkage between the investigation and the payment transaction.

Figure 11: Key E&I references

[This page contains a detailed diagram showing the flow of references between Debtor, Debtor agent, Intermediary agent, Creditor agent, and Creditor, with various message IDs, requestor IDs, responder IDs, EIR, and UETR values illustrated in the context of underlying transaction, investigation request, and investigation response.]

Point of attention: Clarification on actions

Certain actions are not permitted for specific investigation types. For example, RQOB (Objection) is not applicable to the RQFI investigation types. In such cases, if further clarification is needed, a new camt.110 follow-up should be submitted instead.

3.1.1.3 Actions

While the primary purpose of the camt.110 message is to initiate an investigation request or query, the message structure also supports a set of additional actions through a dedicated 'Request Action' component. This component contains structured options that enable specific follow-up functionalities within the same message framework:

—RQCL (Request Investigation Closure). Used to cancel or formally close an ongoing investigation.

—RQST (Request Investigation Status). Triggers a status inquiry, functioning as a status reminder.

—RQOB (Request Objection). Indicates that the requester disagrees with the response received in a previous camt.111 message.

Point of attention: Inclusion of EIR in additional messages

To support cross-functional traceability and improve reconciliation, future ISO 20022 message upgrades will include the EIR in additional message types. This will enable investigation cases to be consistently referenced across related message portfolios and subsequent processes. Examples of messages expected to include the EIR in future releases include: camt.105, camt.106, camt.056, camt.029, trck.003 and pacs.004.

Point of attention: UTAP vs UTEX investigation type

While most use cases align with current practices across the network, it is necessary to distinguish between two specific scenarios: Unable to Apply (UTAP) and Unable to Execute (UTEX). The UTAP message is intended exclusively for post-booking situations, where the payment has been credited to the creditor's account but cannot be applied – typically due to missing remittance information. In contrast, the UTEX message is used in the pre-booking stage, when an agent is unable to process the payment and requires additional information before execution can proceed.

3.1.1.4 Codes

A core advantage of the ISO 20022 standard lies in its use of structured, coded data elements, which reduce ambiguity and enable higher levels of automation, for example in the handling of anti-money laundering (AML) queries (see Figure 12). This principle is also central to E&I messages, where several key elements can be populated using predefined codes to support efficient case handling:

—Investigation Type. Identifies the nature of the investigations, enabling automated routing to the relevant internal teams. For example, queries related to CCNR may be directed to a different team than those concerning sanctions screening.

—Underlying Instrument. Specifies the type of business context or object the investigation relates to, such as a cross-border payment or a statement entry. This distinction also impacts message population; for example, a UETR is mandatory for cross-border payments but not required for other instruments.

3.1.2 Cancellation messages

Since the start of the ISO 20022 and FIN MT coexistence period for cross-border payments in March 2023, two distinct approaches have been used to handle cancellation requests:

1. Sequential exchange (CBPR+) model. In this approach, cancellation requests are relayed step-by-step along the payment chain. A camt.056 (cancellation request) and its corresponding camt.029 (response) are exchanged between each pair of agents in sequence. Messages are formatted in line with CBPR+ usage guidelines.

Figure 12: Handling of AML queries: today vs tomorrow

[This page contains a detailed comparison diagram showing the handling of AML queries in two scenarios: "Today" and "Tomorrow". The diagram illustrates the differences between unstructured format/lack of standardization in today's process versus structured format/central orchestration in tomorrow's process, with examples of message formats and flows between different parties (Debtor, Debtor agent, Intermediary agent, Creditor agent, and Creditor).]

2. Centralised orchestration (SRP) model. Under the SRP service (only applicable to customer credit transfers – pacs.008), camt.056 messages are sent to the Tracker, which then routes the messages directly to the most relevant party for resolution. This model leverages central orchestration and follows the rules defined in the Stop and Recall Rulebook.

With the roll-out of the new Case Orchestrator, the handling of cancellation messages will be fully standardised – eliminating the current distinction between CBPR+ and SRP processes.

Following the E&I migration, all camt.056 and camt.029 messages – regardless of whether they relate to a customer credit transfer (pacs.008) or a financial institutions credit transfer (pacs.009) – will be routed through the central orchestrator (Tracker BIC: TRCKCHZZ) for processing. The corresponding usage guidelines will be updated to reflect this new model, as illustrated in Figure 13.

Figure 13: Key differences between CBPR+ vs SRP

[This section contains a table comparing data elements between CBPR+ v8, SRP, and Future orchestrated camt.056]

3.1.3 Notification messages

As part of the Case Orchestrator lifecycle, new notification messages (see Figure 14) will be introduced to keep participants informed of key events and system-driven actions throughout the case process. These include:

—trck.003 (tracker alert notification). Sent to the requestor or responder to indicate that a submitted message has failed validation (e.g. due to incorrect formatting or missing data)

—trck.005 (tracker investigation status notification). Provides the requestor with real-time updates on the status of the investigation, for case management as well as SRP. The notification covers the following status acknowledgments:

—S000. SRP request was valid and accepted by the Case Orchestrator (SRP).

—S001. UETR placed on network cancellation list (SRP).

—S002. Network stop executed on the UETR.

—S003. SRP request assigned to assignee (SRP).

—S004. SRP request delivered to assignee (network ack) (SRP).

—ASGN. Investigation request assigned to responder (Case).

—DTRP. Investigation request delivered to responder (Case).

—ERMD. Reminder sent by assignee/requester (Case and SRP). May be followed by a DTRP status.

—ARMD. Reminder sent by assignee/requestor (Case and SRP). May be followed by a DTRP status.

These notifications are designed to improve transparency, traceability and user awareness across the lifecycle of each investigation case.

Figure 14: Notification messages

[This section contains a diagram showing the structure of trck.003 (rejection) and trck.005 (notification) messages, with their components and data elements]

Point of attention: Using Case Management GUI

Users operating via the Case Management GUI should evaluate how best to meet internal requirements for screening, archiving, and reconciliation. Where needed, a GUI option can be activated to provide ISO 20022 message copies of the GUI data. This supports effective filtering, archiving, and ensures consistency between manual action and system records.

Point of attention: Understanding the application programming interface (API) release schedule

The initial API release will support POST (to submit investigation requests and response) and GET (to retrieve case details). PUSH APIs – which would enable automatic delivery of updates, including new cases, case events, or changes to existing investigations – are not yet supported. Today, several segregated APIs exist, each covering a specific investigation type. These will be replaced by an overarching GET API to streamline access across investigation types. Further details on the release schedule and functionality will be published by Swift.

3.2 Case orchestration layer

Alongside the new E&I message portfolio, the other key driver of the upcoming changes is the Case Orchestrator. This section outlines the core concepts of the case orchestration layer and highlights key considerations for the future handling of E&I within a centrally coordinated, automated ecosystem.

3.2.1 Connectivity options

Participants can connect to the Case Orchestrator through one of the following three channels:

—FINplus. Enables the exchange of investigation and notifications messages in ISO 20022 format.

—Swift Graphical User Interface (GUI). A screen-based interface designed for users to manually initiate, monitor, and respond to investigation cases.

—API. Supports system-to-system integration, allowing automated submission and retrieval of investigation-related data via the Case Orchestrator.

Although messaging users (i.e. those connected via FINplus) will need to implement and consume the relevant ISO 20022 messages as outlined above, the same underlying data model applies across all channels – API and GUI included. For example, FINPlus users will exchange trck.003 and trck.005 notifications, while GUI users will receive the same updates via on-screen interface notifications.

3.2.2 Key considerations for centralised orchestration

Core features of centralised investigation orchestration include smart routing, auto-response, data pre-population, and automated status reminders, as well as end-to-end visibility on the case status. However, the applicability of each feature is governed by predefined business rules and may vary depending on specific case conditions, as detailed below:

3.2.2.1 Smart routing

Rather than passing investigations through every intermediary, the Case Orchestrator uses smart routing to send queries directly to the bank best able to resolve them (see Figure 15):

—Investigation type dependency. Smart routing will be selectively applied to specific investigation types, such as CCNR/CONR and UTAP – where it delivers clear operational benefits. For other types, including RQFI and OTHR, smart routing will not be enabled due to limited processing efficiency or sensitivity concerns raised by the compliance community, particularly in cases involving high-risk data.

—Migration phase dependency. The application of smart routing rules will evolve over the course of the phased E&I migration. In the initial phase, smart routing will only be applied when the relevant counterparty – such as the creditor agent (for CCNR) or debtor agent (for UTAP) – has completed migration to ISO 20022 messaging and is therefore automatically participating in case orchestration for E&I. Full smart routing capabilities will become available once market-wide adoption is achieved.

Figure 15: CCNR investigation

[This section contains a diagram comparing Serial CCNR investigation vs Smart routed CCNR investigation, showing the flow between Debtor, Debtor agent, Intermediary agents, Creditor agent, and Creditor, with the Case Orchestrator in the smart routing scenario]