Open Banking APIs unter PSD2: Risikominderung

Open Banking hat in den letzten Jahren im Finanzdienstleistungssektor große Beachtung gefunden. Open Banking bedeutet, dass Banken ihre Systeme für autorisierte Drittanbieter von Finanzdienstleistungen öffnen, sodass diese Unternehmen auf Wunsch der Kunden der Bank Zahlungen und Finanztransaktionen initiieren und verarbeiten können.
Open Banking verspricht, Innovationen freizusetzen, die das Bankerlebnis grundlegend verbessern und neue Finanzdienstleistungen einführen. Beispielsweise können Drittanbieter (TPPs) Anwendungen bereitstellen, mit denen Verbraucher mehrere Bankkonten von einer einzigen Anwendung aus abrufen können, oder Apps, die es Unternehmen erleichtern, Daten mit ihren Buchhaltern zu teilen.
Unter PSD2 müssen Banken eine Schnittstelle anbieten, über die TPPs mit ihnen kommunizieren können. Auf diese Weise können diese Anbieter, wenn der Verbraucher andere Finanzdienstleister als die Bank nutzen möchte, über die offene Kommunikationsschnittstelle auf die Systeme der Bank zugreifen und die Kunden der Bank bedienen.
Dies ist nicht ohne Risiko. Gemäß McKinsey & Company „Die meisten Banken berichten, dass sie nicht erwarten, dass Sicherheit unter PSD2 zu einem Problem wird. Sie erkennen jedoch auch an, dass sie in das Betrugsmanagement investieren müssen. Banken sind für die Minderung des Betrugsrisikos verantwortlich und müssen erweiterte Kontrollen implementieren, einschließlich erweiterter Analysen (z. B. um den Ursprung eingehender Aufrufe der API zu überprüfen) und leistungsstarke Tools zur Erkennung von Betrugsangriffen. Die Umfrageteilnehmer der [McKinsey Global Payments Practice PSD2-Umfrage 2017] gaben dies an Das Betrugsrisiko durch den Zugriff Dritter auf Konten ist ein ernstes Problem, und die Betrugsprävention hat oberste Priorität. ”
Risiken für Banken
Durch die Einführung offener APIs sind Banken von der Sicherheit der TPPs abhängig, die diese APIs verwenden. Mögliche Bedrohungsszenarien sind:
- Ein Datenverstoß bei einem TPP macht die Kunden der Bank sichtbar
- TPPs speichern die Finanzdaten der Verbraucher. Wenn ein TPP verletzt wird, können die Kundendaten der Bank offengelegt werden, was sich wiederum auf das Ansehen der Bank auswirken kann. Im Lichte der europäischen Datenschutz-Grundverordnung (DSGVO) müssen Banken sicherstellen, dass TPPs geeignete technische und organisatorische Maßnahmen zum Schutz von Kundendaten implementieren.
- Betrügerische Anfragen von einem kompromittierten TPP
- Wenn ein TPP gehackt wird, kann dies zu betrügerischen Informationsanfragen über die Kunden einer Bank führen - oder zu betrügerischen Zahlungsanforderungen vom TPP an die Bank. Ein solcher Vorfall kann durch Sicherheitslücken in der mobilen App oder Webanwendung des TPP verursacht werden. Da Banken als erste Partei für nicht autorisierte Finanztransaktionen vom Bankkonto eines Benutzers haftbar gemacht werden, kann eine Sicherheitsverletzung bei einem TPP schwerwiegende Folgen für Banken haben.
- Betrügerische Anfragen von TPP-Mitarbeitern
- Ein verärgerter Mitarbeiter eines TPP kann betrügerische Anfragen nach Informationen über die Kunden einer Bank stellen oder betrügerische Zahlungen einleiten.

Banken sollten eine Reihe technischer und organisatorischer Sicherheitsmaßnahmen ergreifen, um diesen und anderen Bedrohungen zu begegnen. Im Rahmen von Open Banking können Banken Risiken auf verschiedene Weise mindern:
1. Verwenden Transaktionsrisikoanalyse
Banken können die Transaktionsrisikoanalyse verwenden, um:
- Erkennen Sie betrügerische Transaktionen und Benutzerverhalten. Die PSD2 Regulatory Technical Standards (RTS) schreiben vor, dass Zahlungsdienstleister (PSPs), einschließlich Banken, eine Risikoanalyse aller von ihnen verarbeiteten Finanztransaktionen durchführen. Auf diese Weise können PSPs Zahlungsbetrug erkennen, z. B. Betrug ohne Karte.
- Erkennen Sie Sicherheitsvorfälle bei TPPs. Die Transaktionsrisikoanalyse kann verwendet werden, um abnormales Verhalten bei Anforderungen zu erkennen, die von TPPs stammen, verdächtige Transaktionen von TPPs zu identifizieren, atypische Sequenzen von API-Aufrufen zu erkennen und all dies in Echtzeit.
- Erkennen Sie Schwachstellen in der API-Implementierung. Schwachstellen bei der Implementierung von APIs können zu betrügerischen Transaktionen und ungewöhnlichem Benutzerverhalten führen, die mithilfe der erweiterten Betrugsüberwachung erkannt werden können.
2. Wählen Sie das richtige Authentifizierungsmodell
Starke Kundenauthentifizierung ist kritisch, ob das so ist Zwei-Faktor-Authentifizierung , Multi-Faktor-Authentifizierung , biometrische Authentifizierung , oder andere. Jedoch, Verschiedene Authentifizierungsmodelle haben jeweils ihre eigenen Merkmale und Sicherheitsauswirkungen. Für die Bank ist es normalerweise am besten, ein Modell zu verwenden, das den Authentifizierungsprozess bei der Bank selbst oder bei einem externen Sicherheitsanbieter platziert. Dies bedeutet, dass die Bank weiterhin direkt mit dem Benutzer anstatt über das TPP kommuniziert. Auf diese Weise stehen der Bank weitere Informationen für die Analyse des Transaktionsrisikos zur Verfügung, einschließlich des Nachweises von Authentifizierungsereignissen, die für die Behandlung von Streitigkeiten über die Haftung einer betrügerischen Transaktion relevant sind.
3. Schützen Sie den Kommunikationskanal mit TPPs
Banken müssen den Datenaustausch mit ihren TPPs schützen. Denken Sie an die gegenseitige Authentifizierung zwischen einer Bank und TPP, indem Sie beispielsweise SSL / TSL-Protokolle verwenden.
4. Fordern Sie unabhängige Sicherheitsüberprüfungsberichte von TPPs an
Die Europäische Kommission hat Sicherheitsrisiken im Rahmen von PSD2 antizipiert und fordert daher PSPs und TPPs auf, Betriebs- und Sicherheitsrisiken zu managen. Insbesondere schreibt Artikel 95 Absatz 1 der PSD2 vor, dass die PSP einen Rahmen mit geeigneten Minderungsmaßnahmen zur Bewältigung der Betriebs- und Sicherheitsrisiken in Bezug auf die von ihnen erbrachten Finanzdienstleistungen festlegen müssen. Die Einrichtung, Umsetzung und Überwachung von Sicherheitsmaßnahmen sollte Folgendes umfassen:
- Governance, einschließlich des Rahmens für das operationelle und Sicherheitsrisikomanagement, die Risikomanagement- und Kontrollmodelle sowie das Outsourcing
- Risikobewertung, einschließlich Identifizierung, Klassifizierung und Risikobewertung von Funktionen, Prozessen und Vermögenswerten
- Schutz der Integrität von Daten, Systemen und Vertraulichkeit, physischer Sicherheit und Asset-Kontrolle
- Überwachung, Erkennung und Meldung von Sicherheitsvorfällen
- Business Continuity Management, einschließlich Testen von Business Continuity-Plänen, Incident Management und Krisenkommunikation
- Unabhängige Prüfung von Sicherheitsmaßnahmen
Banken sollten TPPs auffordern, unabhängige Sicherheitstestberichte vorzulegen, um die Reife ihrer Sicherheitspraktiken zu überprüfen.
5. Vermeiden Sie Sicherheitslücken in der API-Implementierung
Stellen Sie zum Schutz vor Injection-Angriffen sicher, dass die API-Softwarekomponente, die die Datenstrukturen analysiert, unabhängig von dem von der API verwendeten Datenformat gegen Angriffe geschützt ist. Außerdem sollten Banken die Desinfektion von Inputs schützen, um die Injektion aller Formen zu verhindern. Die Sicherheitsanalyse und -tests sollten alle APIs und Tools abdecken, damit Banken sie effektiv erkennen und analysieren können.
Öffnen Sie Banking-APIs und deren Schutz
Die von PSD2 benötigten offenen APIs werden zweifellos zu neuen, innovativen Bankdienstleistungen und Apps führen. Gleichzeitig müssen Banken jedoch verhindern, dass Kriminelle auf Kundendaten und -transaktionen zugreifen. Banken und TPPs müssen sich daher der Risiken bewusst sein und einen ausreichenden Schutz bieten. Laden Sie dieses Whitepaper herunter, um mehr zu erfahren:
Open Banking-APIs unter PSD2: Sicherheitsbedrohungen und -lösungen
Dieser Blog wurde von einem Artikel von Frederik Mennes inspiriert, der zum ersten Mal auf erschien Techzine .