Open‑Banking‑API: Standards, Sicherheit und Integration in der Schweiz

Über eine Open-Banking-API gibt eine Bank Kontodaten oder Zahlungsfunktionen an einen autorisierten Drittanbieter weiter. Das geschieht nur mit der ausdrücklichen Einwilligung der Kundin oder des Kunden, über eine standardisierte und abgesicherte Schnittstelle. In der Schweiz verpflichtet kein Gesetz die Banken dazu. Trotzdem treiben die Institute das Thema freiwillig und über gemeinsame Standards voran. Für CIOs, CTOs und Compliance-Verantwortliche geht es deshalb weniger um die Frage, ob sie eine API anbieten. Entscheidend ist, wie sie diese sauber an ihr Kernbanksystem anbinden, wie sie Einwilligungen verwalten und wie sie Risiken kontrollieren. In diesem Leitfaden gehen wir Schritt für Schritt durch Funktionsweise, Standards, Rechtslage, Sicherheit und Integration.

Kurz gesagt

• Eine Open-Banking-API ist eine standardisierte Schnittstelle, über die eine Bank mit Einwilligung der Kundschaft Daten und Funktionen an Drittanbieter freigibt, etwa Kontoinformationen oder Zahlungsauslösungen.
• In der Schweiz gibt es keine gesetzliche Pflicht wie die PSD2 in der EU. Der Bundesrat setzt auf die Branche und deren freiwillige Multibanking-Initiative.
• Das Swiss NextGen API baut auf dem NextGenPSD2 Framework der Berlin Group auf. Für Wealth Management hat sich mit OpenWealth ein eigener Branchenstandard etabliert.
• Die eigentliche Arbeit liegt in der Integration: Fachmodell, Consent Management, Sicherheitsarchitektur und eine saubere Entkopplung vom Kernbanksystem.
• Das Schweizer Datenschutzgesetz (nDSG), die Anforderungen der FINMA und eine dokumentierte Zusammenarbeit mit Drittanbietern bilden den regulatorischen Rahmen.

Inhaltsverzeichnis

• Inhalt
• Was eine Open-Banking-API ist und wie sie funktioniert
• Open Banking und Open Finance: der Unterschied
• Die Rechtslage in der Schweiz
• Standards und Spezifikationen im Überblick
• API-Design im Banking
• Sicherheit und Consent Management
• Integration in Kernbanksystem und bestehende IT
• Unsere Sicht
• Häufige Fragen
• Wie S-PRO Banken und Finanzinstitute unterstützt
• Quellen

Inhalt

1. Was eine Open-Banking-API ist und wie sie funktioniert
2. Open Banking und Open Finance: der Unterschied
3. Die Rechtslage in der Schweiz
4. Standards und Spezifikationen im Überblick
5. API-Design im Banking
6. Sicherheit und Consent Management
7. Integration in Kernbanksystem und bestehende IT
8. Unsere Sicht
9. Häufige Fragen
10. Wie S-PRO Banken und Finanzinstitute unterstützt

Was eine Open-Banking-API ist und wie sie funktioniert

Eine API (Application Programming Interface) legt fest, wie zwei Systeme miteinander sprechen: welche Anfragen erlaubt sind, welche Daten zurückkommen und wie sich der Aufrufer ausweist. Bei Open Banking öffnet die Bank diese Schnittstelle kontrolliert nach aussen. Auf der einen Seite steht die Bank, die das Konto führt. Auf der anderen Seite steht ein Drittanbieter, zum Beispiel eine Finanzplanungs-App, eine Buchhaltungssoftware für KMU oder eine andere Bank, die eine Multibanking-Übersicht anbietet.

In der Praxis läuft ein typischer Datenzugriff in diesen Schritten ab:

1. Registrierung des Drittanbieters: Der Drittanbieter schliesst mit der Bank oder über eine Plattform einen Vertrag ab und erhält technische Zugangsdaten, etwa Client-ID und Zertifikate.
2. Anfrage der Kundin: Die Kundin möchte in der App des Drittanbieters ihre Konten sehen. Die App leitet sie zur Bank weiter.
3. Authentifizierung bei der Bank: Die Kundin meldet sich in der gewohnten Umgebung ihrer Bank an, zum Beispiel per E-Banking-Login mit zweitem Faktor. Der Drittanbieter sieht ihre Zugangsdaten nie.
4. Einwilligung (Consent): Die Bank zeigt, welche Daten für welchen Zweck und wie lange freigegeben werden. Die Kundin bestätigt oder lehnt ab.
5. Token-Ausgabe: Die Bank stellt dem Drittanbieter ein zeitlich und inhaltlich begrenztes Zugriffstoken aus, meist nach dem Verfahren von OAuth 2.0.
6. Datenabruf: Mit diesem Token ruft der Drittanbieter genau die freigegebenen Daten ab, etwa Saldo und Transaktionen der letzten 90 Tage, oder er löst eine Zahlung aus.
7. Widerruf: Die Kundin kann die Einwilligung jederzeit bei der Bank zurückziehen. Danach ist das Token ungültig.

Fachlich unterscheidet man vor allem zwei Arten von Diensten: Kontoinformationsdienste, die Daten lesen, und Zahlungsauslösedienste, die im Auftrag der Kundschaft eine Zahlung anstossen. Dazu kommen Abfragen wie die Bestätigung, ob ausreichend Deckung vorhanden ist.

Open Banking und Open Finance: der Unterschied

Open Banking beschränkt sich klassisch auf Zahlungs- und Kontodaten. Open Finance geht weiter. Die Schweizerische Bankiervereinigung beschreibt Open Finance in der Schweiz als Möglichkeit für Kundinnen und Kunden, ihre persönlichen Finanzdaten über offene Schnittstellen verschiedenen Finanzdienstleistern zugänglich zu machen. Drittanbieter können dabei auch selbst Banken oder Versicherungen sein.

Eine Open-Finance-API deckt deshalb zusätzliche Bereiche ab:

Für Privatbanken, Vermögensverwalter und Asset Manager ist Open Finance der relevantere Begriff. Hier geht es um Portfolio-Positionen, Order-Platzierung und Kundendaten zwischen Depotbank und unabhängigem Vermögensverwalter, also um Wealth-Management-Prozesse und weniger um Zahlungen.

Die Bankiervereinigung betont dabei eine strategische Perspektive: Wer Drittanbieter-Angebote in den eigenen Kanal einbindet, positioniert sich als vertrauenswürdige Partnerin, schützt die Interessen der Kundschaft und trägt so zur Stabilität des Finanzplatzes bei. Open Finance ist damit nicht nur Pflichtübung, sondern ein Hebel für die eigene Plattformstrategie.

S-PRO

Open Banking vor Ort besprechen

Löwenstrasse 45, 8001 Zürich

Wegbeschreibung öffnen

© OpenStreetMap contributors

Die Rechtslage in der Schweiz

In der EU verpflichtet die Zahlungsdiensterichtlinie PSD2 Banken dazu, lizenzierten Drittanbietern Zugang zu Zahlungskonten zu geben. Das Vereinigte Königreich hat ein ähnliches Regime. In der Schweiz ist das anders. Laut dem Bundesrat zum Stand von Open Finance besteht keine gesetzliche Verpflichtung, Drittanbietern auf Wunsch der Kundschaft Finanzdaten zugänglich zu machen. Der Bundesrat erwartet vielmehr, dass die Branche Standardisierung und Öffnung der Schnittstellen selbst vorantreibt.

Ein wichtiger Meilenstein war die Multibanking-Initiative: Im Mai 2023 haben 40 Banken mit einer Absichtserklärung zugesagt, den Zugang zu Daten von Privat-, Spar- und Kontokorrentkonten zu ermöglichen. Der Bundesrat wertete dies als klares Bekenntnis des Bankensektors zu Open Finance und sieht deshalb derzeit keine staatlichen Massnahmen vor. Den aktuellen Stand sollten Sie beim Bund und bei der Bankiervereinigung verfolgen, denn die Haltung des Bundesrats hängt ausdrücklich vom Fortschritt der Branche ab.

Für Banken mit Geschäft in der EU gilt zusätzlich: Wer dort Zahlungskonten führt, unterliegt den europäischen Regeln. Eine Schweizer Architektur sollte daher so gebaut sein, dass sie mit überschaubarem Aufwand auch PSD2-konforme Endpunkte bereitstellen kann.

Auch ohne Open-Banking-Gesetz gelten weitere Regeln. Das Schweizer Datenschutzgesetz (nDSG) verlangt, dass Verantwortliche die Datenbearbeitung technisch und organisatorisch so gestalten, dass die Datenschutzvorschriften eingehalten werden. Die Massnahmen müssen dem Stand der Technik, Art und Umfang der Bearbeitung sowie dem Risiko angemessen sein. Hinzu kommen das Bankgeheimnis und die Anforderungen der FINMA, etwa an Auslagerungen und an das Management operationeller Risiken. Wie diese Pflichten im digitalen Kanal zusammenspielen, beschreiben wir in unserem Beitrag zu regulatorischer Compliance im digitalen Banking.

Standards und Spezifikationen im Überblick

Ohne gemeinsame Standards müsste jeder Drittanbieter jede Bank einzeln anbinden. Genau das wollen die Schweizer Initiativen vermeiden. Die wichtigsten Bausteine:

Das Swiss NextGen Banking API-Framework basiert auf Version 1.3.4 des NextGenPSD2 Frameworks der Berlin Group. Es verfeinert die Nachrichtenformate für die Schweiz und liefert passende Beispiele. Für Ihre Architektur heisst das: Wer sich daran orientiert, ist auch näher am europäischen Markt.

In der Praxis laufen Schnittstellen zudem oft über Plattformen der Finanzmarktinfrastruktur, allen voran bLink von SIX. Ob Sie eigene Endpunkte direkt anbieten, eine solche Plattform nutzen oder beides kombinieren, ist eine Architekturentscheidung mit Folgen für Kosten, Abhängigkeiten und Time-to-Market.

Wichtig ist die Frage, auf welcher Ebene standardisiert wird. Die Bankiervereinigung unterscheidet in ihrer Übersicht zu Open Banking vier Ebenen: Transport (HTTPS), Codierung (JSON oder XML), Authentifizierung und Autorisierung (OAuth 2.0) sowie die geschäftliche Ebene. Die ersten drei sind weitgehend gelöst. Die grösste Herausforderung liegt in der Business Domain, also in der Frage, was ein „Konto“, eine „Position“ oder ein „Mandat“ fachlich genau bedeutet und wie es abgebildet wird.

API-Design im Banking

Eine gute Banking-API ist mehr als ein technischer Endpunkt. Laut Bankiervereinigung sollten APIs möglichst auf anerkannten Marktstandards beruhen, damit Drittanbieter nahtlos und fehlerfrei andocken können, und die Kundschaft sollte Transparenz und Kontrolle über den Datenzugriff haben. Aus unserer Projekterfahrung leiten sich daraus konkrete Designprinzipien ab:

• Standard vor Eigenbau: Übernehmen Sie Datenmodelle und Fehlercodes aus Swiss NextGen API oder OpenWealth, statt eigene Varianten zu erfinden. Jede Abweichung kostet jeden Partner Integrationsaufwand.
• Klares Fachmodell: Definieren Sie ein kanonisches Datenmodell zwischen Kernbanksystem und API. So schlagen interne Feldnamen und Sonderfälle nicht nach aussen durch.
• Versionierung: Planen Sie von Anfang an, wie neue Versionen eingeführt und alte abgekündigt werden, inklusive Übergangsfristen für Partner.
• Idempotenz bei Zahlungen: Eine wiederholte Anfrage darf keine doppelte Zahlung auslösen. Idempotenz-Schlüssel sind hier Pflicht.
• Paginierung und Limits: Transaktionshistorien können gross sein. Seitenweise Abfragen und Rate Limits schützen das Kernbanksystem vor Lastspitzen.
• Dokumentation und Sandbox: Eine OpenAPI-Spezifikation, eine Testumgebung mit realistischen Testdaten und ein klarer Onboarding-Prozess für Drittanbieter entscheiden darüber, ob Partner Ihre API tatsächlich nutzen.
• Beobachtbarkeit: Messen Sie Verfügbarkeit, Antwortzeiten und Fehlerraten pro Endpunkt und pro Partner. Diese Daten brauchen Sie für Service Levels und für die Aufsicht.

Sicherheit und Consent Management

Sicherheit und Einwilligung sind bei Open Banking untrennbar. Die Bankiervereinigung hält fest, dass Sicherheitsstandards angemessen sein, dem technologischen Stand entsprechen und die Anforderungen der FINMA erfüllen sollten. Kundinnen und Kunden sollen jederzeit wissen, was mit ihren Daten geschieht. Ihre Einwilligung soll möglichst spezifisch sein und freiwillig erfolgen.

Bausteine einer sicheren Bank-API

• Gegenseitige Authentifizierung: Drittanbieter weisen sich mit Zertifikaten aus (mutual TLS), nicht nur mit einem API-Schlüssel.
• Token mit engem Scope: Zugriffstoken gelten nur für die freigegebenen Konten, Datenarten und Zeiträume. Sie laufen kurz und werden über Refresh-Token erneuert.
• Starke Kundenauthentifizierung: Die Einwilligung erfolgt immer in der Umgebung der Bank, mit zweitem Faktor.
• API-Gateway als Kontrollpunkt: Rate Limiting, Schema-Validierung, Bedrohungserkennung und zentrales Logging gehören vor das Kernbanksystem, nicht hinein.
• Verschlüsselung und Schlüsselverwaltung: Daten sind im Transport und in der Ablage verschlüsselt, Schlüssel liegen in einem Hardware-Sicherheitsmodul oder einem gleichwertigen Dienst.
• Betrugserkennung: Ungewöhnliche Muster bei Zahlungsauslösungen, etwa neue Empfänger oder ungewohnte Beträge, werden markiert und gegebenenfalls gestoppt.

Consent Management richtig aufbauen

Das Consent Management ist das Herzstück. Es speichert, welche Kundin welchem Drittanbieter wofür und bis wann Zugriff gegeben hat. Ein belastbares System bietet:

1. Granulare Einwilligungen pro Konto, Datenart und Zweck statt einer pauschalen Freigabe.
2. Ein Dashboard für die Kundschaft im E-Banking und in der Mobile App, in dem alle aktiven Freigaben sichtbar und mit einem Klick widerrufbar sind.
3. Einen lückenlosen Audit-Trail, der Erteilung, Nutzung und Widerruf jeder Einwilligung nachvollziehbar protokolliert.
4. Automatischen Ablauf von Einwilligungen nach der vereinbarten Frist.
5. Eine Schnittstelle zu Compliance und Datenschutz, damit Auskunftsbegehren nach nDSG schnell beantwortet werden können.

Auch die Beziehung zum Drittanbieter selbst braucht Struktur. Gemäss dem Leitfaden der Bankiervereinigung zum Umgang mit Daten hängen die Überwachungs- und Sorgfaltspflichten der Bank von Art und Intensität der Zusammenarbeit ab. Zusammenarbeit und Datenflüsse sollten klar dokumentiert werden, wenn möglich vertraglich. Ob ein konkretes Partnermodell als Auslagerung im Sinne der FINMA gilt, klären Sie am besten früh mit Ihrer Rechtsabteilung und Ihrer Prüfgesellschaft, bevor die Architektur festgelegt ist.

Integration in Kernbanksystem und bestehende IT

Die Bankiervereinigung rät Banken, Entwicklungen und Angebote rasch zu beurteilen, geeignete Partner auszuwählen und gezielt zu integrieren. Dafür seien Investitionen in personelle und technologische Ressourcen nötig. In der Praxis scheitern Open-Banking-Vorhaben selten an der API-Spezifikation, sondern an der Anbindung der gewachsenen Systemlandschaft. Bewährt hat sich dieses Vorgehen:

1. Use Cases priorisieren: Starten Sie mit zwei, drei Anwendungsfällen mit klarem Geschäftsnutzen, etwa Multibanking für KMU-Kunden oder den Datenaustausch mit unabhängigen Vermögensverwaltern.
2. Datenquellen inventarisieren: Klären Sie, wo Konten, Positionen, Kundenstammdaten und Zahlungsstatus heute liegen, in welcher Qualität und mit welcher Latenz.
3. Integrationsschicht einziehen: Zwischen Kernbanksystem und API gehört eine eigene Schicht mit kanonischem Datenmodell, Caching und Ereignisverarbeitung. So bleibt der Kern stabil, während die API sich weiterentwickelt.
4. Gateway und Identität aufsetzen: API-Gateway, Autorisierungsserver und Consent-Service bilden die Sicherheitsarchitektur. Sie sollten mit der bestehenden Kundenauthentifizierung des E-Bankings verbunden sein.
5. Sandbox und Partner-Onboarding: Bevor Produktivdaten fliessen, testen ausgewählte Partner in einer Sandbox. Parallel werden Verträge und Due-Diligence-Prozesse aufgesetzt.
6. Schrittweise produktiv gehen: Erst lesende Dienste, dann schreibende wie Zahlungsauslösung. Monitoring und Incident-Prozesse stehen ab dem ersten Tag.
7. Betrieb und Weiterentwicklung: Neue Standardversionen, zusätzliche Partner und Open-Finance-Daten wie Depots folgen nach Roadmap.

Wenn das Kernbanksystem selbst modernisiert oder ersetzt wird, lohnt es sich, die API-Schicht gleich mitzuplanen. Wie ein solcher Wechsel vom Datenprofil bis zum Cutover abläuft, zeigen wir im Beitrag zur Core-Banking-Migration. Ein angrenzendes Thema ist der Zahlungsverkehr in Echtzeit: Unser Überblick zu Instant Payments in der Schweiz zeigt, welche Anforderungen an Verfügbarkeit und Verarbeitung dort entstehen, die auch für Zahlungs-APIs gelten.

Unsere Sicht

Wir sehen in Schweizer Projekten immer wieder dasselbe Muster: Die API-Spezifikation ist nach wenigen Wochen klar, die eigentliche Arbeit steckt im Fachmodell, in der Anbindung des Kernbanksystems und im Consent Management. Wer die API als dünne Hülle direkt auf das Kernsystem setzt, erkauft sich einen schnellen Start mit hohem Betriebsrisiko. Wir empfehlen deshalb eine eigene Integrationsschicht, die Standards wie Swiss NextGen API und OpenWealth sauber abbildet und den Kern schützt.

Zweitens rechnen wir damit, dass Schnittstellen künftig nicht nur von Apps, sondern auch von KI-Agenten genutzt werden, etwa für KYC und Onboarding oder als RM-Copilot, der Portfolio-Daten aus mehreren Depotbanken zusammenführt. Dann gelten für das KI-System selbst zusätzliche Anforderungen, zum Beispiel aus dem EU AI Act, und Audit-Trail sowie Human-in-the-Loop werden zur Architekturfrage. Wer heute Consent, Protokollierung und Berechtigungen sauber baut, schafft dafür die Grundlage.

Unser Fazit: Die fehlende gesetzliche Pflicht in der Schweiz ist kein Grund zu warten. Sie ist die Chance, eine API-Strategie nach eigenem Geschäftsmodell zu gestalten, statt nur Vorgaben abzuarbeiten.

— Igor Izraylevych

Häufige Fragen

Sind Schweizer Banken verpflichtet, eine Open-Banking-API anzubieten?

Nein. Anders als in der EU oder im Vereinigten Königreich gibt es in der Schweiz keine gesetzliche Pflicht. Der Bundesrat setzt auf die Branche und verweist auf die Multibanking-Initiative, mit der sich 40 Banken 2023 zur Öffnung von Kontodaten bekannt haben.

Welcher Standard ist in der Schweiz massgebend?

Für Konten und Zahlungen ist das Swiss NextGen API die wichtigste Referenz, es basiert auf dem NextGenPSD2 Framework der Berlin Group. Für Wealth Management hat sich OpenWealth als Branchenstandard etabliert. Technisch liegen fast immer HTTPS, JSON und OAuth 2.0 darunter.

Was ist der Unterschied zwischen Open Banking und Open Finance?

Open Banking umfasst Konto- und Zahlungsdaten. Open Finance erweitert dies auf Depots, Kredite, Vorsorge und Versicherungen und lässt auch Banken und Versicherungen als Drittanbieter zu. Für Privatbanken und Vermögensverwalter ist Open Finance meist der relevantere Rahmen.

Wie lange dauert eine Open-Banking-Integration?

Das hängt stark vom Kernbanksystem, von der Datenqualität und vom Umfang der Use Cases ab. Lesende Dienste für einen klar umrissenen Anwendungsfall lassen sich deutlich schneller umsetzen als Zahlungsauslösung oder Open-Finance-Daten. Eine belastbare Planung entsteht erst nach einer Analyse der bestehenden Systemlandschaft.

Wer haftet, wenn ein Drittanbieter Daten missbraucht?

Das regeln in der Schweiz vor allem die Verträge zwischen Bank und Drittanbieter sowie das Datenschutzrecht. Die Bankiervereinigung empfiehlt, Zusammenarbeit und Datenflüsse klar und möglichst vertraglich zu dokumentieren. Für die konkrete Ausgestaltung sollten Sie Ihre Rechtsabteilung oder eine spezialisierte Anwaltskanzlei beiziehen.

Wie S-PRO Banken und Finanzinstitute unterstützt

S-PRO ist ein Softwareentwicklungsunternehmen mit Hauptsitz an der Löwenstrasse 45, 8001 Zürich, und R&D-Zentren in Zürich und Łódź. Seit 2014 entwickeln wir mit 250+ Engineers Software für Banken, Privatbanken, Vermögensverwalter, Asset Manager und Fintechs. Wir sind nach ISO 27001 und ISO 27701 zertifiziert.

Bei Open-Banking- und Open-Finance-Vorhaben unterstützen wir Sie mit Fintech- und Banking-Softwareentwicklung: von der Integrationsschicht zum Kernbanksystem über Consent Management und Sicherheitsarchitektur bis zu Digital-Banking- und Wealth-Management-Plattformen, die APIs nutzen oder bereitstellen. Unsere Lösungen sind auf FINMA, DORA und nDSG ausgelegt. Wo KI-Agenten Daten über APIs verarbeiten, etwa für KYC, Onboarding oder Dokumentenverarbeitung, berücksichtigen wir zusätzlich den EU AI Act. Beispiele aus unserer Arbeit sind das digitale Banking-Erlebnis für AMINA Bank und die B2B-Digitalbanking-Plattform der New Horizon Bank.

Wenn Sie Ihre API-Strategie oder die Anbindung Ihres Kernbanksystems besprechen möchten, finden Sie hier unsere Leistungen zur Core-Banking- und Legacy-Modernisierung sowie zur Finanz-Software-Entwicklung in der Schweiz. Wir gehen gerne gemeinsam mit Ihnen durch Ihre Ausgangslage.

Quellen

• Swiss NextGen Banking API-Framework
• Bundesrat: Fortschritte bei der Umsetzung von Open Finance
• Schweizerische Bankiervereinigung: Open Banking (2020)
• Schweizerische Bankiervereinigung: Open Finance in der Schweiz
• Schweizerische Bankiervereinigung: Handling data in day-to-day business (2021)
• Bundesgesetz über den Datenschutz (nDSG), SR 235.1

Empfehlungen

• Instant Payments in der Schweiz: Stand 2026 und Pflichten für Banken
• E-Banking-Plattformen für die Swiss Digital Asset Bank