AVS/CVV-Prüfungen und Betrugssignale

1) Warum AVS/CVV in iGaming

• verringern Sie das Risiko von Betrug/Chargebacks durch „No Auth „/„ Fraud “,
• das Vertrauen des Emittenten in primäre CITs erhöhen,
• helfen, Bots/Drops vor der 3DS-Challenge auszusortieren,
• liefert Daten für Policy-basiertes Routing und Scoring.

Wichtig: AVS/CVV ersetzen nicht 3DS2/SCA und Tokenisierung, sondern arbeiten gut zusammen.

2) Wie es funktioniert (allgemein)

AVS: Vergleich der Rechnungsadresse des Kunden (Straße, Index, manchmal Stadt/Staat) mit der Adresse beim Emittenten. Der Code (match/partial/no match/unsupported) wird zurückgegeben.
CVV: Überprüfung des Codes auf der Karte; gibt match/no match/not processed/issuer not certified zurück.
Beide Ergebnisse kommen in der Autorisierungsantwort vom PSP/Acquirer (oder in separaten Webhook-Feldern) und müssen ohne PAN protokolliert werden, um mit 'payment _ id' zu kommunizieren.

3) AVS-Codes (konsolidierte Entscheidungslogik)

• Vollständige Übereinstimmung: „Y“ (Straße + Index) → ein starkes positives Signal.
• Teilübereinstimmung:'A'(Straße ok, Index nein),'Z'(Index ok, Straße nein), 'W/X' (9-/5-stellige ZIP), 'D/M' (internationale Überschneidungen) → mäßig positiv.
• Keine Übereinstimmung: 'N' → negatives Signal; Ausfall oder verstärkte Überprüfung/3DS möglich.
• Nicht verfügbar/nicht zutreffend:'U'(issuer unavailable),'R'(retry), 'S' (AVS not supported),' G'(international not supported) → neutral/schwach negativ, die Entscheidung hängt vom Kontext ab.

• Risikoreiche Märkte/Karten: ≥ Teilübereinstimmung oder Standard- 3DS-challenge erfordern.
• Risikoarme Kunden mit Historie: Abmildern bis zum Einlass „Teilspiel“ ohne Challenge.
• Für Abonnements (MIT): AVS ist nützlich auf initial CIT; weiter verlassen Sie sich auf 3DS Artefakte/Token und Geschichte.

4) CVV/CVC-Codes (Normalisierung)

Match: „M“ ist ein stark positiver Faktor (insbesondere für die primäre Kartenerfassung).
No Match:'N 'ist ein starkes Negativ; Ablehnung oder obligatorische 3DS-challenge wird empfohlen.
Nicht verarbeitet/Nicht vorhanden:'P '/' S'- schwach negativ, siehe Kontext (manchmal unterstützt der Emittent nicht oder das Feld geht verloren).
Issuer nicht zertifiziert/Nicht verfügbar:'U'- neutral/leicht negativ.

• Für CIT mit 'CVV = N' - in der Regel ablehnen (oder an 3DS-challenge und Überprüfung senden).
• Für MIT (Wiederholungen) wird kein CVV angefordert; verlassen Sie sich auf die Verbindung mit initial CIT.

5) AVS/CVV-Bündel ↔ 3DS/SCA und Netzwerk-Token

• AVS/CVV reduzieren das Risiko einer Herausforderung und erhöhen die Chance auf frictionless.
• Bei 'AVS = N' und/oder 'CVV = N' ist es sinnvoll, 3DS gewaltsam zu initiieren.
• Netzwerk-Token (VTS/MDES/NSPK) und VAU/ABU erhöhen AR und LTV; zusammen mit AVS/CVV ein besseres Risikobild auf der Initial CIT liefern.

6) Betrugssignale: was zu sammeln und wie zu verwenden

• Device fingerprint (canvas/webgl/audio, шрифты, timezone, lang).
• Velocity: Zahlungsversuche pro Fenster (per Karte/Konto/Gerät/IP/BIN).
• Geo-Konsistenz: IP-Land vs BIN-Land vs Abrechnung vs Sprache/Währung.
• Verhaltensmuster: Eingabegeschwindigkeit, Feldfokus, Copypast, CVV-Fehler.
• Kontoverlauf: Alter, AHT-Spielsitzungen, KYC-Status, Retouren.
• Zahlungsattribute: MCC 7995, Kartentyp (Prepaid/Debit/Credit), Emittentenrisiko.
• 3DS-Metadaten: Methodenabschluss, dsTransID, Herausforderungsrate beim Emittenten.

• Bauen Sie eine Composite-Risiko-Skore (0-100) mit Gewichten: CVV, AVS, Gerät, Geo, Velocity, 3DS-Geschichte.

• 'score ≤ T1' → frictionless (falls verfügbar);
• `T1 < score ≤ T2` → challenge (3DS);
• 'score> T2' → decline oder manuelle Prüfung/alternative.

7) Entscheidungsmatrix (Beispiel für Orchestrator)

8) Retrays und UX-Muster

CVV-Fehler (N): Zeigen Sie die verständliche Meldung „Code auf Karte prüfen“ an, löschen Sie nur das CVV-Feld, zwingen Sie nicht, alles erneut einzugeben.
AVS-Fehlanpassung: Bieten Sie an, den Index/die Straße zu überprüfen, geben Sie Formathinweise (ZIP-5/ZIP-9).
Soft-decline/SCA: automatische Wiederholung mit 3DS, ohne erneute Eingabe der Karte.
Velocity-Block: Ein kurzes „Cool-Down“ mit Timer und Tipp, eine andere Methode zu verwenden.
Alternativen: A2A (Banküberweisungen), lokale Geldbörsen auf dem Markt.

9) Daten & Speicherschemata (Minimum von Feldern)

• `payment_id`, `psp_txn_id`, `token_id`, `bin`, `last4`, `scheme`, `issuer_country`
• `avs_result_normalized` ∈ {Y, PARTIAL, N, NA}
• `cvv_result_normalized` ∈ {M, N, NA}
• `risk_score`, `velocity_bucket`, `device_id`, `ip_country`, `bill_country`
• `threeDS`:{`version`, `eci`, `cavv`?, `method_done`:bool, `challenge`:bool}
• `decision` ∈ {approve, challenge, decline}, `reason`
• `route` (PSP_A/B), `was_retry`:bool, timestamps

10) Metriken und Beobachtbarkeit (KPI/SLO)

Qualität und Umbau

Approval Rate nach Cluster 'AVS/CVV' (z.B. 'CVV = M&AVS = Y' vs' CVV = M&AVS = partial').
Frictionless% und Challenge success% unter verschiedenen AVS-Klassen.
Abandonrate auf CVV/Adresseingabebildschirmen.

Risiken

Chargeback Rate (Betrug/Verbraucher Dispute) im Abschnitt AVS/CVV Kombinationen.
Anteil false positive: Ablehnungen bei nachfolgender Legitimation (bei Appellen/Wiederholungen).
Soft-decline → eine erfolgreiche Wiederholung (nach 3DS).

Technik

AVS/CVV-Latenzprüfung (p95) und Anteil „U/S/G“ (nicht verfügbar).
Adhäsionen durch 'CVV = N', 'AVS = N' (Alerts) im Abschnitt BIN/Emittent/PSP.

11) Anti-Muster

Interpretieren Sie' AVS = U/S/G 'als harte Weigerung bei internationalen BINs - Conversion-Verlust.
Fordern Sie AVS in Ländern/Banken an, in denen es nicht systemisch unterstützt wird.
Protokollieren Sie rohe Adressen ohne Maskierung und ohne Ziele - Gefahr von Lecks/PII.
Hard-Reject 'CVV = N' ohne Analyse der Eingabefehlerrate (ehrlicher Mis-Tip möglich).
Ignorieren Sie 3DS-Artefakte und die Kundengeschichte bei partiellen AVS-Übereinstimmungen.

12) Checkliste Umsetzung

• Normalisiertes Wörterbuch der AVS/CVV-Codes nach Schema/PSP.
• Entscheidungspolitik (approve/challenge/decline) nach Kombinationen.
• Integration mit 3DS2: automatischer Übergang in der Herausforderung bei negativen AVS/CVV.
• Risiko-Scoring: Gerät, Geo, Velocity, Kundenhistorie, BIN-Richtlinien.
• UX-Fehlermuster (Lokalisierung, Speicherung der eingegebenen Felder).
• KPI Dashboards und Alerts für „N “/„ U/S/G“ Spikes.
• PAN-safe: hosted fields/iframe, tokenization; nur Metadaten in den Protokollen.
• A/B-Tests von Schwellenwerten (T1/T2) und Regeln für Märkte/Emittenten.
• Playbooks von Retrays/Soft-Declines und alternativen Zahlungsmethoden.
• Address Storage Policies/PII (GDPR/DSR), Masking, Minimization.

13) Beispiel für Marktpolitik (Skizze)

USA/Kanada (AVS stark): 'AVS = Y' oder 'partial + 3DS/low risk'; 'AVS = N' → challenge/decline.
EU (PSD2): Schwerpunkt auf 3DS2 (frictionless wo möglich); AVS ist ein Scoring-Signal.
Internationale Märkte mit eingeschränkter AVS-Unterstützung: Vertrauen auf 3DS + device/geo/velocity; 'AVS = U/S/G' - neutral.

14) Zusammenfassung

AVS/CVV sind die „ersten Filter“ bei CNP-Zahlungen. Sie sollten in Verbindung mit 3DS2, Tokenisierung und Risikoscoring arbeiten, und Entscheidungen sollten nach Kontext und nicht nach einem Code getroffen werden. Normalisieren Sie Antworten, erstellen Sie Scoring, automatisieren Sie den Übergang zu 3DS, behandeln Sie Adressen/PIIs sorgfältig und messen Sie das Ergebnis mit Metriken. So reduzieren Sie den Betrug und die Charjbacks, ohne die Konvertierung zu töten.