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.