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.