Compliance · February 2025

PSD2 und Strong Customer Authentication

SCA, exemptions, and what it means for your product.

The Revised Payment Services Directive (PSD2) in Europe requires that electronic payments and access to payment accounts be protected by Strong Customer Authentication (SCA). In practice, that usually means two-factor authentication: something the user knows (e.g. PIN), something they have (e.g. phone or token), or something they are (e.g. biometric). If you’re building an open banking or payment product—in the EU, UK, or in jurisdictions that follow similar rules—your flows need to work with SCA, not around it.

Wann ist SCA erforderlich?

SCA ist erforderlich, wenn der Nutzer (1) online auf Zahlungskonto‑Informationen zugreift, (2) eine elektronische Zahlung auslöst oder (3) eine Aktion ausführt, die ein Betrugsrisiko implizieren könnte. Wenn Ihre App also Kontodaten bei der Bank anfragt oder eine Zahlung initiiert, verlangt die Bank typischerweise SCA, bevor Daten freigegeben oder die Zahlung ausgeführt wird. Der Nutzer wird zur Bank weitergeleitet (oder in den eingebetteten Flow), führt dort SCA aus und wird mit einem Auth‑Code zurück in Ihre App geschickt. Ihr Backend tauscht diesen Code dann gegen einen Access‑Token. Genau diesen Flow implementieren wir, wenn wir Open‑Banking‑Auth für Kunden bauen.

Ausnahmen

PSD2 erlaubt Ausnahmen in bestimmten Fällen: Kleinbetragszahlungen (z. B. unter 30 €), vertrauenswürdige Empfänger, wiederkehrende Zahlungen u. a. Banken und Regulatoren können diese unterschiedlich auslegen. Wenn Ihr Produkt auf einer Ausnahme basiert, müssen Sie lokale Regeln und die Bank‑Policy verstehen. Selbst mit Ausnahmen geht der Trend zu konsistenterer SCA – daher ist es langfristig sicherer, Einwilligungs‑ und Redirect‑Flows mit SCA im Blick zu designen.

Was das für Ihr Produkt bedeutet

Ihr Produkt führt SCA nicht selbst aus – das macht die Bank. Ihre Aufgabe ist: (1) den Nutzer mit den richtigen Parametern (z. B. Consent‑ID, Redirect‑URI) zur Auth‑Seite der Bank zu bringen, (2) den Callback mit dem Auth‑Code entgegenzunehmen und (3) den Code gegen einen Token zu tauschen und sicher zu speichern. Die UX lautet: „Bank verbinden“ → Redirect → Bank‑Login/OTP/Biometrie → zurück in Ihre App. Wir bauen diesen Redirect‑ und Token‑Exchange‑Flow, damit Ihre App compliant bleibt und Nutzer ein reibungsloses, sicheres Erlebnis haben. Wir haben das für Kunden wie Meras und Infinipi umgesetzt – und können es auch für Ihr Produkt in Pakistan oder anderen Märkten bauen.

Außerhalb Europas

Viele Länder übernehmen ähnliche Konzepte: sichere Authentifizierung, bevor Kontodaten geteilt oder Zahlungen initiiert werden. Pakistan und andere Märkte können eigene Regeln oder Bank‑Praktiken haben. Wenn wir Open‑Banking‑ oder TPP‑Systeme für Sie bauen, designen wir SCA‑artige Flows und lokale Anforderungen mit – damit Sie für aktuelle und zukünftige Regulierung bereit sind.

Sie brauchen den Auth‑Flow und die SCA‑Integration für Ihr Produkt? Wir bauen das für Sie.


← Zurück zum Blog