Swift Case Management

Veröffentlicht am

07.09.2026

Aktualisiert am

07.09.2026

Lesezeit

3 min

Swift Case Management ist der zentrale Dienst von SWIFT für die Bearbeitung von Ausnahmen, Nachforschungen und Zahlungsstornierungen im grenzüberschreitenden Zahlungsverkehr – im Englischen als Exceptions & Investigations (E&I) bezeichnet. Er löst den bisherigen bilateralen Austausch freiformatiger MT-Nachrichten durch eine zentrale Orchestrierung strukturierter ISO 20022-Nachrichten ab.

Definition

Case Management bündelt alle Nachrichten, die zu einem Reklamationsfall gehören, an einer Stelle und stellt sie unmittelbar dem zuständigen Institut zu, statt sie entlang der Zahlungskette von Bank zu Bank weiterzureichen. Der Dienst steht seit November 2025 allgemein zur Verfügung; nach Angaben von SWIFT nutzen ihn bereits über 200 Banken. Für die weitere ISO-20022-Migration ist er nicht mehr optional: Die Untersuchungsnachrichten camt.110 und camt.111 lassen sich ausschließlich über Case Management austauschen.

Hintergrund ist ein konkretes Mengenproblem: Etwa ein bis drei Prozent aller Zahlungen laufen nicht glatt durch. Deren Klärung ist bislang weitgehend manuell, uneinheitlich und teuer. SWIFT beziffert das branchenweite Einsparpotenzial auf rund 600 Millionen US-Dollar jährlich.

Die beiden Bausteine

Case Orchestrator

Der Case Orchestrator ist der E&I-Baustein und verarbeitet die Untersuchungsnachrichten camt.110 (InvestigationRequest) und camt.111 (InvestigationResponse). Er nimmt die Anfrage entgegen, prüft sie, reichert sie an und leitet sie an das Institut weiter, das den Fall tatsächlich beantworten kann.

Unterstützt werden unter anderem folgende Untersuchungsarten:

  • Creditor Claim Non-Receipt (CCNR) – der Begünstigte meldet, dass die Zahlung nicht angekommen ist
  • Cover Creditor Claim Non-Receipt (CONR) – dieselbe Meldung im Deckungsverfahren
  • Request for Information – Rückfragen zu Sanktionen, Compliance oder nicht ausführbaren Zahlungen
  • Unable to Apply – die Zahlung lässt sich beim Empfänger nicht zuordnen
  • Missing Funds – Nachforschung zu fehlenden Beträgen

Stop and Recall

Der zweite Baustein betrifft Zahlungsstornierungen und den Rückruf. Er arbeitet mit camt.056 (Cancellation Request) und camt.029 (Resolution of Investigation) und macht den zuvor auf SWIFT gpi beschränkten standardisierten Rückrufprozess für alle Institute zugänglich. Praktische Bedeutung hat das vor allem in Betrugsfällen, in denen Minuten über die Wiedererlangung des Betrags entscheiden.

Referenzen und Routing

Zwei Referenzen halten einen Fall zusammen:

  • Die UETR identifiziert die zugrunde liegende Zahlung und verbindet sie mit ihren Statusmeldungen.
  • Die EIR (End-to-End Investigation Reference) identifiziert den Fall und begleitet ihn von der Eröffnung bis zum Abschluss.

Nachrichten an den Dienst werden über die zentrale Tracker-BIC TRCKCHZZ geleitet. Über die UETR kann der Orchestrator die Anfrage automatisch mit den bereits im Payment Tracker vorliegenden Angaben zur Zahlung anreichern – das anfragende Institut muss sie also nicht erneut erfassen.

Funktionsweise

Der Automatisierungsgewinn entsteht nicht durch das Nachrichtenformat allein, sondern durch die Leistungen des Orchestrators:

  • Business-Validierung – Anfragen, die gegen fachliche Regeln verstoßen, werden abgewiesen, bevor sie Aufwand beim Empfänger erzeugen.
  • Vorbefüllung aus dem Tracker – Felder werden aus den Daten der zugehörigen Transaktion gefüllt.
  • Smart Routing – die Anfrage geht direkt an das zuständige Institut, ohne die Zwischenstationen der Zahlungskette.
  • Automatische Erinnerungen und Ende-zu-Ende-Tracking – offene Fälle bleiben sichtbar und werden nachgehalten.

Der Zugang erfolgt wahlweise über Messaging (FIN und FINplus), über eine API oder über eine grafische Oberfläche. Damit können auch Institute teilnehmen, die keine eigene Anbindung an die Untersuchungsnachrichten aufbauen wollen.

Routing über die zentrale Tracker-BIC TRCKCHZZ · Fallreferenz EIR · Zahlungsreferenz UETRBank ARequestorBank BResponderSwift Case ManagementCase Orchestratorcamt.110 / camt.111 – NachforschungenStop and Recallcamt.056 / camt.029 – StornierungenBusiness-ValidierungVorbefüllung aus dem TrackerSmart RoutingErinnerungen & TrackingZugang über Messaging (FIN / FINplus), API oder grafische Oberfläche

Zeitplan

Die Einführung folgt der CBPR+ Roadmap und verläuft in Stufen:

  • November 2025: Der Dienst steht allgemein zur Verfügung, die Nutzung ist freiwillig. MT- und ISO-20022-Formate laufen parallel.
  • November 2026 (SR 2026): Alle Institute müssen camt.110 über Case Management empfangen können. Wer noch nicht umgestellt hat, wird durch die entgeltfreie In-flow Translation unterstützt, die die Anfrage als MT 199 mit eingebetteter Nachricht zustellt.
  • November 2027 (SR 2027): camt.110 und camt.111 müssen über Case Management gesendet und empfangen werden, Zahlungsstornierungen laufen ausschließlich über Stop and Recall. Die In-flow Translation endet, die MT-Nachrichten der Kategorien n95 und n96 werden aus dem Netz genommen und die freiformatige MT n99 wird für E&I-Zwecke eingestellt.

Zu beachten ist eine Verschiebung: Die ursprünglich für November 2026 vorgesehene Pflicht, Zahlungsstornierungen über den Stop-and-Recall-Prozess abzuwickeln, hat SWIFT nach Marktrückmeldungen um ein Jahr auf November 2027 verschoben. Die Empfangspflicht für camt.110 zum November 2026 bleibt davon unberührt.

Bedeutung für Banken und Zahlungsdienstleister

Betroffen sind alle Institute, die Zahlungsreklamationen bearbeiten – nicht nur Teilnehmer von SWIFT gpi. Aus der Stufenlogik ergeben sich drei Planungspunkte:

  • Anbindungsentscheidung. Messaging, API oder Oberfläche unterscheiden sich erheblich im Umsetzungsaufwand und im erreichbaren Automatisierungsgrad. Die Oberfläche sichert die Fristen, hebt den Nutzen aber nur teilweise.
  • Fallführung im Backoffice. EIR und UETR müssen dauerhaft am Vorgang hängen, damit Folgeanfragen automatisch dem richtigen Fall zugeordnet werden.
  • Zwei Prozesse, ein Dienst. Nachforschung und Rückruf haben unterschiedliche Nachrichten, unterschiedliche Fristen und in vielen Häusern unterschiedliche Fachbereiche. Beide Stränge sollten gemeinsam geplant werden.

Für den SEPA-Raum gilt Case Management ausdrücklich nicht: Die Nachrichten camt.110 und camt.111 sind kein Bestandteil der Rulebooks des European Payments Council. Nachforschungen und Fehlerfälle laufen dort weiterhin über camt.027, camt.087, camt.029 sowie die R-Transaktionen mit den zugehörigen SEPA Reason Codes.

Quellen für Spezifikationen