SEPA Credit Transfer/Instant

1) Was ist SCT und SCT Inst - und warum ist es wichtig, iGaming

SCT (SEPA Credit Transfer) - Überweisung in Euro zwischen Banken im SEPA-Raum mit Abwicklung in der Regel T + 0/T + 1 (abhängig vom Cut-off).
SCT Inst (SEPA Instant) - Sofortüberweisung 24/7/365 mit gezielter Gutschrift innerhalb von Sekunden (Limits für den Betrag und die Beteiligung der Bank - bei einer bestimmten Bank/Anbieter).

Die Vorteile für iGaming: niedrige Kosten, keine klassischen Chargebacks, hohe Vollmacht bei den Regulierungsbehörden, vorhersehbares Settlement und bequeme Massenzahlungen.

2) Anwendungsfälle

2. 1 Einlagen (inbound)

Pool-IBANs (virtuelle Referenzen) oder virtuelle IBANs pro Kunde/Rechnung.
Für SCT ist Inst das schnellstmögliche „quasi-sofortige“ Onboarding von Geldern.
Zahlungsziel (Remittance Information) → Mapping auf 'payment _ id'.

2. 2 Schlussfolgerungen/Auszahlungen (outbound)

Massenzahlungen über SCT (Batchi) oder Instant-Cachouts über SCT Inst.
Playbook: Wenn die Bank des Empfängers Inst nicht unterstützt - Auto-Folback zum regulären SCT.

3) Architektur der Integration (Referenz)

• Banking/PSP Layer: EU-Konto (e), SCT/SCT Inst-Unterstützung, Webhooks/Kontoauszugsdateien.
• Payments Core: Orchestrierung von Einzahlungen/Auszahlungen, Status, Limits.
• Risiko & Compliance: Sanktionsscreening von Zahlern/Empfängern, RBA/EDD.
• Accounting & Recon: Lager, Mapping 'payment _ id ↔ bank_ref/EndToEndId', Reporting.
• Monitoring: ETA, Fehlertoleranz, Warnungen nach R-Codes/Retouren.

• IBAN/wirth. Link ausgestellt → Der Kunde initiiert eine Zahlung bei seiner Bank → SCT/SCT Inst → Webhook/Kontoauszug → Gutschrift in der Bilanz des Spielers → Rekonsolidierung.

• Antrag auf Abschluss → Überprüfung (RBA/Sanktion/IBAN-Validierung) → SCT Inst (falls verfügbar) oder SCT → Status/Referenzen → Benachrichtigung des Spielers → Rekonsolidierung.

4) Timing, Cut-Off und ETA

SCT: Eingang T + 0/T + 1, abhängig von Sendezeit und Cut-off der Bank; „Bankstunden/-tage“ sind möglich.
SCT Inst: Ziel Echtzeit, 24/7; wenn die Bank des Empfängers nicht im Inst-Netzwerk ist oder das Limit überschritten wird - die Überweisung kann abgelehnt/an einen regulären SCT übertragen werden (nach den Regeln eines bestimmten Anbieters/einer bestimmten Bank).

UX-Praxis: Zeigen Sie eine dynamische ETA und erklären Sie, dass Inst nicht bei allen Banken/Beträgen verfügbar ist.

5) Verifizierung der Details

IBAN: Längen-/Format-/Prüfsummenüberprüfung (MOD97).
BIC (wo benötigt) und Bankverzeichnisse für das Routing.
Name Check/Bestätigung des Payee-Analoges (sofern bei Ihrer Bank/PSP verfügbar): Der Abgleich des Empfängernamens mit der IBAN reduziert Fehler und R-Codes.
Beneficiary Lock: Whitelist von zuvor verifizierten Details mit TTL und Limits.

6) Retouren und R-Codes (Diagnose)

• Ungültige IBAN/Konto nicht gefunden - Reject vor Gutschrift.
• Inst Limits/Limits - SCT Inst Ablehnung oder Folback.
• Compliance-Sperren bei der Empfängerbank - Return/Recall nach Dop.prüfung.
• Die Bank des Empfängers ist nicht verfügbar - technischer Reject.

Operationen: loggen Sie den R-Code, den Text der Ursache und die Zeit; Starten Sie Auto-Workflow (erneute Überprüfung der IBAN/des Namens, Anforderung von Klarstellungen beim Kunden, Eskalation in der Compliance).

7) Compliance und Risikokontrolle

KYC/KYB: Level für Spieler/RBA-Partner; livnes, PoA/SoF für große Summen oder Anomalien.
Sanktionsscreening des Absenders/Empfängers (Name, Anschrift, Land; für juristische Personen: Name/Reg. Daten).
RBA-Limits: per-tx/per-day caps, velocity per IBAN/Empfänger/Gerät.
Rote Flaggen: Rapid in-out (schnelle Einlösung), IBAN-Änderung, Zerkleinerung, Zufälle durch adverse Medien.
Dokumentenmanagement: Speicherung von bestätigenden Daten/Einwilligungen im Rahmen der Anforderungen der Gerichtsbarkeit.

8) Wirtschaft und Kommissionen

• Bank-/PSP-Tarif für SCT/SCT Inst (Per-Transaktion/Paket/Mengenrabatt);
• mögliche fee für Auszüge/Webhooks/Dateien;
• operativ: R-Code-Verarbeitung/Handkoffer/Sapport;
• FX - nur bei Cross-Conversions außerhalb des Euro (für SEPA in der Regel EUR→EUR).

Metrik: Zählen Sie All-in und Time-to-Funds (bevor das Geld auf Ihrem Konto/beim Kunden erscheint) und nicht nur den „Preis pro Überweisung“.

9) Layger und Rekonsilierung

Eindeutige IDs: Verwenden Sie' EndToEndId '/' RemittanceInfo', um 'payment _ id ↔ bank_ref' zu mappen.
Ranglisten: „payments“, „payouts“, „bank _ statements“, „recon _ lines“.
Auto-Rekonsolidierung T + 0/T + 1: Beträge, Provisionen, Status, nicht zugeordnete Zeilen („Wisjaks“) - in einer separaten Warteschlange.
Reporting: Uploads nach Jurisdiktionen, Anpassungsprotokoll, unveränderliche Protokolle.

10) Orchestrierung von Routen und Failover

Auswahlregeln: Wenn die Bank des Empfängers/der Betrag Inst → SCT Inst unterstützt; ansonsten SCT.
Folback-Logik: Inst nicht verfügbar/hoher Fehler - Auto-Switching; Information der ETA an die UI.
Idempotenz/Anti-Double: Schlüssel 'payment _ id/withdrawal _ id'; Retrays mit Backoff + Jitter.
Doppelanbieter/Konten bei verschiedenen Banken in Schlüsselmärkten → Fehlertoleranz.

11) UX-Muster (Conversion und Trust)

Zeigen Sie die Methode (SCT/SCT Inst), die ETA und die Provisionen vor der Bestätigung deutlich an.
Überprüfen Sie die IBAN/den Namen vor dem Senden (und die Formathinweise).
Real-Time-Status: „erstellt → an die Bank gesendet → gutgeschrieben/abgelehnt/rückerstattet“.
Für Einzahlungen: virtuelle IBANs/Referenzen, QR/Kopieren, Anweisungen für den Zahlungszweck.

12) Metriken und OKRs

Approval/Success Rate по SCT/SCT Inst.
Time-to-Funds (in) / Time-to-Payout (out) p50/p95.
Der Anteil von Inst an den Streams und sein Einfluss auf die Conversion.
R-Codes Rate (nach Typ und Bank), Zeit für die Auflösung von Fällen.
Die Kosten für die Genehmigung (All-in), die Kosten für den manuellen Fall.
Uptime nach Anbieter/Bank, Verzögerungen bei Webhooks/Kontoauszügen.

13) Anti-Muster

Eine Bank/ein Anbieter ohne Reserve (SPOF).
Keine Validierung der IBAN/des Empfängernamens.
Undurchsichtige ETAs und Gebühren - Anstieg der Tickets/Stornierungen.
Keine Idempotenz - doppelte Abschreibungen/Auszahlungen.
Ignorieren Sie R-Codes und „hängende“ Zeilen von Kontoauszügen - Lücken in der Buchhaltung.
Mischen Sie PII und Zahlungsprotokolle ohne Tokenisierung/Zugriffe.

14) Checkliste Umsetzung (kurz)

• Konto (e) bei einem SCT + SCT Inst-fähigen EC/PSP, signierte Webhooks und Auszugsdateien.
• Virtuelle IBANs/Referenzen auf die Rechnung/den Kunden; Mapping 'payment _ id ↔ EndToEndId'.
• Validierung von IBAN/BIC und (falls vorhanden) Name Check; Whitelist-Requisiten mit TTL.
• RBA-Limits, Sanktionen/PEP/adverse, EDD/SoF-Regeln.
• Inst→SCT und Folback-Routing, Idempotenz, Retrays.
• Leiter/Rekonsilierung T + 0/T + 1, Umgang mit „Hängegriffen“, Berichte.
• Zwei Bankpartner/Kanäle, Playbook der Degradierungen und Vorfälle.
• UX: ETA/Gebühren/Echtzeitstatus, Anweisungen für den Zahlungszweck.
• Metriken/Dashboards: AR, Time-to-Funds, R-Codes, Kosten.
• Saport-Training: Grund für R-Codes, Antwortmuster, Zeitrahmen.

15) Zusammenfassung

SCT/SCT Inst ist das „Arbeitstier“ für Euro-Zahlungen bei iGaming: günstig, berechenbar und Compliance-freundlich. Erstellen Sie eine duale Kontur (Inst + Standard SCT), fügen Sie IBAN/Namensvalidierungen und einen klaren Lager hinzu, automatisieren Sie die Rekonsolidierung und Verarbeitung von R-Codes und zeigen Sie ETA und Provisionen transparent in UX an. So erhalten Sie eine hohe Konversion, schnelle Auszahlungen und eine nachhaltige operative Leistung auf den EU-Märkten.