Identifikationsprozess kostengünstig optimieren

Ausgangslage

Der Identifikationsprozess bei Banken scheint auf den ersten Blick banal zu sein. Identifikationsdokument prüfen, kopieren/scannen, Daten im System erfassten - fertig.

In der Praxis ist der Prozess bei den Banken aber häufig nicht ganz so effizient wie möglich und vor allem auch Fehleranfällig. Häufige Fehler sind etwa:

- Die Kopie/der Scan ist schlecht lesbar
- Es wurden nicht alle notwendigen Seiten kopiert/gescannt
- Die Daten wurden falsch ins System übertragen

Gerade letzteres kommt häufiger vor als manche vielleicht denken. Trotz 4-Augenkontrolle. Bspw. Wird ein Italiener anhand eines CH-Führerausweises identifiziert und im System die Nationalität "Schweiz" erfasst. Da die Nationalität auf dem CH-Führerausweis auch kaum zu finden ist. Oder es wird nicht der vollständige Name erfasst.

Mit technischen Hilfsmitteln liesse sich da einiges machen. Allerdings gilt es, Aufwand und Nutzen abzuwägen. Intelligente Scan-Lösungen an jedem Arbeitsplatz einzurichten ist kostspielig.

In der Zeit von Smartphones sollte es jedoch möglich sein, den prozess Kostengünstig technisch zu unterstützten - oder doch nicht? Ich habe es mit einem funktionierenden Prototypen ausprobiert. Diesen möchte ich hier kurz vorstellen.

Android-App als Identifikations-Hilfsmittel

Ich habe eine Android-App (Prototype) geschrieben, welche folgende Funktionen hat:

- Scannen des Identifikationspapiers (mittels Kamera)
- Textextraktion aus maschinen lesbarem Code (bspw. CH-Identifikationskarte)
- Textextraktion aus Text (bspw. Nationalität bei CH-Führerausweis, ist leider nicht in maschinen lesbarem Code enthalten)
- Strukturierung der extrahierten Daten (Name, Geburtsdatum, Nationalität etc.)
- Kleine Bildbearbeitung (Reduktion der Grösse)
- Festhaltung der Lokalisierung mittels Smartphone (wo wurde die Aufnahme gemacht)

Problemstellungen

Als erstes muss ein spezifisches Dokument ausgewählt werden. Das Programm muss wissen, welches Dokument (CH-Identfikationskarte, DE-Pass etc.) man scannen möchte. Dies aus zweierlei Gründen:

1) Die Textextraktion ist für ein Smartphone zu rechenintensiv, wenn zuerst ein vollständiges Bild analysiert werden muss um den Typ zu erkennen

2) Durch die Wahl des Dokumententypes kann gleich zu Beginn festgelegt werden, welche Seiten gescannt werden müssen.

Dadurch, dass das Programm weiss, welches Dokument er vor sicht haben sollte, kann die Texterkennung relativ effizient und mit guter Qualität erfolgen.

Eine weitere Herausforderung ist die Kamera. Die Bildqualität ist entscheidend für den Erfolg der Texterkennung. Dazu muss die Kamera direkt via API, inkl. Vorschau, angesteuert werden. Nur so können die notwendigen ausprobierten Einstellungen durchgesetzt werden. Mit der standard Kamera-App ist dies nicht möglich.

Zusatzfunktionen

Neben der reinen strukturierten Informationsausgabe sollen diese Daten auch gleich dazu verwendet werden, einen KYC-Check zu machen. Gemeint ist, dass die Daten der zu identifizierenden Person gleich mittels Name-Matching mit einer Datenbank von politisch exponierten Personen (PEP), Sanktionierten Personen, Terroristen etc. abgeglichen werden.

Übertragung der Daten

Die Datenübertragung vom Smartphone in ein CRM-System (bspw. das Core-Banking-System) ist technische auf viele Wege möglich. Praktisch gibt es auch meiner Sicht jedoch nur einen wirklich gangbaren Weg:

- Übertragung via USB-Kabel als Speicher: Die meisten Banken haben zu Recht den USB-Port für Datenübertragungen geschlossen, oder haben bspw. Citrix-Lösungen wo dies per Default nicht funktioniert.

- Übertragung via USB-Kabel als Anwendung: Funktioniert für Citrix-Umgebungen glaub ich auch nicht. Zudem müsste auf jedem Client eine entsprechende Software installiert werden. Dies dürfte kaum wirtschaftlch sei.

- Übertragung via Bluetooth: Die meisten Banken haben Bluethooth bei ihren Clients aus Gründen der Security abgeschaltet.

Bei all den Möglichkeiten gibt es ein zusätzliches Problem: Es braucht auf dem Client eine Software. Immer mehr CRM-System sind heute aber Browserbasiert. Das heisst, für die Datenübertragung vom USB-Kabel oder Bluethoth ins CRM-System wäre so oder so eine separate zusätzliche Software notwendig, da eben die CRM-Software nicht (mehr) auf dem Client selber läuft, sondern im Browser.

Meine favorisierte Lösung ist daher eine Datenübertragung via WLAN an einen internen Server. Dazu braucht es ein geschütztes WLAN, in welches sich das Smartphone einwählen kann. Anschliessend werden die Daten mittels HTTP-Post an einen Server übertragen. Durch die Hinterlegung der Benutzererknennung auf dem Smartphone kann die eingereichte Identfikations-Akte einem Benutzer im System zugeorndet werden. So kann der Mitarbeiter schliesslich die Identifikations-Akten (auch mehrere) einem oder mehreren Kundenstämmen zuordnen.

Eingebetet in einen Eröffnungsworkflow müssen die Kundendaten nur einmal erfasst werden. Die strukturierten Daten der Identifikations-Akte können direkt übernommen werden.

Diese Lösung der Übertragung lässt sich zum einen technisch gut absichern und zum anderen ist die Übertragung mit verschiedenen Architekturen und Technologien möglich, ohne dass auf den Clients Software installiert werden müsste.

Die App in Aktion - ein paar Printscreens

1) Das Land wählen ...

2) Das gewünschte Dokument wählen ...

3) Das Dokument photographieren ...

4) Das Ergebnis berechnen und anzeigen ...

Mögliche Betriebsmodelle

Die Banken haben verschiedene Möglichkeiten, Smartphones einzusetzen. Mögliche Varianten sind:

BYOD (Bring Your Own Device):
Die Mitarbeiter können die App auf ihrem eigenen Smartphone installieren und nutzen. Vorteil: Kostengüsntig. Die meisten Mitarbeiter haben heute bereits ein Smartphone. Nachteil: Geringere Sicherheit, weil die Firma weniger Konstrolle über das Gerät hat.

Smartphone zur Verfügung stellen:
Die Banken können, wie dies teils bereits gemacht wird, den betroffenen Mitarbeitern ein entsprechendes Gerät zur Verfügun stellen, welches sie unter bestimmten Bedingungen auch privat verwenden können. Vorteil: Die Firma hat eine gute Kontrolle über das Gerät, indem bspw. vorgeschrieben wird, dass eine bestimmte Security-Softwate auf dem Gerät installiert werden muss. Nachteil: Es braucht ein entsprechendes Mitarbeiter-"Programm" wo die Konditionen und Nutzungsbedingungen festgehalten werden.

Zweckgebundenes Smartphone:
Die Bank kann für den Mitarebiter oder bspw. pro Arbeitsplatz Geräte beschaffen, welche einzig diesem zweck dienen und für nichts anderes benutzt werden können. Vorteil: Volle Kontrolle und maximale Sicherheit. Nachteil: Insgesamt wahrscheinlich die teuerste Option.

Der Einsatz einer solchen Lösung ist im Übrigen nicht nur auf Banken beschränkt. Alle Branchen, welche Kunden formell identifizieren müssen, können mit solchen Lösungen den entsprechenden Prozess optimieren. Dazu zählen etwa Kasinos oder die Telekom-Branche.

Grenzen der Lösung

Die Lösung bietet sich grundsätzlich nur für die formelle Identifikation von natürlichen Personen an. Die Dokumente von Firmen und Organisationen lassen sich damit m.E. nicht effizient erfassen und eine solche App bietet entsprechend für solche Eröffnungsprozesse keinen Mehrwert.

Konklusion

Mit den heutigen technischen Möglichkeiten kann eine Bank relativ kostengünstig relevante Prozesse digitalisieren, effizienter und sicherer machen. Für den ersten Prototypen für den CH-Führerausweis hatte ich ca. 2.5-3 Tage Entwicklungsaufwand. Natürlich wurde dieser Prototyp nie "scharf" in einem Eröffnungsprozess verwendet. Die Praxistauglichkeit ist entsprechend noch nicht erwiesen worden.

Regulatorische Anforderungen im OnBoarding-Prozess bei den Banken

Ausgangslage

Der Kundeneröffnungsprozess zählt zu den wichtigsten Prozessen bei den Banken. Versäumnisse und Fehler in diesem Prozess sind häufig überproportional teuer. Bei ungenügender Qualität wird nicht selten die erst junge Geschäftsbeziehung seitens der Kunden wieder abgebrochen oder nicht so stark ausgebaut wie geplant war. Es gibt immer mehr gesetzliche und regulatorische Vorgaben, welche (auch) diesen Prozess betreffen. Dadurch wird dieser für die Bank so wichtige Prozess zunehmend komplexer und fehleranfälliger. Eine Kundenneueröffnung ist heute nicht mehr so günstig wie noch vor 5 oder 10 Jahren.

Die Prozessgestaltung und -defintion des Eröffnungsprozesses ist daher von entscheidender Bedeutung.

Übersicht

Die nachfolgende Abbildung zeigt schematisch auf, welche Themen und Regularien es beim Eröffnungsprozess zu berücksichtigen gilt. Da im Normalfall eine Eröffnung einer Geschäftsbeziehung mit einer oder mehreren Produkteröffnungen verbunden ist, enthält die Abbildung auch eine Auswahl an produktspezifischen Anforderungen. Die Abbildung erhebt keinen Anspruch auf Vollständigkeit. Aus meiner Sicht ist aber gut ersichtlich, dass der Eröffnungsprozess bei Banken stark reguliert ist. Die ganze Komplexität lässt sich so einfach natürlich nicht darstellen (sonst wäre es kaum komplex). Ein paar der Regulatorien sind relativ linear und von geringem Umfang. Andere wiederum sind schon für sich allein komplexe Konstrukte mit vielen Ausprägungen, Ausnahmen und mehr oder weniger Interpretationsspielraum.

Dazu kommt, das ist aus der Abbildung auch nicht ersichtlich, dass immer mehr Regulatorien auf andere verweisen oder noch schlimmer, zwar verweisen, aber dann doch noch eigene Ausnahmen dazu spezifizieren. Ein Beispiel ist der wirtschaftlich Berechtigte aus der GwG/VSB. Dieser wird bspw. auch im Zusammenhang mit dem Thema Steuern verwendet - aber nicht immer im exakt gleichen Sinn:

Hier können Sie die Abbildung als Excel-Sheet herunterladen. Und hier können Sie das Bild in Originalgrösse ansehen.

Konsequenzen

Die Konsequenz ist die, dass die Banken den Eröffnungsprozess standardisieren und technisch unterstützen müssen. Für einen durchschnittlichen Kundenberater ist es kaum möglich, all diese regulatorischen Anforderungen ohne Hilfsmittel bei jeder Kundenneueröffnung korrekt anzuwenden. Verständlicherweise hätten wohl bereits viele Mühe damit, alle betroffenen Regulatorien aufzuzählen. Schliesslich hat ein Kundenberater pro Jahr nicht all zu viele Spezialfälle. Entsprechend fehlt auch das praktische Training für solche Konstelationen. Der Schweizer aus dem Nachbarsdorf der ein Lohnkonto eröffnen will, dürfte kein Problem darstellen.

Lösungsansätze

Nun wie kann man denn einen Kundenberater wirkungsvoll unterstützen? Die Prozessmodellierung und Abbildung in einem UML-Diagramm kostet zwar etwas Aufwand, dürfte aber keine unlösbare Aufgabe sein. Nur wird ein Kundenbertater in der täglichen Arbeit wohl kaum wirkungsvoll damit arbeiten können.

Eine wirkungsvolle Unterstützung findet auf zwei Ebenen statt. Die meisten Abklärungen und Informationen aus dem Eröffnungsprozess gelangen irgendwie auf irgend ein Formular, welches der Kunde unterzeichnen muss. Eine Ebene sind diese Formulare. Diese müssen sowohl Kunden- wie auch Kundenberaterfreundlich gestaltet sein. Der Kundenberater muss diese Formulare überprüfen und sie daher rasch verstehen können. Es hat sich in der Praxis bewährt, dass die Kunden-Unspezifischen Vertragstexte wie AGB, Depotreglement, Spesenreglement, Kartenreglement etc. separat von den Kunden-Spezifischen Dokumenten wie dem Eröffnungs- oder Basisvertrag, dem Kartenantrag etc. gehalten sind. Die Kunden-Spezifischen Dokumente werden dadurch übersichtlicher und können besser kontrolliert werden. Die Kunden-Unspezifischen Verträge muss der Kundenberater inhaltlich nicht überprüfen (der Kundenberater liest sich nicht bei jedem Neukunden die AGB durch).

Die andere Ebene ist das Ausfüllen all dieser Unterlagen. Es ist noch nicht all zu lange her, da haben die Kundenberater bei vielen Banken diese Formulare noch (einzeln) in MS Word ausgefüllt. Ich habe selber solche Unterlagen noch einzeln mit der (elektrischen) Schreibmaschine getippt (wie praktisch doch die Speicherfunktion für die Adresse war ...). Heute werden all diese Daten direkt in den Systemen erfasst und anschliessend werden die notwendigen Unterlagen ausgestellt.

Damit der Kundenberater wirkungsvoll bei der Datenerfassung unterstützt wird, drängen sich Assistenten auf. Damit meine ich, dass die Software Erfassungs-Dialoge zur Verfügung stellt, welche die Business-Rules implementieren. Abhängig von den bereits gemachten Erfassungen zeigt der Assistent die folgenden Erfassungsmasken an. Das Ziel dabei ist, dass der Kundenberater so wenig Daten wie möglich erfassen muss, aber alle notwendigen Informationen hat. Erfasst der Kundenberater bspw. einen US-Pass als VSB-Identifikationspapier, so kommen zusätzliche Dialoge zum US-Steuerrecht, welche nicht erscheinen, wenn es keine Hinweise auf eine US-Steuerpflicht gibt.

Wichtig: Das Thema ist Kundenneueröffnung. Dennoch darf nicht vergessen gehen, dass sich viele Informationen im Laufe der Geschäftsbeziehung ändern können (Beispiel: Kunde zieht ins Ausland). In dem Fall muss mindestens ein Teil der Prüfungen aus dem Eröffnungs-Assistenten erneut durchlaufen werden. Daher sollte bei der Implementierung solcher Assitenten auf die Modularisierung geachtet werden, so dass eine (Teil-) Wiederverwendung problemlos möglich ist.

Bei Mutationen von bestehenden Kunden stellt sich die Frage, wann dann dieser Teil-Eröffnungs-Assistent erscheinen soll. Dazu gibt es grundsätzlich zwei Möglichkeiten:

1) Synchron direkt bei der Mutation. Das heisst, dass bspw. die Adresse nur über den "Eröffnungs-Assistenten" geändert werden kann, mit Direkteinstieg beim Punkt "Adress-Erfassung".

2) Asynchron nach einem Compliance-Check. In dem Fall kann die Adresse in einem "normalen" Adress-Mutationsdialog geändert werden. Ein Trigger löst anschliessend einen Compliance-Check aus. Dieser überprüft, ob auf Grund der Änderung der "Eröffnungs-Assistent" erneut durchlaufen werden muss oder nicht und generiert bei Bedarf einen entsprechenden Task.

Ich persönlich favorisiere zurzeit (vielleicht ändert sich dies noch) die Variante 2. Und zwar aus folgenden Gründen:

1) Die Entwicklung ist atomarer und daher weniger komplex.
2) Die einzelnen Mutationen können schneller vorgenommen werden.
3) Viele Mutationen haben keinen Einfluss auf die Compliance. Die meisten Adress-Änderungen sind bspw. im Inland. Es ist daher wohl etwas übertrieben, den Kundenberater jedes Mal durch einen Assistenten zu jagen.
4) Der Assistent kann weniger komplex entwickelt werden, weil es weniger Ausnahmen braucht. Beispiel Adresse: Jemand ist ins Ausland gezogen. Die Post muss sofort ins Ausland gesendet werden, die zusätzlich notwendigen Abklärungen können aber nicht unmittelbar gemacht werden (der Kunde ruft nächste Woche an ...). Den Assistenten kann man daher noch gar nicht abschliessen, die Adresse muss aber dennoch gültig erfasst werden können.

Konklusion

Basierend auf einer fundierten Analyse kann man mittels modularer Entwicklung unter Einbezug von Business-Rules eine robuste, nachhaltige und kosteneffiziente technische Unterstüzung für den Eröffnungsprozess realisieren, welche die Effizienz steigert und die Fehlerrate senkt. Für eine optimale Formular- und Vertragsgestealtung ist die Fachstelle Legal und/oder Compliance zuständig. Software-Entwicklung und Legal/Compliance tun im Interesse der Bank gut daran, eng und konstruktiv zusammen zu arbeiten. Und last but not least, muss auch das Business frühzeitig gut integriert werden. Denn was nützt eine optimale Lösung, welche im Alltag nicht korrekt genutzt wird?

Neue Regulierungen mit starkem IT-Bezug

Stand per Ende Januar 2014

Ausgangslage

Die meisten regulatorischen Anforderungen für Banken haben früher oder später einen Berührungspunkt mit der IT. Die einen mehr, die anderen weniger. Nachfolgende Übersicht dient IT-Mitarbeitern, sich ein Bild über die aktuellen und künftigen regulatorischen Anforderungen zu machen, wo die IT eine relativ grosse/wichtige Rolle spielt oder spielen sollte.

Die wichtigsten aktuellen und neuen Regulierungen

Abgeltungssteuer (IQG)

Regulierungsstufe: Abkommen (CH-AT, CH-GB), Gesetz (IQG) und ESTV-Wegleitungen
Status: Zu einem grossteil umgesetzt
Stichworte: Steuereinzung mit abgeltender Wirkung für Östereich und Grossbritannien.
Beteiligung IT: Vorwiegend Datenerhebung Vergangenheit, Datenmapping und Steuerberechnung (resp. Schnittstelle zu Steuerrechner) und Reporting.
Aufwand IT: Je nach Anzahl betroffeneKunden und angebotene Produkte: Wenig bis viel.
Links: http://www.sif.admin.ch/themen/00502/00758/index.html?lang=de

US Steuerprogramm für Schweizer Banken (US-Steuerstreit)

Regulierungsstufe: Joint-Statement (CH-US), Verordnung (BR) und Vertrag DOJ (Bank-US)
Status: In Umsetzung
Stichworte: Bereinigung der Altlasten von nicht versteuertem US-Vermögen und Einkommen mit den USA (DOJ).
Beteiligung der IT: Vorwiegend Datenanalysen für die Indiziensuche und die Ermittlung der Vermögen zu bestimmten Zeitpunkten.
Aufwand IT: Von Bank zu Bank sehr unterschiedlich (je nach Grösse, Anzahl US-Kunden und Exponierung)
Links: http://www.sif.admin.ch/themen/00502/00806/index.html?lang=de

FATCA (Foreign Account Tax Compliance Act)

Regulierungsstufe: Abkommen (CH-US), Gesetz (FATCA-Gesetz), Vertrag mit IRS (Bank-IRS)
Status: In Umsetzung (Referendum kam nicht zustande), in Kraft per 01.07.2014
Stichworte: Identifikation und Offenlegung US-Personen, allenfalls Quellensteuerabzug
Beteiligung der IT: Programme zur einmaligen und wiederkehrenden Indiziensuche, erweiterte Datenerfassung (bspw. Geburtsort), Überwachung von Vermögenswerten (Limiten), allenfalls Quellensteuerberechnung und Abzug, Reporting für Meldung an IRS.
Aufwand IT: Je nach Bankgrösse und Kategorie: Mittel bis viel.
Links: http://www.sif.admin.ch/themen/00502/00807/index.html?lang=de

Operationelle Risiken: Schutz von Kundendaten (CID)

Regulierungsstufe: FINMA-Rundschreiben (FINMA-RS 08/21, Anhang 3)
Status: In Umsetzung, in Kraft per 01.01.2015
Stichworte: Technischer Schutz von Kundendaten, Protokollierung, Überwachung und Ausbildung von Mitarbeitern und externen Partnern.
Beteiligung der IT: Vorwiegend Implementierung von neuen Schutzmechanismen für Kundendaten sowie neue zusätzliche Zugriffs-Protokollierungen.
Aufwand IT: Je nach eingesetzer Softwarelösung und Architektur: Wenig bis mittel.
Links: http://www.finma.ch/d/regulierung/Documents/finma-rs-2008-21.pdf
http://ronnyfuchs.blogspot.ch/2014/01/finma-rs-200821-anhang-3-aufgabenliste.html

Liquiditätsvorschriften

Regulierungsstufe: Gesetz, Verordnung und Rundschreiben (insb. LiqV und FINMA-RS)
Status: In Vernehmlassung, voraussichtlich in Kraft per 01.01.2015, abgestufter Erfüllungsgrad vom 01.01.2015-01.01.2019
Stichworte: Neuer Liquiditätsausweis, LCR
Beteiligung IT: Vor allem Datenschnittstelle (Core-System zu Drittanbieter), allenfalls neue Felder und Logik bei Produkten (Durchsetzung Kündigungsfristen).
Aufwand IT: Je nach verwendetem Core- und Drittsystem: Wenig bis mittel.
Links: http://www.finma.ch/d/aktuell/Seiten/mm-rs-liquiditaet-banken-20140117.aspx

GwG-Revision (Umsetzung GAFI-Empfehlungen)

Regulierungsstufe: Gesetzt (GwG) und Verordnung (GwV)
Status: Vernehmlassung abgeschlossen, voraussichtlich in Kraft per 01.01.2015
Stichworte: Meldepflicht für Inhaber- und Namenaktionäre von nicht-börsenkotierten Firmen, Identifikationspflicht und risikobasierte Sorgfaltspflichten bei CH-PEPs, Einführung im Strafgesetzbuch einer neuen Vortat zur Geldwäscherei (Tax-Crime)
Beteiligung IT: Automatische Erkennung von CH-PEPs, Anpassungen/Erweiterung der TmeR-Algorhythmen für Tax-Crime, Anpassungen an elektronischen Formularen, Eröffnungsdialogen etc. Ggf. neue Datenfelder.
Aufwand IT: Je nach verwendeter Software: Wenig bis Mittel.
Links: http://www.admin.ch/ch/d/gg/pc/documents/2331/GwG_Entwurf_de.pdf

VSB-Revision (VSB15 oder 16)

Regulierungsstufe: Selbstregulierung als Mindeststandart (VSB)
Status: Offen, hängt von der in Kraftsetzung der GwG-Revision ab.
Stichworte: Vorallem Konkretisierung der neuen Sorgfaltsplfichten in Bezug auf Tax-Crime.
Beteiligung IT: Anpassung elektronischer Dokumente, ggf. neue Datenfelder, Anpassung Eröffnungs-Workflow
Aufwand IT: Wahrscheinlich eher wenig.
Links: ---

FIDLEG (Finanzdienstleistungsgesetzt, eine Art MiFID der Schweiz)

Regulierungsstufe: Gesetz
Status: Offen, Vernehmlassung zum Hearingbericht ist abgeschlossen
Stichworte: Kundenschutz bei Finanzdienstleistungen und -Produkten.
Beteiligung IT: Nach aktuellem Stand vor allem im Bereich Kundenprofil, Protokollierung und Überwachung (passen Transaktionen zum Kundenprofil und der Protokollierung etc.)
Aufwand IT: Noch schwer abzuschätzen.
Links: http://www.efd.admin.ch/dokumentation/medieninformationen/00467/index.html?lang=de&msg-id=47816

Finanztransaktionssteuer

Regulierungsstufe: Ausländische Gesetzgebung
Status: Frankreich (2012) und Italien (2013) eingeführt/umgesetzt, 11 EU-Staaten haben einer Einführung zugestimmt
Stichworte: Transaktionssteuer, FTT, Verkehrssteuer
Beteiligung IT: Anpassung an Steuermodulen, Einbindung der relevanten externen Steuerdaten, Anpassungen an Kundenbelegen, Anpassung/neue Reportings für die Abrechnung und Abführung
Aufwand IT: Je nach eingesetzter Lösung und Lösungsansatz (bspw. Abwicklung entsprechender Geschäfte über Drittbanken) wenig bis mittel.
Links: http://de.wikipedia.org/wiki/Finanztransaktionssteuer

Bundesgesetz über die Finanzmarktinfrastruktur (FinfraG)

Regulierungsstufe: Gesetz
Status: Vernehmlassung (bis Ende März 2014)
Stichworte: Regulierung der Finanzmarktinfrastrukturen, insb. Derivatenhandel. Betrifft grundsätzlich alle Markteilnehmer, welche mit Derivaten handeln.
Beteiligung IT: Vor allem Unterstützung. Bspw. Auswahl Handelsplatz, Kundenidentifikation, Reporting und Kontrolle.
Aufwand IT: Kommt stark darauf an, wie viele Kunden (keine nat. Personen) betroffen sind und wie gross der Eigenhandel ist. Wenig bis mittel.
Links: http://www.admin.ch/ch/d/gg/pc/documents/2287/FinfraG_BG_de.pdf

Rechtzeitig mit der Umsetzung beginnen

Wie ich in meinem Blog-Beitrag hier beschrieben habe ist es wichtig, dass mit der Umsetzung rechtzeitig begonnen wird. Dabei ist es wichtig, dass das Management so früh als möglich die weichenstellenden Entscheidungen trifft. Anschliessend muss die IT-Führung die IT-strategischen Entscheidungen fällen. Sodann ist in der Umsetzung zu unterscheiden, was die Regel und was die Ausnahme ist.

Erste Analyse der geplanten Volksinitiative "Vollgeld-Inititative"

Ausgangslage

Der Verein monetäre Modernisierung plant eine Volksinitiative, mit welcher er das Vollgeld-Konzept in der Schweiz einführen will (http://www.vollgeld-initiative.ch/). Letztes Jahr habe ich in einem Beitrag beschrieben, wie die Geldschöpfung der Geschäftsbanken funktioniert. Sich einmal ein anderes monetäres Konzept anzuschauen hilft oft, das aktuelle besser zu verstehen. Aus diesem Grund habe ich mir den Initiativtext einmal angeschaut.


Vollgeld versus Schuldgeld

Unser jetziges Konzept ist ein Schuldgeld-Konzept. Das Geld ist aus Sicht des Schöpfers eine Schuld. Die SNB schöpft die Banknoten bspw. mit dem Buchungssatz: Aktiven / Notenumlauf. Somit ergibt sich, dass der Wert des heutigen Geldes auf der Bilanz-Aktivseite des Schöpfers steht. Vollgeld hingegen ist schuldfrei und daher ein eigenständiger Wert wie bspw. Gold. Als solcher Wert wird es in die Bilanz aufgenommen. Entsprechend kann Vollgeld nur auf der Bilanz-Aktivseite stehen. Da Vollgeld theoretisch unbeschränkt geschöpft werden kann und damit kein realer Wert verbunden ist, ist der Begriff m.E. etwas irreführend. Um das zum Ausdruck zu bringen, wird es von verschiedenen Autoren auch als "Leergeld" bezeichnet.


Umsetzungsvariante

Unabhängig davon, ob das Vollgeld-Konzept besser als das Schuldgeld-Konzept ist, präsentiert sich die von den Initianten vorgeschlagene Umsetzung als Lückenhaft und widersprüchlich. Buchgeld und Vollgeld werden vermischt (Buchgeld kann nicht Vollgeld sein), eine elektronische Variante des Vollgeldes fehlt komplett. Der Zahlungsverkehr scheint nicht ganz zu Ende gedacht zu sein.

Das jetzige Finanzsystem hat seine Schwächen und die wurden leider bereits mehrmals ausgenutzt. Die Aktivitäten der Initianten sind als Beitrag zur Diskussion wie das gegenwärtige System stabilisiert werden kann zu begrüssen. Die vorgeschlagene Umsetzungsvariante der Initianten scheint mir derzeit aber zu wenig durchdacht zu sein.

Die vollständige Analyse können Sie hier herunterladen.

Neue regulatorische Anforderungen: Umsetzung in der IT wird zunehmend komplexer

Ausgangslage

Die Umsetzung neuer oder geänderter regulatorischer Anforderungen wird zunehmend komplexer. Weshalb ist das so? Dafür gibt es mehrere Gründe:

Einer davon ist sicher, dass die Anforderungen zunehmend mehr Themen verknüpfen. Ein Beispiel ist die Einlagensicherung. Zu Beginn musste die Bank einfach in der Lage sein, die entsprechenden Zahlen (Beträge pro Person) innert nützlicher Frist zu liefern. Dazu war vielleicht der eine oder andere manuelle Schritt notwendig (bspw. die Berücksichtigung der Nummernkunden, oder bei den Vorsorgegeldern etc.). Nun muss mind. ein Teil dieser Information auch im LCR verwendet werden. Das bedeutet, dass auch der umgesetzte Mechanismus der Einlagensicherung ggf. angepasst werden muss, was wiederum ein Testing etc. Bedarf. Oder die Information des wirtschaftich Berechtigten nach VSB wird nun auch für die Steuerthemen relevant. Die Steuerdaten werden aber vielleicht in einem separaten System gepflegt, wodurch es eine neue Schnittstelle braucht. Die Liste könnte weiter fortgeführt werden.

Ein weiterer Grund basiert teilweise auf dem ersten: Die Systeme werden immer komplexer. Es braucht immer mehr Schnittstellen, weil immer mehr Daten und Funktionen geteilt werden müssen. Zugleich kann man je nach System aus zeitlichen Gründen nicht immer alles architektonisch perfekt lösen. Damit schafft man sich Restanzen (Architektur-Defects), mit denen man sich dann früher oder später wieder herumschlagen muss.

Schliesslich werden die Anforderungen nicht weniger, zumal auch die Umsetzungsdauer mind. teilweise länger wird. Dadurch muss parallel an verschieden Anforderungen gearbeitet werden, was automatisch zu mehr Komplexität führt (dies vor allem auch im IT-Betrieb und der Organisation).

Zusätzliche Problemstellungen

Mit all dem würde eine gute Softwareentwicklung (mit einem guten IT-Betrieb) in aller Regel noch gut zurecht kommen. Wären da nicht auch noch die oft hausgemachten Probleme.

Und davon gibt es gleich drei:
1) Oftmals und immer mehr, gerade als kleinere Bank, hat man verchiedene Umsetzungsvarianten. Man kann es vollständig umsetzen, man darf unter gewissen Umständen gewisse Anforderungen weglassen, oder man kann  sich durch Verzicht (bspw. auf ein Geschäft, ein Produkt oder eine Kundengruppe) fast ganz aus der Affähre ziehen. Diese Entscheidung liegt aber beim Management. Und das Problem entsteht dann, wenn die Verantworltichen nicht oder sehr spät entscheiden. Nämlich dann, wenn man mit der Umsetzung bereits beginnen musste.

2) Das kennen alle: Verändernde Anforderungen bedeuteten schon vielen Projekten den zeitlichen oder finanziellen Tod. Die Fachverantwortlichen können sich ebenfalls nicht entscheiden oder befassten sich eingangs zu wenig mit der Materie und stellen dann später fest, dass es so nicht wie gewünscht funktioniert.

3) Es wird nicht unterschieden zwischen Use-Cases die oft vorkommen (die Regel) und solchen die (sehr) selten vorkommen (die Ausnahme). Die Regel muss technisch elegant sein und den Benutzer maximal unterstützten. Die Ausnahme wird nicht selten von einem Fachspezialisten behandelt und darf technisch ruhig etwas weniger elegant sein. Oftmals definieren aber die betroffenen Fachspezialisten die Anforderungen und die sehen natürlich nur die Ausnahmen, mit denen sie dann später zu tun haben werden.

Lösungswege

Die Lösung habe ich natürlich auch nicht. Sonst würde ich kaum diesen Blog schreiben (sondern mich in der Sonne bräunen). Die nachfolgende Grafik dient den auch mehr als Denkanstoss wie es sein könnte.

Sie können das Bild hier grösser herunterladen.

Es sind alle Beteiligten gefordert. Wenn das Management zu Beginn (1) rechzeitig die wichtigen Entscheidungen fällt, die IT-Entwicklung (2) vorausschauend definiert wie die Architektur ausschauen soll und man sich bei der konkreten Umsetzung (3) mit den Fachabteilungen rasch darauf einigt, was die Regel und was die Ausnahme ist, dann können auch immer komplexere regulatorische Anforderungen in angemessener Zeit, der richtigen Qualität und zu vernünftigen Kosten umgesetzt werden.

Versuchen Sie doch beim nächsten Umsetzungsprojekt, alle Beteiligten bei Projektbeginn für die Wichtigkeit dieser drei Elemente zu sensibilisieren.

FINMA-RS 2008/21, Anhang 3: Aufgabenliste und Musterweisung als Hilfestellung

Ausganslage

Der Anhang 3 vom FINMA-RS 2008/21, Umgang mit elektronischen Kundendaten, tritt per 01.01.2015 in Kraft. Bis dahin müssen die Anforderungen umgesetzt resp. einsatzbereit sein. Über ein Jahr Zeit für die Umsetzung scheint eine komfortable Dauer zu sein. Dabei dürfen folgende Aspekte nicht ausser Acht gelassen werden:

• Für gewisse Anforderungen sind ggf. Vertragsanpassungen mit Business-Partner (B2B, insb. Outsourcing) notwendig. Dazu müssen wahrscheinlich gewisse Kündigungsfristen eingehalten werden.
   
• Ein paar Anforderungen erfordern ein interdisziplinäres Vorgehen innerhalb der Bank, was erfahrungsgemäss mehr Zeit in Anspruch nimmt.
   
• Schliesslich ist die Umsetzung dieses Anhangs nicht die einzige Regulatorische Anforderung im Jahr 2014, welche es umzusetzen gilt. Das US Steuerprogramm und FATCA sind nur zwei Beispiele. Die Ressourcen bei den Banken dürften entsprechend knapp sein.
   

Zuständigkeit und Umfang

 
Aus meiner Sicht liegt der Aufwand in der Umsetzung nicht primär in der IT, sondern mehr bei der Organisation. Der Aufwand ist denn auch mehrheitlich nicht primär von der Softwareentwicklung zu erwarten, sondern von Zusammenarbeit und Beschlussfassung. Es gibt doch die eine oder andere Frage die zwischen verschiedenen Stellen (Compliance, Software-Entwicklung, Betrieb, HR etc.) besprochen werden sollte. Schliesslich sind auch Business-Partner (Outsourcing) betroffen, welche in Entscheidungen zu Anforderungen involviert werden müssen.

Wie gross der Aufwand für die Umsetzung ist, hängt stark von der jetzigen Organisation der Bank, deren Grösse und eingesetzter IT/Software ab. Unabhängig vom effektiven Gesamtzeitaufwand darf die Dauer auf der Zeitachse nicht unterschätzt werden. Das Vorhaben lässt sich auch mit höchster Priorität wohl kaum innerhalb 5-8 Wochen umsetzen (mit Vertragsanpassungen etc.). Deshalb sollte man möglichst früh mit der Umsetzung beginnen.

Hilfestellung (Aufgabenliste und Musterweisung)

 
Ich habe aus diesem Anhang 3 in einem ersten Schritt insgesamt 48 Aufgaben identifiziert (ohne Gewähr für Vollständigkeit). Diese habe ich in einer Aufgabenliste zusammengefasst und mit einer möglichen, aus meiner Sicht sinnvollen und realistischen, Terminplanung versehen. Weiter habe ich eine neutrale Musterweisung erstellt. Diese korreliert mit der Aufgabenliste und dient ebenfalls als Checkliste für eine Bank.

Ich bin überzeugt, dass sich die Anforderungen bei rechtzeitigem Beginn und mit einer gut funktionierenden Projektorganisation relativ schlank umsetzen lassen.

Die komplette Aufgabenliste im MS Excel-Format mit Kommentaren können Sie hier kostenlose herunterladen.

Die Musterweisung im PDF-Format können Sie hier kostenlos herunterladen.