Zahlungsverkehr und Operations
Open-Banking-API-Konfiguration — PSD2-Konformitätsprüfung
anymize entfernt eingebettete Test-IBAN und Kundendaten aus der API-Konfiguration, bevor das Frontier-Modell ein PSD2-RTS-Konformitäts-Mapping erstellt — SCA, CSC, Fallback, Anti-Friction, Performance. Der Bericht kommt mit Konfigurations-Zeilen-Referenz und priorisierten Findings zurück.
Schwierigkeit: Spezialist · Datenklasse: Mandantendaten · Letztes Review:
Zur Orientierung gedacht. Die anwaltliche Würdigung im Einzelfall bleibt selbstverständlich bei Ihnen — KI-Outputs sind vor jeder Verwendung zu prüfen. Mehr dazu am Ende.
Anwendungsbereich
Worum geht es hier?
PSD2 macht kontoführende Banken (ASPSP) zur API-Bereitstellung verpflichtet. Berlin Group NextGenPSD2 und STET sind die dominierenden Standards. Die Konfigurations-Files sind 500–3000 Zeilen YAML/JSON; manuelle Konformitäts-Prüfung 6–10 h. anymize beschleunigt: die KI mappt Konfigurations-Elemente gegen RTS-Anforderungen, der PSD2-Compliance-Officer entscheidet abschließend.
Für wen passt das?
Zielgruppe und Kontext
- Rolle
- Open-Banking-Product-Owner, API-Engineering-Lead, PSD2-Compliance-Officer, Operations-Manager Payments, IT-Sicherheit.
- Seniorität
- Senior — API-Konfiguration mit Compliance-Bezug erfordert Erfahrung in PSD2-RTS, Berlin Group oder STET und eIDAS-Zertifikatslogik.
- Kanzleigröße
- Alle ASPSP (kontoführende Banken/ZAG-Institute) mit PSD2-Verpflichtung. Sparkassen/Volksbanken nutzen typisch Verbund-Endpunkte; Großbanken eigene.
- Spezifische Kontexte
- Erst-Konfiguration nach Verbund-Update, API-Patch, Quartals-Compliance-Review, BaFin-Vorhalt.
Die Situation in der Kanzlei
So bringen Sie Tempo und Sorgfalt zusammen
PSD2-RTS verlangt eine vollständige Liste konfigurations-relevanter Anforderungen: SCA inkl. Exemptions (Low-Value, Trusted Beneficiary, TRA), 90-Tage-Re-SCA, CSC mit eIDAS-Zertifikaten, Fallback-Mechanismus oder Exemption, Anti-Friction (Consent-Management), Performance-Metriken. Manuelle Mapping-Prüfung 6–10 h pro Konfigurations-Stand. Wer das Konfigurations-File direkt in ChatGPT lädt, riskiert nichts hinsichtlich Personenbezug — solange keine echten Test-IBAN oder Kundendaten in den Konfigurations-Anhängen stehen. anymize prüft das vorab und pseudonymisiert nur dann.
Was Sie davon haben
Zeit, Wert, Vertraulichkeit
Zeit pro Konformitäts-Check
4–8 h
KI mappt Konfigurations-Elemente gegen RTS-Anforderungen mit Konfigurations-Zeilen-Referenz. Compliance-Officer entscheidet final.
BaFin-Vorhalt
ZAG-konform
Strukturierte Konformitäts-Matrix mit Findings-Priorisierung — ZAG-MaRisk-Anforderungen erfüllbar.
PSD3-Forward-Look
antizipiert
Prompt fragt explizit nach Konfigurations-Elementen, die voraussichtlich Anpassung an PSD3 erfordern.
Vertraulichkeit
B + A-Anhänge
Konfigurationsdaten sind typisch Klasse B; eingebettete Test-IBAN werden vorab pseudonymisiert.
So gehen Sie vor
In 5 Schritten zum Antrag
Konfigurations-Files sammeln: YAML/JSON-Konfiguration, OpenAPI-Spec, eIDAS-Zertifikat-Manifest, Fallback-Performance-Nachweise. Vorab-Prüfung: stehen echte Test-IBAN oder Kundendaten in den Anhängen?
Sie
Datenbasis · Datenklassen-Check
Klasse-Entscheidung. Konfigurationsdaten sind typisch Klasse B (technisch). Falls Test-IBAN/Kundendaten in Anhängen vorhanden, anymize pseudonymisiert nur diese; Konfigurations-Klauseln bleiben in Klartext.
anymize + Sie
DSGVO · § 43 KWG
Frontier-KI mappt. Der CRAFT-Prompt fragt eine Konformitäts-Matrix ab: RTS-Anforderung → Konfigurations-Element → Status (konform/teilweise/nicht-konform) → Konfigurations-Zeilen-Referenz. Plus Findings-Priorisierung, Mitigationsvorschläge und PSD3-Forward-Look.
GPT / Claude / Gemini in anymize
Strukturierung mit Konfigurations-Referenz
anymize re-identifiziert (falls A-Anteile vorhanden). Auffälligkeiten manuell gegen RTS-Originaltext und Berlin-Group-Spec verifizieren. Fallback-Mechanismus-Test in separatem Workflow — KI prüft nur Konfigurations-Vorhandensein.
anymize + Sie
Letztverantwortung Compliance
Bericht: Konformitäts-Matrix + Findings + Mitigationsvorschläge. Freigabe Compliance-Officer und IT-Sicherheit; bei Findings Re-Konfiguration und erneuter Test-Lauf.
Sie
Freigabe · Re-Konfiguration
Womit Sie arbeiten
So setzen Sie anymize konkret ein
Was anymize tut
- Erkennt eingebettete Test-IBAN und Kundendaten in Konfigurations-Anhängen.
- Pseudonymisiert nur die A-Anhänge; Konfigurations-Klauseln bleiben sichtbar für die KI.
- Re-identifiziert KI-Output mit den richtigen Konfigurations-Bezügen.
- Verarbeitung in deutschen Rechenzentren (Hetzner). AVV im Standardvertrag.
Was Sie als API-Engineering/Compliance tun
- Konfigurations-Files vollständig zusammenstellen (YAML/JSON, OpenAPI-Spec, eIDAS-Manifest).
- RTS-Mapping gegen Originaltext und Berlin-Group-Spec verifizieren — KI darf RTS-Klauseln nicht erfinden.
- Backend-Test ist Pflicht — Konfiguration sagt „aktiviert“, Implementierung muss übereinstimmen.
- PSD3-Forward-Look manuell prüfen — Trilog-Ergebnisse können RTS-Entwürfe ändern.
Daten-Input
Konfigurations-Dateien (YAML/JSON), OpenAPI-Spec, eIDAS-Zertifikat-Manifest, Performance-/Verfügbarkeits-KPI-Reports der letzten 6 Monate, RTS-Anforderungs-Katalog.
Output-Kontrolle
Pseudonymisierte Konfiguration (falls A-Anteile) geht an die KI. Konformitäts-Matrix mit Zeilen-Referenz, Findings priorisiert, Mitigationsvorschläge mit Pseudo-Code-Patches und PSD3-Forward-Look kommen zurück.
Freigabeprozess
Sie behalten die Hoheit: Datenklassen-Vorprüfung, RTS-Mapping-Verifikation, Backend-Test, Compliance-Freigabe, Produktiv-Setzung. anymize ist der Anonymisierungs-Layer, kein PSD2-Konformitäts-System.
Die KI-Anweisung
Prompt zum Kopieren
So nutzen Sie diesen Prompt:
1. Konfigurations-Files in anymize einfügen — eingebettete Test-IBAN werden zu Platzhaltern.
2. Diesen Prompt kopieren und an die pseudonymisierte Konfiguration anhängen.
3. In anymize unter „Tools → Reasoning“ auf ”Thinking-Modus“ stellen.
# Rolle
Du bist PSD2-Konformitäts-Assistenz für einen ASPSP-Bank.
Rechtsstand: <heutiges Datum — bitte aktuell ermitteln und hier einsetzen>.
# Aufgabe
Prüfe die unten beigefügte Open-Banking-API-Konfiguration (Berlin Group
NextGenPSD2 oder STET) gegen PSD2-RTS-Anforderungen. Eingebettete
Test-IBAN sind pseudonymisiert.
# Inhalt
1. Konformitäts-Matrix
Tabelle: RTS-Anforderung | Konfigurations-Element | Status
(konform/teilweise/nicht-konform) | Konfigurations-Zeilen
Pflicht-Anforderungen:
- SCA: Endpunkte, Exemptions (Low-Value, Trusted Beneficiary, TRA),
90-Tage-Re-SCA
- CSC: TLS-Version, Cipher-Suites, eIDAS-Zertifikat-Validierung
(QWAC/QSealC)
- Fallback: Vorhandensein oder Exemption-Begründung
- Anti-Friction: Consent-Management, Re-Auth-Vermeidung
- Performance: SLA-Konfiguration
2. Findings (priorisiert)
Kritisch / wesentlich / nachrangig.
3. Mitigationsvorschläge
Je Finding mit Konfigurations-Patch-Snippet (Pseudo-YAML/JSON).
4. PSD3-Forward-Look
Welche Konfigurations-Elemente werden voraussichtlich Anpassung
erfordern.
5. Unsicherheiten
[[UNSICHER: …]] bei mehrdeutiger Konfigurations-Interpretation.
# Format
Markdown. Tabelle für Matrix, nummerierte Listen für Findings.
# Verbote
KEINE Erfindung spezifischer RTS-Klauseln — bei Unsicherheit Quellen-
Hinweis statt Zitat.
KEINE Konformitäts-Aussage ohne Konfigurations-Zeilen-Referenz.
KEINE Vermischung TLS-Best-Practice mit RTS-Pflicht.
KEIN PSD3-RTS-Entwurfsklauseln als verbindlich übernehmen — als
Forward-Look kennzeichnen.So sieht der Sachverhalt aus
Pseudonymisierter Eingabetext
openapi: 3.0.3
info:
title: ASPSP PSD2 API
version: 1.6.0
servers:
- url: https://api.[[Bank-Domain-a3f9]].example/psd2/v1
security:
- eidas-cert: []
paths:
/v1/consents:
post:
summary: Create consent
x-sca-exemption: "low-value-payment"
/v1/accounts:
get:
summary: Read account list
x-90day-re-sca: true
x-consent-validity-days: 180
/v1/payments/sepa-credit-transfers:
post:
summary: Initiate SEPA-CT
x-sca-method:
- sms-otp
- push-tan
- chip-tan
x-fallback: "exempted"
components:
securitySchemes:
eidas-cert:
type: mutualTLS
x-tls-version: "1.2"
x-cipher-suites:
- "TLS_AES_256_GCM_SHA384"So liefert anymize zurück
Der Antrags-Entwurf
# PSD2-Konformitäts-Bericht — Entwurf
## Konformitäts-Matrix
| Anforderung | Konfigurations-Element | Status | Zeilen |
|---|---|---|---|
| SCA-Endpunkte | x-sca-method (SMS-OTP, Push-TAN, Chip-TAN) | konform | /payments path |
| TRA-Exemption | x-sca-exemption "low-value-payment" | konform | /consents path |
| 90-Tage-Re-SCA | x-90day-re-sca: true | konform | /accounts path |
| Consent-Validity | x-consent-validity-days: 180 | Auffälligkeit | RTS-Regelfall ≤ 180 Tage, Maximum bei Berlin Group ≤ 180 |
| Fallback-Mechanismus | x-fallback: "exempted" | prüfen | Exemption nur bei Verfügbarkeits-/Performance-Nachweis zulässig |
| TLS-Version | TLS 1.2 | teilweise | TLS 1.3 ist empfohlene Praxis; eIDAS-Anforderungen erfüllt |
| Cipher-Suite | TLS_AES_256_GCM_SHA384 | konform | — |
| eIDAS-MutualTLS | mutualTLS | konform | — |
## Findings (priorisiert)
1. **Wesentlich**: Fallback-Mechanismus auf "exempted" —
Verfügbarkeits-/Performance-Nachweis dokumentieren oder Fallback
aktivieren.
2. **Nachrangig**: TLS-Version 1.2 — Upgrade auf TLS 1.3 in
Folge-Release planen.
3. **Nachrangig**: Consent-Validity am Limit (180 Tage) — interner
Review.
## Mitigationsvorschläge
1. Fallback-Dokumentation: Performance- und Verfügbarkeits-KPIs der
letzten 6 Monate (Berlin-Group-Schwellen) belegen Exemption.
2. TLS 1.3-Upgrade in Q3-Release einplanen.
3. Consent-Validity-Review mit Compliance.
## PSD3-Forward-Look
PSD3 verschärft Behavior-/Device-Intelligence-Anforderungen
(UC-V-FIN-PAY-008). Aktuelle Konfiguration hat keine
x-device-intelligence-Element — bei PSD3-Geltung Konfigurations-
Ergänzung erforderlich.
## Unsicherheiten
1. [[UNSICHER: x-90day-re-sca: true — Implementierung gegen 90-Tage-
Frist Backend-Test erforderlich]]Was das Berufsrecht verlangt
Pflichten — und wie anymize sie abdeckt
PSD2/PSD3 RTS (SRC-0137)
SCA, CSC, Fallback und Anti-Friction sind RTS-Pflicht. PSD3 wird Behavior-/Device-Intelligence ergänzen — die KI-Konfigurations-Prüfung muss zwischen verbindlicher Pflicht und Entwurfsklausel unterscheiden.
MaRisk ZAG (SRC-0118)
BaFin-ZAG-Aufsicht prüft API-Konfigurationen im Rahmen der Vor-Ort-Prüfung. Konformitäts-Matrix mit Konfigurations-Zeilen-Referenz ist Pflichtbestand des Berichts.
BaFin Orientierungshilfe IKT-Risiken KI (SRC-0119)
API ist IKT-Asset; bei KI-gestützter Konformitätsprüfung ist die KI selbst IKT-Asset und gehört ins Inventar (UC-V-FIN-PAY-017).
DORA Art. 28/31 (SRC-0128)
API-Gateway und Pseudonymisierungs-Provider sind Auslagerungen; AVV und Auslagerungs-Register-Eintrag Pflicht (UC-V-FIN-PAY-002). Konzentrationsrisiko parallel prüfen (UC-V-FIN-PAY-004).
§ 25b KWG + BSI C5 (SRC-0107, SRC-0145)
Cloud-API-Hosting ist Auslagerung; BSI C5-Attestat Pflicht. eIDAS-Zertifikate (QWAC/QSealC) müssen live validiert sein.
DSGVO Art. 28 (SRC-0142)
AVV mit Cloud-Provider. Bei Test-IBAN-Verarbeitung in Konfigurations-Anhängen ist Pseudonymisierung Pflicht — anymize bietet das.
Datenschutz und Vertraulichkeit
So funktioniert das mit anymize
Konfigurationsdaten sind typisch Klasse B (technisch, ohne Kundenbezug). Test-IBAN oder Kundendaten in Konfigurations-Anhängen gehören nicht in die Konfigurations-Prüfung — anymize pseudonymisiert solche Anteile vor LLM-Transfer. Verarbeitung in deutschen Rechenzentren (Hetzner), AVV nach Art. 28 DSGVO und § 25b KWG. Rechtsgrundlage: Art. 6 Abs. 1 lit. c DSGVO (gesetzliche PSD2-Pflicht). Backend-Test der tatsächlichen Implementierung bleibt Pflicht — die Konfigurations-Prüfung allein reicht nicht.
Was anymize konkret leistet
- Erkennt eingebettete Test-IBAN in Konfigurations-Anhängen.
- Pseudonymisiert nur die A-Anhänge; Konfigurations-Klauseln bleiben sichtbar.
- Re-identifiziert KI-Output mit den richtigen Konfigurations-Bezügen.
- Verarbeitung in deutschen Rechenzentren (Hetzner). AVV im Standardvertrag.
- Zuordnungstabelle bleibt im Haus.
Sicherheitscheck vor der Einreichung
Was anymize liefert — was Sie souverän entscheiden
Vor dem KI-Aufruf
- Konfigurations-Files vollständig (YAML/JSON, OpenAPI, eIDAS)?
- Test-IBAN/Kundendaten in Anhängen geprüft?
- Klasse-Entscheidung dokumentiert?
- RTS-Originaltext und Berlin-Group-Spec verfügbar?
- Performance-KPIs (für Fallback-Exemption) zur Hand?
Nach der KI-Antwort
- Jedes Mapping mit Konfigurations-Zeilen-Referenz?
- RTS-Klauseln gegen Originaltext abgeglichen?
- TLS-Best-Practice von RTS-Pflicht unterschieden?
- PSD3-Forward-Look als „Forward-Look“ markiert?
- Backend-Test als Pflicht-Folge dokumentiert?
Vor Produktiv-Setzung
- Compliance-Officer-Freigabe?
- IT-Sicherheit-Freigabe?
- Penetrations-Test für kritische Findings?
- Re-Konfiguration nach Findings dokumentiert?
Typische Fehlermuster — und wie anymize gegensteuert
- →KI halluziniert spezifische RTS-Klauseln — Prompt zwingt Quellen-Hinweis statt Zitat.
- →Konformitäts-Statement ohne Backend-Test (Konfiguration sagt „aktiviert“, Implementierung weicht ab).
- →TLS-Best-Practice mit RTS-Pflicht verwechselt — Prompt-Verbot greift.
- →PSD3-Entwurfsklauseln als verbindlich übernommen statt mit Forward-Look-Markierung.
- →Konfigurations-Zeilen-Referenz fehlt — Mapping-Aussagen ohne Beleg unbrauchbar.
Rechtsgrundlagen
Normen, Urteile, Belege
Primärnormen Aufsichtsrecht
- PSD2/PSD3 + RTS SCA/CSC
- BaFin MaRisk ZAG
- DORA Art. 28
- § 25b KWG
BaFin KI-/IKT-Aufsicht
- BaFin Orientierungshilfe IKT-Risiken KI 18.12.2025
- BSI C5
- DSGVO Art. 28
Methodische Rahmen
- Berlin Group NextGenPSD2 Implementation Guidelines
- STET PSD2 Specification
Sekundärquellen
- PwC KI-Finanzsektor 2025
Stand: · Nächste Überprüfung:
Hinweis zur Nutzung
Zur Orientierung — nicht als Mandatsersatz
Diese Anleitung beschreibt einen Arbeitsablauf, den Sie mit anymize umsetzen können. Sie ist zur Orientierung gedacht und ersetzt weder die anwaltliche Würdigung im Einzelfall noch eine fachanwaltliche Prüfung. Welche Rechtsprechung einschlägig ist, wie der Sachverhalt rechtlich zu bewerten ist, welche Anträge in Ihrem konkreten Mandat richtig sind — das bleibt selbstverständlich bei Ihnen.
KI-Outputs müssen vor jeder Verwendung anwaltlich geprüft werden. Insbesondere Urteils-Aktenzeichen, Norm-Verweise und Fristen sind gegen Primärquellen zu verifizieren. anymize gewährleistet die Vertraulichkeit der Mandantendaten gegenüber dem KI-Anbieter; die fachliche Richtigkeit des Outputs liegt in Ihrer Verantwortung.
Jetzt starten.
14 Tage kostenlos testen.
Alle Modelle. Alle Features. Keine Kreditkarte.
Wir sind überzeugt von anymize. Und wir wissen: Bei einem KI-Werkzeug, das Mandanten-, Patienten- oder Mitarbeiter-Daten berührt, reicht ein Demo-Video nicht. Deshalb 14 Tage voller Zugang – alle Modelle, alle Features, keine Kreditkarte. Genug Zeit, um sicher zu sein, bevor du uns vertraust.
Dein KI-Arbeitsplatz wartet.