SWIFT’s cancellation and investigation messages, mapped: camt.056/029, camt.110/111, and pain.002/camt.055/029 in one place

Three posts on this site, all published within the same week, each cover a different leg of SWIFT's payment cancellation and investigation message family: what changes when one correspondent bank cancels a payment it sent another, what changes when a customer asks its own bank to cancel a payment, and what happens when someone needs to investigate a payment without cancelling it at all. Read individually, those look like three passes at a similar-sounding topic. Read together, they're three separate conversations, each with its own message set and its own participants — and understanding which is which is the actual point of this post. This post is the map, not a rehash; if you want the full mechanics, timeline, and checklist for any one leg, follow the link below to the post that covers it in full.

The bank-to-bank leg: camt.056 and camt.029

When one correspondent bank wants to cancel a payment it already sent another, that's camt.056 (FIToFIPaymentCancellationRequest), replacing the legacy MT192 (and MT292 for FI-to-FI cover cancellations). The responding bank confirms whether the request was accepted, rejected, or is still pending with camt.029 (ResolutionOfInvestigation), replacing MT196 (and MT296). camt.056 trades MT192's narrative free text for a trackable case ID and structured cancellation reason codes — a meaningful difference in a message whose entire value depends on the receiving bank acting on it fast. Full detail: [MT192/MT196 to camt.056/camt.029](/blog/mt192-mt196-to-camt056-camt029-cancellation-migration).

The investigation-only leg: camt.110 and camt.111

Not every case is a cancellation. camt.110 (InvestigationRequest) and camt.111 (InvestigationResponse) are the structured replacements for the free-format MT199/MT299 correspondence banks use today for "where is my payment" queries, misdirected-funds investigations, and other ad hoc case types — request-for-information and unable-to-apply cases among them. The structural difference that matters most here isn't the message format, it's the channel: unlike camt.056/camt.029, there's no bilateral option for camt.110/camt.111. They can only be exchanged through SWIFT's Case Management service, which turns readiness into a connectivity and onboarding question rather than a field-mapping exercise. Full detail: [camt.110/camt.111 and the Case Management onboarding problem](/blog/camt110-camt111-investigation-request-case-management-onboarding).

The customer-to-bank leg: pain.002, camt.055, and camt.029

When a corporate or treasury team wants to cancel a payment it already initiated, it sends camt.055 (Customer Payment Cancellation Request) to its own bank, which responds with camt.029 and reports ongoing status back via pain.002 (Customer Payment Status Report) — the same camt.029 message type used in the bank-to-bank leg above, just answering a different leg of the conversation. Adoption of these "ancillary messages," as SWIFT groups them, is subject to bilateral agreement between an institution and each counterparty or customer channel — but a November 2026 RMA bootstrap forces every institution to be able to receive them regardless of where its own sending agreements stand, and full adoption is required by November 2027. Full detail: [pain.002, camt.055, and camt.029](/blog/pain002-camt055-camt029-ancillary-messages-2027).

Who is cancelling what, and who are they telling

The cleanest way to keep the three apart is to ask two questions of any given message: who initiated it, and who's being told. A correspondent bank cancelling a payment it sent another correspondent bank sends camt.056 and gets camt.029 back — that's bank talking to bank. A corporate or treasury team cancelling a payment it already sent its own bank sends camt.055, gets camt.029 back, and gets ongoing status via pain.002 — that's customer talking to its own bank. Someone investigating or inquiring about a payment without necessarily cancelling it sends camt.110 and gets camt.111 back, exclusively through Case Management — a question, not a cancellation, and not a customer-facing message at all. camt.029 shows up in two of the three because ISO 20022 reuses the same resolution message regardless of who initiated the request it's resolving, not because the two legs overlap.

Three clocks, but they converge on the same two dates

Read separately, each source post has its own timeline; read together, the checkpoints line up. November 2026 is the first hard date across all three: cancellation requests and responses must move through SWIFT's gpi Stop and Recall / Case Management service, institutions must be able to receive camt.110 investigation requests via Case Management, and the RMA bootstrap forces receive-readiness for pain.002/camt.055/camt.029. None of the legacy MT messages disappear on that date, but each loses its free-standing bilateral option. November 2027 is the full retirement date across all three: camt.056/camt.029 over FINplus becomes the only permitted channel for cancellations, camt.110/camt.111 become mandatory via Case Management, and pain.002/camt.055/camt.029 adoption must be complete — MT192, MT196, MT199, MT299, and the rest of the legacy E&I set are fully phased out.

Where PayOpsApp's ISO 20022 Validator fits, and where it doesn't

As you prepare test files across any of these three legs ahead of the November 2026 and 2027 dates, PayOpsApp's ISO 20022 Validator handles camt.056, camt.029, camt.110, camt.111, camt.055, and pain.002 the same way it handles any other ISO 20022 message: namespace-based message-type detection, XSD conformance where a schema is available, and a structural fallback — well-formedness plus GrpHdr presence and consistency — when it isn't. That's useful for catching a malformed or structurally inconsistent file before it goes anywhere near a bank, a customer channel, or Case Management. It does not perform message-specific business-rule validation for any of the six, and it has no SWIFT Case Management or Case Orchestrator connectivity — it can't submit, route, or track a cancellation request or an investigation case, on either leg. Use it to sanity-check file structure across this migration, not as a substitute for confirming your case-handling, bilateral agreements, or Case Management onboarding status directly.

This is educational reference material only, not legal or compliance advice; confirm your institution's actual E&I and ancillary-message migration obligations and deadlines, across all three legs, with SWIFT's own published guidance or your compliance function before relying on anything above.