A Third Party Provider (TPP) in open banking is a regulated entity that uses bank APIs to offer Account Information Services (AIS) and/or Payment Initiation Services (PIS). Users consent once, and the TPP can then read account data or initiate payments on their behalf. Building a TPP means getting architecture, consent, and compliance right from day one.
AIS vs PIS
AIS (Account Information Services) bedeutet „Lesen“: Kontoliste, Salden, Transaktionen. Use Cases sind u. a. Aggregations‑Dashboards, Lending und Einkommensverifikation sowie Budget‑Apps. Der Nutzer stimmt zu („Teile meine Kontodaten mit dieser App“) und der TPP ruft die Bank‑APIs mit dem resultierenden Access‑Token auf.
PIS (Payment Initiation Services) bedeutet, eine Zahlung vom Konto des Nutzers zu initiieren. Der Nutzer wählt Konto und Betrag; der TPP sendet die Anweisung an die Bank. Keine Karte, keine separate Überweisung – die Zahlung wird über den Open‑Banking‑Kanal initiiert. Use Cases: Checkout, Bill Pay und Disbursements.
Viele TPPs machen beides: zuerst Konten anzeigen (AIS) und dann aus einem Konto zahlen lassen (PIS). Einwilligung muss klar und scoped sein – welche Daten oder Aktion ist erlaubt, wie lange, und widerrufbar.
Consent in practice
Einwilligung ist kein einmaliger Checkbox‑Klick. Sie hat einen Lifecycle: erstellen, nutzen, erneuern, widerrufen. Der TPP muss Einwilligung und Scope speichern, mit dem Access‑Token verknüpfen und Widerrufe respektieren. Nutzer sollten Einwilligungen in Ihrer App oder über ein zentrales Portal einsehen und zurückziehen können. Wir bauen Einwilligungsmanagement und Audit Trails, damit unsere Kunden compliant und nutzerfreundlich bleiben.
Strong Customer Authentication (SCA)
Banken verlangen typischerweise SCA (z. B. Two‑Factor), bevor Daten freigegeben oder Zahlungen ausgeführt werden. Der TPP redirectet den Nutzer zur Bank; die Bank führt SCA aus und redirectet mit einem Auth‑Code zurück. Der TPP tauscht den Code gegen einen Access‑Token. Wir designen und implementieren diesen Redirect‑ und Token‑Flow, damit Ihr Produkt kein Security‑Expertenteam werden muss – wir bauen das für Sie, wie für Meras, Infinipi und andere.
Regulatory readiness
TPPs unterliegen oft Lizenzierung (z. B. als Zahlungsinstitut oder nach lokalen Open‑Banking‑Regeln). Die Architektur sollte Audit Trails, sichere Token‑Speicherung und eine klare Trennung von Einwilligung und Execution unterstützen. Bei FintechPaa bauen wir TPP‑fähige Systeme mit PSD2/Open‑Banking‑Alignment, damit Sie sich auf Produkt und Regulierung konzentrieren – nicht auf Low‑Level‑Integration.
Planen Sie einen TPP oder wollen AIS/PIS zu Ihrem Produkt hinzufügen? Wir können Architektur und Flows für Sie bauen.
← Zurück zum Blog