Outsourcing im ­Wertpapierhandel

Das Wertpapiergeschäft wird immer internationaler und elektronische Handelsplattformen verdrängen die klassischen Parkettbörsen. Gleichzeitig werden die zugrunde liegenden Geschäftsprozesse komplexer, müssen bei stetig verbesserter Servicequalität schneller sowie effizienter abgewickelt werden. Hinzu kommt die Notwendigkeit immer breitere Produktpaletten anzubieten, wodurch der Handel und die Abwicklung immer komplexer werden. Vor diesem Hintergrund ist der Markt für Wertpapierservices neben dem Zahlungsverkehr das Geschäftsfeld, bei dem viele Banken große Teile der Wertschöpfungskette an spezialisierte Transaktionsbanken ausgegliedert haben oder darüber nachdenken. An die Entscheidung für ein Outsourcing und die dabei einzusetzenden Produkte sind neben strategischen und wirtschaftlichen auch technologische Fragen geknüpft. Wie kann die Systemarchitektur so gestaltet werden, dass vor dem Hintergrund der ausgelagerten Schritte des Wertpapierabwicklungsprozesses und des dynamischen Marktumfeldes die Produkte einheitlich erscheinen und trotzdem eine möglichst große technische Unabhängigkeit von der Transaktionsbank erreicht wird? Wie muss neben der prozesstechnischen Trennung die technologische Trennung zwischen Outsourcing-Unternehmen und Transaktionsbank »geschnitten« sein, um möglichst geringe Kosten zu erreichen und den permanenten Änderungen von steuer- und aufsichtsrechtlichen Bestimmungen zu begegnen? Mit welchen Frontend-Produkten lässt sich der »Schnitt« zur Transaktionsbank unter Berücksichtigung des dort eingesetzten Backend-Systems sowohl für Kunden als auch für Mitarbeiter am effektivsten abbilden, so dass ein akzeptabler Grad an Abhängigkeit beziehungsweise Unabhängigkeit erreicht wird? Im Folgenden sei die Interaktion zwischen Frontend- und Backend-Systemen zwischen Outsourcing-Unternehmen und Transaktionsbank für das Wertpapiergeschäft ins Auge gefasst. Weitere Schnittstellen, etwa für die Anbindung an dispositive Systeme für Reporting und Bilanzierung sowie für die Übertragung von Kunden- oder Depotstammdaten, sind dann noch separat zu behandeln.

Unterschiedliche Benutzer
Systeme für den Wertpapierhandel müssen im Wesentlichen die folgende Funktionen abdecken: Basisfunktionen wie Ordererteilung, Änderung, Löschung, Depotbestandsansicht und Orderbuchansicht. Analysefunktionen wie Depotstrukturanalyse, Performanceanalyse, Musterdepot, Was-wäre-wenn Analysen. Informationsfunktionen wie Wertpapier-Stammdaten, Kursdaten und -listen sowie Research-Informationen. Back-Office-Funktionen wie Storno-Bearbeitung, Abrechnungssteuerung, manuelle Abwicklung und bankweite Analysen. Die Nutzergruppen unterscheiden sich in den Kriterien Anzahl der Nutzer, Qualifikation, Häufigkeit und Ort der Systemnutzung, wie in dem Kasten auf Seite 38 zusammengefasst. Kunden nutzen Basis-, Analyse- und Informationsfunktionen meist in eingeschränkter Form über Internet-Banking, Kundenterminals oder andere Vertriebskanäle im Sinne des Multi-Channeling. Eine Umstellung sollte möglichst unbemerkt erfolgen und mindestens die gewohnte Funktionalität und Oberfläche anbieten. Wertpapierhändler nutzen Basis-, Analyse- und Informationsfunktionen in sehr umfangreicher Form am Arbeitsplatz. Beim Outsourcing tritt die Kontinuität in der Oberfläche gegen­über der Möglichkeit zurück, die Funktionen des neuen Systems vollständig und effizient nutzen zu können. Aufgrund der geringen Personenzahl und der hohen Qualifikation dieser Gruppe ist ein Systemwechsel hier mit dem geringsten Aufwand möglich. Back-Office-Mitarbeiter nutzen hauptsächlich Back-Office-Funktionen am Arbeitsplatz im Rahmen des Abwicklungsprozesses. Das Verhalten und die Anforderungen beim Outsourcing sind analog zum Wertpapierhändler. Kundenberater nehmen hinsichtlich der genannten Kriterien eine mittlere Position ein, da sie Basis-, Analyse- und Informationsfunktionen in umfangreicher Form sowohl am Arbeitsplatz als auch am Laptop beim Kunden vor Ort nutzen. Ein kompletter Systemwechsel ist bei dieser Gruppe machbar, aber häufig nicht wünschenswert. Grundlage für die funktionale Unabhängigkeit und technologische Trennung zwischen Outsourcing-Unternehmen und Transaktionsbank sind Standardprotokolle (siehe Kasten). Bezogen auf die genannten Funktionsgruppen decken diese Standards jedoch nur die Basisfunktionen und einen Teil der Informationsfunktionen ab. Für Wertpapierstamm- und Kursdaten gibt es SWIFT-Nachrichtentypen, die Übertragung von Research-Informationen ist jedoch nicht standardisiert. Die Analyse- und Back-Office-Funktionen werden von standardisierten Protokollen meist nicht ausreichend berücksichtigt. Das hat die Verwendung proprietärer Protokolle sowie individuelle Lösungen für Frontend-Systeme zur Folge.

Verschiedene Frontends
Die Frontend-Systeme können aus technologischer Sicht in die Kategorien Fat Client, Web-Oberfläche und Terminal-Emulation eingeteilt werden. Weiterhin ist es sinnvoll, zwischen Homebanking-Anwendungen und Frontend-Systemen der Transaktionsbanken zu unterscheiden. Homebanking-Anwendungen sind in der Regel Fat Clients. Aufgrund der für Produkte erforderlichen Multibankenfähigkeit wird von allen HBCI, bei neueren Versionen auch FinTS, unterstützt. Seit HBCI 2.0 ist Wertpapier­handel möglich und wird von allen Produkten angeboten. Neben den üblichen Homebanking-Funktionen wie Konto­standsabfrage, Überweisungseingabe und Dauerauftragsverwaltung werden verschiedene Kontenarten (Kontokorrent-, Spar-, Darlehen-, Festgeld-, Kreditkartenkonto) und weitergehende Funktionalität (zum Beispiel Termin- oder Sammelüberweisung oder Festgeldprolongation) angeboten. Über den Umfang des verwendeten Protokolls hinausgehende Funktionalität wird durch lokale Datenhaltung und Anwendungslogik realisiert. Homebanking-Anwendungen sind ausschließlich für Kunden interessant, sie sind weder für Kundenberater noch für das Back-Office geeignet. Jede Transaktionsbank bietet ein oder mehrere Frontend-Systeme an, die spezifisch auf ihre Backend-Systeme und die Zielanwender zugeschnitten sind. Diese Systeme sind abhängig vom Backend und müssen bei einem Systemwechsel ausgetauscht werden. Wenn das Backend auf einem Großrechner implementiert ist, wird zumeist auf Basis einer Terminal­emulation ein direkter Zugriff angeboten. Über diesen Weg der Host-Anbindung steht der gesamte Funktionsumfang zur Verfügung. Die Bedienung ist jedoch meist nur für geübte Nutzer praktikabel. Über ein Internet-Frontend-System wird meist nur ein eingeschränkter Funktionsumfang angeboten. Die Anbindung an das Backend erfolgt über das Protokoll S-HTML an einen Application Server und von dort über eine proprietäre Schnittstelle zum Backend-System. Bei den von Transaktionsbanken zur Verfügung gestellten Fat Clients handelt es sich zumeist um direkte Übertragungen der Funktionalität der Terminal-Emulation auf eine grafische Benutzeroberfläche. Damit werden die Bedienmöglichkeiten komfortabler und mehrere Host-Anwendungen unter einer Oberfläche zusammengefasst. Die Anbindung erfolgt über proprietäre Schnittstellen. Aus den dargelegten Verhältnissen bei Funktionen, Nutzergruppen und Produkten ergeben sich Konsequenzen für den Aufbau und die Optimierung der Systemarchitektur. Das Frontend-System für die Kunden verbleibt beim Outsourcing-Unternehmen und wird ausschließlich über Standardprotokolle an die Transaktionsbank angebunden, womit diese austauschbar wird. Für das Back-Office wird ein Frontend-System eingesetzt, das die Transaktionsbank anbietet und den vollen Funktionsumfang des ­Backend-Systems abbildet. Hier besteht bei den meisten Transaktionsbanken die Wahlmöglichkeit zwischen einem Fat Client und einer Terminalemulation. Für die Kundenberater ist eine Entscheidung zwischen diesen beiden Extremen zu treffen. Es kommt letztlich darauf an, was an Daten und Funktionen für die Beratungsaufgaben gebraucht wird.

Architekturen für Kunden
Die ideale Architektur unterscheidet sich damit für die drei Nutzergruppen. Die Systemarchitektur für Kunden-Frontend-Systeme stützt sich wesentlich auf Standardprotokolle. Bei der Bank verbleibt ein Application Server, der diese Protokolle miteinander verknüpft: HBCI / FinTS für die Homebanking-Anwendungen, S-HTML für das Internet-Frontend, S-WML für mobile Endgeräte wie Handys oder PDAs, SWIFT für die Anbindung der Transaktionsbank, XML für die Anbindung weiterer Anbieter zur Umsetzung von Informations- und Analysefunktionen. Die Anbindungen an die Transaktionsbank sowie an WM, GIS oder Reuters können zusätzlich auch als Service implementiert werden und stehen damit über die Verwendung für das Kunden-Frontend hinaus auch anderen Banksystemen im Rahmen einer serviceorientierten Architektur (SOA) zur Verfügung. Dieses Vorgehen bietet einige Vorteile. Die Anbindung zur Transaktionsbank erfolgt nur über ein Standardprotokoll, ein Wechsel ist für das Outsourcing-Unternehmen ohne großen Aufwand möglich. Eine vollständige Kontrolle über den Funktionsumfang und die Weiterentwicklung des Kunden-Frontend-Systems ist möglich. Doch auch einige Nachteile sind zu bedenken. So ist der Umsetzungsaufwand verhältnismäßig hoch. Die Bank muss eine Middleware mit Applikationslogik betreiben, die die SWIFT-Schnittstelle zur Transaktionsbank in die Schnittstellen zu den Frontend-Systemen oder anderen operativen Systemen umsetzt. Außerdem müssen vom Standardprotokoll nicht abgedeckte Funktionen der Transaktionsbank individuell angebunden und entwickelt werden.

Architekturen fürs ­­Back-Office
Die Systemarchitektur für Frontend-Systeme des Back-Office ist einfacher, da diese Nutzergruppe das von der Transaktionsbank angebotene System verwendet. Von Vorteil ist, dass nahezu kein Implementierungsaufwand beim Outsourcing-Unternehmen erforderlich ist. Es muss lediglich das von der Transaktionsbank angebotene Frontend-System installiert werden. Die von der Transaktionsbank angebotene Funktionalität lässt sich vollständig nutzen. Fachliche oder gesetzliche Erweiterungen erfolgen durch die Transaktionsbank. Diesen Vorzügen stehen jedoch auch einige Nachteile gegenüber. Der Wechsel der Transaktionsbank erfordert einen Systemwechsel im Back-Office. Und die Kontrolle über Funktionsumfang und Weiterentwicklung ist nur mittelbar möglich: durch Einflussnahme auf die Transaktionsbank. Die Systemarchitektur für Kundenberater-Frontend-Systeme kann zwischen den beiden Extremen für die Kunden- und das Back-Office gewählt werden. In Abhängigkeit von den konkreten Anforderungen dieser Nutzergruppe sind auch Mischformen möglich.

Bernd Eberhardt ist Projektmanager, Andreas Grün und Roland Reichel sind Berater bei dem IT-Dienstleister sd&m in München.