DE112007003476T5

DE112007003476T5 - Anonymes Matching-System für den Pakethandel

Info

Publication number: DE112007003476T5
Application number: DE112007003476T
Authority: DE
Inventors: Anthony Kingston upon Thames Mackay
Original assignee: Instinet Europe Ltd
Current assignee: Instinet Europe Ltd
Priority date: 2007-05-01
Filing date: 2007-05-01
Publication date: 2010-03-18
Also published as: KR20150102044A; EP2143060A1; KR100949652B1; GB2463996A; WO2008132420A1; KR20170015529A; GB0918290D0; KR20080094767A; KR102035117B1

Abstract

Anonymes Pakethandels-Matchingsystem, welches aufweist:
zumindest einen Server, der konfiguriert ist, über ein Netzwerk Auftragsdaten für einen Auftrag eines Wertpapiers zu empfangen, wobei die Auftragsdaten die Spezifikation eines Benutzers einer Peis-Benchmark für den Auftrag umfassen, wobei die Preis-Benchmark ausgewählt wurde von einer Gruppe bestehend aus: ein Peg-Wert mit einem harten Limit, ein Peg-Wert ohne ein hartes Limit, oder ein zukünftiger Kreuzungspreis;
eine Kerndatenbank, in der die Auftragsdaten gespeichert sind, wobei die Auftragsdaten die Preis-Benchmark einschließen;
einen Alarmgenerator, der konfiguriert ist, die Auftragsdaten zu verwenden, um an zumindest eine potentielle Handelspartei anonym einen Alarm zu übertragen, der den Auftrag beschreibt.

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft im allgemeinen das Gebiet von Computersystemen und insbesondere ein neues Computersystem, das den Pakethandel von Wertpapiertransaktionen ermöglicht.
HINTERGRUND DER ERFINDUNG
Pakethandel, auch bezeichnet als ”Crossing” (Kreuzung) ist ein wohlbekannter Typ einer Wertpapiertransaktion, bei der Abschlüsse privat unabhängig vom öffentlichen Auktionsmarkt ausgehandelt werden. Der Pakethandel (block trading) erlaubt Händlern auf der Verkäuferseite und Händlern auf der Käuferseite die Transaktionskosten, sowie Ticketkosten, Ausführungskosten und Zahlungskosten zu reduzieren. Während der Pakethandel meistens über manuelle Verhandlung durchgeführt wird, gibt es im Stand der Technik verschiedene Matchingsysteme und alternative Handelssysteme, um Wertpapierkäufer mit Verkäufern zu ”matchen”, sowie zum Matchen von Wertpapierverkäufern mit Pools von Liquidität.
Einige solcher Matching-Engines, vorher bekannt als Instinet, VT und CBX (die ”Instinet-Systeme”), zur Verfügung gestellt durch Instinet, erlauben Benutzern, anonyme Aufträge einzureichen. Die Systeme verteilen Auftragsalarme an andere Benutzer des Systems, die an der Durchführung einer Transaktion mit dem Benutzer interessiert sein könnten, dessen Auftrag die Auftragsalarme getriggert hat. Wenn Auftragsalarme verteilt werden und zwischen Parteien verhandelt werden, sind die Parteien anonym zueinander. In dieser Beziehung erlauben Auftragsalarme den Parteien, ein natürliches Gegenüber zum Handeln zu suchen, während das Entweichen von Informationen kontrolliert und die Handelsstrategie geschützt werden.
Benutzer von solchen Systemen kontrollieren, welche Auftragsinformationen der Markt sieht, so dass extern nur eine minimale Ausführungsgröße und ein minimaler Ausführungspreis gezeigt werden, während die tatsächliche Größe und der tatsächliche Preis mit natürlichen Gegenübern ausgehandelt werden.
Die Instinet-Systeme und andere Matching-Engines, die den Pakethandel ermöglichen, sind jedoch in verschiedener Hinsicht eingeschränkt. Während sie eine Einrichtung für kontinuierliches außerbörsliches Kreuzen (Crossing) bereitstellen, liefern sie keine ausreichende Fähigkeit, Aufträge unter Verwendung von impliziten KGV-Marktbenchmarks (Market PEG Benchmarks) oder zukünftiger Preis-Cross-Benchmarks (Future Price Cross Benchmarks) über eine webbasierte Terminalanwendung einzugeben. Während solche Systeme eine Einrichtung zum Übertragen von Alarmen an Abonnenten bereitstellten, um sie auf potentielle Handelsmöglichkeiten hinzuweisen, gab es keine Einrichtung, um dem Benutzer zu erlauben, zu kontrollieren, welche Benutzer oder Typen von Benutzern solche Alarme erhalten werden. Daneben haben solche Systeme, die den Pakethandel ermöglichten, typischerweise nur eingeschränkte Mittel zur Verhandlung zwischen den Parteien bereitgestellt und solche Verhandlungen waren nur verfügbar für Kunden, die proprietäre Handelsplattformen auf einem proprietären Datennetzwerk verwendeten.
AUFGABEN UND ZUSAMMENFASSUNG DER ERFINDUNG
Es ist daher eine Aufgabe der Erfindung, ein verbessertes anonymes Pakethandels-Matchingsystem bereitzustellen.
Es ist ferner eine Aufgabe der Erfindung, ein System bereitzustellen, das Teilnehmern ermöglicht, große Blöcke von internationalen oder nationalen Aktien anonym zu handeln, um Ticketkosten, Ausführungskosten und Zahlungskosten zu reduzieren, während auch der Markteinfluß und Spreadkosten reduziert werden.
In bevorzugten Ausführungsbeispielen stellt die Erfindung ein anonymes Pakethandels-Matchingsystem zur Verfügung, das Benutzern, die große Blöcke von Aktien handeln wollen, erlaubt, Aufträge oder Interessenindikationen (indications of interest) einzugeben, mit der Option der Verwendung von impliziten KGV-Marktbenchmarks oder zukünftigen Preis-Kreuzungs-Benchmarks (future price cross benchmarks). Eingegebene Aufträge können Schwellwerten minimaler Größe unterworfen werden. Nach der Eingabe von einem festen Auftrag in das System wird ein Alarm erzeugt, um die Auftragsdaten an andere User zu liefern, mit dem Potential, den Auftrag zu kreuzen (to cross the order). Die Sichtbarkeit von Auftragsdaten durch andere Benutzer kann basierend auf einer Dateninteraktionsgruppe, zu der der auftraggebende Benutzer oder der andere Benutzer gehören, beschränkt werden. Das System kann den Benutzern ermöglichen, Auftragsdaten zu sehen mit einer Fähigkeit der Verhandlung mit dem eingebenden Benutzer über ein beschränktes Zweiwege-Nachrichten-Interface. Flatrate-Kostenmodelle und Abschlags-Gebühren-Kostenmodelle können als Mittel verwendet werden, um einem Benutzer den Zugriff auf das System in Rechnung zu stellen.
Die Erfindung liefert daher eine gegenseitig vorteilhafte Handelslösung, wo beide Handelsparteien aus dem direkten Handel mit einem natürlichen Gegenüber Nutzen ziehen können.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorhergehenden und weitere Aufgaben, Merkmale und Vorteile der Erfindung werden von der nachfolgenden genaueren Beschreibung bevorzugter Ausführungsbeispiele wie in den beigefügten Zeichnungen illustriert klar, wobei Bezugszeichen sich über die unterschiedlichen Ansichten hinweg auf gleiche Teile beziehen. Die Zeichnungen sind nicht notwendigerweise maßstabsgerecht, die Betonung liegt stattdessen auf dem Illustrieren der Prinzipien der Erfindung.
1 zeigt ein schematisches Blockdiagramm, das ein System in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung illustriert.
2a zeigt eine grafische Illustration eines Interfaces, mit dem das System einen Auftrag erhält, in Übereinstimmung mit einem Ausführungsbeispiel.
2b zeigt eine grafische Illustration eines Interfaces, mit dem das System einen Auftrag erhält, in Übereinstimmung mit einem Ausführungsbeispiel.
3 ist ein funktionales Flußdiagramm auf hoher Ebene, das einen Prozeß zur Erzeugung und Verteilung von Alarmen illustriert.
4 zeigt eine grafische Illustration eines Webanwendungsinterfaces in Übereinstimmung mit einem Ausführungsbeispiel.
5 zeigt eine grafische Illustration eines Zweiwege-Nachrichten-Systeminterfaces.
6 zeigt eine grafische Illustration eines Suchfensters in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung.
DETAILLIERTE BESCHREIBUNG DES BEVORZUGTEN AUSFÜHRUNGSBEISPIELS
Es wird nun im Detail auf die bevorzugten Ausführungsbeispiele der vorliegenden Erfindung Bezug genommen, von denen Beispiele in den beigefügten Zeichnungen illustriert sind.
Die vorliegende Erfindung wird nachfolgend beschrieben unter Bezugnahme auf Blockdiagramme und operational Illustrationen von Verfahren und Vorrichtungen, um ein Pakethandels-Matchingsystem in Übereinstimmung mit der Erfindung herzustellen und zu verwenden. Es ist zu verstehen, dass jeder Block des Blockdiagramms oder von operationalen Illustrationen und Kombinationen von Blöcken in den Blockdiagrammen oder operationalen Illustrationen implementiert werden können mittels analoger oder digitaler Hardware und Computerprogramminstruktionen. Diese Computerprogramminstruktionen können an einen Prozessor eines Allzweckrechners, einen Computer für spezielle Zwecke, ASIC, oder eine andere programmierbare Datenverarbeitungsvorrichtung geliefert werden, so dass die Instruktionen, die über den Prozessor des Computers oder andere programmierbare Datenverarbeitungsvorrichtungen ausgeführt werden, die Funktionen/Handlungen implementieren, die in den Blockdiagrammen oder dem operationalen Block oder Blöcken spezifiziert werden. In einigen alternativen Implementierungen können die Funktionen/Handlungen, die in den Blöcken gezeigt werden, in anderer Reihenfolge als in den operationalen Illustrationen auftreten. Beispielsweise können zwei nacheinander gezeigte Blöcke tatsächlich im wesentlichen gleichzeitig ausgeführt werden oder die Blöcke können manchmal in umgekehrter Reihenfolge ausgeführt werden, abhängig von den involvierten Funktionalitäten/Handlungen.
1 illustriert ein Ausführungsbeispiel des anonymen Handels-Matchingsystems 10 für den Handel von natürlichen großen Blöcken von Aktien über internationale oder nationale Märkte. Das System liefert den Benutzern die Fähigkeit, während durchgehender Handelsstunden Aufträge für den Pakethandel einzugeben. Wenn ein fester Auftrag platziert wird, können die Auftragsdaten für den Auftrag in einem Paket-Match-”Alarm” oder einer ”Interessenindikation (IOI)” enthalten sein, die selektiv an andere Benutzer verteilt wird, um solche Benutzer über die Möglichkeit, in einen Kreuzungs-Handel (cross trade) einzutreten, zu alarmieren.
Eine Pakethandel-Matching-Engine 12 verwendet Algorithmen, die weiter unten diskutiert werden, um Aufträge zu matchen. Eine Kerndatenbank 14 wird bereitgestellt, um historische Informationen betreffend Abschlüsse zu speichern und die Handelshistorie von Klienten zu verfolgen. In einem Ausführungsbeispiel ist die Kerndatenbank der Erzeuger von Alarmen. Wie jedoch von Fachleuten verstanden wird, können Alarme durch jeden Server in dem System erzeugt werden, ohne von dem Geist und dem Umfang der Erfindung abzuweichen. Clients können auf das Handels-Matchingsystem zugreifen, um Aufträge zu platzieren und/oder Alarme über ein Interface mit einer Inhouse-Handels-Applikation 24 zu empfangen, die mit einer Inhouse-Handelsplattform 16 kommuniziert, mit einem Interface mit einem externen Handelssystem 18, das mit Inhouse-Handelsplattform 16 kommuniziert, oder über einen Webclient 20, der über das Internet mit einem Web-Infrastrukturserver 22 verbunden ist.
Das externe Handelssystem 18 kann mit dem Handels-Matchingsystem 10 unter Verwendung eines geeigneten Standards oder proprietären Auftragsprotokolls kommunizieren. Ein Beispiel eines geeigneten Protokolls ist das financial information exchange (FIX) Protokoll, veröffentlicht durch fixed protocol, bereitgestellt durch FIX Protocol Ltd. aus London, UK. Das FIX-Protokoll ist ein wohlbekanntes elektronisches Kommunikationsprotokoll für internationalen Echtzeitaustausch von Informationen betreffend Wertpapiertransaktionen und Märkte. FIX-Nachrichten werden durch eine Anzahl von Feldern gebildet, wobei jedes Feld ein Bezeichner-Wert-Paar (tag value pairing) ist, das von dem nächsten Feld durch einen Begrenzer SOH separiert ist. Der Bezeichner (TAG) ist eine Stringrepräsentation einer ganzen Zahl, die die Bedeutung des Feldes angibt. Der Wert ist ein Array von Bytes, das eine spezifische Bedeutung für den bestimmten TAG hat. So ist beispielsweise ”TAG 48” securityID und ist ein String, der die Sicherheit identifiziert, ”TAG 22” ist IDSource und ist ein Integer, der die verwendete Identifiziererklasse angibt. Der Wert ist hauptsächlich lesbarer Text. Jedoch können Felder verschlüsselt sein und somit kann der Wert rein binär sein und den normalen Begrenzer SOH einschließen – binären Feldern geht immer ein Längenfeld voraus. Das FIX-Protokoll definiert die Bedeutungen für die meisten TAGs und ein Bereich von TAGs ist reserviert für die private Verwendung zwischen zustimmenden Parteien. Das FIX-Protokoll definiert auch Sätze von Feldern, die eine besondere Nachricht ausmachen. Innerhalb des Satzes von Feldern sind einige unter dem Protokoll verpflichtend und andere optional.
Der Webinfrastrukturserver 22 stellt ein sicheres Interface für Webclients zur Verfügung, die auf das System über das Internet zugreifen und setzt Benutzerrang-Berechtigungen. Der Webclient 20 führt eine über das Internet bereitgestellte Webapplikation aus, die es Benutzern erlaubt, Handelsgelegenheiten in der Form von ”Alarmen” zu sehen, die weiter unten im Detail beschrieben werden. Die Webapplikation kann zusätzlich dem Benutzer die Möglichkeit bereitstellen, Filter aufzusetzen, um zu verhindern, dass sie eine überwältigende Anzahl von Alarmen für Marktsektoren erhalten, an denen solch ein Benutzer nicht interessiert ist. Die Webapplikation kann auch eine Instant-Messaging-Funktionalität einschließen, um Clients zu erlauben, miteinander unter Verwendung erlaubter Phrasen zur Förderung des Aushandelns eines Abschlusses zu kommunizieren, wie weiter unten im Detail diskutiert wird. Die Webanwendung kann ferner einen fortgeschrittenen Suchbildschirm aufweisen, der es Benutzern ermöglicht, Kriterien ihrer Wahl einzugeben, um Aufträge anzuzeigen, die in dem System platziert wurden. Die Webanwendung etabliert in einem Ausführungsbeispiel eine Echtzeit-Dateneinspeisung von der Kerndatenbank, so dass in der Kerndatenbank durchgeführte Änderungen sofort im Web-Frontend reflektiert werden. Die Präsentation der Daten durch die Webapplikation kann erreicht werden, indem sie konfiguriert wird, so dass vier Typen von Fenstern angezeigt werden: ein Aktienlisten-Fenster, das eine Auftrag-nach-Auftrag-Liste von lebenden, gehandelten, gestrichenen und abgelaufenen Aufträgen in dem System anzeigt; ein Markttiefenfenster, das konsolidierte Daten nach Preis für lebende, gehandelte, gestrichene und abgelaufene Aufträge anzeigt, ein Alarmfenster, das IOIs anzeigt, die sich auf im System platzierte Aufträge beziehen, und ein Zweiwege-Nachrichtenfenster, das verwendet wird, um mit Teilnehmern über existierende Aufträge, abgelaufene gestrichene Aufträge und gehandelte Aufträge zu verhandeln.
2a und 2b zeigen grafische Illustrationen eines Interfaces, mit dem das System einen Wertpapierauftrag in Übereinstimmung mit einem Ausführungsbeispiel entgegennimmt. Momentane Marktdaten für ein Wertpapier werden im oberen Drittel des Interfaces angezeigt. Im Zentrum des Interfaces wird eine Serie von Feldern mit Auswahloptionen angezeigt. Ein ”Mengen”-Feld erlaubt dem Benutzer, eine mit dem Auftrag assoziierte Menge zu spezifizieren. Ein ”Anzeige Menge”-Feld liefert eine Kombo-Steuerung, um einem Benutzer zu erlauben, eine Anzeigemenge zu spezifizieren, die minimalen Anzeigekriterien unterworfen ist, mit der Option, Systemwerte unter Verwendung eines Drop-Down auszuwählen. Solche Systemwerte können z. B. ”1000”, ”2000”, ”3000”, ”4000”, ”5000”, ”10000”, ”15000”, ”20000”, oder ”25000” sein. Der voreingestellte Wert kann auf ”Alle” gesetzt sein, in dem Fall wird der gesamte Auftrag angezeigt. Ein ”Abgelaufen”-Feld stellt eine Kombo-Steuerung zur Verfügung, um einem Benutzer zu ermöglichen, ein Ablaufdatum für die Aufträge zu spezifizieren. Benutzer können auf eine Liste von Systemwerten unter Verwendung des Drop-Down zugreifen. Solche Systemwerte können z. B. ”Tag”, ”GTD”, ”Blotter”, ”Plus 5 min”, ”Plus 10 min”, ”Plus 1 Std”, oder ”IOC”. Der erforderliche voreingestellte Wert kann auf ”Tag” gesetzt sein.
Der Auftragsschirm von 2a und 2b enthält in einem Ausführungsbeispiel ein ”Anzeigepreis”-Feld, das den Benutzer auffordert, eine Benchmark in Verbindung mit dem Auftrag auszuwählen. Aufträge können eingegeben werden unter Verwendung von z. B. impliziten KGV-Marktbenchmarks ”Mid”, ”Bid” und ”Ask”, und zukünftigen Preis-Kreuzungs-Benchmarks ”VWAP”, ”Open” und ”Close”. Indem die Fähigkeit bereitgestellt wird, Aufträge unter Verwendung dieser Benchmarks während durchgehender Handelsstunden einzugeben, kann das System eine gegenseitig vorteilhafte Handelslösung anbieten, bei der beide Handelsparteien davon profitieren, direkt mit einem natürlichen gegenüber zu handeln und kann somit ein Mittel zum Kappen von Ticketkosten, Ausführungskosten und Zahlungskosten bereitstellen, indem der Mittelsmann eliminiert wird, während auch Markteinfluß und Spreadkosten reduziert werden.
Wenn der Benutzer eine primäre Peg-Benchmark (primäre implizite KGV-Benchmark) (z. B. ”Mid”, ”Bid” oder ”Ask”) in dem ”Anzeigepreis”-Feld von 2a und 2b spezifiziert, dann liefert das System die Option des Hinzufügens eines harten Limits zu dem Auftrag. In solch einem Fall bewegt sich der primäre Peg-Benchmark-Preis so, wie sich der Markt bewegt, aber den Benutzer ist letztlich geschützt durch das harte Limit, falls sich der Markt jenseits des oberen Preislimits bewegt. Der Auftrag wird angezeigt unter Verwendung des alphabetischen Peg0-Benchmark-Werts, z. B. MID, und nicht mit dem tatsächlichen Wert des Preises. Wenn der Markt sich jenseits des harten Limits des Benutzers bewegt, dann ändert sich der Auftragstyp automatisch in einen Auftrag mit hartem Limit und wird dann den Preis des harten Limits im numerischen Format anzeigen. Falls der Markt sich wieder günstiger bewegt, so wird der Auftrag wieder zu einem alphabetischen Wert zurückkommen. Wenn ein Match gefunden wird (eine Person, die einen Auftrag für die andere Seite mit dem gleichen Benchmark-Wert eingibt), so werden Abschlüsse ausgeführt zu dem primären Preis der spezifizierten Benchmark zu der Zeit, bei der der Match auftrat.
Wenn der Benutzer einen primären zukünftigen Kreuzungs-Preis-Benchmarkwert, z. B. ”VWAP”, ”Open” oder ”Close” in dem ”Anzeige Preis”-Feld von 2a und 2b spezifiziert, so wird keine Option zur Spezifizierung eines harten Limits gegeben. Der Auftrag wird bei der gewählten Benchmark gesetzt und beim Finden eines Matches – einer Person, die einen Auftrag für die gegenüberliegende Seite mit gleichem Benchmarkwert eingibt – so wird eine indikative Ausfüllung (indicative fill) an beide Teilnehmer zu dem letzten Schlußpreis des Primärmarkts gesendet. Wenn die Primärbörse ihren offiziellen Preis veröffentlicht, den der Benutzer als seinen zukünftigen Kreuzungs-Benchmark spezifiziert hat, so werden Handelskorrekturen an beide Teilnehmer zu dem offiziellen Kreuzungspreis gesandt.
Das System kann konfiguriert werden, so dass ein User aufgefordert wird, einen Auftrag an eine oder mehrere minimale Schwellwerte zu knüpfen, auf einer per-Aktie-Basis, um an den Pakethandels-Matchingfunktionen, die von dem System bereitgestellt werden, teilzunehmen. Solche Schwellwerte schließen einen ”%-ADV”-Schwellwert und einen Aktien-Mengen-Schwellwert ein. Um den %-ADV-Schwellwert zu erfüllen, muß ein Auftrag ”X”-Prozent des durchschnittlichen täglichen Volumens repräsentieren. Um den Aktien-Mengen-Schwellwert zu erfüllen, muß ein Auftrag ”X” Aktien enthalten. Wenn ein Auftrag, der den erforderlichen Schwellwert nicht erfüllt, in das System eingegeben wird, kann er vom System zurückgewiesen werden. Schwellwerte für bestimmte beauftragte Aktien können auf jeden Wert gesetzt werden, werden aber im allgemeinen auf der Liquidität der Aktie und dem Preispegel der beauftragten Aktie basieren.

Das System kann ferner konfiguriert sein, um Benutzern die Möglichkeit bereitzustellen, ihre Auftragsdaten in Pakethandel-Match-Alarmen oder Interessenanzeigen (IOIs) einzuschließen, um das Potential zum Finden einer geeigneten Handelspartei zu maximieren. Das System segregiert in unterschiedlichen Ausführungsbeispielen Benutzer in vier bestimmte Dateninteraktionsgruppen und macht AuftragsdatenBenutzern sichtbar in Übereinstimmung mit der Gruppe, zu der sie gehören. In einem Ausführungsbeispiel sind die vier Gruppen: Käuferseite, Verkäuferseite, Marktmacher und dunkle Bereitsteller. Die Zusammensetzung dieser Gruppen und das Ausmaß, in dem sie in der Lage sind, Aufträge in dem System zu sehen, wird in der nachfolgenden Tabelle zusammengefaßt:

Gruppe	Typ	Sichtbarkeit
Käuferseite	Institutionen typische Hedgefonds	Volle Sichtbarkeit von Aufträgen von Käufer- und Verkäuferseite. Keine Sichtbarkeit von dunklen Aufträgen.
Verkäuferseite	Broker/Händler Prop Desks	Beschränkt – nach Wunsch des Teilnehmers, der Liquidität offeriert.
Marktmacher	Marktmacher	Beschränkt – nach Wunsch des Teilnehmers, der Liquidität offeriert.
dunkle Anbieter	Teilnehmer, die keine Sichtbarkeit ihrer Aufträge wünschen	Null Sichtbarkeit von Aufträgen von allen Gruppen.

3 ist ein hochrangiges funktionales Flußdiagramm, das einen Prozeß zum Erzeugen und Verteilen von Alarmen illustriert. Der Prozeß beginnt in Schritt 310 mit dem Empfang eines festen Auftrags in dem System. Benutzer müssen einen festen Auftrag in das Pakethandel-Matchingsystem eingeben, um einen Alarm-IOI auszulösen. Die Auftragsdaten werden zuerst zu der Kerndatenbank in Schritt 312 gesandt. Im Schritt 314 werden die Auftragsdaten untersucht, um zu ermitteln, ob der Benutzer, der den Auftrag platziert hat, sich als dunkler Anbieter bezeichnet hat. Dunkle Anbieter werden niemals irgendwelche Auftragsdaten für Aufträge, die in dem Pakethandels-Matchingsystem platziert wurden, sehen, sondern sind stattdessen in der Lage, mit Aufträgen als blinder Teilnehmer zu interagieren. Ihre Aufträge sind nicht sichtbar für irgendeine der teilnehmenden Gruppen. Wenn somit der Benutzer, der den Auftrag platziert, ein dunkler Anbieter ist, so wird kein Alarm erzeugt und der Alarmerzeugungsprozeß wird in Schritt 316 gestoppt. Andernfalls fährt der Prozeß mit Schritt 318 fort. Im Schritt 318 werden die Auftragsdaten untersucht, um zu ermitteln, ob der Benutzer eine ”versteckte” Anweisung zu dem Auftrag hinzugefügt hat. wenn der Benutzer eine ”versteckte” Anweisung hinzufügt, wenn er einen Auftrag platziert, so wird der Auftrag nicht im Auftragsbuch angezeigt und kein Alarm wird erzeugt.
Wenn der Auftrag nicht als versteckt bezeichnet wird und nicht von einem dunklen Anbieter platziert wurde, so fährt der Prozeß mit der Erzeugung eines Alarms in Schritt 322 fort. Der Inhalt eines solchen Alarms wird unten unter Bezugnahme auf 4 diskutiert. Unter weiterer Bezugnahme auf 3 werden die Auftragsdaten dann untersucht, um zu ermitteln, ob der Benutzer darin eine Verkäuferseite-Anweisung eingeschlossen hat. In Übereinstimmung mit einem Ausführungsbeispiel sind in dem System platzierte Aufträge durch Voreinstellung nur für Benutzer auf der Käuferseite sichtbar. Käuferseite-Benutzer haben jedoch die Option, ihre Aufträge für die Verkäuferseite/Macher sichtbar zu machen durch Hinzufügung einer ”Verkäuferseite”-Anweisung zu ihrem Auftrag. Solch eine Verkäuferseite-Anweisung kann zum Zeitpunkt des Auftrags angegeben werden, z. B. durch Anklicken einer ”Verkäuferseite”-Box, die in 2a und 2b gezeigt wird. Alternativ kann solch eine Anweisung automatisch durch das System in Übereinstimmung mit einem Benutzerprofil gesetzt werden. Benutzer auf der Verkäuferseite sind in der Lage, Aufträge in das System einzugeben, aber ihre Aufträge werden immer sichtbar für die Käuferseite sein. Sie sind jedoch in der Lage, Aufträge vor anderen Benutzern auf der Verkäuferseite/Marktmacherseite zu verstecken, und zwar durch Nichthinzufügen der ”Verkäuferseite”-Anweisung zu ihrem Auftrag.
Basierend auf den Handelshistoriendaten eines Benutzers, die in der Kerndatenbank 14 (1) gespeichert werden, und speziell dem Volumen von Abschlüssen, die der Benutzer innerhalb eines spezifizierten historischen Zeitrahmens getätigt hat (z. B. vergangener Monat, vergangene vier Monate, vergangene sechs Monate etc.) kann einem bestimmten Client ein ”Rang” zugewiesen werden. Als Anreiz für die Verwendung des Systems kann das System so konfiguriert werden, dass hochrangigere Clients, z. B. diejenigen mit einem größeren historischen Volumen von Abschlüssen, vor niederrangigeren Clients mit Alarmen beliefert werden. In einem Ausführungsbeispiel gibt es zwei Ränge von Benutzern, Rang 1 und Rang 2. Rang-1-Benutzer empfangen Alarme vor Rang-2-Benutzern und anderen Teilnehmern. In einem Ausführungsbeispiel ist das System konfiguriert, um Alarme zu Rang-1-Benutzern eine Minute vor Rang-2-Benutzern zu übertragen. Das System kann konfiguriert sein, so dass Benutzer ein voreingestelltes minimales Volumen von Abschlüssen innerhalb einer spezifizierten Zeitperiode erreichen müssen, um für Rang-1-Alarme berechtigt zu sein. So kann von Benutzern beispielsweise gefordert werden, zumindest einmal innerhalb der letzten Woche auf dem System gehandelt zu haben. Alarm-Subskriptionen werden durch das System überprüft, wenn ein neuer Auftrag in dem System platziert wird, um zu ermitteln, welche Benutzer den Alarm zuerst erhalten. Das System kann konfiguriert sein, so dass Rang-1-Alarme nur durch Inhouse-Frontends verfügbar sind und alle externen Alarm-Abonnenten den Rang 2 zugewiesen bekommen.
4 zeigt eine grafische Illustration, die ein Beispiel eines Webapplikationsinterfaces zeigt, welches ein Alarmfenster, ein Aktienlisten-Fenster und ein Handlungsfenster in Übereinstimmung mit einem Ausführungsbeispiel aufweist. In Übereinstimmung mit einem Ausführungsbeispiel zeigt das Alarmfenster Alarme/IOIs für Aufträge an, und zwar sobald und wann sie in dem System platziert werden, unter Berücksichtigung des Zielrangpegels des Benutzers und der Client-Gruppensichtbarkeit (z. B. Käuferseite, Verkäuferseite oder dunkler Anbieter). Das Fenster kann als ein permanentes Anzeigefenster voreingestellt sein. Das System kann jedoch konfiguriert sein, Benutzern die Fähigkeit zum rechten Mausklick zu gestatten, beispielsweise auf dem Fenster und es als ”gesetzt als Popup-Fenster” auszuwählen, falls sie bevorzugen, dass das Fenster auf Empfang eines neuen Alarms hin öffnet. Das Alarmfenster zeigt die Aktie, die Seite und die Menge für jeden neuen Alarm/IOI an. Das System kann konfiguriert sein, einen Alarm/IOI verfallen zu lassen und vom Alarmfenster zu beseitigen, und zwar nach einer voreingestellten Zeitperiode, beispielsweise zwei Minuten.
Wie in 4 gezeigt kann ein Aktienlisten-Fenster in dem Webapplikationsinterface zum Betrachten und Interagieren mit momentanen und historischen Auftragsdaten bereitgestellt werden. Das Interface erlaubt Benutzern, die ein Abonnement zum Betrachten von Auftragsdaten für im System platzierte Aufträge haben, lebende Aufträge sowie gehandelte zu sehen, sowie die Auftragshistorie von gestrichenen und abgelaufenen Aufträgen über einen spezifizierten Zeitraum zu sehen, z. B. über die letzten 30 Tage. Jeder Auftrag kann in einer separaten Zeile repräsentiert werden, wobei die Zeilen so sortiert werden, dass lebende Aufträge oben erscheinen, sortiert nach Datum und Zeit, gefolgt von den gehandelten, gestrichenen und abgelaufenen historischen Aufträgen, die jeweils auch nach Datum und Zeit sortiert werden. Das System kann so konfiguriert werden, dass, wenn ein neuer lebender Auftrag zu dem System für eine Aktie hinzugefügt wird, die in dem Aktienlistenfenster eines Benutzers angezeigt wird, die Zeile für den Auftrag in einer bestimmten Farbe angezeigt wird, die allmählich über einen Zeitraum, beispielsweise zwei Minuten, verblaßt, um die darunterliegende Spaltenfarbe für den Auftrag sichtbar zu machen.
Verhandlungen über historische Auftragsdaten sowie lebende Aufträge werden über ein Zweiwege-Nachrichtensystem ermöglicht, das beispielsweise aktiviert wird durch Doppelklicken auf einen bestimmten Auftrag, der in dem Aktienlistenfenster oder dem Alarmfenster, das in 4 gezeigt wird, aktiviert wird, oder durch Aktivieren eines Knopfes oder einer anderen Steuerung, die mit dem Auftrag in einem solchen Fenster assoziiert ist. 5 zeigt eine grafische Illustration eines Zweiwege-Nachrichten-Systeminterfaces. Das Zweiwege-Nachrichten-System kann als Echtzeit-Nachrichtensystem bereitgestellt werden, z. B. Instant Messaging, oder als Nicht-Echtzeit-Nachrichtensystem wie etwa ein EMail-System. Das Zweiwege-Nachrichtensystem kann als Teil der Webapplikation, die auf dem Webclient 20 (1) läuft, bereitgestellt werden.
Benutzer können das Zweiwege-Nachrichteninterface von 5 verwenden, um auf einen interessierenden Auftrag zu zielen und eine eingeschränkte Nachricht dem Eigner des historischen Auftrags unter Verwendung hart kodierter Phrasen aufzuspielen, die durch das System mittels beschränkter Tastenschläge oder Knopfdrucke erlaubt werden. Tasten-Sticker können Benutzern bereitgestellt werden, um bestimmte Tasten mit bestimmten erlaubten Phrasen zu assoziieren. So kann beispielsweise die S-Taste assoziiert sein mit der Phrase ”Sorry, momentan nicht” und die W-Taste kann assoziiert sein mit der Phrase ”Wirst Du handeln bei”. Die hart kodierten Phrasen können auf ähnliche Weise implementiert werden in der Form einer Serie von Phrasen, die mit einer entsprechenden Serie von Soft-Buttons assoziiert sind, die auf dem Interface von 5 erscheinen. In solchen Ausführungsbeispielen beschränkt das System die Parteien auf Kommunikationen unter Verwendung einer endlichen Anzahl von Phrasen, die mit einer endlichen Anzahl von entsprechenden Knöpfen sowie den Zahlentasten auf der Tastatur des Benutzers. Numerische Tasten sind vorzugsweise nicht beschränkt.

Nachfolgend eine exemplarische Liste der Nachrichten, die durch das Verhandlungsfenster unter Verwendung von Soft-Buttons (z. B. Sorry) gestattet werden und durch die Maus oder Hot-Keys (z. B. W) mittels der Tastatur aktiviert werden:

Knopfbezeichner	Volltextnachricht	Tastatur-Hot-Key
Ja:	Ja	J
Nein:	Nein	N
Wirst:	Wirst du handeln für _?	W
Sorry:	Sorry, momentan nicht	S
Bester:	Mein bester Preis ist	B
Anruf:	Muß Anruf tätigen, bin gleich zurück	A
Limit:	Momentan limitiert bei	L
Neg ID:	Fordert eine Verhandlungs-ID an	I

Das Verhandlungsfenster von 5 zeigt eine Verhandlung zwischen zwei Teilnehmern. Der erste Teilnehmer hat eine Nachricht ”Wirst du handeln bei 22,75?” an den Eigner des Auftrags WTB.L, verkaufe, 1,000,000 gesandt. Der Auftragseigentümer wird antworten mit ”Sorry, momentan nicht”.
Wenn eine Verhandlung zu einer Übereinstimmung in Sachen Preis oder Volumen führt, können Benutzer eine systemerzeugte Verhandlungs-ID anfordern, die einem festen Auftrag hinzugefügt wird, um den Auftrag von der Ausführung mit irgendjemand anderem als dem Verhandlungspartner auszuschließen. Diese ID kann systemerzeugt sein durch die Webanwendung und sichtbar für beide Benutzer. Beide Benutzer geben einen Auftrag mit ihren verabredeten Auftragsparametern (Größe, Preis) ein, wobei sie die Verhandlungs-ID zu ihrem Auftrag in ein Verhandlungstext-Feld einfügen. Dies verschließt effektiv den Auftrag für die beiden Teilnehmer und verhindert, dass der Auftrag des Benutzers mit einer anderen Partei als derjenigen gekreuzt wird, mit der verhandelt wurde. Der vervollständigte Auftrag wird über eine externe Handelsfreigabe freigegeben (1).
6 zeigt ein Beispiel eines fortgeschrittenen Suchfensters in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung, das es einem Benutzer erlaubt, Kriterien ihrer Wahl einzugeben, um Aufträge, die im System platziert wurden, anzuzeigen. Wenn der Benutzer in die Webapplikation eingeloggt ist, wird ihm das Suchfenster präsentiert. Der Benutzer kann dieses Fenster verwenden, um Anfragen auf einer Ad-hoc-Basis zu erzeugen, oder er kann seine bevorzugten Suchkriterien aufsetzen und die Suchanfrage speichern, so dass bei nachfolgenden Log-ins alles, was von ihm gefordert wird, die Auswahl des Suchanfragenamens und die Auswahl eines ”Los”-Knopfs oder einer ähnlichen Steuerung ist.
In dem Suchfenster von 6 bietet ein ”Symbol”-Feld ein Mittel für einen Benutzer, um eine spezifische Aktie zu identifizieren, mehrere Aktien unter Verwendung eines Komma-Separators zu identifizieren, oder eine oder mehrere Aktien von einer Liste auszuwählen. Ein ”Symbol-Typ”-Feld erlaubt dem Benutzer, den Typ des Symbols, das in das Symbolfeld eingegeben wird, auszuwählen, z. B. ”Instinet”-Symbol, ”RIC”, ”Cusip”, ”Sedol” und Bezugnahmen auf Produktangebote dritter Parteien wie etwa Bloomberg. Ein ”Alarm ausgeschlossen”-Feld bietet dem Benutzer die Möglichkeit, diejenigen Aufträge von den Suchergebnissen auszuschließen, für die ein Alarm erzeugt wurde. Ein ”Seite”-Feld bietet eine Drop-Down-Liste, die dem Benutzer ermöglicht, die Suche entweder auf Aufträge von Käuferseite oder Verkäuferseite zu beschränken. Ein ”Auftragstyp”-Feld erlaubt dem Benutzer, die Suche auf Aufträge zu beschränken, die entweder lebend, gehandelt, gestrichen oder abgelaufen sind. Ein ”Menge”-Feld bietet ein Mittel, um dem Benutzer einen Bereich zu spezifizieren, z. B. 10000 bis 20000. Ein ”Instrument-Typ”-Feld erlaubt es dem Benutzer, einen spezifischen Typ von Instrument zu suchen, beispielsweise UKE, ITE, USE, USEO, oder CAE. Ein ”Markt”-Feld erlaubt dem Benutzer, seine Suche auf einen bestimmten Markt zu beschränken, z. B. U. K. oder U. S. Ein ”Region”-Feld erlaubt auf ähnliche Weise dem Benutzer, seine Suche auf eine bestimmte Region zu beschränken, beispielsweise Europa, USA, oder Asien, oder auf mehrere Regionen unter Verwendung eines Komma-Separators. Ein ”Währung”-Feld erlaubt dem Benutzer, die Suche auf Aufträge in einer bestimmten Währung zu beschränken, z. B. GBP, GBp, USD, JPY, HKD, EUR, CHE, NOK, DKK, ZAR, oder alle. Ein ”Prozent ADV”-Feld erlaubt es dem Benutzer, einen Bereich zu spezifizieren, z. B. zwischen 5% und 200%, für den Prozentsatz der Ordermenge, die es für die spezifizierte Aktie gibt. Ein ”Auch versteckt”-Feld erlaubt dem Benutzer, in den Suchergebnissen Aufträge einzuschließen, die mit der ”Versteckt”-Anweisung, die oben diskutiert wurde, platziert wurden. Ein ”Suche Paket-Match”-Knopf veranlaßt die Anfrage, mit den obigen Kriterien ausgeführt zu werden und gibt eine Liste von Aufträgen in dem System zurück, die zu den Suchkriterien passen.
Das System kann so konfiguriert werden, dass es den Benutzern ein gegenseitig vorteilhaftes Kostenmodell für zwei Parteien bereitstellt, die große Pakete von Aktien außerbörslich kreuzen möchten. In dieser Beziehung kann das System zwei Kostenmodell-Optionen bereitstellen – ein Flatrate-Kostenmodell und ein Abschlags-/Gebühren-Kostenmodell.
Die Flatrate-Kostenmodell-Option bietet Benutzern, die ein Flatrate-Kostenmodell wünschen, Zugriff zu dem System mit Flatratekosten pro Handel, z. B. 2,5 bp pro Handel für DMA-Aufträge oder Aufträge, die in dem System über einen Repräsentanten des Systemeigners platziert wurden. Aufträge, die mit dem System unter Verwendung von mehreren Mehrwert-addierenden Algorithmen platziert wurden, die den Zugriff auf Liquidität automatisieren, können mit einer anderen, höheren Flatrate, z. B. 3 oder 4 bp angeboten werden.
Die Abschlags-Gebühren-Kostenmodell-Option bietet Benutzern die Möglichkeit, eine Transaktion auszuführen, wo der kaufende Bereitsteller einen Nettopreis von z. B. 10 – 2,5 bp erhält und der Verkäufer einen Nettopreis von z. B. 10 – 7,5 bp erhält. Um das Abschlags-/Gebühren-Modell unterzubringen, wird konfiguriert, automatisch Klein-Abschlüsse als Gebühr oder Abschlag auf einer per-Abschluß-Basis zu berechnen, basierend darauf, welcher Client der Anbieter oder der Nehmer von Liquidität war. Alternativ kann das System konfiguriert sein, um die Verarbeitung aller Abschlüsse unter einem Flatrate-Modell zu erlauben und dann am Ende des Tages oder Monats manuell jede Rate mit einer neuen Rate überschreiben, nachdem alle Abschläge/Gebühren in Betracht gezogen wurden.
Somit kann das System so konfiguriert werden, dass es Teilnehmern, die direkt in ihm posten, die Fähigkeit anbietet, mit einer Flatrate, z. B. 7,5 bp ”Liquidität zu nehmen”, während ”Liquiditätsanbieter” von einem Abschlag, z. B. 2,5 bp auf Aufträgen profitieren. Das System kann ferner konfiguriert sein, so dass Teilnehmer, die ungefähr ein gleiches Verhältnis von dem Anbieten und nehmen von Liquidität handeln, auf das System mit einer Flatrate zugreifen können, wie beispielsweise dem mittleren Punkt der gesamten Kommission für das direkte Posten und das Nehmen von Liquidität, z. B. 2,5 bp, auf allen Abschlüssen.
Während die Erfindung insbesondere gezeigt und beschrieben wurde unter Bezugnahme auf eines ihrer bevorzugten Ausführungsbeispiele, wird der Fachmann verstehen, dass verschiedene Veränderungen in Form und Details davon gemacht werden können, ohne vom Geist und Umfang der Erfindung abzuweichen.
Zusammenfassung
Es wird ein anonymes Pakethandels-Matchingsystem offenbart, das Benutzern, die große Blöcke von Aktien kreuzen möchten, Aufträge einzugeben oder Interessenindikationen mit der Option der Verwendung von Markt-Peg-Benchmarks oder zukünftigen Preiskreuzungsbenchmarks. Eingegebene Aufträge können minimalen Schwellwerten unterworfen werden, einschließlich eines Schwellwerts, der erfordert, dass der Auftrag ”X”% des täglichen durchschnittlichen Volumens repräsentiert. Nach Eingabe eines festen Auftrags in das System wird ein Alarm erzeugt, um die Auftragsdaten anderen Benutzern mit der Möglichkeit zum Kreuzen des Auftrags bereitzustellen. Die Sichtbarkeit von Auftragsdaten durch andere Benutzer kann basierend auf einer Dateninteraktionsgruppe beschränkt werden, zu der der auftragerteilende Benutzer oder der andere Benutzer gehört. Das System kann das Ansehen von Auftragsdaten ermöglichen mit der Fähigkeit des Verhandelns mit dem eingebenden Benutzer über ein beschränktes Zweiwege-Nachrichteninterface. Flatrate und Abschlags-/Gebühren-Kostenmodelle können als Mittel verwendet werden, um einem Benutzer den Zugriff auf das System in Rechnung zu stellen.

Claims

Anonymes Pakethandels-Matchingsystem, welches aufweist: zumindest einen Server, der konfiguriert ist, über ein Netzwerk Auftragsdaten für einen Auftrag eines Wertpapiers zu empfangen, wobei die Auftragsdaten die Spezifikation eines Benutzers einer Peis-Benchmark für den Auftrag umfassen, wobei die Preis-Benchmark ausgewählt wurde von einer Gruppe bestehend aus: ein Peg-Wert mit einem harten Limit, ein Peg-Wert ohne ein hartes Limit, oder ein zukünftiger Kreuzungspreis; eine Kerndatenbank, in der die Auftragsdaten gespeichert sind, wobei die Auftragsdaten die Preis-Benchmark einschließen; einen Alarmgenerator, der konfiguriert ist, die Auftragsdaten zu verwenden, um an zumindest eine potentielle Handelspartei anonym einen Alarm zu übertragen, der den Auftrag beschreibt.
Anonymes Pakethandels-Matchingsystem nach Anspruch 1, wobei der zumindest eine Server ferner konfiguriert ist, die Auftragsdaten über ein privates Netzwerk zu empfangen.
Anonymes Pakethandels-Matchingsystem nach Anspruch 1, wobei der zumindest eine Server ferner konfiguriert ist, die Auftragsdaten über ein öffentlich zugreifbares Netzwerk zu empfangen.
Anonymes Pakethandels-Matchingsystem nach Anspruch 1, wobei der zumindest eine Server einen ersten Server zum Empfangen der Auftragsdaten über ein öffentlich zugreifbares Netzwerk aufweist und einen zweiten Server zum Empfangen anderer Auftragsdaten über ein privates Netzwerk.
Anonymes Pakethandels-Matchingsystem nach Anspruch 1, ferner aufweisend eine Matching-Engine zum Finden eines Auftrags auf gegenüberliegender Seite, die den Benchmarkwert erfüllt.
Anonymes Pakethandels-Matchingsystem nach Anspruch 1, wobei der Alarmgenerator ferner konfiguriert ist, den Alarm so zu generieren, dass ein alphabetischer Benchmarkwert und nicht ein tatsächlicher Preis-Wert in dem Alarm für die potentielle Handelspartei angezeigt wird.
Anonymes Pakethandels-Matchingsystem nach Anspruch 6 wobei die Preis-Benchmark einen Peg-Wert aufweist und der alphabetische Benchmarkwert ausgewählt wird aus der Gruppe bestehend aus: MID, BID oder ASK, wobei der Benchmarkwert auf einen Primärmarkt für den Preis des Wertpapiers Bezug nimmt.
Anonymes Pakethandels-Matchingsystem nach Anspruch 1, wobei der Preis-Benchmark einen zukünftigen Kreuzungspreis aufweist und der alphabetische Benchmarkwert ausgewählt aus der Gruppe bestehend aus: VWAP, OPEN oder CLOSE, wobei der VWAP-Benchmarkwert einen Preis referenziert, der nach dem Ermessen eines Eigentümers des Systems bestimmt wird und die OPEN- und CLOSE-Benchmarkwerte einen Primärmarkt für den Preis des Wertpapiers referenzieren.
Anonymes Pakethandels-Matchingsystem nach Anspruch 1, wobei das System ferner so konfiguriert ist, dass, wenn eine Börse, auf der das Wertpapier gehandelt wird, jenseits des vom Benutzer spezifizierten harten Limits wandert, ein Auftragstyp, der mit dem Auftrag assoziiert ist, automatisch von dem Typ Preisbenchmark in den Typ Auftrag mit hartem Limit sich ändert.
Anonymes Pakethandels-Matchingsystem nach Anspruch 9, wobei das System ferner so konfiguriert ist, dass der Alarm einen Preis mit hartem Limit im numerischen Format anzeigt, nach der Veränderung von einem Preis-Benchmark-Auftragstyp zu einem Auftragstyp mit hartem Limit.
Anonymes Pakethandels-Matchingsystem nach Anspruch 9, wobei das System ferner so konfiguriert ist, dass, wenn nach der Veränderung im Auftragstyp die Börse sich unter das vom Benutzer spezifizierte harte Limit bewegt, der Auftragstyp automatisch zurückkehrt zum Auftragstyp Preis-Benchmark.
Anonymes Pakethandels-Matchingsystem nach Anspruch 11, wobei das System ferner so konfiguriert ist, dass der Alarm wiederum eine alphabetische Benchmark anzeigt nach der Veränderung von dem Auftragstyp mit hartem Limit zum Auftragstyp Preis-Benchmark.
Anonymes Pakethandels-Matchingsystem nach Anspruch 8, wobei das System ferner so konfiguriert ist, dass, nachdem eine primäre Börse einen offiziellen Preis für das beauftragte Wertpapier unter Verwendung einer zukünftigen Kreuzungsbenchmark veröffentlicht hat, Handelskorrekturen an beide Teilnehmer zu dem offiziellen Kreuzungspreis gesandt werden.
Anonymes Pakethandels-Matchingsystem, aufweisend: einen Server, der konfiguriert ist, Auftragsdaten für einen Auftrag eines Wertpapiers zu empfangen; eine Kerndatenbank, in der die Auftragsdaten gespeichert sind; und einen Alarmgenerator, der konfiguriert ist, um die Auftragsdaten zu verwenden, um an eine Mehrzahl von potentiellen Parteien anonym einen Alarm zu übertragen, der den Auftrag beschreibt, wobei der Alarmgenerator konfiguriert ist, den Alarm selektiv an eine Mehrzahl von potentiellen Parteien zu senden basierend auf einer Angabe in den Auftragsdaten dahingehend, welche Typen von Benutzern den Alarm empfangen sollen.
Anonymes Pakethandels-Matchingsystem nach Anspruch 14, wobei der Alarmgenerator eine Datenbank umfaßt.
Anonymes Pakethandels-Matchingsystem nach Anspruch 14, wobei die Angabe in den Auftragsdaten, welcher Typ von Benutzern den Alarm empfangen soll, eine Angabe umfaßt, dass der Alarm von einer Gruppe von Benutzern versteckt werden soll.
Anonymes Pakethandels-Matchingsystem nach Anspruch 16, wobei die Gruppe von Benutzern alle Benutzer umfaßt.
Anonymes Pakethandels-Matchingsystem nach Anspruch 16, wobei die Gruppe von Benutzern weniger als alle Benutzer umfaßt.
Anonymes Pakethandels-Matchingsystem nach Anspruch 14, wobei die Angabe in den Auftragsdaten betreffend welcher Typ von Benutzern den Alarm empfangen soll, eine Angabe aufweist, ob Benutzer auf Verkäuferseite den Alarm empfangen sollen.
Anonymes Pakethandels-Matchingsystem nach Anspruch 14, wobei der Alarmgenerator den Alarm mittels Voreinstellung auf Benutzer auf Käuferseite überträgt, und wobei die Angabe in den Auftragsdaten bezüglich des Typs von Benutzern, welche den Alarm empfangen sollen, eine Angabe umfaßt, ob Benutzer auf der Verkäuferseite den Alarm empfangen sollen.
Anonymes Pakethandels-Matchingsystem nach Anspruch 14, wobei die Angabe in den Auftragsdaten bezüglich des Typs von Benutzern, die den Alarm empfangen sollen, eine Angabe umfaßt, ob Marktmacher-Benutzer den Alarm empfangen sollen.
Anonymes Pakethandels-Matchingsystem nach Anspruch 14, wobei der Alarmgenerator konfiguriert ist, einen dunklen Anbieter am Ansehen der Auftragsdaten zu hindern.
Anonymes Pakethandels-Matchingsystem, aufweisend: einen Server, der konfiguriert ist, Auftragsdaten für einen Auftrag eines Wertpapiers zu empfangen; eine Kerndatenbank, die Auftragsdaten speichert; und einen Alarmgenerator, der konfiguriert ist, die Auftragsdaten zu verwenden, um anonym einen Alarm an eine Mehrzahl von potentiellen Parteien zu übertragen, der den Auftrag beschreibt, wobei der Alarmgenerator konfiguriert ist, den Alarm an eine erste Untermenge der Mehrzahl von potentiellen Parteien zu übertragen und danach den Alarm an eine zweite Untermenge von der Mehrzahl der potentiellen Parteien zu übertragen, nach dem Ablauf einer vorbestimmten Zeitperiode von der Übertragung des Alarms an die erste Untermenge der Mehrzahl von potentiellen Parteien.
Anonymes Pakethandels-Matchingsystem nach Anspruch 23, wobei die vorbestimmte Zeitspanne eine Minute ist.
Anonymes Pakethandels-Matchingsystem nach Anspruch 23, wobei das System ferner konfiguriert ist, so dass ein Benutzer, um berechtigt zu sein, in der ersten Untermenge eingeschlossen zu werden, das System in der Vergangenheit verwendet haben muß, um eine Anzahl von Wertpapiergeschäften auszuführen.
Anonymes Pakethandels-Matchingsystem nach Anspruch 25, wobei die Anzahl von Wertpapiergeschäften 1 ist.
Anonymes Pakethandels-Matchingsystem nach Anspruch 25, wobei Berechtigung davon abhängt, ob der Benutzer das System innerhalb einer vorbestimmten vergangenen Zeitspanne verwendet hat.
Anonymes Pakethandels-Matchingsystem nach Anspruch 27, wobei die vorbestimmte vergangene Zeitspanne eine Woche ist.
Anonymes Pakethandels-Matchingsystem nach Anspruch 23, wobei der Alarmgenerator konfiguriert ist, um den Alarm durch die Platzierung eines neuen Auftrags zu übertragen.
Anonymes Pakethandels-Matchingsystem nach Anspruch 23, wobei der Alarmgenerator konfiguriert ist, den Alarm durch die Platzierung eines festen Auftrags zu übertragen.
Anonymes Pakethandels-Matchingsystem, aufweisend: einen Server, der konfiguriert ist, Auftragsdaten für einen Auftrag eines Wertpapiers durch einen ersten Benutzer zu empfangen; eine Kerndatenbank, die darin die Auftragsdaten speichert; einen Alarmgenerator, der konfiguriert ist, die Auftragsdaten zu verwenden, um an zumindest einen zweiten Benutzer anonym einen Alarm zu übertragen, der den Auftrag beschreibt; und einen Client, der konfiguriert ist, dem zweiten Benutzer ein Zweiwege-Nachrichten-Interface anzuzeigen, das eine Verhandlungskonversation zwischen dem ersten Benutzer und dem zweiten Benutzer ermöglicht, wobei das Zweiwege-Nachrichten-Interface die Kommunikation von zumindest einem der ersten Benutzer und dem zweiten Benutzer auf einen endlichen Satz von Phrasen einschränkt.
Anonymes Pakethandels-Matchingsystem nach Anspruch 31, wobei das Zweiwege-Nachrichten-Interface konfiguriert ist, um die Kommunikation von beiden, dem ersten Benutzer und dem zweiten Benutzer, auf den endlichen Satz von Phrasen einzuschränken.
Anonymes Pakethandels-Matchingsystem nach Anspruch 31, wobei das Zweiwege-Nachrichten-Interface konfiguriert ist, um einen Tastendruck durch den ersten Benutzer in eine Verhandlungsphrase zu übersetzen und die Verhandlungsphrase an den zweiten Benutzer zu übertragen.
Anonymes Pakethandels-Matchingsystem nach Anspruch 31, wobei das Zweiwege-Nachrichten-Interface konfiguriert ist, um das Drücken eines Soft-Buttons oder eines Mausklicks durch den ersten Benutzer in eine Verhandlungsphrase zu übersetzen und die Verhandlungsphrase an den zweiten Benutzer zu übertragen.
Anonymes Pakethandels-Matchingsystem nach Anspruch 31, wobei das System konfiguriert ist, so dass, wenn eine Verhandlung zwischen dem ersten Benutzer und dem zweiten Benutzer unter Verwendung des Zweiwege-Nachrichten-Interfaces abgeschlossen wurde, das System eine Verhandlungs-ID erzeugt, die den Auftragsdaten hinzugefügt wird und den Auftrag vom Handel mit irgendeiner Partei anders als der erste Benutzer und der zweite Benutzer verschließt.
Anonymes Pakethandels-Matchingsystem, aufweisend: einen Server, der konfiguriert ist, Auftragsdaten für einen Auftrag eines Wertpapiers zu empfangen, wobei die Auftragsdaten eine Angabe enthalten, dass eine Nettopreis-Verbesserung einem Liquiditäts-Anbieter, der den Auftrag platziert, bereitgestellt wird; eine Kerndatenbank, die die Auftragsdaten speichert; und eine Matching-Engine zum Finden eines Auftrags gegenüberliegender Seite, die den Wertpapierauftrag matcht.
Anonymes Pakethandels-Matchingsystem nach Anspruch 36, ferner aufweisend einen Alarmgenerator, der konfiguriert ist, die Auftragsdaten zu verwenden, um anonym einen Alarm an zumindest eine potentielle Handelspartei zu übertragen, der den Auftrag beschreibt.
Anonymes Pakethandels-Matchingsystem, aufweisend: einen Server, der konfiguriert ist, Auftragsdaten für einen Wertpapierauftrag eines Benutzers zu empfangen; eine Kerndatenbank, in der die Auftragsdaten gespeichert werden; und eine Matching-Engine zum Finden eines Auftrags gegenüberliegender Seite, welche den Wertpapierauftrag matcht, wobei die Matching-Engine konfiguriert ist, den Auftrag des Benutzers zurückzuweisen, wenn der Auftrag sich nicht an einen Schwellwert minimaler Größe hält, der dem Wertpapier zugewiesen ist.
Anonymes Pakethandels-Matchingsystem nach Anspruch 38, wobei der Schwellwert minimaler Größe Liquidität des Wertpapiers umfaßt.
Anonymes Pakethandels-Matchingsystem nach Anspruch 38, wobei der Schwellwert minimaler Größe einen Preispegel des Wertpapiers umfaßt.
Anonymes Pakethandels-Matchingsystem nach Anspruch 38, wobei der Schwellwert minimaler Größe eine Aktienmenge des Wertpapiers umfaßt.
Anonymes Pakethandels-Matchingsystem nach Anspruch 38, wobei der Schwellwert minimaler Größe ein durchschnittliches tägliches Volumen von Aktien des Wertpapiers, die an einer Börse gehandelt werden, umfaßt.
Anonymes Pakethandels-Matchingsystem nach Anspruch 38, ferner aufweisend einen Alarmgenerator, der konfiguriert ist, die Auftragsdaten zu verwenden, um anonym einen Alarm an zumindest eine potentielle Handelspartei zu übertragen, die den Auftrag beschreibt.