Risikofaktoren schnell und präzise zu bestimmen ist das tägliche Brot der Landesbank Baden-Württemberg (LBBW). Die internationale Geschäftsbank zählt gemessen an der Bilanzsumme zu den zehn größten Kreditinstituten in Deutschland.
Die wichtigsten Unsicherheiten, mit denen die Bank konfrontiert ist, sind Zins- und Kreditrisiken. Zu Letzteren zählt auch die Bonität eines Unternehmens. Um diese Risiken einzuschätzen, simulieren die Verantwortlichen Cashflows, die die künftigen Zahlungen für Kredite oder Wertpapiere berechnen.
Diese Risiken lassen sich mit einem mathematisch-statistischen Modell ermitteln, der Monte-Carlo-Simulation. Bei diesem Verfahren wird für jedes Portfolio eine so genannte Verlustverteilung berechnet. Daraus kann zum Beispiel abgelesen werden, dass mit 80 Prozent Wahrscheinlichkeit der Verlust für die Bank nicht größer als x Euro ist. Auf der Basis dieser Monte-Carlo-Simulation entscheidet das Institut dann über zu vergebende Kredite an ein Unternehmen.
Doch einen Haken hat die Sache: Eine zuverlässige Monte-Carlo-Simulation ist sehr zeitaufwändig. Je genauer die Risikoaussage sein soll, umso mehr Simulationsläufe müssen durchgeführt werden. Dies gilt für jedes Portfolio. "Wir nehmen für gewöhnlich 50 000 bis 100 000 Simulationsläufe. Das dauert für ein großes Portfolio ein bis zwei Stunden", sagt Peter Oellers, Leiter der Abteilung Portfolio-Management bei der LBBW.
1999 potenzierte sich das Problem: Bedingt durch die Fusion mit drei Banken bekam die LBBW plötzlich einen immensen Bestand zu prüfender Risiken, der die vorhandenen Rechnerressourcen sprengte. Mit mehr als einer Million Krediten und Wertpapierkonten war der Kapazitätsaufwand für die Risikobewertung enorm groß. Die Konsequenzen: "Die Erzeugung der Cashflows für eine Million Kredite war auf einer Maschine nicht mehr möglich, weil wir dafür viel zu lange gebraucht hätten", sagt Oellers.
Größere Rechnerkapazität musste her
Für den Abteilungsleiter war die Sache klar. Größere Rechnerkapazitäten mussten her. Die LBBW entschied sich für eine Clusterlösung, die die Risikoberechnungen simultan auf mehreren Rechnern durchführt. Die Entscheidung für eine verteilte Lösung begründet Oellers mit einer einfachen Überlegung: "Zwischen den einzelnen Risikosimulationen besteht keine Abhängigkeit. Einen Cashflow zu erzeugen, ist ein Prozess, der nicht von anderen abhängig ist. Wenn ich zehn Risiken evaluieren will, kann ich das erste auf Maschine eins rechnen lassen, das zweite auf Maschine zwei und so weiter. Das heißt: Ich brauche mit zehn Maschinen nur ein Zehntel der Zeit."
Um die Ressourcen effektiv zu managen, setzte die LBBW auf Software von Platform, einem Lösungsanbieter für verteilte Computeranwendungen. Der "Master"-Rechner - ausgestattet mit der Platform-Software LSF - übernimmt dabei die automatische Zuweisung einzelner Rechenjobs an die angeschlossenen "Slaves", die die einzelnen Simulationen durchführen. Werden an den Master-Rechner beispielsweise 1000 Jobs (Prozesse) geschickt, so arbeitet LSF die Warteschlange nach und nach gemäß dem Prinzip First-in-First-out ab und weist sie den Slaves zu. LSF kontrolliert, welche Prozessoren frei sind, und verwaltet die Rechner, wenn ein Prozess gestört ist oder abbricht. Der Rechner, auf dem LSF läuft, ist kein dedizierter Server, sondern ein ganz normaler PC und könnte zusätzlich für andere Anwendungen genutzt werden.
Insgesamt 32 Rechner führen bei der LBBW als Slaves die Risikoberechnungen aus, die allein für diesen Zweck bereitstehen. "Man könnte die Simulationen auch auf den PCs der Mitarbeiter laufen lassen", ergänzt Oellers. "Wenn ein Arbeitsplatzrechner stillsteht, könnte er einen Job aufnehmen und ohne große Mehrkosten simulieren." Innerhalb der Bank gab es jedoch Vorbehalte gegen diesen Plan: "Unsere Inhouse-IT war dagegen, weil man befürchtete, dass sich Prozesse in die Quere kommen. Deshalb haben wir separate Rechner für das Cluster-Computing eingeführt."
Für Peter Oellers verschwanden mit der LSF-Lösung gleich mehrere Probleme auf einen Schlag. "Mit der verteilten Lösung können wir in der gleichen Zeit erheblich mehr Simulationen laufen lassen. Der Zeitaufwand für die Simulationen konnte auf etwa ein Zehntel gedrückt werden. Weil länger gerechnet werden konnte, erhielten wir auch eine deutlich höhere Genauigkeit bei den Risikomessungen", sagt Oellers. Ein wichtiges Entscheidungskriterium für Platform war auch die Anwenderfreundlichkeit: "In die Codes unserer Anwendungen musste nicht eingegriffen werden."
Gleichzeitig hielten sich die Kosten in Grenzen. "Wir hatten überlegt, eine 30-Prozessor-Maschine anzuschaffen. Doch das wäre im Vergleich zu LSF deutlich teurer geworden", erklärt Oellers. Zwischen 20 000 und 100 000 Euro kostet eine Clusterlösung, wie sie die LBBW einsetzt. Konkrete Zahlen wollte die Bank nicht nennen.
Merten Slominksy, Geschäftsführer Zentraleuropa beim Lösungsanbieter Platform, sieht im Parallel-Computing à la LBBW - im Fachjargon auch als Grid Computing bezeichnet - die gute alte Großrechner-Welt in moderner Form wiederaufleben: "Die 32 separaten Server der LBBW werden zu einem virtuellen Großrechner zusammengefasst und behandelt, als wäre es eine einzige Infrastruktur. Innerhalb dieser Infrastruktur können entsprechende Aufgaben intelligent zerlegt und verteilt werden. Die wichtigsten Teilaufgaben können so am schnellsten mit der höchsten Priorität bedient werden", sagt Slominsky.
Kleine Einheiten schaffen
Natürlich ist nicht jede Anwendung von Hause aus Grid-fähig. "In einer Prozesskette, in der ein Prozess B sehr stark von einem Vorgängerprozess A abhängt, ist die Zeitersparnis vergleichsweise gering, weil B erst auf A warten muss. Auch hier gibt es heute Methoden und Lösungen, aber am einfachsten ist es, erst die Anwendungen Grid-fähig zu machen, in denen man keine großen Abhängigkeiten zwischen Prozessen hat, denn dann lassen sich die Vorgänge schön parallelisieren", erklärt Slominsky. Und das ist in der Regel beim Risiko-Management der Fall.
LBBW-Experte Oellers rät allen Firmen, die Ähnliches vorhaben: "Man sollte sich grundsätzlich Gedanken machen, ob der Gesamtprozess parallelisierbar ist. Wenn man eigene Programme einsetzt, ist darauf zu achten, dass die Module, die man entwickelt, einfach in so ein Schema passen. Man muss vernünftige kleine Einheiten schaffen, die das ganze Gebäude bilden."