Ein Karteninhaber bestreitet eine Zahlung; die Regeln der Kartenorganisation geben dem Händler (oder dem Kartenherausgeber) wenige Tage Zeit, mit genau den richtigen Nachweisen zu antworten. Die meisten Händler ignorieren kleine Streitfälle oder verbrennen Analystenstunden mit manueller Nachweissammlung. Ein Agent liest den Reason Code, holt Nachweise aus Shop-, Versand- und Support-Systemen, entscheidet, ob er den Fall bekämpft oder erstattet, und entwirft die Antwort vor Fristablauf. Kartenherausgeber nutzen dasselbe Muster, um Reklamationen zu sichten und die eindeutigen automatisch zu lösen.
Problem & Nutzen
- Heute (Händler/PSP): Eine Rückbuchung kommt über das Dashboard bzw. die API des Acquirers oder PSP mit einem Reason Code und einer Antwortfrist von wenigen Tagen. Mitarbeitende suchen die Bestellung heraus, finden Liefernachweise, Screenshots, IP- und Login-Protokolle und frühere unbestrittene Bestellungen und schreiben eine Gegendarstellung in dem Format, das die Kartenorganisation erwartet. Streitfälle mit geringem Wert werden oft einfach anerkannt, weil das Bekämpfen mehr kostet als der Betrag.
- Heute (Kartenherausgeber): Das Streitfallteam der Bank sammelt die Schilderung des Karteninhabers, prüft Autorisierungs- und 3-D-Secure-Daten, wählt den passenden Reason Code und reicht den Fall bei der Kartenorganisation ein. Das Volumen ist hoch und überwiegend repetitiv.
- KI-Nutzen: einheitliche Klassifikation, automatische Zusammenstellung der Nachweise aus vielen Systemen, maßgeschneiderte Darstellungen, strikte Fristenüberwachung und eine Entscheidung, welche Streitfälle sich wirtschaftlich bekämpfen lassen. Außerdem trennt sie freundlichen Betrug (der Karteninhaber erkennt den Kauf später wieder) von echtem Betrug und von Serviceproblemen, die eine Erstattung oder eine Prozessänderung erfordern.
- Belege für die Wirkung: Anbieter veröffentlichen Erfolgsquoten (als Marketing behandeln, nicht als unabhängig). Stripe gibt an, dass Smart Disputes Nachweispakete automatisch erstellt, aber keine Ergebnisse garantiert, weil der Kartenherausgeber entscheidet [2]. Messen Sie Ihre eigene Ausgangsbasis.
Varianten
- Händler / E-Commerce (Card-not-present): Betrug (Typ Visa 10.4), „Ware nicht erhalten“, „nicht wie beschrieben“, Kündigung von Abonnements und Streitfälle bei wiederkehrender Abrechnung.
- PSP / Acquirer / Marktplatz: Streitfallbearbeitung für mehrere Händler, Programmüberwachung der Kartenorganisationen (Schwellen für übermäßige Streitfälle), Auszahlungs- und Rücklagenverwaltung.
- Kartenherausgeber / Kartenprozessor: Aufnahme von Reklamationen über App oder Chat, Regeln für automatische vorläufige Gutschrift, Einreichung bei der Kartenorganisation.
- Abwehr vor dem Streitfall: Frühwarnungen (Mastercard Ethoca Alerts, Visa Order Information Sharing) erlauben dem Händler, vor einer Rückbuchung zu erstatten [3].
- Privatnutzung: Ein persönlicher Agent könnte eine Reklamation an einen Kartenherausgeber entwerfen, es gibt aber keine nennenswerte Überschneidung mit dem Katalog; siehe AGENT-019.
So funktioniert es
dispute event (PSP webhook / acquirer API / scheme alert)
-> normalise: scheme, reason code, amount, deadline, payment method
-> classify: genuine fraud | friendly fraud | service/delivery | duplicate/processing error
-> economics: win probability x amount vs. fee and effort (tabular model)
-> decide: auto-refund | accept | fight | escalate to analyst
-> evidence collection (orders, 3-D Secure, shipping tracking, usage logs, chat history,
prior undisputed transactions)
-> draft representment (reason-code-specific template + LLM narrative, fields filled by tools)
-> human review (above amount threshold or low confidence) -> submit via API before deadline
-> outcome feedback -> win-rate analytics, root-cause tickets (fulfilment, descriptor, policy)
- Klassifikation: Reason Codes liefern bereits Struktur; ein kleiner Klassifikator oder ein LLM verarbeitet die Freitext-Reklamation des Karteninhabers und Abweichungen zwischen Code und Tatsachen.
- Nachweis-Agent: Tool-Aufrufe über Bestellsystem, Paketdienst-APIs, Helpdesk und Produktprotokolle. Jeder Nachweis wird mit seiner Quelle zitiert, damit die prüfende Person ihn verifizieren kann.
- Logik der überzeugenden Nachweise (Compelling Evidence): Visa Compelling Evidence 3.0 erlaubt dem Händler, frühere unbestrittene Transaktionen mit übereinstimmenden Kennungen (berichtet: zwei oder mehr innerhalb von 120-365 Tagen) vorzulegen, um bei Betrugsbehauptungen im Kartenfernverkauf die Haftung zu verlagern; genaue Regeln und aktuelle Erweiterungen sind in den geltenden Visa-Regeln zu prüfen [1].
- Mensch-in-der-Schleife (Human-in-the-Loop): Fälle mit hohem Wert, neuartige Muster und jede endgültige Ablehnung auf Kartenherausgeber-Seite werden geprüft; der Agent erfindet nie Nachweise und weist auf fehlende Belege hin.
Datenaufbereitung
Händlerseite: Bestellungen, Liefer- und Sendungsnachweise, Kundenkommunikation, Erstattungshistorie, beim Checkout akzeptierte Bedingungen, Protokolle (IP, Gerät) aus Shop, ERP und PSP. Kartenherausgeber-Seite: Transaktionsdaten, Kontaktverlauf der Karteninhaber und Streitfallakten. In einem KMU liegen diese Daten verstreut über Shopsystem, ERP, Versandportal, Postfach und PDFs; typische Lücken sind fehlende Liefernachweise, Nachweise ohne Verknüpfung mit der Bestellnummer, nicht beschriftete frühere Streitfälle und knappe Fristen.
Aufbereitungsschritte: - Shop-, ERP-, PSP- und Versanddaten über Bestell- und Transaktions-ID verbinden, siehe PREP-005. - Frühere Streitfälle mit Reason Code und Ergebnis als Labels exportieren, siehe PREP-020 und PREP-019. - Erfolgreiche Nachweispakete als Vorlagen sammeln, siehe PREP-016. - Papiernachweise wie unterschriebene Lieferscheine digitalisieren, siehe PREP-006 und DOC-014. - Für Tests verwendete Exporte pseudonymisieren, siehe PREP-022.
Werkzeuge: PSP- und Shop-APIs, ein OCR-/Dokumenten-Parser, eine einfache Datenbank. Grober Aufwandsanteil: etwa 30 Prozent, vor allem das Zusammenführen der Nachweisquellen und das Beschriften der Historie. Nutzen Sie GUIDE-003 für einen Reifegradcheck.
Umsetzungswege
Welcher Weg für wen
- KMU (A): Zahlungsdienstleister und Chargeback-Dienste bieten eingebaute Streitfallwerkzeuge, bei denen Regeln und Fristen der Kartenorganisationen für Sie gepflegt werden; das passt zu üblichen Händleranforderungen.
- Großunternehmen (B): Kartenherausgeber, große Händler und PSPs brauchen die Integration in Kernsysteme, eigene Risikoregeln und Nachweisquellen, daher passt ein Aufbau auf Cloud-KI-Diensten in einer EU-Region.
- Entwickler (B): Cloud-LLMs plus ein Klassifikator und Nachweis-Konnektoren sind der schnellste Weg zu einer funktionierenden Pipeline für Gegendarstellungen.
Weg A — Kaufen (Standardsoftware) (empfohlen)
- PSP-nativ: Stripe Smart Disputes (eine Regel-Engine erstellt Pakete und kann sie automatisch einreichen; das API-Feld
intended_submission_methodsteuert, wer einreicht) [2]; Adyen, Checkout.com und Worldpay bieten Werkzeuge und APIs für das Streitfallmanagement. - Spezialisierte Streitfallplattformen: Chargeflow, Justt, Quavo (Streitfallautomatisierung für Kartenherausgeber und Händler), Chargebacks911, die Alert-Netzwerke Verifi (Visa) und Ethoca (Mastercard) [3]. Überwiegend US-/UK-Anbieter; prüfen Sie Datenspeicherung in der EU und Auftragsverarbeitungsvertrag. PSPs mit Sitz in der EU: Adyen (NL), Mollie (NL), Nexi, Worldline (FR) mit eigenen Streitfall-Workflows.
- Plattformen für Kartenherausgeber: die Streitfallintegration von Mastercard mit Salesforce sowie Streitfallmodule von Kernbankensystemen [4].
- Wählen Sie A, wenn: Sie einen gängigen PSP nutzen und Ergebnisse in Wochen brauchen; die meisten KMU.
Weg B — Auf Cloud-KI-Diensten aufbauen
- PSP-Webhooks und -APIs für Streitfälle (Stripe, Adyen, Checkout.com) plus ein führendes LLM mit strukturierten Ausgaben (Claude, Gemini, GPT oder Mistral als EU-Anbieter; EU-Regionen über Azure OpenAI, Vertex AI, Bedrock).
- Orchestrierung mit n8n oder einem eigenen Dienst; Nachweis-Konnektoren zu Shop (Shopify, Shopware, Magento), Paketdiensten und Helpdesk.
- Wählen Sie B für eigene Richtlinienlogik, mehrere PSPs oder branchenspezifische Nachweise (digitale Güter, Reisen, SaaS).
Weg C — Selbst betreiben (Open Source)
- Open-Weight-LLMs (z. B. Mistral-, Qwen-, Llama-Familien) auf vLLM oder Ollama zum Entwerfen der Darstellungen; scikit-learn/XGBoost für die Erfolgswahrscheinlichkeit; Docling oder PaddleOCR für Liefernachweise; n8n oder Camunda für den Workflow.
- Hardware HW2 genügt für Fallvolumina von Tausenden pro Monat. Nur nötig, wenn Streitfalldaten (Daten der Karteninhaber) On-Premises bleiben müssen, z. B. bei Kartenherausgebern und Banken.
Weg D — Eigenes Training
Einen Klassifikator oder ein Modell für die Erfolgswahrscheinlichkeit auf der eigenen Historie bekämpfter Streitfälle und ihrer Ergebnisse feintunen (einige Tausend beschriftete Fälle). Ein Feintuning des LLM ist selten nötig.
Stand der Technik (2026)
- Produktisierte Automatisierung: PSPs erzeugen Nachweise automatisch und reichen sie automatisch ein; Spezialanbieter versprechen vollständig autonome Gegendarstellungen für geeignete Reason Codes [2].
- Datenaustausch auf Seiten der Kartenorganisationen: Auf Bestellebene mit Kartenherausgebern geteilte Daten (Programme von Visa und Mastercard) erlauben Herausgebern, ungültige Reklamationen früher abzulehnen, oder Händlern, proaktiv zu erstatten [3].
- Agenten bringen Mehrwert bei der Nachweissammlung über unübersichtliche Systeme und beim Schreiben von Darstellungen je Reason Code; die Entscheidung, ob bekämpft wird, lässt sich besser mit einem kalibrierten Modell treffen.
- Grenzen: Der Kartenherausgeber entscheidet; Erfolgsquoten schwanken stark nach Reason Code, Branche und Nachweisqualität. Agenten scheitern, wenn Quelldaten fehlen (keine Sendungsverfolgung, keine unterschriebene Lieferung), und erfundene Nachweise in einer Gegendarstellung sind ein Compliance- und Glaubwürdigkeitsrisiko. Regeln der Kartenorganisationen ändern sich häufig, daher müssen Regeltabellen gepflegt und versioniert werden. Jeden Streitfall zu bekämpfen kann unwirtschaftlich sein.
Gemeinsame Bausteine & Kombinationen
- Betrugssignale: ANOM-001 (Betrugsscores zum Zeitpunkt der Autorisierung fließen in die Entscheidung Bekämpfen/Erstatten ein), ANOM-022 (Betrugsmuster).
- Dokumenten-/Nachweisextraktion: Stack aus DOC-001 (ocr-docparse, workflow-automation); ANOM-017 für manipulierte Nachweisdokumente.
- Kundendialog: CONV-013 (Bankassistent nimmt die Reklamation des Karteninhabers beim Kartenherausgeber auf).
- Verwandte Prozesse: AGENT-014 (Muster der Schadenbearbeitung), AGENT-023 (Abzüge und Forderungseinzug), AGENT-011 (Datenhygiene bei Kundendaten für als Nachweis genutzte Kennungen).
Aufwand, Kosten & Kennzahlen
- Weg A: Tage bis Wochen; üblicherweise ein Anteil der zurückgewonnenen Beträge oder eine Gebühr pro Streitfall (Anbieterbedingungen prüfen).
- Weg B: 1-3 Monate inkl. Konnektoren und Regeltabellen; laufende Pflege der Regeln der Kartenorganisationen.
- Weg C: 2-4 Monate, ein GPU-Server plus Betrieb.
- Kennzahlen: Gewinn-/Rückgewinnungsquote nach Reason Code, Chargeback-Quote (Streitfälle / Transaktionen), Quote fristgerechter Antworten, Kosten pro Streitfall, Anteil ohne Analyst bearbeiteter Fälle, Quote der Erstattungen vor dem Streitfall, Anteil freundlichen Betrugs, umgesetzte Ursachenbehebungen.
Menschen & Veränderung
Beziehen Sie die Geschäftsleitung (Erfolgsquote und Erstattungspolitik), die Abteilungsleitung Zahlungsverkehr oder Kundenservice, die Anwender, die Streitfälle bearbeiten, IT und IT-Sicherheit (Zahlungsdaten, PCI-DSS-Geltungsbereich) sowie die Datenverantwortlichen für Shop-, ERP- und PSP-Daten ein. Die oder der Datenschutzbeauftragte sollte die Rechtsgrundlage bestätigen und AVVs mit Anbietern abschließen; eine DSFA ist bei der reinen Nachweisverarbeitung durch Händler meist nicht nötig, sollte aber bei Scoring oder großflächigem Einsatz beim Kartenherausgeber geprüft werden (GUIDE-005).
Betriebsrat: kommt darauf an. Das Werkzeug zur Fallbearbeitung protokolliert typischerweise, welche Mitarbeitenden welchen Fall bearbeitet haben, wodurch §87 Abs. 1 Nr. 6 BetrVG greifen kann; §90 Abs. 1 Nr. 3 verlangt frühzeitige Information, wenn sich Arbeitsabläufe ändern. Im Zweifel vereinbaren Sie kurz, dass keine individuelle Leistungsbewertung erfolgt (GUIDE-004).
Fördern Sie die KI-Kompetenz (Art. 4 KI-Verordnung) durch eine kurze Schulung zu Reason Codes, zur Prüfung von KI-Entwürfen und zur Eskalation (GUIDE-006). Starten Sie mit einem Pilot für einen Reason Code und ein kleines Team (GUIDE-009). Typische Sorge: zu Unrecht bekämpfte oder zu Unrecht anerkannte Streitfälle. Begegnen Sie ihr zunächst mit menschlicher Freigabe jeder Einreichung, einer gemessenen Erfolgsquote und einem klaren Rückfall auf manuelle Bearbeitung (GUIDE-011). Auf Kartenherausgeber-Seite müssen Kunden stets einen Menschen erreichen können.
Risiken, Regulierung & Compliance
- KI-Verordnung (EU AI Act): minimales Risiko; keine Kategorie nach Anhang III (Bonitätsbewertung ist nicht beteiligt). KI-Kompetenz der Beschäftigten (Art. 4) gilt. Würde ein Kartenherausgeber den Agenten nutzen, um Kunden für Kreditentscheidungen oder Kontokündigungen zu profilieren, ist neu zu bewerten [5].
- DSGVO: Streitfälle enthalten Identität des Karteninhabers, Kaufhistorie, IP und Kommunikation. Die Rechtsgrundlage ist typischerweise Vertrag/berechtigtes Interesse; beschränken Sie Nachweise auf das, was die Kartenorganisation verlangt, legen Sie Speicherfristen fest, schließen Sie Auftragsverarbeitungsverträge mit PSP und KI-Anbietern ab und prüfen Sie Übermittlungen außerhalb der EU [6].
- Zahlungsverkehrsrecht: Die PSD2 (Richtlinie 2015/2366) regelt nicht autorisierte Transaktionen, Erstattungsrechte und starke Kundenauthentifizierung; 3-D-Secure-Daten sind ein zentraler Nachweis. Regeln der Kartenorganisationen sind vertraglich und ändern sich oft [7].
- Automatisierte Entscheidungen: Die automatische Ablehnung einer Reklamation eines Karteninhabers durch einen Kartenherausgeber kann eine Entscheidung mit erheblicher Wirkung sein (DSGVO Art. 22): Halten Sie eine menschliche Prüfung und einen Widerspruchsweg vor.
- Risiken: erfundene oder nicht belegte Nachweise, falsche Fristen, Erstattungen an Betrüger, Verzerrung gegenüber bestimmten Kundengruppen bei Markierungen für freundlichen Betrug. Gegenmaßnahmen: nur verifizierte Nachweise zitieren, Fristenüberwachung, Prüfprotokoll, stichprobenartige Qualitätssicherung, schwellenwertbasierte menschliche Freigabe.
Erste Schritte
- Streitfälle der letzten 6-12 Monate exportieren: Reason Code, Betrag, Ergebnis, eingereichte Nachweise; Erfolgsquote und Kosten pro Streitfall berechnen.
- Die nativen Werkzeuge Ihres PSP aktivieren (z. B. Smart Disputes oder Entsprechendes) und mit den manuellen Ergebnissen für eine Reason-Code-Gruppe vergleichen.
- Frühwarnungen und Erstattungsregeln für Fälle mit geringem Wert und hoher Verlustwahrscheinlichkeit ergänzen.
- Nachweis-Konnektoren für Bestell-, Liefer- und Supportdaten bauen oder kaufen; zuerst Datenlücken schließen.
- Ursachenberichte (Verwechslung des Buchungstexts, Lieferprobleme, Stornoablauf) ergänzen, um eingehende Streitfälle zu senken.
Quellen
- Chargeflow - Visa Compelling Evidence 3.0 explained (vendor; verify against Visa rules) - https://www.chargeflow.io/blog/visa-compelling-evidence-3-0-explained
- Stripe - Smart Disputes docs - https://docs.stripe.com/disputes/smart-disputes
- Chargebacks911 - Mastercom Collaboration / Ethoca alerts overview - https://chargebacks911.com/mastercom-collaboration/
- Mastercard - Mastercard and Salesforce transaction-dispute integration (2024) - https://newsroom.mastercard.com/news/press/2024/may/mastercard-and-salesforce-announce-new-integration-to-transform-transaction-disputes
- Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Regulation (EU) 2016/679 (GDPR) - https://eur-lex.europa.eu/eli/reg/2016/679/oj
- Directive (EU) 2015/2366 (PSD2) - https://eur-lex.europa.eu/eli/dir/2015/2366/oj
- Stripe - Set up Smart Disputes - https://docs.stripe.com/disputes/set-up-smart-disputes