Regelungen von IT‑Anwendungen: Umsetzung von Normierungsansätzen in der Finanzberatung

In der Finanzberatung sind eine Vielzahl von Regelungen zum Beispiel zur Einschätzung der Risikosituation des Kunden, zur Erhebung des Kundenbedarfs, zur Produktaufklärung und Dokumentation des Beratungsgesprächs einzuhalten (vgl. u.a. VVG oder WpHG). Eine Norm im engeren Sinne stellen diese Regelungen jedoch nicht dar.  Mit den DIN-Spezifikationen SPEC 77222 „Standardisierte Finanzanalyse für den Privathaushalt“ und DIN SPEC 77223 „Standardisierte Vermögens- und Risikoanalyse“ ist jedoch eine Vorstufe einer DIN-Normierung erreicht, die 2017 zu einer Norm für die Finanzberatung führen soll. Im Folgenden wird am Beispiel der DIN SPECs beschrieben, wie ein enger „normierter“ Rahmen zur Finanzberatung bestehend aus einer Vielzahl einzelner Regelungen im Rahmen von IT-Anwendungen umgesetzt werden kann.

Professor Dr. Philipp Janetzke

Es ist absehbar, dass Bedeutung und Komplexität normnaher Regelungen, Standards bzw. Vorschriften in der Finanzdienstleistungsindustrie aufgrund der hohen Regulierungsintensität weiter an Gewicht gewinnen werden. Die Digitalisierung von Beratungsprozessen und Finanztransaktionen sowie die zunehmende Verbreitung von Selbstberatungsanwendungen für Kunden – Stichwort „Robo Advice“ – erfordern zudem eine stärkere Standardisierung und Automatisierung von Beratungsabläufen, für die sich Normen oder normnahe Ansätze eignen.

Fachliche Erläuterung der DIN SPEC 77222 und 77223

Die DIN SPEC 77222 ist ein fachliches Regelwerk, das Mindeststandards für umfassende Finanzberatungen privater Haushalte auf den Themenfeldern Altersvorsorge, Gesundheitsvorsorge, Sachversicherung und Kapitalaufbau definiert. Die DIN SPEC 77223 umfasst darüber hinaus Regeln zur Definition von Mindeststandards für eine Kapitalanlageberatung.

Ein Finanzdienstleister, der zukünftig damit werben will, dass seine Finanzberatung den Qualitätsansprüchen einer DIN-Norm genügt, wird nachweisen müssen, dass er die in der Norm definierten Standards nachhaltig erfüllt. Dabei steht es jedem Unternehmen offen, die fachlichen Beratungsregeln der DIN SPECS durch unternehmensspezifische Regeln zu ergänzen, bspw. um effiziente Prozesse zu gewährleisten oder betriebsorganisatorische Besonderheiten wie heterogene Provisionsstrukturen im Regelsystem abzubilden. Es mag in bestimmten Konstellationen auch betriebswirtschaftlich sinnvoll sein, auf eine offizielle DIN-Zertifizierung zu verzichten und die Normen nur in Teilen umzusetzen. Kurzum: Die DIN SPECs alleine determinieren noch nicht die konkrete Umsetzung.

Die fachlichen Regeln lassen sich strukturell in Meta-  und Detailregeln unterteilen. Metaregeln bilden den Rahmen, da sie Regeln über Regeln darstellen, d. h. Regeln, wie mit den Detailregeln umzugehen ist und wie diese zu strukturieren sind. Beispielsweise gliedern die Metaregeln den Haushaltsbedarf in drei Bedürfnisstufen und priorisieren die Bedürfnisse danach tiefergehend (vgl. Tab.1).

Die Anzahl der Regeln ist abhängig von der Anzahl der zu beratenen Themengebiete, der Produkte, der unternehmensspezifischen Besonderheiten und auch der Anzahl möglicher Kommunikationskanäle (z. B. Internet, Mobile, Filiale/Agentur) und den daraus ableitbaren Varianten. Eine Übersicht der verschiedenen Regeltypen ist in Abb. 1 zu sehen.

Für die IT-Umsetzung bieten die DIN SPECs aufgrund ihrer genauen fachlichen Beschreibung eine gut strukturierte Ausgangslage. Der Ablauf der Datenerhebung in der Interaktion mit dem Kunden sowie die Anwendung des fachlichen Regelwerks können in der IT automatisiert werden und führen so zu Beratungsergebnissen mit einheitlich hohem Qualitätsstandard.

Die IT-Umsetzung

Technisch kann zwischen der Umsetzung durch klassische objektorientierte Programmierung oder – im Sinne eines Ansatzes aus der Künstlichen Intelligenz (KI) – in Form von Regelwerken gewählt werden. Vor- und Nachteile der beiden Ansätze sind in der folgenden Tab. 2 gezeigt.

Die Transparenz in der Umsetzung durch ein Business-Rule-Management-System (BRMS) ist hoch, da Fachanwender (bspw. auch Rechtsabteilung, Compliance usw.) die Regeln in verständlicher Form, also in Sätzen, Entscheidungsbäumen oder Tabellen, vorfinden und ggfs. selbst ändern können. Der direkte Blick in den Programmcode einer objektorientierten Umsetzung ist hingegen für den Fachanwender weniger geeignet.

Die Komplexität der Regelwerke ist unabhängig von der gewählten Lösungsvariante hoch.

Die Performance einer programmierten Lösung ist typischerweise höher, wenngleich auch bei BRMS mit verschiedenen Mechanismen eine hohe Performance sichergestellt werden kann: So erzeugen die BRMS aus jeder einzelnen Regel zum Beispiel Java-Code, der schneller ausgeführt werden kann als eine langsame Regelinterpretation. Die gesamthafte Auswertung der Regeln erfolgt zudem über geeignete, performante Algorithmen, z. B. dem optimierten und patentierten Vorwärtsverkettungs-Algorithmus von Oracle bei dem BRMS Oracle Policy Automation (OPA). Zudem erhöht die Skalierung über die Hardware auf Serverseite den Durchsatz.

Softwarebasierte Testunterstützung gibt es zu beiden Entwicklungsansätzen.”

Die Umsetzung mit BRMS bietet insgesamt mehr Transparenz und eine einfachere Pflege der fachlichen Inhalte, Performance-Nachteile konnten in den letzten Jahren weitgehend beseitigt werden.

Software-Auswahl zur Implementierung der Regelwerke

Open Source BRMS bieten einen günstigen Einstieg in die Welt der Regelwerke. Allerdings erfordern diese Anwendungen wie bspw. Drools[2] ein hohes Maß an Einarbeitung und die Umsetzung hat letztlich eine hohe Ähnlichkeit mit klassischem Code, der in den Regelbeschreibungen verwendet wird.

Kommerzielle Lösungen bieten eine bessere Usability und reduzierten Pflegeaufwand. So setzt bspw. Bosch Software Innovations mit Visual Rules BRM[3] auf die transparente Darstellung von Entscheidungsbäumen bei der Regelbeschreibung. OPA von Oracle[4] geht noch einen Schritt weiter und erlaubt die Regeldefinition mit Word und Excel, also auch mit den meisten Fachanwendern gewohnten Anwendungen. Kommerzielle Anwendungen bieten zudem zusätzliche Werkzeuge zum Testen von Regeln, Debugging oder Deployment, die für professionelle Anwendungen üblich sind.

Kommerzielle Lösungen sind zwar in der Anschaffung deutlich teurer, bieten aber gerade bei größeren Anwendungen den Vorteil, dass Erstellung und Pflege großer Regelwerke im späteren Betrieb ressourcenschonender möglich sind.

Formulierung von Regeln

Üblicherweise sind die Regeln vom Typ WENN-DANN-Klausel, z. B. WENN der Kunde vom Risikotyp „niedrig“ ist, DANN sind nur Anlagen der Klasse 1 oder 2 erlaubt. Im WENN-Teil wird die Bedingung formuliert, im DANN-Teil findet entweder das Setzen von Variablen statt oder es werden Aktionen angestoßen. Zur besseren Visualisierung haben sich auch tabellenartige Darstellungen oder Baumdiagramme etabliert.

In Abb. 2 ist die Formulierung einer Metaregel mit Drools zu sehen. Dabei wird deutlich, dass das Grundgerüst der Regel „Prio-Teilbedarfsfelder“ aus einem „when“- und einem „then“-Teil besteht, hier also die Regeln mit den sogenannten Wenn-Dann-Klauseln modelliert werden. Metaregeln sind von der Art komplexer, in diesem Fall die Priorisierung der Teilbedarfsfelder gemäß der Schadenshöhe in Prozent. Die Teilbedarfsfelder werden in Listen eingetragen und nach ihrer Priorität sortiert. Drools erlaubt auch die Vermeidung von Wiederholungen der Regelprüfungen „no-loop“ und die Vergabe von Regelprioritäten selbst „salience“.

Die Formulierung von Detailregeln mit OPA ist in Tab. 3 und Abb. 3 zu sehen. In Tab. 3 wird die Produktkategorie für das Teilbedarfsfeld Pflege ausgewählt. In dieser Regel werden Scores verwendet, die für jede Produktkategorie vorab berechnet wurden. Abhängig von den Score-Werten wird dann die Produktkategorie Pflegekosten, Pflegerenten oder Pflegetagegeld ausgewählt. Die Regel heißt „AusgewähltesProdukt“ und ist in tabellarischer Form modelliert. Der Regeleditor ist Word, wobei die tabellarischen Regeln (gerade die größeren mit vielen Varianten) auch mit Excel erstellt werden können.

Die Formulierung einer Detailregel mit OPA in der Wenn-Dann-Klausel-Form, wie auch zuvor beschrieben mit Drools, ist in Abb. 3 zu sehen. Dargestellt ist der Auszug zur Regel zur Prüfung eines Förderanspruchs nach dem Altersvermögensgesetz (Riesterförderung). Ein Förderanspruch besteht, wenn der Kunde entweder Angestellter, Beamter oder Soldat auf Zeit ist. Bei Selbstständigen, geringfügig beschäftigten Personen ohne Erwerbseinkommen oder Studenten besteht der Förderanspruch, wenn ein Partner mit Anspruch vorliegt. Die Regel heißt „Der mögliche Bedarf des Kunden liegt im Produktsegment Riester“ und ist im Regeleditor Word erstellt.

 

Die grafische Modellierung mit dem Regeleditor von Visual Rules ist in Abb. 4 zu sehen. In der dargestellten Regel wird entschieden, welche Risikoklasse einem Kunden zuzuordnen ist (in Anlehnung an DIN SPEC 77223, S. 19). Dabei gibt es einen Regelkopf mit der Entscheidungsbedingung. Hier wird das Kriterium „Anteil sicherer Anlagen“ geprüft und abhängig davon die Risikoklasse festgelegt.

Bei der Regelentwicklung sollte auf die Modularisierung geachtet werden. Die Kapselung fachlich zusammengehörender Regeln vereinfacht später die Wartung, aber auch die Fehlersuche. Bei der Anwendung ist die Auswertung auch schneller, wenn nicht durch zu starke Vernetzung unnötig viele Regeln geprüft werden müssen. Da im Lauf der Zeit auch viele Versionen der Regeln entstehen, bieten die Rule-Engine-Frameworks auch eine Versionsverwaltung an. Dies ist regulatorisch relevant. So ist bspw. gegenüber Aufsichtsorganen nachzuweisen, zu welchem Zeitpunkt welche Regelversion aktiv war.

Management von Regelwerken

Für den systematischen Umgang mit Regelwerken wurde das Konzept des Geschäftsregel-Managements (GRM) entwickelt. Beim GRM werden geschäftsrelevante Regeln festgelegt und in einem Managementzyklus gepflegt (vgl. Abb. 5).

Als Optionen für das Projektmanagement sind dabei bei der Regelmodellierung sowohl die klassische Wasserfallmethode, in der aus den Fachbereichen unter Zugriff auf die DIN SPECs alle Regeln vollständig definiert und dann umgesetzt werden, als auch die agile Herangehensweise zu nennen. So könnte mit Scrum ein Themengebiet nach dem anderen (bspw. erst Altersvorsorge dann Sach-/Vermögensrisiko) umgesetzt werden. Der Gesamtrahmen durch die Metaregeln zur Priorisierung sollte dabei aber frühzeitig implementiert werden.

Nach der Modellierung müssen die Regelwerke produktiv gesetzt und überwacht werden.

Das Deployment wird von modernen Rule-Engines unterstützt. Typischerweise laufen die Runtime-Umgebungen der BRMS auf entsprechenden Servern und neue Regelversionen können (bei Bedarf) auch im laufenden Betrieb produktiv geschaltet werden. Ein Monitoring des laufenden Betriebs ist ebenfalls möglich.

Im exemplarischen IT-Architektur-Chart von Visual Rules sind die genannten Komponenten im Zusammenhang zu sehen (vgl. Abb. 6). Im Client, dem Modeling-Frontend, erfolgt die Modellierung und Analyse der Regeln. Im Zusammenspiel mit dem Builder des BRM-Servers ist dann das Testen und das Deployment möglich. Auch die gemeinsame Arbeit an den Regeln im Regel-Repositiory ist über entsprechende Collaboration-Werkzeuge möglich. Die Regelarchitekturen sind mandantenfähig und erlauben auch Angebote in Form von Web-Services, SaaS- bzw. Cloud-Diensten.

Fazit

Perspektivisch ist zu erwarten, dass Finanzberatung durch Regulatorik und entstehende Normen zunehmend standardisiert ablaufen wird. In diesem Zusammenhang entstehende Regelwerke, wie z. B. aus der DIN SPEC 77222, können über Business-Rule-Management-Systeme (BRMS) abgebildet und effizient implementiert werden. Die Wahl des BRMS wird beeinflusst durch die betriebsorganisatorischen und finanziellen Rahmenbedingungen, aber auch durch den dahinter stehenden Business Case. Eine Automatisierung der Auswertung der Regelwerke ermöglicht auch die weitere Digitalisierung bzw. die Einbindung von „Robo Advice“.Professor Dr. Philipp Janetzke

Literaturverzeichnis:

[1] Vgl. DIN SPEC 77222, S. 8
[2] Vgl. Drools; download vom 19.09.2016; http://www.drools.org/; Verwendung z. B. als Plug-In für die Entwicklungsumgebung Eclipse
[3] Vgl. Visual Rules BRM (Business Rules Management) von Bosch Software Innovations; Download vom 19.09.2016; https://www.bosch-si.com/de/produkte/business-rules-management/visual-rules-brm/regelmanagement.html
[4] Vgl. OPA (Oracle Policy Automation); Download vom 19.09.2016; http://www.oracle.com/us/products/applications/oracle-policy-automation/overview/index.html
[5] Umsetzung einer Metaregel in Drools durch die Firma Crealogix Elaxy, USB – Universelle Schnellberatung, Drools Umsetzung Erfahrung, S. 16)
[6] Nur intern: Quelle: OPA Projekt/ajco-Projektbeispiel
[7] Nur intern: Quelle: OPA Projekt/ajco-Projektbeispiel