PSD3 wird zum Compliance-Risiko wenn Banken ihre IAM-Architektur nicht radikal umbauen
Ping Identity
von Alex Laurie, Ping Identity
PSD3 und PSR1 verschieben den Schwerpunkt von der statischen Zwei-Faktor-Authentifizierung zu kontinuierlichen, kontextbasierten Risikoentscheidungen. Die Authentifizierung liefert nur ein Identitätsniveau, aber nicht die Zulässigkeitsbestimmung einer Transaktion. Genau diese systemische und reproduzierbare Bewertung wird von den Regulierungsbehörden künftig erwartet. Eine phishing-resistente Erstauthentifizierung ist nur der Einstieg in den Entscheidungsprozess.
Die Bewertung erfolgt unter Einbezug verschiedener Faktoren wie Gerätebindung, Geräte-Reputation, Verhaltensabweichungen, Session-Telemetrie, Geolokation, Empfänger-Neuheit, Betragshöhe und historische Muster.“
Diese Parameter müssen innerhalb weniger hundert Millisekunden aggregiert, gewichtet und in einen belastbaren Risikoscore überführt werden. Erst die deterministische Kombination aus Identitätsniveau, Risikoscore und regulatorischer Richtlinie ergibt die finale Entscheidung über Freigabe, Step-up oder Abbruch.
Ohne saubere Architektur wird PSD3 zum Release-Risiko
Eine tragfähige Zielarchitektur muss mindestens vier logisch eigenständige Schichten trennen:
einen Identity Core mit Verzeichnisdiensten, Credential-Management, Token-Services und Föderation;
einen zentralen Policy Decision Point mit attribut- oder beziehungsbasiertem Autorisierungsmodell;
eine Risk Engine mit Event-Streaming, Feature-Extraktion und regel- bzw. modellbasierter Bewertung;
sowie eine Transaktionsorchestrierung, die diese Komponenten deterministisch zusammenführt.
Alex Laurie ist Go-To-Market Chief Technology Officer (GTM CTO) bei Ping Identity (Website) und operiert an der Schnittstelle zwischen Technologie, Produktentwicklung und Architektur. Vor seiner aktuellen Position war er über sechs Jahre bei ForgeRock tätig, unter anderem als Vice President Global Solution Architecture und SVP Global Sales Engineering. Zuvor arbeitete er als Director bei der Technologieberatung Amido sowie über ein Jahrzehnt als Mitgründer und Director des Technologieunternehmens Mobbu. Seine berufliche Laufbahn begann er Anfang der 2000er Jahre als unabhängiger IT-Consultant mit Spezialisierung auf die Implementierung früher mobiler Technologien für Großunternehmen.Der neue Zahlungsflow: deterministisch, auditierbar, echtzeitfähig
Ein PSD3-konformer Zahlungsfluss beginnt mit einer phishing-resistenten Authentifizierung und der Emittierung kurzlebiger, gebundener Access-Tokens. Bei Initiierung einer Transaktion werden sämtliche Kontextattribute an die Risk Engine übergeben. Diese berechnet in Near-Real-Time einen Score, der regelbasierte Heuristiken und modellgestützte Mustererkennung kombiniert. Parallel dazu prüft der Policy Decision Point regulatorische Anforderungen, etwa die Anwendbarkeit von SCA-Ausnahmen. Wird ein definierter Schwellenwert des aggregierten Risikos überschritten, wird eine dynamische Step-up-Authentifizierung ausgelöst.
Die finale Freigabe erfolgt mit kryptografischer Bindung von Betrag und Empfänger, sodass eine nachträgliche Manipulation ausgeschlossen ist.“
Jede Entscheidung muss vollständig auditierbar und reproduzierbar sein. Modellbasierte Komponenten benötigen nachvollziehbare Entscheidungslogiken und eine dokumentierte Governance. Black-Box-Modelle ohne Erklärbarkeit sind im Kontext interner Revision und Aufsicht faktisch nicht vertretbar.
300 Millisekunden entscheiden über Compliance
PSD3 impliziert eine Near-Real-Time-Architektur. Um Sicherheitsanforderungen und Nutzererlebnis zu vereinen, sind Entscheidungszeiten von deutlich unter 300 Millisekunden erforderlich. Technisch bedeutet dies: Event-Streaming mit garantierter Zustellung, performante Feature Stores, Inline-Token-Introspektion im API-Layer sowie manipulationssichere Protokollierung für forensische Analysen.
Kritisch ist die Synchronisation von Session-State, Device-Bindings, Fraud-Flags und Token-Gültigkeit.“
In verteilten Microservice-Architekturen entstehen Inkonsistenzen, wenn Risikoentscheidungen auf anderen Datenständen basieren als Autorisierungsprüfungen. Solche Race Conditions sind nicht nur technische Fehler, sondern auch potenzielle Haftungsrisiken. Konsistenzmodelle und klar definierte Entscheidungszeitpunkte werden somit zu regulatorisch relevanten Architekturparametern.
APIs sind kritische Infrastruktur – nicht nur Schnittstellen
Gemäß PSR1 gelten Open-Banking-APIs de facto als kritische Infrastruktur. Identitätsbehauptung, Einwilligungsprüfung und fachliche Berechtigungsprüfung müssen strikt getrennt voneinander implementiert werden. Ein Access-Token allein belegt weder eine gültige Kundeneinwilligung noch eine zulässige Operation. Jede API-Operation sollte daher eine eigenständige, kontextabhängige Autorisierungsentscheidung durchlaufen.
mTLS, kurzlebige Tokens, Zertifikatsbindung und differenziertes Rate-Limiting sind Mindestanforderungen.“
Ein konsequenter Zero-Trust-Ansatz – intern wie extern – ist technisch zwingend erforderlich. Die Vermengung von Identitätsnachweis und Berechtigungsmodell stellt ein strukturelles Compliance-Risiko dar.
eIDAS 2.0 verschiebt KYC von Datenspeicherung zu Verifikation
Die europäische Wallet-Initiative verändert die Rolle von Identitätsdaten. Finanzinstitute werden Identitätsattribute künftig nicht mehr persistent speichern, sondern kryptografisch signierte Nachweise prüfen. Das reduziert die Angriffsfläche, erhöht jedoch die Komplexität der Verifikationslogik. Benötigt werden eine Signaturprüfung, Revocation-Checks, die Verwaltung kryptografischer Vertrauensanker sowie ein sauberes Mapping externer Attribute in interne Rollen- und Berechtigungsmodelle (siehe BSI TR-03170).
Klassische IAM-Systeme, die primär auf zentral gespeicherten Identitätsprofilen beruhen, müssen um eine verifikationszentrierte Architektur erweitert werden. Andernfalls entstehen Parallelprozesse mit erheblichen Betriebs- und Prüfungsrisiken.“
Identität wird zur Echtzeit-Steuerung von Haftung
Für den Übergang zu PSD3 müssen die IAM-, Fraud- und API-Teams organisatorisch enger verzahnt werden. Für Risiko- und ML-Modelle sind formalisierte Validierungs- und Freigabeprozesse erforderlich.
Die Incident-Response für Social-Engineering-Fälle muss integraler Bestandteil der Identitätsarchitektur sein und darf nicht als nachgelagerte Reaktion erfolgen.“
Identität ist somit kein Login-Thema mehr, sondern ein Echtzeit-Steuerungsmechanismus für Risiko, Haftung und Kundenschutz. Die zentrale Frage ist nicht, ob PSD3 strengere Anforderungen stellt, sondern ob die bestehende IAM-Architektur kontextbasierte Entscheidungen unter regulatorischen und performancekritischen Bedingungen deterministisch treffen kann. Alex Laurie, Ping Identity
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/240953
Schreiben Sie einen Kommentar