„Need to Know“ als neue Herausforderung beim Testing bei der Harmonisierung ZV Schweiz

Mit dem Rundschreiben „2008/21 Operationelle Risiken Banken“ der FINMA kam erstmals das Prinzip „Need to Know“ auf die Agenda der Banken-IT-Verantwortlichen. Die Banken werden dadurch vor neue Herausforderungen gestellt und müssen sich nun für einen Weg entscheiden, wie sie durch das Labyrinth der neuen Anforderungen navigieren.

Unter anderem werden dort folgende Grundsätze zitiert:

• „Die Bank muss wissen, wo CID (Client Identifying Data) gespeichert werden, von welchen Anwendungen und IT-Systemen CID verarbeitet werden und wo elektronisch auf sie zugegriffen werden kann. Der Datenzugriff muss klar geregelt werden und darf nur auf einer strikten Need to know-Basis erfolgen.“
• „Personen dürfen nur auf diejenigen Informationen oder Funktionalitäten Zugriff haben, die für die Wahrnehmung ihrer Aufgaben erforderlich sind.“

Obwohl die technischen Anforderungen zu den Sicherheitsstandards im vierten Grundsatz sehr generisch formuliert worden sind, sind sie heute in der operationellen Praxis, insbesondere bei Grossbanken, schon seit längerem organisatorisch und technisch umgesetzt. Auch die regelmässigen Audits (im Sinne von „gegenwärtigem Stand der Technik“, VDSG RS 235.11, Art. 8 Abs. 2) externer Fachspezialisten sind fixe Termine in der Agenda der Banken-CIOs.
So weit so gut, könnte man meinen.

Legen wir nun den Fokus auf das aktuelle Vorhaben Harmonisierung ZV Schweiz. Der Zahlungsverkehr ist naturgemäss ein heikles Minenfeld, wenn es um Kundendaten geht. Aus diesem Grund haben verschiedene Institute eigene Konzepte entwickelt, um mit sog. anonymisierten Daten die Testzyklen im Projekt durchzuführen. Bei der Harmonisierung ZV Schweiz ist dies insbesondere eine Herausforderung, da die gesamte ZV-Verarbeitungskette involviert ist. 

Angefangen bei der Annahme von Zahlungsaufträgen, über die Verarbeitung, Verbuchung, Archivierung und Rapportierung in Form von Kontoauszügen, soll der gesamte Datenfluss in allen Systemen keine Rückschlüsse auf effektiv existierende Kunden zulassen. Dies notabene über alle Kundensegmente, d.h. vom Privatkunden mit einem Bankkonto bis hin zum internationalen Grosskonzern mit einigen hundert Konti und den jeweiligen Stammdaten-Einstellungen.

In der Praxis zeichnen sich drei Hauptherangehensweisen ab:

1. Komplette Anonymisierung mit Hilfe „synthetischer“ Daten
2. Teilweise Anonymisierung unter Beibehaltung der Kontonummer als zentrales Element mit Verschleierung der restlichen Kundendaten
3. Keine Anonymisierung, d.h. Tests mit älteren Daten aus einem Abzug aus den Produktivsystemen

Es ist selbstredend, dass die Ansatz 1 den grössten Aufwand verursacht (komplette Neuanlage von Kunden, Konti, Einstellungen, Berechtigungen in Kanälen etc.) und aus diesem Grund auch nur von den wenigsten Instituten im Testing gelebt wird.

Ansatz 2 hat sich gemäss unseren Beobachtungen zu einer Art „best practice“ entwickelt. Die Verantwortlichen sind sich bewusst, dass sie da allenfalls in einem Graubereich operieren. Sie haben jedoch das Risiko akzeptiert. Ob dieses Vorgehen in den Geschäftsleitungen transparent kommuniziert wird, ist eine andere Frage. 

Obwohl man meinen würde, dass keine Schweizer Bank den Ansatz 3 heute noch praktiziert, ist dies vor allem bei kleineren Instituten gang und gäbe. Es stellt sich die Frage, inwiefern hier Compliance-Vorgaben verletzt werden und wer schlussendlich die Verantwortung für ein solches Vorgehen trägt.

Obwohl das Thema bei jedem neuen IT-Release wieder periodisch aufpoppt, sind echte Vorgehensanpassungen die Ausnahme. Das Business-Projekt hat aktuell kein Budget für eine solche „Grossübung“ und auch in der zentralen IT oder dem Sicherheitsdepartment ist das Thema ZV-Testing nicht zuoberst in der Prioritätenliste.

Hier sind pragmatische Ansätze gefragt, die die Ressourcen der kleineren Banken berücksichtigen und dennoch einen gewissen Reifegrad bezüglich der Anonymisierung gewährleisten. Aus dem Fundus der zahlreich durchgeführten ZV-Testszenarien bei unseren Kunden ist PPI hier in der Lage Unterstützung zu leisten, damit diese „weissen Flecken“ entfernt werden können und kein CIO durchwachte Nächte deswegen mehr haben muss (mehr Infos oder konkrete Anfragen zum Thema unter info@ppi-schweiz.ch).

Dieser Beitrag wurde von Carsten Miehling gepostet.

#CID #FINMA #Harmonisierung