Agentenbasierter Rentenhandel 1

Transkript

1 Agentenbasierter Rentenhandel 1 Peter Gomber, Miroslav Budimir (Uni Gießen); Klaus Kosciankowski, Robert Urtheil (Deutsche Börse AG) Markus Lohmann (Dresdner Bank AG); Norbert Nopper (living systems AG); Peter Henning (FH Karlsruhe) Kernpunkte für das Management: Der Beitrag stellt die Ergebnisse eines Kooperationsprojektes der Deutsche Börse AG, Compaq Computer GmbH (vormals: Digital Equipment GmbH), living systems AG und des Lehrstuhls BWL- Wirtschaftsinformatik, Universität Gießen vor. Ziel war die prototypische Realisierung eines Elektronischen Handelssystems für den Rentenmarkt. Motivation für dieses Projekt sind die hohen Transaktionskosten und die mangelnde Effizienz des außerbörslichen Rentenhandels. Die wesentlichen Ergebnisse sind: Im deutschen Rentenmarkt wird der Großteil der Geschäfte bilateral oder über Broker abgewickelt. Durch eine Elektronisierung sind hohe Effizienzvorteile zu erwarten. Das Paradigma der Softwareagenten erweist sich insbesondere für die Kontrahentensuche als ein sehr leistungsfähiger Ansatz. Eine objektorientierte Modellierung sowie eine auf der FIPA-Spezifikation basierende Architektur stellen die Erweiterbarkeit, Verfügbarkeit, Skalierbarkeit und Performance des Systems sicher. Stichworte: Rentenhandel, Elektronische Handelssysteme, Softwareagenten, OTC-Markt. Agent-Mediated Bond Trading abstract: In bond markets, most trades are conducted via bilateral negotiations or the use of brokers. Especially in the case of large blocks, the anonymity of the traders is very important. In a joint project of Deutsche Börse AG, Compaq Computer GmbH, living systems AG and the chair of Information Systems of the University of Giessen, a trading system was modelled and implemented which allows the identification of potential trading partners within an anonymous market. Software agents represent the orders and try to match both, products and partners. Alternative pricing mechanisms were realised. The architecture is based upon the FIPA-specification. The system was modelled object-oriented and implemented in Java. keywords: bond trading, trading systems, software agents, OTC market. 1 Die vorliegende Arbeit stellt eine Überarbeitung und Zusammenfassung der Arbeiten [GoBu98] und [LoNo98] dar.

2 1 Einführung Im Wertpapierhandel ist die Entwicklung zu einem rein computerbasierten Handel unumkehrbar. Trotzdem wird in verschiedenen Marktsegmenten immer noch die direkte menschliche Interaktion via Telefon bevorzugt. Dieser außerbörsliche (Over the counter, OTC) Handel findet bevorzugt in Werten statt, in denen die Börse als zentraler Platz zur Preisfindung nicht benötigt wird - wie z. B. bei festverzinslichen Wertpapieren (Renten) oder Derivaten, deren Ausgestaltung von den normierten Produkten der Terminbörsen abweicht (z. B. Swaps). Die erheblichen Transaktionskosten, die bereits ex ante stark reduzierte Anzahl möglicher Kontraktpartner und die fehlende integrierte Prozeßkette von Handel und Abwicklung sind die wesentlichen Problemfelder des OTC-Handels. Es liegt eine nur begrenzte Transparenz des Preisbildungsprozesses vor. Dies führt zu einer deutlichen Reduktion der Effizienz auf dem OTC-Markt. Trotzdem dominiert der außerbörsliche Handel den Börsenhandel in den genannten Wertpapiersegmenten bezüglich der gehandelten Volumina deutlich. Der Anteil des außerbörslichen Handel in deutschen Rentenwerten wird auf ca. 90% geschätzt, genaue Zahlen sind aufgrund der Fragmentierung sowie der Intransparenz dieses Marktes nur schwer zu erheben. Die große Bedeutung des OTC-Handels und der Versuch, die Ineffizienzen des OTC-Marktes zu überwinden, sind Anlaß eines Forschungsprojektes, das die Projektpartner Deutsche Börse AG, Compaq Computer GmbH (vormals: Digital Equipment GmbH) und living systems AG unter Projektleitung des Lehrstuhls BWL-Wirtschaftsinformatik der Justus-Liebig-Universität Gießen durchführten. Im Rahmen des Projektes wurde ein auf der Technologie der Softwareagenten elektronisches Handelssystem für den Rentenhandel konzipiert und prototypisch umgesetzt. Mit dem Paradigma der Softwareagenten (im folgenden kurz: Agenten) sollen die Charakteristika der gehandelten Objekte, der Marktprozesse und der Verhaltensweisen der Marktteilnehmer im Rentenhandel so abgebildet werden, daß das System dem konventionellen Handel über Telefon und Broker vorgezogen wird. Diese Arbeit stellt das Projekt sowohl aus finanzwirtschaftlich/funktionaler als auch aus technischer Sicht vor: Im zweiten Abschnitt wird der außerbörsliche Wertpapierhandel kurz erläutert. Die bestehenden Systeme zur Unterstützung des elektronischen Rentenhandels und die Aufnahme des elektronischen Rentenhandels durch die Deutsche Börse AG mit Einführung von Xetra (Exchange Electronic Trading) Release 3 werden in Abschnitt 3 dargestellt. Kapitel 4 erläutert das Potential der Agententechnologie für die Elektronisierung dieses Marktsegments, stellt die Anforderungen an das zu entwickelnde Handelssystem dar und zeigt auf, warum das Agentenparadigma ein geeigneter Lösungsansatz ist. Abschnitt 5 erläutert die Architektur des Systems, während der sechste Abschnitt die technische Umsetzung aufzeigt. Eine Zusammenfassung und ein Ausblick auf weitere Projektschritte schließen die Arbeit ab. 2

3 2 Der außerbörsliche Wertpapierhandel Teilnehmer im OTC-Markt sind Banken, Broker und Wertpapierhäuser sowie deren Kunden, zumeist institutionelle Investoren [GrGr95]. Der Handel findet meist per Telefon statt, dies ermöglicht den Händlern maßgeschneiderte Vertragsgestaltungen. Die relevanten Parameter wie etwa Kontraktgröße, Laufzeit und Nominalbetrag können individuell vereinbart werden. Somit wird ein hohes Maß an Flexibilität erzielt, außerdem sind die Händler nicht auf feste Börsenzeiten angewiesen. Die Kommunikation zwischen den Handelspartnern kommt entweder direkt zustande oder wird von Brokern vermittelt. Brokers bring buyers and sellers together for a commission. By definition, brokers never position securities. Their function is to provide a communications network that links market participants who are often numerous and geographically dispersed [Stig83, 30]. Ein zentraler Grund für die Existenz des Brokers ist die oft fehlende Liquidität im Börsenhandel (z. B. bei Pfandbriefen [DeKi96]). Über die reine Partnersuche hinaus bieten Broker auch die Orderpflege, die Durchführung von Plausibilitätsprüfungen und/oder Research an. Außerdem besteht die Aufgabe des Brokers darin, Handelsstrategien oder größere Orders - welche ungewünschte Kursveränderungen verursachen könnten - so auszuführen, daß die Kunden möglichst geringen negativen Preiseffekten ausgesetzt werden [MaCh97; GeRa92]. Beim Handel größerer Volumina - sog. Blockhandel - kann die Ordergröße von den Marktteilnehmern als Signal für private Informationen gedeutet werden und zu adversen Preiseffekten führen [EaOH92; BuOH87]. Aus diesem Grund sind die Händler daran interessiert, die Information über ihre Blockorders vor dem Markt zu verstecken und engagieren einen Broker. Dieser soll eine entsprechende Gegenpartei finden und dabei dem Markt keine Informationen über die Blockorder preisgeben. Das Einschalten eines Brokers verlängert die Intermediationskette zwischen Käufer und Verkäufer des Wertpapiers und erhöht somit die Transaktionskosten z. B. durch anfallende Brokercourtage [GrTh94]. Trotz der hohen Kosten werden Dienstleistungen der Broker in Anspruch genommen, da die Suche nach Verhandlungspartnern äußerst zeitintensiv ist. 3 Rentenhandel im System Xetra Die Rahmenbedingungen für den Rentenhandel haben sich entscheidend verändert. Die Einführung der gemeinsamen europäischen Währung schafft den zweitgrößten Rentenmarkt der Welt und stärkt die Rolle von Xetra als standortunabhängige Handelsplattform. Der Handel in Benchmark- Anleihen ist bereits heute stark internationalisiert, ca. 50% des Umsatzes in deutschen Staatsanleihen wird mit ausländischen Counterparts getätigt. Der zunehmende Konzentrationsprozeß im Bankenwesen verstärkt den Kostendruck und fördert Systeme mit integrierter Prozeßkette (Handel und Abwicklung) und niedrigen Transaktionskosten. Der elektronische Rentenhandel hat in den vergangenen Jahren zunehmend an Bedeutung gewonnen. 3

4 So hat sich die Anzahl elektronischer Transaktionssysteme im amerikanischen Rentenmarkt von 12 in 1997 auf 24 in 1998 verdoppelt. Die Deutsche Börse AG unterstützt den Rentenhandel seit dem 5. Dezember 1995 mit dem Rentenhandelssystem IBIS-R, welches am 12. Oktober 1998 mit der Einführung von Xetra Release 3 eingestellt wurde. Mit Xetra Bond Trading implementierte die Deutsche Börse ein modulares Marktmodell, welches auf die unterschiedlichen Handels- und Marktsegmente zugeschnitten werden kann. So können hochliquide Werte (zum Start von Release 3 sind dies die in Futures lieferbaren Werte und 30- jährige Anleihen sowie die Jumbo Pfandbriefe) fortlaufend gehandelt werden, weniger liquide Werte werden in Auktionen gehandelt. Während im fortlaufenden Handel nur Round lot orders zugelassen sind, und damit der Wholesalehandel unterstützt wird, können in den untertägigen Auktionen (für alle Wertpapiere) alle Ordergrößen und damit das Retailgeschäft ausgeführt werden. Das Orderbuch ist sowohl im fortlaufenden Handel als auch in den Auktionen offen, den Teilnehmern werden die zum jeweiligen Limit kumulierten Volumina angezeigt. Im fortlaufenden Handel findet ein automatisches Matching statt: sich gegenüberstehende ausführbare Orders werden automatisch zusammengeführt. Dabei werden sowohl Limit- als auch Marketorders unterstützt, die jeweils durch verschiedene Gültigkeitsbeschränkungen ausgestaltet werden können. Im Dezember 1998 waren über 280 Marktteilnehmer an Xetra angebunden, davon mehr als 35 aus dem europäischen Ausland. Dies unterstreicht die internationale Ausrichtung des kommenden europäischen Rentenmarktes. 4 Agentenbasierter Rentenhandel Im folgenden wird die Konzeption eines agentenbasierten Rentenhandelssystems auf der Basis der Agententechnologie vorgestellt. Diese Technologie ermöglicht die Realisierung neuer Such- und Verhandlungsstrategien, birgt Potential zur Elektronisierung des außerbörslichen Rentenhandels und kann insbesondere für den Blockhandel sowie für den Handel in illiquiden Werten eine wertvolle Ergänzung des Rentenhandels in Xetra Release 3 darstellen. 4.1 Funktionale Anforderungen an das agentenbasierte Rentenhandelssystem Das Handelssystem soll einen fortlaufenden Handel in öffentlichen Anleihen, Jumbo-Pfandbriefen und klassischen Pfandbriefen ermöglichen und den Anforderungen der Wertpapierhändler gerecht werden. Zu diesem Zwecke wurden mit Händlern verschiedener Banken und Wertpapierhandelshäuser umfassende Interviews geführt, um die Ist-Situation zu analysieren und die Anforderungen der Marktteilnehmer zu ermitteln. Am OTC-Markt gibt es kein Orderbuch; Partnersuche und Preisfindung erfolgen jeweils bilateral zwischen den Händlern. Die Partnersuche sollte daher auch im System individuell ausgestaltet werden. Im Idealfall sollte jeder Transaktionswunsch eines Händlers mit allen Transaktionswünschen 4

5 aller am System teilnehmenden Händler abgeglichen werden, um Übereinstimmungen bezüglich der Wertpapiere und der Konditionen zu erhalten. Das System soll die Marktteilnehmer bei akzeptablem Kommunikations- und Zeitaufwand in die Lage versetzen, potentielle Kontraktpartner zu identifizieren, um mit diesen die Vertragskomponenten bilateral auszuhandeln. Darüber hinaus sind im Systemkonzept auch die im OTC-Markt vorhandenen Risiken zu berücksichtigen, insbesondere das Wiederbeschaffungsrisiko. Dabei handelt es sich um das Preisänderungsrisiko, das sich ergibt, wenn der vereinbarte Handel aufgrund der Nichtzahlung bzw. Nichtlieferung durch einen Kontraktpartner nicht ausgeführt wird und das Papier vom Markt - eventuell zu einem ungünstigeren Preis - beschafft werden muß [Büsc93, 774; Kran96; ScLu96, 95-96]. Daher ist ein entsprechendes Kontrahentensuchkonzept zu realisieren, um den teilnehmenden Banken bzw. Händlern die Möglichkeit zu bieten, den Partnersuchraum auf Basis individueller Bewertungskriterien einzustellen. So entstehen individuelle Suchräume, die der Händler aus der Einschätzung der Kontrahentenbonität, der Häufigkeit und Qualität vergangener Transaktionen, der Dringlichkeit des aktuellen Transaktionswunsches usw. herleiten kann [WeGo99]. Darüber hinaus müssen auch solche Transaktionsinteressen im System ausführbar sein, bei denen kein konkretes Wertpapier angegeben wird, sondern potentiell interessierende Coupongrößen, Laufzeiten und/oder Emittenten spezifiziert werden, um so analog dem Telefonhandel mit noch sehr unscharfen Angaben andere Markteilnehmer zu suchen und zu finden. Das Handelssystem, das den Rentenhändler unterstützen soll, muß folgende Anforderungen erfüllen [WeGo99]: Die Repräsentation der zu handelnden Papiere, die Identifikation potentieller Kontraktpartner, der Abgleich der Wertpapiereigenschaften, eine Präsentation der Vertragsvorschläge beim auftraggebenden Händler und nicht zuletzt Kompetenz zur Führung bilateraler Vorverhandlungen bzw. zur Teilnahme an einer Auktion. 4.2 Technische Anforderungen an das agentenbasierte Rentenhandelssystem In diesem Abschnitt werden die wichtigsten Anforderungen aus technischer Sicht erläutert: Die Performance des zu entwickelnden Matchingsystems wird von der Zeitspanne determiniert, in welcher die Identifikation der potentiellen Kontraktpartner und der Abgleich der Eigenschaften der gehandelten Objekte durchlaufen werden. Das System wird nur dann erfolgreich sein, wenn es dem Händler eine Zeitersparnis bringt und gleichzeitig die Kosten für die Informationsbeschaffung deutlich reduziert. Der Erfolg eines EHS ist auch daran zu messen, wie viele Handelsteilnehmer das System einsetzen. Aus diesem Grund muß das Matchingsystem so konzipiert werden, daß die Teilnehmerzahl nicht von vornherein beschränkt oder gar fixiert ist. Das System muß folglich skalierbar sein. Elektronische Handelssysteme müssen sich durch eine ständige Verfügbarkeit auszeichnen, d. h. sie müssen während der Handelszeiten stets einsetzbar sein. Dies kann nur gewährleistet werden, wenn 5

6 sich keine dedizierten Komponenten im System befinden. Bei einem eventuellen Ausfall einzelner Komponenten soll auf solche mit identischem Funktionsumfang umgeschaltet werden können. Eine Möglichkeit, eine derartige gewünschte Redundanz zu schaffen, ist die Verwendung einer dezentralen Lösung. Für das Matchingsystem ist daher eine Architektur zu konzipieren, die aus mehreren gleichberechtigten Komponenten besteht, von denen jede den notwendigen Funktionsumfang für ein Kontrahentenmatching abbildet. Ebenso sollte es möglich sein, bestehende Systeme koppeln zu können, um einen Investitionsschutz der Betreiber zu gewährleisten. Durch die Kopplung an externe Systeme kann zudem eine Erweiterung des implementierten Matchingprozesses notwendig sein. Ein weiteres Kriterium zur Sicherung der Akzeptanz ist die Gewährleistung der Sicherheit. Ein elektronisches Handelssystem ist dann als sicher zu bezeichnen, wenn keine Manipulationsmöglichkeiten vorgenommen und keine Informationen extrahiert werden können, die nicht vom Betreiber des Systems freigegeben werden. Darüber hinaus sollten die Plattformunabhängigkeit und die Integrationsmöglichkeit in eine heterogene Rechnerumgebung als generelle Anforderungen erfüllt sein. 4.3 Das Paradigma der Softwareagenten Die genannten Anforderungen können mit Hilfe einer modernen Softwaretechnologie erfüllt werden - den Softwareagenten. Agenten werden in der Literatur ausgiebig diskutiert [WoJe95; SyDe96; FrGr97], eine einheitliche Definition ist jedoch nicht verfügbar. Eine anerkannte, jedoch recht grobe Charakterisierung von Agenten liefern Jennings und Wooldridge [JeWo96]. Dabei werden Agenten als Stellvertreter angesehen, die im Auftrag eines Benutzers handeln und die folgenden Eigenschaften aufweisen: Autonomie (Agenten sollten in der Lage sein, die ihnen übertragenen Aufgaben ohne Hilfe von außen zu lösen), soziales Verhalten (Agenten interagieren mit anderen Agenten und dem Benutzer), Reaktionsvermögen (Wahrnehmung der Systemumgebung und deren Veränderungen) und Bewußtsein (nicht nur Reaktion auf die Umwelt, sondern bei Bedarf Initiative und zielgerichtetes Handeln). In einem elektronischen Handelssystem werden Orders eines Wertpapierhändlers durch je einen Agenten repräsentiert. Ein Händler übergibt einem Agenten den Auftrag, einen passenden Kontrahenten für eine Transaktion zu finden. Der Agent erledigt die Aufgabe ohne ständige Kommunikation mit seinem Händler (Autonomie). Damit er seine Aufgabe erfüllen kann, interagiert ein Agent mit anderen Agenten des Matchingsystems (soziales Verhalten). Da laufend weitere Orders (und damit Agenten) in das System eintreten und aus diesem wieder entnommen werden, muß der Agent diese Veränderungen seiner Umgebung sowohl wahrnehmen als auch in die Lösung seiner Aufgabe einfließen lassen können (Reaktionsvermögen). Ist ein Matching gescheitert, kann ein Agent im System verbleiben und selbständig entscheiden, wann er einen erneuten Versuch unternimmt, seine Aufgabe zu erfüllen. Er ergreift die Initiative, z. B. nachdem er sich neue 6

7 Informationen über die aktuell im System verfügbaren Agenten beschafft hat (Bewußtsein). Im folgenden wird ein Modell zur Elektronisierung des außerbörslichen Rentenhandels auf Basis von Softwareagenten dargestellt. Dafür wird zunächst das Marktmodell skizziert und darauf aufbauend die Kontrahenten- und Produktsuche sowie der Preisfindungsprozeß dargestellt. 4.4 Systemkonzept Marktmodell Die Struktur von Börsenmärkten wird durch die Ausprägungen ihrer Strukturmerkmale [Lüde96] bestimmt. Im folgenden werden die relevanten Parameter und die Ausprägungen der Strukturmerkmale des agentenbasierten Handelssystems vorgestellt. Die Ausprägung des Parameters Handelsfrequenz ist der fortlaufende Handel. Aufträge können so zu jeder Zeit während des Handelstages ausgeführt werden. Als Preisermittlungsverfahren sind sowohl bilaterale bzw. multilaterale Verhandlungen als auch von Agenten initiierte Auktionen möglich. Die Markttransparenz bezeichnet die visibility of the order flow [PaRö96, 581]. Diese visibility bezieht sich auf die Zeiträume vor der Preisermittlung (pre-trade-markttransparenz), sowie auf vollzogene Transaktionen (post-trade-markttransparenz). Die pre-trade-markttransparenz ist im Handelssystem aufgrund der adversen Informationseffekte auf die Angaben über den aktuellen Systemtraffic, d. h. der Zahl aktiver Agenten beschränkt. Die post-trade-markttransparenz ist durch den jeweiligen Systembetreiber einstellbar. Die Partnersuche des agentenbasierten Handelssystems ist vollständig automatisiert. Die Preisfindung in der Abschlußphase kann optional von Agenten durchgeführt werden. Agenten sollten in der Lage sein, sofern der Händler dies zuläßt, mit den Agenten potentieller Kontraktpartner zu verhandeln bzw. Auktionen zu initiieren. Die...basic function of any trading market mechanism [Domo92], die automatisierte Preisfindung, soll auch in diesem System gewährleistet sein Such- und Preisfindungsprozeß Aufgrund des modularen Aufbaus des Systems ist es möglich, Such- und Preisfindungsprozesse isoliert zu betrachten. Bild 1 stellt die im System realisierten, alternativen Such- und Verhandlungspfade dar. Die schattierten Flächen sind die Bereiche, in denen die Agenten autonom agieren, die nicht schattierten Flächen zeigen die Bereiche, in denen Händler mit dem System und/oder anderen Händlern interagieren. 7

8 Such- und Preisfindungsprozeß Eingabe der Parameter durch Händler Kontrahentenidentifikation Suchprozeß Kontrahentenmatching Preismatching Produktmatching Bekanntgabe der Partner Rückmeldung erfolglose Suche Bekanntgabe des konkreten Wertpapiers Eingabe Preisvorstellungen Preisfindungsprozeß Verhandlungen über Wertpapier und Preis telefonisch elektronisch direkte Offerte? Multicast Broadcast nein Auktion Ranking potentieller Kontrahenten Verhandlungen der Agenten autonomer Abschluß durch Agent Rückmeldung handelbarer Preis elektronische Verhandlungen über Wertpapier und Preis Rückmeldung Auktionspreis Telefonverhandlungen beide Händler akzeptieren mindestens ein Händler akzeptiert nicht Bild 1: Such- und Preisfindungsprozeß Nach der Spezifikation des zu handelnden Wertpapiers und der gewünschten Kontraktpartner beauftragt der Händler den Agenten mit der Suche. Dazu identifiziert der Händleragent zunächst alle im System vorhandenen Agenten (Kontrahentenidentifikation) und sucht in dieser Grundgesamtheit nach den für den Händler relevanten Agenten. Eine Suche ist erfolgreich, wenn zwei Händler sich sowohl wechselseitig als mögliche Kontrahenten spezifiziert haben (Kontrahentenmatching) als auch das gleiche Wertpapier suchen bzw. anbieten (Produktmatching). Dabei kann ein Wertpapier entweder über die Wertpapierkennummer vollständig definiert werden oder die Händler spezifizieren übereinstimmende Wertpapiereigenschaften, konkret: Emittent, Kupon und/oder Laufzeit. Definiert der Händler gesuchte Maximal- bzw. Minimalpreise, wird dies als drittes Auswahlkriterium herangezogen (Preismatching). Ziel des Suchprozesses ist es, potentielle Kontraktpartner durch Unterstützung der Softwareagenten zu finden, um mit diesen anschließend Transaktionspreise für die ermittelten Rentenpapiere verhandeln zu können. Die Preisfindung kann nach erfolgreicher Suche alternativ vollständig telefonisch durchgeführt werden oder über elektronische direkte Händlerkommunikation oder automatisiert durch bilaterale oder multilaterale Verhandlungen der Agenten oder über eine Auktion erfolgen. 5 Technische Umsetzung Die Plattform, die den Kern des elektronischen Matchingsystems darstellt, wurde auf Basis der FIPA-Spezifikation konzipiert [FIPA97]. Bild 2 zeigt den Aufbau der Plattform: 8

9 Agent Management System (AMS) Domain Independent Directory Facilitator (DIDF) Domain Specific Directory Facilitator (DSDF) Domain Specific Agent (DSA) Agent Communication Channel (ACC) Agent Communication Channel (ACC) Agent Communication Channel (ACC) Agent Communication Channel (ACC) Agent Communication Channel (ACC) Agent Communication Channel (ACC) Agent Communication Channel (ACC) Agent Communication Channel (ACC) Agent Communication Channel Router (ACCR) Bild 2: Aufbau der Agentenplattform Eine Agentenplattform entspricht - logisch gesehen - einem Computer in einem Netzwerk. Um ein Matchingsystem implementieren zu können, bedarf es einiger betriebssystemähnlicher Grundfunktionalitäten. In der hier präsentierten Lösung werden die Basisfunktionalitäten von speziellen Agenten, den sogenannten Systemagenten, übernommen. Diese sind in Bild 2 hellgrau schattiert und als AMS, DIDF sowie ACCR bezeichnet. AMS und ACCR werden in 5.1, DIDF in 5.2 erläutert. Neben den Systemagenten gibt es anwendungsspezifische Agenten, die als Taskagenten bezeichnet werden und in Bild 2 dunkel eingezeichnet sind (DSDF bzw. DSA). Zu ihnen zählen die Agenten, die Händler vertreten, um z. B. ein Kontrahentenmatching durchzuführen. Diese speziellen Taskagenten werden im weiteren Verlauf Händleragenten genannt. Auf die Taskagenten wird in 5.2 näher eingegangen. 5.1 Basiskomponenten der Agentenplattform Grundlage der Agentenplattform bildet als Systemagent das Agent Management System (AMS). Dieses ist u. a. für die Instantiierung und das Löschen von Händleragenten verantwortlich. Auf jeder Plattform existiert genau ein AMS. Die Interagentenkommunikation erfolgt über den Agent Communication Channel Router (ACCR), der wie das AMS ein Systemagent ist und ebenfalls pro Plattform genau einmal existiert. Seine Aufgabe ist mit der eines Postboten vergleichbar; sie besteht im Routing der eingehenden und ausgehenden Nachrichten für bzw. von allen Agenten der Plattform. Die verbleibende Komponente, der Agent Communication Channel (ACC), dient als Briefkasten und als Verbindung zwischen ACCR und den Agenten der Plattform. Für jeden Agenten der Plattform gibt es einen ACC und einen zugeordneten ACC auf der Gegenstelle, dem ACCR (vgl. Bild 2). 9

10 5.2 Agenten zur Realisierung des Kontrahentenmatching Um eine schnelle Suche durchzuführen, werden die Händleragenten vom Matchingsystem gruppiert und in sogenannte Domänen eingeteilt. Domänen werden anwendungsspezifisch festgelegt. Sie gruppieren Elemente mit gleichen Eigenschaften. Gruppierungsmerkmale sind dabei für den Rentenhandel das zu handelnde Produkt (Pfandbrief, Bundesanleihe etc.) und die zugehörige Restlaufzeit (bis 2 Jahre, 2-5 Jahre etc.). Realisiert wird die Domänenbildung durch zwei spezielle Agenten der Plattform, die als Verzeichnisdienst arbeiten und mit den Händleragenten interagieren. Der erste Verzeichnisdienst wird durch einen Systemagenten abgebildet. Dieser wird Domain Independent Directory Facilitator (DIDF) genannt und dient dazu, Informationen über die Zusammensetzung des gesamten Systems (d. h. welche Plattformen am Gesamtsystem beteiligt sind) und Informationen über lokal präsente Domänen zu liefern. Er speichert dazu die Adressen aller entfernten DIDFs sowie die Adressen der lokalen Domänen. Informationen darüber, welche entfernten Plattformen sich im System befinden, erhält der DIDF, nachdem er gestartet wurde. Er synchronisiert sich dazu mit einem DIDF einer bereits existierenden Plattform und registriert sich bei allen ihm bei der Synchronisation übermittelten DIDFs, so daß jeder DIDF alle entfernten Plattformen kennt. Jeder Händleragent gehört einer bestimmten Domäne an (z. B. Jumbo-Pfandbrief mit 2-5 Jahren Restlaufzeit). Adressen von Händleragenten einer Domäne werden in dem zweiten Verzeichnisdienst, dem sogenannten Domain Specific Directory Facilitator (DSDF) abgelegt und können dort abgerufen werden. Genutzt werden beide Informationsquellen von Händleragenten, den Domain Specific Agents (DSA). Diese stellen an die Verzeichnisdienste aller im System befindlichen Plattformen Anfragen, um potentielle Kontrahenten zu identifizieren. Ein DSA repräsentiert einen Händler und wird von diesem parametrisiert. Die Verbindung zwischen Händler und seinem Agenten erfolgt durch entsprechende Nachrichten, die der Händler an seinen Agenten schickt. Aufgrund der Parametrisierung seitens des Händlers wird der Agent in eine oder mehrere Domänen eingeordnet und entsprechend bei den zugehörigen lokalen DSDFs registriert. Daher muß ein Händleragent im Vergleich zu einem Systemagent über folgende zusätzliche Funktionalität verfügen: Empfang und Interpretation der Parametrisierung/Händleranweisungen, Registrierung in den lokalen DSDFs gemäß seiner Parameterwerte, Durchführung der ihm zugedachten Aufgaben anhand der vom Händler vorgenommenen Parametrisierung sowie Senden von Statusmeldungen an den Händler. Das Zusammenspiel der beschriebenen Komponenten wird im folgenden anhand des Kontrahentenmatchings vorgestellt. 10

11 6 Kontrahentenmatching mit Softwareagenten Anhand eines konkreten Beispiels soll im folgenden gezeigt werden, wie mit Hilfe der oben erläuterten Agentenplattform ein elektronisches Kontrahentenmatching durchgeführt wird. Das Kontrahentenmatching erfolgt in vier Schritten: 1. Identifikation der Plattformen des Systems, 2. Identifikation der Plattformen, die die gesuchte(n) Domäne(n) vertreten, 3. Identifikation der Agenten, die der/den gesuchten Domäne(n) angehören sowie 4. Matching der vom Händler spezifizierten Parameter Zur Erläuterung des Matching wird folgender vereinfachter Sachverhalt angenommen: Im Beispiel sind drei Händler aktiv und jeweils durch einen Agenten im System repräsentiert. Relevante Parameter sind das zu handelnde Produkt, die Restlaufzeit, der minimale bzw. maximale Coupon und der Name des Instituts. Zur Verdeutlichung der plattformübergreifenden Funktionsweise des Matchingsystems lebt im Beispiel jeder der drei Agenten auf einer eigenen Plattform. Die Konfiguration der einzelnen Agenten zeigt Tabelle 1: Agent Händler Institut Produkt Restlaufzeit Coupon H1 Petra Dörr Dresdner Bank Jumbo 4-6 Jahre 4-6% H2 Doug Berry Morgan Stanley Bundesanleihen 5-8 Jahre 3-6% H3 Michael Dom Deutsche Bank Jumbo 2-4 Jahre 4-6% Tabelle 1: Konfiguration der Händleragenten Als Attribute zur Festlegung der Domänen werden das Produkt und die Restlaufzeit verwendet. Als Ausprägungen sind Restlaufzeiten von kleiner 2 Jahre, 2-5 Jahre, 5-10 Jahre und Jahre möglich. Im folgenden wird eine Domäne mit der Notation (Produkt-minLaufzeit-maxLaufzeit) bezeichnet, z. B. (J-2-5) für Jumbo-Pfandbriefe mit einer Restlaufzeit von zwei bis fünf Jahren. Die Agenten H2 und H3 seien bereits in den DSDFs B-5-10 (H2) bzw. J-2-5 (H3) registriert. Agent H1 wird nun von der Händlerin konfiguriert und vom AMS erzeugt. Er registriert sich bei seinen DSDFs (J-2-5 und J-5-10) und beginnt mit dem Kontrahentenmatching. Die vier Schritte des Kontrahentenmatching nach dem Eintritt von H1 sind in Bild 3 dargestellt: 11

12 Handelssystem Agentenplattform I Agentenplattform II AMS DIDF DSDF J-2-5 DSDF J-5-10 Agent H1 AMS DIDF DSDF B-5-10 Agent H ACCR ACCR Agentenplattform III AMS DIDF DSDF J-2-5 Agent H ACCR Bild 3: Zusammenspiel der einzelnen Agenten beim Kontrahentenmatching Schritt 1: Zunächst ermittelt der Händleragent H1, welche Plattformen zum System gehören. Dazu erfragt er bei seinem lokalen DIDF (Plattform I) die Liste der entfernten DIDFs (Verbindung 1). Schritt 2: H1, der aufgrund seiner Konfiguration den Domänen Jumbo 2-5 (J-2-5) und Jumbo 5-10 (J-5-10) angehört, erfragt bei allen ihm übermittelten DIDFs, welche DSDFs dort registriert sind (Verbindung 2). Schritt 3: H1 befragt die DSDFs seiner Domänen (J-2-5 und J-5-10) nach dort registrierten Agenten. Dies sind die DSDFs J-2-5 und J-5-10 auf der Plattform I sowie der DSDF J-2-5 der Plattform III (Verbindung 3). Schritt 4: Lediglich Agent H3 ist in einer Domäne registriert, der auch H1 angehört. Im abschließenden Schritt (Verbindung 4) wird ein Attributvergleich bezüglich des letzten verbleibenden Attributs durchgeführt. Da sowohl H1 als auch H3 in Papieren handeln wollen, die einen Coupon von 4-6% aufweisen, war das Matching erfolgreich. Mit Hilfe der Einteilung der Händleragenten in Domänen und dem Einsatz der Verzeichnisdienste wird eine Vorselektion potentieller Kontrahenten durchgeführt. Die Registrierung der Händleragenten bei den DSDFs garantiert ein erfolgreiches Suchen, sofern mindestens ein Agent der gleichen Domäne angehört. Durch den Einsatz eines Agenten ist der Händler in der Lage, gleichzeitig alle passenden Kontrahenten durch eine einzige Spezifikation seiner Order zu identifizieren. Dadurch wird ein performantes Matching erzielt. Seitens der Architektur des Systems gibt es keine Beschränkung bezüglich der Anzahl von Händleragenten auf der Plattform. Engpässe sind folglich nicht durch die Konzeption des Systems bedingt, sondern werden von der zugrunde liegenden Hardware determiniert. Weiterhin kann das System aus einer beliebigen Anzahl von Plattformen bestehen, die auch während des laufenden Betriebs hinzugefügt werden können, ohne die Funktionsfähigkeit des Systems zu beeinträchtigen. Die Skalierbarkeit ist folglich gegeben. 12

13 Um die Verfügbarkeit zu gewährleisten, sollte das System aus mindestens zwei Agentenplattformen bestehen. Jede einzelne Plattform bietet die vollständige Funktionalität, so daß bei Ausfall einer Plattform das System noch funktionsfähig ist. Basis des performanten Matchingprozesses ist eine effiziente Verwaltung und Registrierung von Agenten. Zur Vermeidung dedizierter Komponenten gibt es keine zentrale Stelle, die eine plattformübergreifende Agentenverwaltung realisiert. Diese wird vielmehr auf die einzelnen Plattformen aufgeteilt, die sich synchronisieren, um über konsistente Daten zu verfügen. Die Verfügbarkeit wird somit durch die Trennung in mehrere Plattformen und durch die Aufteilung der Agentenidentifikation auf die dezentralen Agenten DIDF und DSDF sichergestellt. Die Anbindung weiterer Agenten ist sowohl von der konzeptionellen als auch der implementationstechnischen Seite her unproblematisch. Konzeptionell wird ein Agent (sowohl ein System- als auch ein Taskagent) zur Plattform hinzugefügt, indem eine entsprechende Nachrichtenbox (ACC) für ihn bereitgestellt wird. Dadurch ist es auch möglich, Agenten hinzuzufügen, die Schnittstellen zu externen Systemen bilden. Diese Art von Erweiterung kann während der Laufzeit erfolgen. Durch die Trennung von DIDF und DSDF kann das Matchingsystem auf andere Bereiche wie Aktien- oder Derivatehandel erweitert werden, wobei der Handel aller Produkte (theoretisch) trotzdem auf einer einzelnen Plattform durchgeführt werden kann. Für die prototypische Realisierung wurde auf die Einbindung von kryptografischen Verfahren und weitere Maßnahmen zur Realisierung der Systemsicherheit verzichtet. Prämisse des Einsatzes des Matchingsystems ist deshalb das Vorhandensein eines abgesicherten Computernetzwerks, wie es z. B. von der Deutschen Börse AG zur Verfügung gestellt wird. Die Agentenplattform ist vollständig objektorientiert modelliert (nach [CoYo91]) und in der Programmiersprache Java (mit Hilfe des JDK von SUN [SUN98]) implementiert. 7 Zusammenfassung und Ausblick Der OTC-Markt hat eine große Bedeutung am gesamten Wertpapierhandel. Dies gilt insbesondere für den Rentenmarkt. Der größte Umsatzanteil im Rentenhandel wird heute telefonisch zwischen Wertpapierhändlern abgewickelt. In den meisten Fällen - vor allem beim Blockhandel - wird zudem ein Broker zur Vermittlung des Geschäfts hinzugezogen. Diese Vorgehensweise ist zeitintensiv und verursacht hohe Transaktionskosten. Ein Ansatz zur effizienten Gestaltung des Rentenhandels ist die Nutzung elektronischer Rentenhandelssysteme. Diese werden jedoch seitens der Marktteilnehmer kaum akzeptiert, da sie die Anforderungen der Händler nicht in ausreichendem Maße erfüllen. Ein wichtiger Ansatz zur Überwindung dieser Problematik ist das von der Deutschen Börse AG im Herbst 1998 eingeführte Release 3 von Xetra. Eine Ergänzung für bestimmte Marktsegmente kann ein agentenbasiertes System darstellen. Dieses ermöglicht dem Händler, seine Transaktionswünsche und gegebenenfalls Verhandlungsstrategien dem Agenten mitzuteilen. Die Grundbausteine des elektronischen Handelssystems bilden dabei Agenten, die einerseits die Präferenzen des Händlers abbilden und ihm die zeitaufwendige Kontrahentensuche abnehmen, andererseits den Betreibern des 13

14 elektronischen Handelssystems die Chance bieten, Erweiterungen in funktionaler und technischer Sicht jederzeit vornehmen zu können. Je nach Spezifikation des Händlers [BuGo99] kann der Agent entweder eine Suche nach geeigneten Partnern, d. h. Agenten anderer Marktteilnehmer, durchführen und die Ergebnisse der Suche anschließend dem Händler mitteilen, damit dieser die weiteren Verhandlungen persönlich durchführt, oder selbständig Verhandlungen durchführen. Für diesen Zweck werden spezielle Verhandlungs- bzw. Auktionsmechanismen entwickelt. Nach der Implementierung ist die Systemevolution vorgesehen. In dieser Phase können weitere Koordinationsmechanismen zur Preisfindung implementiert werden, Tauschgeschäfte (Papier-gegen-Papier) zwischen Händlern vorgesehen werden sowie Anbindungen des Systems an bestehende Handelssysteme erfolgen. Zusätzlich werden alternative Marktmikrostrukturen experimentell im Hinblick auf Liquidität, Effizienz und Transaktionskosten getestet, um die so gewonnenen Erkenntnisse in einem nachfolgenden Release umzusetzen. 8 Literaturverzeichnis [BuGo99] Budimir, M.; Gomber, P.: Dynamische Marktmodelle im elektronischen Wertpapierhandel. Erscheint in: Tagungsband Wirtschaftsinformatik 99. Physica-Verlag, Heidelberg [BuOH87] Burdett, K.; O Hara, M.: Building Blocks: An Introduction to Block Trading. In: Journal of Banking and Finance 11 (1987), S [Büsc93] Büschgen, H. E.: Bankbetriebslehre: Bankgeschäfte und Bankmanagement. 4., vollständig überarbeitete und erweiterte Auflage, Gabler, Wiesbaden [CoYo91] Coad, P.; Yourdon, E.: Object Oriented Analysis. 2. Aufl., Prentice Hall, Englewood Cliffs [DeKi96] Deutsch, J.; Kirschner, W.; Petit, H.: Perspektiven des Pfandbriefmarktes. In: Die Bank (1996) 1, S [Domo92] Domowitz, I.: Automating the Price Discovery Process: Some International Comparisons and Regulatory Implications. In: Journal of Financial Services Research (1992), S [EaOH92] Easley, D.; O Hara, M.: Adverse Selection and Large Trade Volume: The Implications for Market Efficiency. In: Journal of Financial and Quantitative Analysis 27 (1992) 2, S [FIPA97] Foundation for Intelligent Physical Agents (FIPA): FIPA 97 Specification, Version

15 [FrGr97] Franklin, S.; Graesser, A.: Is it an Agent or just a Program? A Taxonomy for Intelligent Agents. In: Müller, J.P; Wooldridge, M.; Jennings, N. (Hrsg.): Intelligent Agents III Agent Theories, Architectures and Languages. Lecture Notes in Artificial Intelligence Springer Verlag, Berlin 1997, S [GrGr95] Grill, W.; Gramlich, L.; Eller, R. (Hrsg.): Gabler Bank Lexikon. 11., vollständig neu bearbeitete und erweiterte Auflage, Gabler, Wiesbaden 1995 (1. Auflage 1953). [GoBu98] Gomber, P.; Budimir, M.; Kosciankowski, K.; Urtheil, R.: Elektronisierung des außerbörslichen Rentenhandels auf Basis von Softwareagenten. In: Weinhardt, Ch.; Meyer zu Selhausen, H.; Morlock, M. (Hrsg.): Informationssysteme in der Finanzwirtschaft. Springer, Heidelberg et al. 1998, S [GrTh94] Greenbaum, S. I.; Thakor, A.V.: Contemporary Financial Intermediation. Dryden, Fort Worth u. a [JeWo96] Jennings, N.; Wooldridge, M.: Software Agents. In: IEEE Review (1996)1, S [Kran96] Krannich, L.: Risiken der Wertpapierleihe und Wertpapierpensionsgeschäfte. In: Eller, R. (Hrsg.): Handbuch Derivater Instrumente: Produkte, Strategien, Risikomanagement. Schäffer- Poeschel, Stuttgart [LoNo98] Lohmann, M.; Nopper, N.; Henning, P.: Elektronisches Kontrahentenmatching im agentenbasierten Wertpapierhandel. In: Weinhardt, Ch.; Meyer zu Selhausen, H.; Morlock, M. (Hrsg.): Informationssysteme in der Finanzwirtschaft. Springer, Heidelberg et al. 1998, S [Lüde96] Lüdecke, T.: Struktur und Qualität von Finanzmärkten. Gabler, Wiesbaden [MaCh97] Madhavan, A.; Cheng, M.: In Search of Liquidity: Block Trades in the Upstairs and Downstairs Markets. In: The Review of Financial Studies 10 (1997) 1, S [PaRö96] Pagano, M.; Röell, A.: Transparency and Liquidity: A Comparison of Auction and Dealer Markets with Informed Trading. In: The Journal of Finance 51 (1996) 2, S [Stig83] Stigum, M.: The Money Market. 2 nd, revised edition, Dow Jones-Irwin, 1983 (1 st edition 1978). [SUN98]: Sun Microsystems: The Java Development Kit (JDK) [WeGo99] Weinhardt, Ch.; Gomber, P.: Elektronisierung des außerbörslichen Wertpapierhandels - ein finanzwirtschaftlich und mikroökonomisch basierter Multi-Agenten-Ansatz. In: Wirtschaftsinformatik, 41(1999)1. [WoJe95] Wooldridge, M.; Jennings, N.: Intelligent Agents Theories, Architectures, and Languages. Lecture Notes in Artificial Intelligence 890. Springer Verlag, Berlin

16 Autorenadressen: Dipl.- Kaufmann Peter Gomber, Dipl.- Kaufmann Miroslav Budimir Lehrstuhl für BWL-Wirtschaftsinformatik, Universität Gießen Licher Str. 70, D Gießen {peter.gomber Dipl.- Ökonom Klaus Kosciankowski, Dipl.- Betriebswirt Robert Urtheil Deutsche Börse AG Frankfurt/M. {klaus_kosciankowski Dipl.- Wirtschaftsinformatiker Markus Lohmann Dresdner Bank AG Jürgen-Ponto-Platz Frankfurt/M. markus.lohmann@dresdner-bank.com Dipl.- Informatiker Norbert Nopper living systems AG Roggenbachstr VS-Villingen norbert.nopper@living-systems.de Prof. Dr. Peter Henning MediaLab, Fachhochschule Karlsruhe Karlsruhe p.henning@fh-karlsruhe.de 16