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?