Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

09.02.1996 - 

Erfolgreiche Aussenseiterrolle

Die Dresdner Bank setzt beim Risiko-Management auf Objekte

"Das Wichtigste fuer den Erfolg dieses Projekts war die Bereitschaft, auch mal einen Schritt zurueckzugehen und neu anzusetzen", resuemiert Thomas Muessener, Abteilungsdirektor im Geschaeftsbereich Treasury, Eigenhandel, Markt-Risiko-Management bei der Dresdner Bank. Das galt im Projektverlauf sowohl fuer die Organisation als auch fuer die Technik selbst: "Die Flexibilitaet in der Objektorientierung erwies sich als ihr groesster Vorteil und als groesster Nachteil." Objekte zu ersinnen und zu programmieren war fuer das Projektteam etwas Neues.

"Frueher haben die Haendler ihre Kalkulationen auf der Basis von Spreadsheets gemacht", erlaeutert Muessener. Ein Financial Engineering habe jedoch viele Aufgaben zu erfuellen, von der Preisfindung ueber den Einsatz verschiedenster Finanzinstrumente bis hin zur Bewertung von Portfolios und Durchfuehrung des Risiko-Managements. "Bei uns besteht das ganze Leben aus Finanzmathematik; Spreadsheets reichen nicht aus. Wir brauchen eine Software, die Standards erfuellt, flexibel und portabel ist und nicht von jedem Haendler manipuliert werden kann."

Die Banker entwickelten mit dem PC-basierten Dbase-Werkzeug "Clipper" einen Prototypen. Zwar funktionierte anfangs alles "ganz wunderbar", doch schon bald stiess man an Grenzen. Zum einen erlaubte die prozedurale Struktur keine schnellen Erweiterungen oder Veraenderungen, zum anderen legte DOS dem System unnoetige Restriktionen auf. "Wir sahen schon recht frueh, dass wir mit einer objektorientierten Sprache weiterkaemen. Darueber hinaus waren wir ueberzeugt, dass C++ wesentlich performanter ist." Zusaetzlich sprach fuer C++, dass die Sprache weit verbreitet ist und das Projektteam ueber C-Kenntnisse verfuegte.

Die Funktionalitaet des Clipper-Prototyps sollte erhalten bleiben, die innere Struktur jedoch gaenzlich veraendert werden. Die Bank vergab das Projekt an einen externen C++-Spezialisten. Da dieses Softwarehaus jedoch keinerlei Kenntnisse im Financial Engineering hatte, mussten derart detaillierte Beschreibungen angefertigt werden, dass das Softwaredesign vernachlaessigt wurde. "Das behagte uns gar nicht", erinnert sich Muessener. Zunehmende Kommunikationsschwierigkeiten und "lange Wege" zwangen dazu, die Zusammenarbeit nach einem dreiviertel Jahr aufzugeben. "Wir haben die Vorleistungen uebernommen und komplett ueberarbeitet."

Das Projektteam wurde um sieben auf elf Mitarbeiter aufgestockt. Dabei waren C++-Kenntnisse gefragt. "Wir haben niemanden gefunden, der sowohl Kenntnisse im Programmieren als auch im Financial Engineering hatte", so Muessener. Schliesslich gab es ein PC-Team, das mit "Borland C++" arbeitete, und eine Unix-Gruppe, die "HP Softbench" einsetzte.

Wichtig fuer den Programmaufbau ist "die Abschottung" der Logik gegenueber Datenbanken, Oberflaechen, Drucker und Betriebssystemen. Man wollte eine Unabhaengigkeit erlangen, die es erlaubt, die Software in vielen Umgebungen laufen zu lassen. Um die Entwicklung zu verkuerzen und die Arbeit zu vereinfachen, entschied sich das Finanzinstitut fuer den Zukauf von Klassen. Durch diese Massnahmen hofft man, auch von kuenftigen Entwicklungen im Markt profitieren zu koennen.

Auf das Wesentliche der Anwendung konzentrieren

So existiert nur eine einheitliche Drucker-Schnittstelle. "Wir wollten uns nicht mit jedem Drucker auseinandersetzen, den es gibt", begruendet Muessener. Bei der Kommunikation mit Datenbanken beschraenkte sich das Team auf den Gebrauch von ANSI-SQL. Leider habe man die Schicht zu den Druckern und Datenbanken selber herstellen muessen. Doch waehrend zuvor auch Oberflaechen codiert wurden, setzen die Banker nun GUI-Bibliotheken von XVT ein, die eine Betriebssystem-Unabhaengigkeit erlauben.

Stars ++ besteht aus rund 500 Klassen und ist etwa 5 MB gross. Hauptmerkmale der Finanzprodukte sollten dabei folgenden objektorientierten Methoden entsprechen (siehe Abbildung):

- Grundlagen, die in jedem Programm verwendet werden koennen, finden sich in den Basisklassen.

- Produktvariationen sollten sich aus Vererbung und Spezifikation ergeben.

- Produktkombinationen erhaelt man, indem das Objekt oder die Klasse Optionen erhaelt und die Finanzinstrumente miteinander kombiniert werden.

- Polymorphismus eignet sich fuer globale Risiko-Management-Methoden; so weiss beispielsweise jedes Instrument, dass es einem Pricing unterliegt.

Basisklassen liefern in unterschiedlicher Komplexitaet einfache Dienste, wie Kalenderfunktionen (siehe Abbildung) oder Fenstertechniken. Die Fenster, die durch ein Skript beschrieben sind, dokumentieren sich selbst, so dass aus dem Skript heraus die Verbindung zur Klasse geschaffen wird. Die Klasse stellt die Verbindung zur Datenbank her. Durch dieses automatisierte Verfahren koennen die Haendler ihren Bildschirm individuell aufbauen, ohne dass jeweils Programmaenderungen vonnoeten sind.

Auf den Basisklassen setzen die finanz-mathematischen Klassen auf, die das Herz von Stars++ bilden und die gesamte Formelsammlung enthalten. Solche Klassen sind in der Lage, komplexe Strukturen zu erkennen, koennen sie auseinanderdividieren oder zusammensetzen, den Preis berechnen und Bewertungen vornehmen.

Die applikationsspezifischen Klassen enthalten im wesentlichen die Ereignissteuerungen. Ein Ereignis loest Aktionen des Programms per Tastatur oder ueber das automatische Datenfeed aus, etwa Wirtschaftsdaten von Reuters oder Kreditdaten, die der Grossrechner in flachen Strukturen an Benutzungsklassen ueberstellt. Von dort werden sie aufbereitet an die Applikationsklassen weitergegeben.

Drei grosse Probleme stellten sich dem Projektteam. Wie lassen sich sinnvolle Objekte finden und Klassen bilden? Wie koennen die Objekte miteinander kommunizieren? Wie lassen sie sich so dokumentieren, dass sie wiederauffindbar sind und Redunzanz ausgeschlossen ist?

Am einfachsten war die Dokumentationsfrage zu loesen. Hier setzt Muessener das CASE-Tool "OEW" von Innovative Software ein, "das wir ueber die Software laufen lassen". Jeder Entwickler ist gehalten, im Code sauber den Klasseninhalt zu beschreiben. "Wir sind heute in der Lage, zu jedem Zeitpunkt ein Handbuch auszudrucken, das den neuesten Stand der Entwicklung widerspiegelt", so der Abteilungsdirektor.

Dadurch, dass es in der objektorientierten Programmierung keine festen Regeln ueber die Anordnung von Objekten und den Informationsaustausch gibt, mussten die Entwickler zum Beispiel entscheiden, wo die Kommunikation lokalisiert werden soll. Die Muessener-Gruppe fuehrte fuer spezielle Finanzinstrumente- und Synchronisationsklassen Kommunikatoren ein. Diese stellen das Verbindungsglied dar.

Hier und beim Aufbau der Objektklassen kam das Projektteam ins Schleudern. Insbesondere in den Anfaengen gab es Verzoegerungen, und der ehrgeizige Zeitrahmen von zwei Jahren konnte nicht eingehalten werden. Trotzdem, so schaetzt Muessener, hat das gesamte Projekt einschliesslich der Hardware (HP-Workstation Serie 9000 und Windows-PCs) und Entwicklungs-Tools nur ein Zehntel dessen gekostet, was vergleichbare Bankprojekte sonst verschlingen. Begonnen wurde im Fruehjahr 1991; nun ist Stars ++ bereits zwei Jahre erfolgreich im Einsatz.

Fuehlte sich das Team zu Beginn erhoehtem Druck ausge- setzt, weil es die bekannte Softwarewelt auf den Kopf stellen wollte, sind heute auch die Skeptiker ueberzeugt, "und die Anwender sind begeistert", konstatiert Muessener. Allein in Frankfurt arbeiten etwa 70 Banker mit der Software, dazu kommen Mitarbeiter in den deutschen Niederlassungen in Tokio und New York.

Vor allem die Flexibilitaet bei Erweiterungen und Anpassungen des Programms, etwa durch den schnellen Wandel im Derivate-Bereich, traegt zur Akzeptanz bei. "Wir setzen lediglich die Grundstrukturen neu zusammen. Programmierung faellt kaum noch an", stellt Abteilungsdirektor Muessener fest. So sollte das Team eine Software entwickeln, die aus den Daten anderer Bereiche der Bank das jeweilige Marktrisiko qualifizieren konnte. "Dazu haben wir nicht einmal drei Monate gebraucht."

Kalender- und Kurvenfunktionen gehoeren zu den Basisdiensten, denen Basisklassen zugeordnet sind. Das Beispiel "Date" zeigt, wie sich aus einer Klasse weitere, komplexere ableiten lassen. An oberster Stelle stehen die Datumsangaben (Date), die etwa bei Berechnungen laenderspezifische Konventionen beruecksichtigen muessen. Sie bilden die Grundlage fuer das "City Date". Diese Klassen muessen beispielsweise wissen, dass in verschiedenen Regionen unterschiedliche Feiertage gelten und dass eine zu berechnende Periode von einem Jahr nicht unbedingt 365 Tage zaehlt. Das Financial Date kann bereits mit Diskontierungsfaktoren arbeiten. Es erkennt und interpretiert die Zeitintervalle einer Kurve. Wird eine dieser Klassen nach einem Diskontierungsfaktor gefragt, liefert sie den fuer das Datum oder die Periode stimmigen.

Produktbeschreibung

"Stars ++" ist ein Risiko-Management-System, das neben den klassischen Treasury-Instrumenten auch die gaengigen Zinsderivate abdeckt. Es unterstuetzt als Front-end den Haendler und liefert ihm Risiko-Analysen und -Quantifizierungen. Darstellungsformen sind in der Regel Tabellen und Kurven. Als Back-end laesst sich das System auch bei der Verwaltung und Bewertung von Kredit-, Anlage- oder Handelsportfolios nutzen. Es unterstuetzt zum Beispiel FRAs, Swaps, Caps, Floors und Swaptions. Das System laeuft auf Windows-, Window-NT- und Windows-95-PCs sowie auf Unix-Workstations.

Glossar der Dresdner Bank Arbitrage: risikofreie Ausnutzung von komparativen Kostenvorteilen von zwei oder mehr Parteien durch Inanspruchnahme unterschiedlicher Maerkte.

Bond: festverzinsliches Wertpapier.

Cap: vertragliche Vereinbarung einer Zinsobergrenze, bezogen auf einen zugrundeliegenden, nominellen Kapitalbetrag. Uebersteigt dabei der Referenzzinssatz (in der Regel Libor) die vertraglich festgelegte Zinsobergrenze (Strike-Preis), so zahlt der Verkaeufer (Stillhalter) dem Kaeufer des Cap die Differenz zwischen Zinsobergrenze und Referenzzinssatz.

Derivate, derivative (abgeleitete) Finanzprodukte: verschiedene Formen von Termingeschaeften, die auf gaengigen Finanzinstrumenten wie Aktien, Renten, Devisen oder Indizes beruhen. Die bekanntesten Derivate sind Optionen, Terminkontrakte und Swapgeschaefte.

Financial Engineering: massgeschneiderte, auf spezielle Situationen des Kunden zugeschnittene Problemloesungen.

Floor: Zinsuntergrenze, siehe Cap.

FRA: Future Rate Agreement; Vereinbarung zweier Vertragsparteien ueber die Festlegung des Zinssatzes, der fuer einen vereinbarten Zeitraum in der Zukunft verbindlich ist. Die Zinsen werden auf einen vereinbarten nominellen Kapitalbetrag berechnet, ohne dass Kapital zur Verfuegung gestellt wird.

Libor: London Interbank Offered Rate, Referenzzinssatz fuer variabel verzinsliche Eurogeld-Kredite.

Swaption: gibt einem Optionskaeufer gegen Zahlung einer Optionspraemie das Recht, zu einem festgelegten Zeitpunkt in einen hinsichtlich Laufzeit und Zinshoehe spezifizierten Swap einzutreten.

Treasury: Liquiditaets-, Zins- und Waehrungs-Management.

Zinsswap: vertragliche Vereinbarung ueber den Austausch von unterschiedlich gestalteten Zinszahlungsstroemen ueber einen bestimmten Zeitraum. Dabei werden ueblicherweise feste gegen variable Zinssaetze getauscht.