Agentenbasierter Rentenhandel

1 Einführung

Im Wertpapierhandel ist die Entwicklungzu einem rein computerbasierten Handelunumkehrbar. Trotzdem wird in verschie-denen Marktsegmenten immer noch diedirekte menschliche Interaktion via Tele-fon bevorzugt. Dieser außerbörsliche

(Over the counter, OTC) Handel findetbevorzugt in Werten statt, in denen dieBörse als zentraler Platz zur Preisfindungnicht benötigt wird – wie z.B. bei festver-zinslichen Wertpapieren (Renten) oderDerivaten, deren Ausgestaltung von dennormierten Produkten der Terminbörsenabweicht (z.B. Swaps). Die erheblichenTransaktionskosten, die bereits ex antestark reduzierte Anzahl möglicher Kon-traktpartner und die fehlende integrierteProzeßkette von Handel und Abwicklungsind die wesentlichen Problemfelder desOTC-Handels. Es liegt eine nur begrenzteTransparenz des Preisbildungsprozessesvor. Dies führt zu einer deutlichen Reduk-tion der Effizienz auf dem OTC-Markt.Trotzdem dominiert der außerbörslicheHandel den Börsenhandel in den genann-ten Wertpapiersegmenten bezüglich dergehandelten Volumina deutlich. Der An-teil des außerbörslichen Handel in deut-schen Rentenwerten wird auf ca. 90% ge-schätzt, genaue Zahlen sind aufgrund derFragmentierung sowie der Intransparenzdieses Marktes nur schwer zu erheben.

Die große Bedeutung des OTC-Handelsund der Versuch, die Ineffizienzen desOTC-Marktes zu überwinden, sind Anlaßeines Forschungsprojektes, das die Pro-jektpartner Deutsche Börse AG, Compaq

Computer GmbH (vormals: Digital Equip-ment GmbH) und living systems AG unterProjektleitung des Lehrstuhls BWL-Wirt-schaftsinformatik der Justus-Liebig-Uni-versität Gießen durchführten. Im Rahmendes Projektes wurde ein – auf der Techno-logie der Softwareagenten basierendes –elektronisches Handelssystem für denRentenhandel konzipiert und prototy-pisch umgesetzt. Mit dem Paradigma derSoftwareagenten (im folgenden kurz:Agenten) sollen die Charakteristika der ge-handelten Objekte, der Marktprozesseund der Verhaltensweisen der Marktteil-nehmer im Rentenhandel so abgebildetwerden, daß das System dem konventio-nellen Handel über Telefon und Brokervorgezogen wird [WeGo99a].

Diese Arbeit stellt das Projekt sowohlaus finanzwirtschaftlich/funktionaler alsauch aus technischer Sicht vor: Im zwei-ten Abschnitt wird der außerbörslicheWertpapierhandel kurz erläutert. Die be-stehenden Systeme zur Unterstützung deselektronischen Rentenhandels und dieAufnahme des elektronischen Rentenhan-dels durch die Deutsche Börse AG mit Ein-führung von Xetra® (Exchange ElectronicTrading) Release 3 werden in Abschnitt 3dargestellt. Kapitel 4 erläutert das Poten-tial der Agententechnologie für die Elek-tronisierung dieses Marktsegments, stelltdie Anforderungen an das zu entwickeln-de Handelssystem dar und zeigt auf, wa-rum das Agentenparadigma ein geeigneterLösungsansatz ist. Abschnitt 5 erläutert dieArchitektur des Systems, während dersechste Abschnitt die technische Umset-zung aufzeigt. Eine Zusammenfassung undein Ausblick auf weitere Projektschritteschließen die Arbeit ab.

2 Der außerbörslicheWertpapierhandel

Teilnehmer im OTC-Markt sind Banken,Broker und Wertpapierhäuser sowie de-ren Kunden, zumeist institutionelle Inves-toren [GrGr95]. Der Handel findet meistper Telefon statt, dies ermöglicht denHändlern maßgeschneiderte Vertragsge-staltungen. Die relevanten Parameter wieetwa Kontraktgröße, Laufzeit und Nomi-nalbetrag können individuell vereinbartwerden. Somit wird ein hohes Maß an Fle-xibilität erzielt, außerdem sind die Händ-ler nicht auf feste Börsenzeiten angewie-sen. Die Kommunikation zwischen den

124

AgentenbasierterRentenhandel1

Peter Gomber, Miroslav Budimir,Klaus Kosciankowski, Robert Urtheil,Markus Lohmann, Norbert Nopper, Peter Henning

WIRTSCHAFTSINFORMATIK 41 (1999) 2, S. 124 – 131

Dipl.-Kaufmann Peter Gomber, Dipl.-Kaufmann Miroslav Budimir, Lehrstuhl fürBWL-Wirtschaftsinformatik, UniversitätGießen, Licher Str. 70, D-35394 Gießen, E-Mail: {peter.gomber|miroslav.budimir}@wirtschaft.uni-giessen.deDipl.-Ökonom Klaus Kosciankowski,Dipl.-Betriebswirt Robert Urtheil, DeutscheBörse AG, D-60284 Frankfurt/M., E-Mail:{klaus_kosciankowski|robert_urtheil}@exchange.deDipl.-Wirtschaftsinformatiker Markus Loh-mann, Stadtmauer 29, D-59872 Meschede,E-Mail: [email protected] Norbert Nopper,living systems AG, Roggenbachstr. 1,D-78050 VS-Villingen, E-Mail: [email protected]. Dr. Peter Henning, MediaLab, Fach-hochschule Karlsruhe, D-76012 Karlsruhe,E-Mail: [email protected]

WI – Schwerpunktaufsatz

Handelspartnern kommt entweder direktzustande oder wird von Brokern vermit-telt.

„Brokers bring buyers and sellers toge-

ther for a commission. By definition, bro-

kers never position securities. Their func-

tion is to provide a communications net-

work that links market participants who

are often numerous and geographically

dispersed“ [Stig83, 29]. Ein zentralerGrund für die Existenz des Brokers ist dieoft fehlende Liquidität im Börsenhandel(z.B. bei Pfandbriefen [DeKi96]). Über diereine Partnersuche hinaus bieten Brokerauch die Orderpflege, die Durchführungvon Plausibilitätsprüfungen und/oder Re-search an. Außerdem besteht die Aufgabedes Brokers darin, Handelsstrategien odergrößere Orders – welche ungewünschteKursveränderungen verursachen könnten– so auszuführen, daß die Kunden mög-lichst geringen negativen Preiseffektenausgesetzt werden [MaCh97; GeRa92].

Beim Handel größerer Volumina – sog.Blockhandel – kann die Ordergröße vonden Marktteilnehmern als Signal für priva-te Informationen gedeutet werden und zuadversen Preiseffekten führen [EaOH92;BuOH87]. Aus diesem Grund sind dieHändler daran interessiert, die Informa-tion über ihre Blockorders vor dem Marktzu „verstecken“ und engagieren einenBroker. Dieser soll eine entsprechendeGegenpartei finden und dabei dem Marktkeine Informationen über die Blockorderpreisgeben.

Das Einschalten eines Brokers verlän-gert die Intermediationskette zwischenKäufer und Verkäufer des Wertpapiersund erhöht somit die Transaktionskosten– z.B. durch anfallende Brokercourtage[GrTh94]. Trotz der hohen Kosten werdenDienstleistungen der Broker in Anspruchgenommen, da die Suche nach Verhand-lungspartnern äußerst zeitintensiv ist.

3 Rentenhandel imSystem Xetra®

Die Rahmenbedingungen für den Renten-handel haben sich entscheidend verän-dert. Die Einführung der gemeinsamen eu-ropäischen Währung schafft den zweit-größten Rentenmarkt der Welt und stärktdie Rolle von Xetra® als standortunabhän-gige Handelsplattform. Der Handel inBenchmark-Anleihen ist bereits heutestark internationalisiert, ca. 50% des Um-

satzes in deutschen Staatsanleihen wirdmit ausländischen Counterparts getätigt.Der zunehmende Konzentrationsprozeßim Bankenwesen verstärkt den Kosten-druck und fördert Systeme mit integrierterProzeßkette (Handel und Abwicklung)und niedrigen Transaktionskosten.

Der elektronische Rentenhandel hat inden vergangenen Jahren zunehmend anBedeutung gewonnen. So hat sich die An-zahl elektronischer Transaktionssystemeim amerikanischen Rentenmarkt von 12in 1997 auf 24 in 1998 verdoppelt. DieDeutsche Börse AG unterstützt den Ren-tenhandel seit dem 5. Dezember 1995 mitdem Rentenhandelssystem IBIS-R, wel-ches am 12. Oktober 1998 mit der Einfüh-rung von Xetra® Release 3 eingestelltwurde.

Mit Xetra® Bond Trading implemen-tierte die Deutsche Börse ein modularesMarktmodell, welches auf die unter-schiedlichen Handels- und Marktsegmen-te zugeschnitten werden kann. So könnenhochliquide Werte (zum Start von Release3 sind dies die in Futures lieferbaren Wer-te und 30-jährige Anleihen sowie die Jum-bo-Pfandbriefe) fortlaufend gehandeltwerden, weniger liquide Werte werden inAuktionen gehandelt. Während im fort-laufenden Handel nur Round lot orderszugelassen sind, und damit der Wholesale-handel unterstützt wird, können in denuntertägigen Auktionen (für alle Wertpa-

piere) alle Ordergrößen und damit das Re-tailgeschäft ausgeführt werden. Das Or-derbuch ist sowohl im fortlaufenden Han-del als auch in den Auktionen offen, denTeilnehmern werden die zum jeweiligenLimit kumulierten Volumina angezeigt. Imfortlaufenden Handel findet ein automati-sches Matching statt: sich gegenüberste-hende ausführbare Orders werden auto-matisch zusammengeführt. Dabei werdensowohl Limit- als auch Marketorders un-terstützt, die jeweils durch verschiedeneGültigkeitsbeschränkungen ausgestaltetwerden können.

Im Dezember 1998 waren über 280Marktteilnehmer an Xetra angebunden,davon mehr als 35 aus dem europäischenAusland. Dies unterstreicht die internatio-nale Ausrichtung des kommenden euro-päischen Rentenmarktes.

4 AgentenbasierterRentenhandel

Im folgenden wird die Konzeption einesagentenbasierten Rentenhandelssystemsauf der Basis der Agententechnologie vor-gestellt. Diese Technologie ermöglicht dieRealisierung neuer Such- und Verhand-lungsstrategien, birgt Potential zur Elek-tronisierung des außerbörslichen Renten-handels und kann insbesondere für den

125

Agentenbasierter Rentenhandel

Kernpunkte für das Management

Der Beitrag stellt die Ergebnisse eines Kooperationsprojektes der DeutscheBörse AG, Compaq Computer GmbH (vormals: Digital Equipment GmbH),living systems AG und des Lehrstuhls BWL-Wirtschaftsinformatik, Uni-versität Gießen vor. Ziel war die prototypische Realisierung einesElektronischen Handelssystems für den Rentenmarkt. Motivation für diesesProjekt sind die hohen Transaktionskosten und die mangelnde Effizienzdes 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 hoheEffizienzvorteile zu erwarten.

• Das Paradigma der Softwareagenten erweist sich insbesondere für dieKontrahentensuche als ein sehr leistungsfähiger Ansatz.

• Eine objektorientierte Modellierung sowie eine auf der FIPA-Spezifi-kation basierende Architektur stellen die Erweiterbarkeit, Verfügbarkeit,Skalierbarkeit und Performance des Systems sicher.

Stichworte: Rentenhandel, Elektronische Handelssysteme, Softwareagenten,OTC-Markt

Blockhandel sowie für den Handel in illi-quiden Werten eine wertvolle Ergänzungdes Rentenhandels in Xetra® Release 3darstellen.

4.1 FunktionaleAnforderungen an dasagentenbasierteRentenhandelssystemDas Handelssystem soll einen fortlaufen-den Handel in öffentlichen Anleihen, Jum-bo-Pfandbriefen und klassischen Pfand-briefen ermöglichen und den Anforderun-gen der Wertpapierhändler gerecht wer-den. Zu diesem Zwecke wurden mitHändlern verschiedener Banken undWertpapierhandelshäuser umfassende In-terviews geführt, um die Ist-Situation zuanalysieren und die Anforderungen derMarktteilnehmer zu ermitteln.

Am OTC-Markt gibt es kein Orderbuch;Partnersuche und Preisfindung erfolgenjeweils bilateral zwischen den Händlern.Die Partnersuche sollte daher auch im Sy-stem individuell ausgestaltet werden. ImIdealfall sollte jeder Transaktionswunscheines Händlers mit allen Transaktions-wünschen aller am System teilnehmendenHändler abgeglichen werden, um Über-einstimmungen bezüglich der Wertpapie-re und der Konditionen zu erhalten. DasSystem soll die Marktteilnehmer bei ak-zeptablem Kommunikations- und Zeitauf-wand in die Lage versetzen, potentielleKontraktpartner zu identifizieren, um mitdiesen die Vertragskomponenten bilateralauszuhandeln.

Darüber hinaus sind im Systemkonzeptauch die im OTC-Markt vorhandenen Risi-ken zu berücksichtigen, insbesondere dasWiederbeschaffungsrisiko. Dabei handeltes sich um das Preisänderungsrisiko, dassich ergibt, wenn der vereinbarte Handelaufgrund der Nichtzahlung bzw. Nichtlie-ferung durch einen Kontraktpartner nichtausgeführt wird und das Papier vomMarkt – eventuell zu einem ungünstigerenPreis – beschafft werden muß [Büsc93,774; Kran96]. Daher ist ein entsprechen-des Kontrahentensuchkonzept zu realisie-ren, um den teilnehmenden Banken bzw.Händlern die Möglichkeit zu bieten, denPartnersuchraum auf Basis individuellerBewertungskriterien einzustellen. So ent-stehen individuelle Suchräume, die derHändler aus der Einschätzung der Kontra-hentenbonität, der Häufigkeit und Quali-

tät vergangener Transaktionen, der Dring-lichkeit des aktuellen Transaktionswun-sches usw. herleiten kann [WeGo99b].

Darüber hinaus müssen auch solcheTransaktionsinteressen im System aus-führbar sein, bei denen kein konkretesWertpapier angegeben wird, sondern po-tentiell interessierende Coupongrößen,Laufzeiten und/oder Emittenten spezifi-ziert werden, um so – analog dem Tele-fonhandel – mit noch sehr unscharfen An-gaben andere Markteilnehmer zu suchenund zu finden.

Das Handelssystem, das den Renten-händler unterstützen soll, muß folgendeAnforderungen erfüllen: Die Repräsenta-tion der zu handelnden Papiere, die Iden-tifikation potentieller Kontraktpartner,der Abgleich der Wertpapiereigenschaf-ten, eine Präsentation der Vertragsvor-schläge beim auftraggebenden Händlerund nicht zuletzt Kompetenz zur Führungbilateraler Vorverhandlungen bzw. zurTeilnahme an einer Auktion.

4.2 TechnischeAnforderungen an dasagentenbasierteRentenhandelssystemIn diesem Abschnitt werden die wichtigs-ten Anforderungen aus technischer Sichterläutert:

Die Performance des zu entwickelndenMatchingsystems wird von der Zeitspan-ne determiniert, in welcher die Identifika-tion der potentiellen Kontraktpartner undder Abgleich der Eigenschaften der gehan-delten Objekte durchlaufen werden. DasSystem wird nur dann erfolgreich sein,wenn es dem Händler eine Zeitersparnisbringt und gleichzeitig die Kosten für dieInformationsbeschaffung deutlich redu-ziert.

Der Erfolg eines EHS ist auch daran zumessen, wie viele Handelsteilnehmer dasSystem einsetzen. Aus diesem Grund mußdas Matchingsystem so konzipiert wer-den, daß die Teilnehmerzahl nicht vonvornherein beschränkt oder gar fixiert ist.Das System muß folglich skalierbar sein.

Elektronische Handelssysteme müssensich durch eine ständige Verfügbarkeit

auszeichnen, d.h. sie müssen während derHandelszeiten stets einsetzbar sein. Dieskann nur gewährleistet werden, wennsich keine dedizierten Komponenten imSystem befinden. Bei einem eventuellen

Ausfall einzelner Komponenten soll aufsolche mit identischem Funktionsumfangumgeschaltet werden können. Eine Mög-lichkeit, eine derartige gewünschte Re-dundanz zu schaffen, ist die Verwendungeiner dezentralen Lösung. Für das Mat-chingsystem ist daher eine Architektur zukonzipieren, die aus mehreren gleichbe-rechtigten Komponenten besteht, von de-nen jede den notwendigen Funktionsum-fang für ein Kontrahentenmatching abbil-det.

Ebenso sollte es möglich sein, beste-hende Systeme koppeln zu können, um ei-nen Investitionsschutz der Betreiber zu ge-währleisten. Durch die Kopplung an ex-terne Systeme kann zudem eine Erweite-

rung des implementierten Matchingpro-zesses notwendig sein.

Ein weiteres Kriterium zur Sicherungder Akzeptanz ist die Gewährleistung derSicherheit. Ein elektronisches Handelssy-stem ist dann als sicher zu bezeichnen,wenn keine Manipulationsmöglichkeitenvorgenommen und keine Informationenextrahiert werden können, die nicht vomBetreiber des Systems freigegeben wer-den.

Darüber hinaus sollten die Plattformun-abhängigkeit und die Integrationsmög-lichkeit in eine heterogene Rechnerumge-bung als generelle Anforderungen erfülltsein.

4.3 Das Paradigma derSoftwareagentenDie genannten Anforderungen könnenmit Hilfe einer modernen Softwaretechno-logie erfüllt werden – den Softwareagen-ten. Agenten werden in der Literatur aus-giebig diskutiert [WoJe95; FrGr97], eineeinheitliche Definition ist jedoch nichtverfügbar.

Eine anerkannte, jedoch recht grobe,Charakterisierung von Agenten liefernJennings und Wooldridge [JeWo96]. Da-bei werden Agenten als Stellvertreter an-gesehen, die im Auftrag eines Benutzershandeln und die folgenden Eigenschaftenaufweisen: Autonomie (Agenten solltenin der Lage sein, die ihnen übertragenenAufgaben ohne Hilfe von außen zu lösen),soziales Verhalten (Agenten interagierenmit anderen Agenten und dem Benutzer),Reaktionsvermögen (Wahrnehmung derSystemumgebung und deren Veränderun-gen) und Bewußtsein (nicht nur Reaktion

126

Peter Gomber, Miroslav Budimir, Klaus Kosciankowski, Robert Urtheil, Markus Lohmann, Norbert Nopper, Peter Henning

auf die Umwelt, sondern bei Bedarf Initia-tive und zielgerichtetes Handeln).

In einem elektronischen Handelssy-stem werden Orders eines Wertpapier-händlers durch je einen Agenten repräsen-tiert. Ein Händler übergibt einem Agentenden Auftrag, einen passenden Kontrahen-ten für eine Transaktion zu finden. DerAgent erledigt die Aufgabe ohne ständigeKommunikation mit „seinem“ Händler(Autonomie). Damit er seine Aufgabe er-füllen kann, interagiert ein Agent mit an-deren Agenten des Matchingsystems (so-ziales Verhalten). Da laufend weitere Or-ders (und damit Agenten) in das Systemeintreten und aus diesem wieder entnom-men werden, muß der Agent diese Verän-derungen seiner Umgebung sowohl wahr-nehmen als auch in die Lösung seiner Auf-gabe einfließen lassen können (Reaktions-vermögen). Ist ein Matching gescheitert,kann ein Agent im System verbleiben undselbständig entscheiden, wann er einenerneuten Versuch unternimmt, seine Auf-gabe zu erfüllen. Er ergreift die Initiative,z.B. nachdem er sich neue Informationenüber die aktuell im System verfügbarenAgenten beschafft hat (Bewußtsein).

Im folgenden wird ein Modell zur Elek-tronisierung des außerbörslichen Renten-handels auf Basis von Softwareagentendargestellt. Dafür wird zunächst dasMarktmodell skizziert und darauf aufbau-end die Kontrahenten- und Produktsuchesowie der Preisfindungsprozeß darge-stellt.

4.4 Systemkonzept4.4.1 Marktmodell

Die Struktur von Börsenmärkten wirddurch die Ausprägungen ihrer Struktur-merkmale [Lüde96] bestimmt. Im folgen-den werden die relevanten Parameter unddie Ausprägungen der Strukturmerkmaledes agentenbasierten Handelssystems vor-gestellt.

Die Ausprägung des Parameters Han-

delsfrequenz ist der fortlaufende Handel.Aufträge können so zu jeder Zeit währenddes Handelstages ausgeführt werden. AlsPreisermittlungsverfahren sind sowohl bi-laterale bzw. multilaterale Verhandlungenals auch von Agenten initiierte Auktionenmöglich. Die Markttransparenz bezeich-net die „visibility of the order flow“ [Pa-Rö96, 581]. Diese „visibility“ bezieht sichauf die Zeiträume vor der Preisermittlung(pre-trade-Markttransparenz), sowie auf

vollzogene Transaktionen (post-trade-Markttransparenz). Die pre-trade-Markt-transparenz ist im Handelssystem auf-grund der adversen Informationseffekteauf die Angaben über den aktuellen „Sy-stemtraffic“, d.h. der Zahl aktiver Agentenbeschränkt. Die post-trade-Markttranspa-renz ist durch den jeweiligen Systembe-treiber einstellbar.

Die Partnersuche des agentenbasiertenHandelssystems ist vollständig automati-siert. Die Preisfindung in der Abschluß-phase kann optional von Agenten durch-geführt werden. Agenten sollten in derLage sein, sofern der Händler dies zuläßt,mit den Agenten potentieller Kontrakt-partner zu verhandeln bzw. Auktionen zuinitiieren. Die „... basic function of any tra-ding market mechanism“ [Domo92], dieautomatisierte Preisfindung, soll auch indiesem System gewährleistet sein.

4.4.2 Such- undPreisfindungsprozeß

Aufgrund des modularen Aufbaus des Sy-stems ist es möglich, Such- und Preisfin-dungsprozesse isoliert zu betrachten.Bild 1 stellt die im System realisierten, al-ternativen Such- und Verhandlungspfadedar. Die schattierten Flächen sind die Be-reiche, in denen die Agenten autonomagieren, die nicht schattierten Flächen zei-gen die Bereiche, in denen Händler mitdem System und/oder anderen Händlerninteragieren.

Nach der Spezifikation des zu handeln-den Wertpapiers und der gewünschtenKontraktpartner „beauftragt“ der Händlerden Agenten mit der Suche. Dazu identifi-ziert der Händleragent zunächst alle imSystem vorhandenen Agenten (Kontra-hentenidentifikation) und sucht in dieserGrundgesamtheit nach den für den Händ-ler relevanten Agenten. Eine Suche ist er-folgreich, wenn zwei Händler sich sowohlwechselseitig als mögliche Kontrahentenspezifiziert haben (Kontrahentenmat-ching) als auch das gleiche Wertpapier su-chen bzw. anbieten (Produktmatching).Dabei kann ein Wertpapier entweder überdie Wertpapierkennummer vollständigdefiniert werden oder die Händler spezifi-zieren übereinstimmende Wertpapierei-genschaften, konkret: Emittent, Kuponund/oder Laufzeit. Definiert der Händlergesuchte Maximal- bzw. Minimalpreise,wird dies als drittes Auswahlkriterium he-rangezogen (Preismatching).

Ziel des Suchprozesses ist es, potentiel-le Kontraktpartner durch Unterstützungder Softwareagenten zu finden, um mitdiesen anschließend Transaktionspreisefür die ermittelten Rentenpapiere verhan-deln zu können. Die Preisfindung kannnach erfolgreicher Suche alternativ

■ vollständig telefonisch durchgeführtwerden oder

■ über elektronische direkte Händler-kommunikation oder

■ automatisiert durch bilaterale odermultilaterale Verhandlungen der Agen-ten oder

■ über eine Auktion erfolgen.

5 Technische Umsetzung

Die Plattform, die den Kern des elektroni-schen Matchingsystems darstellt, wurdeauf Basis der FIPA-Spezifikation konzipiert[FIPA97]. Bild 2 zeigt den Aufbau der Platt-form.

Eine Agentenplattform entspricht – lo-gisch gesehen – einem Computer in ei-nem Netzwerk. Um ein Matchingsystemimplementieren zu können, bedarf es eini-ger betriebssystemähnlicher Grundfunk-tionalitäten. In der hier präsentierten Lö-sung werden die Basisfunktionalitätenvon speziellen Agenten, den sogenanntenSystemagenten, übernommen. Diese sindin Bild 2 hellgrau schattiert und als AMS,DIDF sowie ACCR bezeichnet. AMS undACCR werden in 5.1, DIDF in 5.2 erläu-tert.

Neben den Systemagenten gibt es an-wendungsspezifische Agenten, die alsTaskagenten bezeichnet werden und inBild 2 dunkel eingezeichnet sind (DSDFbzw. DSA). Zu ihnen zählen die Agenten,die Händler vertreten, um z.B. ein Kontra-hentenmatching durchzuführen. Diesespeziellen Taskagenten werden im weite-ren Verlauf Händleragenten genannt. Aufdie Taskagenten wird in 5.2 näher einge-gangen.

5.1 Basiskomponenten derAgentenplattformGrundlage der Agentenplattform bildet –als Systemagent – das Agent ManagementSystem (AMS). Dieses ist u.a. für die Ins-tantiierung und das Löschen von Händler-agenten verantwortlich. Auf jeder Platt-form existiert genau ein AMS.

127


Die Interagentenkommunikation er-folgt über den Agent CommunicationChannel Router (ACCR), der – wie dasAMS – ein Systemagent ist und ebenfallspro Plattform genau einmal existiert. SeineAufgabe ist mit der eines „Postboten“ ver-gleichbar; sie besteht im Routing der ein-gehenden und ausgehenden Nachrichtenfür bzw. von allen Agenten der Plattform.

Die verbleibende Komponente, derAgent Communication Channel (ACC),dient als „Briefkasten“ und als Verbindungzwischen ACCR und den Agenten derPlattform. Für jeden Agenten der Platt-form gibt es einen ACC und einen zuge-ordneten ACC auf der Gegenstelle, demACCR (vgl. Bild 2).

128


Eingabe der Parameter durch Händler

Kontrahentenmatching Produktmatching

Such

proz

eß

Kontrahentenidentifikation

Preismatching

Prei

sfin

dung

spro

zeß

telefonisch

Rückmeldung„erfolglose Suche“

direkteOfferte?

Broadcast

Auktion

Verhandlungen der Agenten

Such- und Preisfindungsprozeß

elektronisch neinMulticast

elektronischeVerhandlungen überWertpapier und Preis

Rückmeldung„Auktionspreis”

Rankingpotentieller

Kontrahenten

autonomerAbschluß

durch Agent

Rückmeldung“handelbarer

Preis”

• Bekanntgabe derPartner

Verhandlungen überWertpapier und Preis

• Bekanntgabe des konkretenWertpapiers

• Eingabe Preisvorstellungen

Telefonver-handlungen

beide Händlerakzeptieren

mindestens einHändler akzeptiert

nicht

Bild 1 Such- und Preisfindungsprozeß

Agent Communication Channel Router (ACCR)

Agent Management

System (AMS)

Agent CommunicationChannel (ACC)


Domain IndependentDirectory Facilitator(DIDF)



Domain Specific

Agent (DSA)




Domain SpecificDirectory Facilitator(DSDF)


Domain Specific

Agent (DSA)



Domain Specific

Agent (DSA)



Bild 2 Aufbau der Agentenplattform

5.2 Agenten zur Realisierungdes KontrahentenmatchingUm eine schnelle Suche durchzuführen,werden die Händleragenten vom Mat-chingsystem gruppiert und in sogenannteDomänen eingeteilt. Domänen werdenanwendungsspezifisch festgelegt. Siegruppieren Elemente mit gleichen Eigen-schaften. Gruppierungsmerkmale sind da-bei für den Rentenhandel das zu handeln-de Produkt (Pfandbrief, Bundesanleiheetc.) und die zugehörige Restlaufzeit (bis 2Jahre, 2–5 Jahre etc.). Realisiert wird dieDomänenbildung durch zwei spezielleAgenten der Plattform, die als Verzeichnis-dienst arbeiten und mit den Händleragen-ten interagieren.

Der erste Verzeichnisdienst wird durcheinen Systemagenten abgebildet. Dieserwird Domain Independent Directory Faci-

litator (DIDF) genannt und dient dazu, In-formationen über die Zusammensetzungdes gesamten Systems (d.h. welche Platt-formen am Gesamtsystem beteiligt sind)und Informationen über lokal präsenteDomänen zu liefern. Er speichert dazu dieAdressen aller entfernten DIDFs sowie dieAdressen der lokalen Domänen.

Informationen darüber, welche ent-fernten Plattformen sich im System befin-den, erhält der DIDF, nachdem er gestartetwurde. Er synchronisiert sich dazu mit ei-nem DIDF einer bereits existierendenPlattform und registriert sich bei allen ihmbei der Synchronisation übermitteltenDIDFs, so daß jeder DIDF alle entferntenPlattformen kennt.

Jeder Händleragent gehört einer be-stimmten Domäne an (z.B. Jumbo-Pfand-brief mit 2–5 Jahren Restlaufzeit). Adres-sen von Händleragenten einer Domänewerden in dem zweiten Verzeichnis-dienst, dem sogenannten Domain Specific

Directory Facilitator (DSDF) abgelegt undkönnen dort abgerufen werden.

Genutzt werden beide Informations-quellen von Händleragenten, den Domain

Specific Agents (DSA). Diese stellen an die

Verzeichnisdienste aller im System befind-lichen Plattformen Anfragen, um poten-tielle Kontrahenten zu identifizieren. EinDSA repräsentiert einen Händler und wirdvon diesem parametrisiert. Die Verbin-dung zwischen Händler und seinem Agen-ten erfolgt durch entsprechende Nach-richten, die der Händler an seinen Agen-ten schickt. Aufgrund der Parametrisie-rung seitens des Händlers wird der Agentin eine oder mehrere Domänen eingeord-net und entsprechend bei den zugehöri-gen lokalen DSDFs registriert. Daher mußein Händleragent im Vergleich zu einemSystemagent über folgende zusätzlicheFunktionalität verfügen:

■ Empfang und Interpretation der Para-metrisierung/Händleranweisungen,

■ Registrierung in den lokalen DSDFs ge-mäß seiner Parameterwerte,

■ Durchführung der ihm zugedachtenAufgaben anhand der vom Händlervorgenommenen Parametrisierung so-wie

■ Senden von Statusmeldungen an denHändler.

Das Zusammenspiel der beschriebenenKomponenten wird im folgenden anhanddes Kontrahentenmatchings vorgestellt.

6 Kontrahentenmatchingmit Softwareagenten

Anhand eines konkreten Beispiels soll imfolgenden gezeigt werden, wie mit Hilfeder oben erläuterten Agentenplattformein elektronisches Kontrahentenmatchingdurchgeführt wird.

Das Kontrahentenmatching erfolgt invier Schritten:

1. Identifikation der Plattformen desSystems,

2. Identifikation der Plattformen, die diegesuchte(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 spezifi-zierten Parameter

Zur Erläuterung des Matching wird folgen-der vereinfachter Sachverhalt angenom-men: Im Beispiel sind drei Händler aktivund jeweils durch einen Agenten im Sy-stem repräsentiert. Relevante Parametersind das zu handelnde Produkt, die Rest-laufzeit, der minimale bzw. maximaleCoupon und der Name des Instituts. ZurVerdeutlichung der plattformübergreifen-den Funktionsweise des Matchingsystems„lebt“ im Beispiel jeder der drei Agentenauf einer „eigenen” Plattform. Die Konfi-guration der einzelnen Agenten zeigt Ta-belle 1.

Als Attribute zur Festlegung der Domä-nen werden das Produkt und die Restlauf-zeit verwendet. Als Ausprägungen sindRestlaufzeiten von kleiner 2 Jahre, 2–5Jahre, 5–10 Jahre und 10–30 Jahre mög-lich. Im folgenden wird eine Domäne mitder Notation (Produkt-minLaufzeit-maxLaufzeit) bezeichnet, z.B. (J-2-5) fürJumbo-Pfandbriefe mit einer Restlaufzeitvon zwei bis fünf Jahren.

Die Agenten H2 und H3 seien bereits inden DSDFs B-5-10 (H2) bzw. J-2-5 (H3) re-gistriert. Agent H1 wird nun von derHändlerin konfiguriert und vom AMS er-zeugt. Er registriert sich bei seinen DSDFs(J-2-5 und J-5-10) und beginnt mit demKontrahentenmatching. Die vier Schrittedes Kontrahentenmatching nach dem Ein-tritt von H1 sind in Bild 3 dargestellt.

Schritt 1: Zunächst ermittelt der Händler-agent H1, welche Plattformen zum Systemgehören. Dazu erfragt er bei seinem loka-len DIDF (Plattform I) die Liste der ent-fernten DIDFs (Verbindung 1).Schritt 2: H1, der aufgrund seiner Konfi-guration den Domänen Jumbo 2-5 (J-2-5)und Jumbo 5-10 (J-5-10) angehört, erfragtbei allen ihm übermittelten DIDFs, wel-

129


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

che DSDFs dort registriert sind (Verbin-dung 2).Schritt 3: H1 befragt die DSDFs seiner Do-mänen (J-2-5 und J-5-10) nach dort regi-strierten Agenten. Dies sind die DSDFs J-2-5 und J-5-10 auf der Plattform I sowie derDSDF J-2-5 der Plattform III (Verbindung3).Schritt 4: Lediglich Agent H3 ist in einerDomäne registriert, der auch H1 angehört.Im abschließenden Schritt (Verbindung4) wird ein Attributvergleich bezüglichdes letzten verbleibenden Attributs durch-geführt. Da sowohl H1 als auch H3 in Pa-pieren handeln wollen, die einen Couponvon 4–6% aufweisen, war das Matchingerfolgreich.

Mit Hilfe der Einteilung der Händleragen-ten in Domänen und dem Einsatz der Ver-zeichnisdienste wird eine Vorselektionpotentieller Kontrahenten durchgeführt.Die Registrierung der Händleragenten beiden DSDFs garantiert ein erfolgreiches Su-chen, sofern mindestens ein Agent dergleichen Domäne angehört. Durch denEinsatz eines Agenten ist der Händler inder Lage, gleichzeitig alle passenden Kon-trahenten durch eine einzige Spezifikationseiner Order zu identifizieren. Dadurchwird ein performantes Matching erzielt.

Seitens der Architektur des Systemsgibt es keine Beschränkung bezüglich derAnzahl von Händleragenten auf der Platt-form. Engpässe sind folglich nicht durchdie Konzeption des Systems bedingt, son-dern werden von der zugrunde liegendenHardware determiniert. Weiterhin kanndas System aus einer beliebigen Anzahl

von Plattformen bestehen, die auch wäh-rend des laufenden Betriebs hinzugefügtwerden können, ohne die Funktionsfähig-keit des Systems zu beeinträchtigen. DieSkalierbarkeit ist folglich gegeben.

Um die Verfügbarkeit zu gewährleis-ten, sollte das System aus mindestens zweiAgentenplattformen bestehen. Jede ein-zelne Plattform bietet die vollständigeFunktionalität, so daß bei Ausfall einerPlattform das System noch funktionsfähigist. Basis des performanten Matchingpro-zesses ist eine effiziente Verwaltung undRegistrierung von Agenten. Zur Vermei-dung dedizierter Komponenten gibt eskeine zentrale Stelle, die eine plattform-übergreifende Agentenverwaltung reali-siert. Diese wird vielmehr auf die einzel-nen Plattformen aufgeteilt, die sich syn-chronisieren, um über konsistente Datenzu verfügen. Die Verfügbarkeit wird somitdurch die Trennung in mehrere Plattfor-men und durch die Aufteilung der Agente-nidentifikation auf die dezentralen Agen-ten DIDF und DSDF sichergestellt.

Die Anbindung weiterer Agenten ist so-wohl von der konzeptionellen als auchder implementationstechnischen Seite herunproblematisch. Konzeptionell wird einAgent (sowohl ein System- als auch einTaskagent) zur Plattform hinzugefügt, in-dem eine entsprechende Nachrichtenbox(ACC) für ihn bereitgestellt wird. Da-durch ist es auch möglich, Agenten hinzu-zufügen, die Schnittstellen zu externenSystemen bilden. Diese Art von Erweite-

rung kann während der Laufzeit erfolgen.Durch die Trennung von DIDF und DSDF

kann das Matchingsystem auf andere Be-reiche wie Aktien- oder Derivatehandelerweitert werden, wobei der Handel allerProdukte (theoretisch) trotzdem auf einereinzelnen Plattform durchgeführt werdenkann.

Für die prototypische Realisierungwurde auf die Einbindung von kryptogra-fischen Verfahren und weitere Maßnah-men zur Realisierung der Systemsicherheit

verzichtet. Prämisse des Einsatzes des Mat-chingsystems ist deshalb das Vorhanden-sein eines abgesicherten Computernetz-werks, wie es z.B. von der Deutschen Bör-se AG zur Verfügung gestellt wird.

Die Agentenplattform ist vollständigobjektorientiert modelliert (nach [CoYo91]) und in der Programmiersprache Java(mit Hilfe des JDK von SUN [SUN98]) im-plementiert.

7 Zusammenfassung undAusblick

Der OTC-Markt hat eine große Bedeutungam gesamten Wertpapierhandel. Dies giltinsbesondere für den Rentenmarkt. Dergrößte Umsatzanteil im Rentenhandelwird heute telefonisch zwischen Wertpa-pierhändlern abgewickelt. In den meistenFällen – vor allem beim Blockhandel –wird zudem ein Broker zur Vermittlungdes Geschäfts hinzugezogen. Diese Vorge-hensweise ist zeitintensiv und verursachthohe Transaktionskosten. Ein Ansatz zureffizienten Gestaltung des Rentenhandelsist die Nutzung elektronischer Rentenhan-delssysteme. Diese werden jedoch seitensder Marktteilnehmer kaum akzeptiert, dasie die Anforderungen der Händler nichtin ausreichendem Maße erfüllen. Einwichtiger Ansatz zur Überwindung dieserProblematik ist das von der DeutschenBörse AG im Herbst 1998 eingeführte Re-lease 3 von Xetra®. Eine Ergänzung für be-stimmte Marktsegmente kann ein agenten-basiertes System darstellen. Dieses ermög-licht dem Händler, seine Transaktions-wünsche – und gegebenenfalls Verhand-lungsstrategien – dem Agenten mitzutei-len. Die Grundbausteine des elektroni-schen Handelssystems bilden dabei Agen-ten, die einerseits die Präferenzen desHändlers abbilden und ihm die zeitauf-wendige Kontrahentensuche abnehmen,andererseits den Betreibern des elektroni-schen Handelssystems die Chance bieten,Erweiterungen in funktionaler und techni-

130


Handelssystem

AMS

ACCR

AMS

AMS

Agentenplattform III

Agentenplattform IIAgentenplattform I

1 2

2

2

3

3

4

3

DIDF AgentH2

AgentH3

DSDFJ-2-5

AgentH1

DSDFJ-5-10

DSDFJ-2-5DIDF

DIDF

DSDFB-5-10

ACCR

ACCR

Bild 3 Zusammenspiel der einzelnen Agenten beim Kontrahentenmatching

scher Sicht jederzeit vornehmen zu kön-nen.

Je nach Spezifikation des Händlers [Bu-Go99] kann der Agent entweder

■ eine Suche nach geeigneten Partnern,d.h. Agenten anderer Marktteilnehmer,durchführen und die Ergebnisse der Su-che anschließend dem Händler mittei-len, damit dieser die weiteren Ver-handlungen persönlich durchführt,oder

■ selbständig Verhandlungen durchfüh-ren. Für diesen Zweck werden speziel-le Verhandlungs- bzw. Auktionsmecha-nismen entwickelt.

Nach der Implementierung ist die System-evolution vorgesehen. In dieser Phasekönnen

■ weitere Koordinationsmechanismenzur Preisfindung implementiert wer-den,

■ Tauschgeschäfte (Papier-gegen-Papier)zwischen Händlern vorgesehen wer-den sowie

■ Anbindungen des Systems an bestehen-de Handelssysteme erfolgen.

Zusätzlich werden alternative Marktmi-krostrukturen experimentell im Hinblickauf Liquidität, Effizienz und Transaktions-kosten getestet, um die so gewonnenenErkenntnisse in einem nachfolgenden Re-lease umzusetzen.

Anmerkung1 Die vorliegende Arbeit stellt eine Überarbei-

tung und Zusammenfassung der Arbeiten [Go-Bu98] und [LoNo98] dar und gehört zumForschungsbereich des DFG-Projektes „Elek-tronisierung des außerbörslichen Wertpapier-handels“ (WE 1436-4/1).

Literatur

[BuGo99] Budimir, M.; Gomber, P.: DynamischeMarktmodelle im elektronischen Wertpapier-handel. Erscheint in: Tagungsband Wirt-schaftsinformatik ’99. Physica-Verlag, Heidel-berg 1999.

[BuOH87] Burdett, K.; O’Hara, M.: BuildingBlocks: An Introduction to Block Trading. In:Journal of Banking and Finance 11 (1987),S. 193-212.

[Büsc93] Büschgen, H. E.: Bankbetriebslehre:Bankgeschäfte und Bankmanagement. 4. Auf-lage, Gabler, Wiesbaden 1993.

[CoYo91] Coad, P.; Yourdon, E.: Object Ori-ented Analysis. 2nd edition, Prentice Hall,Englewood Cliffs 1991.

[DeKi96] Deutsch, J.; Kirschner, W.; Petit, H.:

Perspektiven des Pfandbriefmarktes. In: DieBank (1996) 1, S. 20-25.

[Domo92] Domowitz, I.: Automating the PriceDiscovery Process: Some International Com-parisons and Regulatory Implications. In:Journal of Financial Services Research (1992),S. 305-326.

[EaOH92] Easley, D.; O’Hara, M.: Adverse Selec-tion and Large Trade Volume: The Implica-tions for Market Efficiency. In: Journal of Fi-nancial and Quantitative Analysis 27 (1992)2, S. 185-208.

[FIPA97] Foundation for Intelligent Physical

Agents (FIPA): FIPA 97 Specification, Version1. http://drogo.cselt.stet.it/fipa/spec/fipa97/fipa97.htm, 1997.

[FrGr97] Franklin, S.; Graesser, A.: Is it an Agentor just a Program? A Taxonomy for IntelligentAgents. In: Müller, J.P; Wooldridge, M.;

Jennings, N. (Hrsg.): Intelligent Agents III –Agent Theories, Architectures and Languages.Lecture Notes in Artificial Intelligence 1193.Springer Verlag, Berlin 1997, S. 21-35.

[GeRa92] Gerke, W.; Rasch, S.: Ausgestaltungdes Blockhandels an der Börse. In: Die Bank(1992) 4, S. 193-201.

[GrGr95] Grill, W.; Gramlich, L.; Eller, R.

(Hrsg.): Gabler Bank Lexikon. 11. Auflage,Gabler, Wiesbaden 1995.

[GoBu98] Gomber, P.; Budimir, M.; Koscian-

kowski, K.; Urtheil, R.: Elektronisierung desaußerbörslichen Rentenhandels auf Basis von

Softwareagenten. In: Weinhardt, Ch.; Meyer

zu Selhausen, H.; Morlock, M. (Hrsg.): Infor-mationssysteme in der Finanzwirtschaft.Springer, Heidelberg et al. 1998, S. 253-267.

[GrTh94] Greenbaum, S. I.; Thakor, A.V.: Con-temporary Financial Intermediation. Dryden,Fort Worth u. a. 1994.

[JeWo96] Jennings, N.; Wooldridge, M.: Soft-ware Agents. In: IEE Review (1996) 1, S. 17-20.

[Kran96] Krannich, L.: Risiken der Wertpapier-leihe und Wertpapierpensionsgeschäfte. In:Eller, R. (Hrsg.): Handbuch Derivater Instru-mente: Produkte, Strategien, Risikomanage-ment. Schäffer-Poeschel, Stuttgart 1996.

[LoNo98] Lohmann, M.; Nopper, N.; Henning,

P.: Elektronisches Kontrahentenmatching imagentenbasierten Wertpapierhandel. In:Weinhardt, Ch.; Meyer zu Selhausen, H.; Mor-

lock, M. (Hrsg.): Informationssysteme in derFinanzwirtschaft. Springer, Heidelberg et al.1998, S. 269-284.

[Lüde96] Lüdecke, T.: Struktur und Qualität vonFinanzmärkten. Gabler, Wiesbaden 1996.

[MaCh97] Madhavan, A.; Cheng, M.: In Search ofLiquidity: Block Trades in the Upstairs andDownstairs Markets. In: The Review of Finan-cial Studies 10 (1997) 1, S. 175-203.

[PaRö96] Pagano, M.; Röell, A.: Transparencyand Liquidity: A Comparison of Auction andDealer Markets with Informed Trading. In:The Journal of Finance 51 (1996) 2, S. 579-611.

[Stig83] Stigum, M.: The Money Market. 2nd edi-tion, Dow Jones-Irwin, 1983.

[SUN98]: Sun Microsystems: The Java Develop-ment Kit (JDK). http://java.sun.com/products/jdk/index.html, 1998.

[WeGo99a] Weinhardt, Ch.; Gomber, P.: Elek-tronisierung des außerbörslichen Wertpapier-handels. Erscheint in: WIRTSCHAFTSINFOR-MATIK (1999).

[WeGo99b] Weinhardt, Ch.; Gomber, P.: Agent-Mediated Off-Exchange Training. In: Proceed-ings of the 32nd Hawaii Conference on Sys-tem Sciences, Maoi, Hawaii, 1999.

[WoJe95] Wooldridge, M.; Jennings, N.: Intelli-gent Agents – Theories, Architectures, andLanguages. Lecture Notes in Artificial Intelli-gence 890. Springer Verlag, Berlin 1995.

131


Documents

Agentenbasierter Rentenhandel