Tradingarchitekturen – Tests & Kapazitätsprüfungen bei Tradingsystemen

Die Bedeutung des Prüfens von Technologie-Stacks sollte als selbstverständlich angesehen werden, sei es in der verarbeitenden Industrie oder in einem privaten oder öffentlichen Dienstleistungssektor. Die Besonderheit beim Testen von Trading-Architekturen ist dabei, dass sich die Technologie in einem Tempo entwickelt hat, mit dem die Prozesse nicht Schritt halten konnten.

von Steven Townsend, Operations Manager bei Spectrum Markets

Wenn Sie zum Beispiel ein Auto nehmen, könnten Sie zu Recht argumentieren, dass die heutigen Fahrzeuge nicht mehr viel mit denen von vor 30 oder 40 Jahren gemein haben. Sie würden aber auch nicht bestreiten, dass die Automobilhersteller seit der Erfindung des Benz Patent-Motorwagens an das Testen gewöhnt sind und dass sich die Testanforderungen parallel zum technologischen Fortschritt entwickelt haben, während die Relevanz aller externen Faktoren – von der individuellen Sicherheit bis hin zu Umweltfragen – linear gestiegen ist. Zwar haben sich auch hier die Entwicklungszyklen deutlich verkürzt. Aber so viele branchenweit standardisierte Anforderungen bedeuten, dass es immer eine natürliche Linearität gibt zwischen dem, was technisch möglich ist und dem, was wann und wie in die Produktion gehen wird. Die Erprobung ist hier viel stärker in der Gesamtprozessgestaltung verankert, nicht zuletzt wegen der immensen Haftungsrisiken, die von Bauteilen oder Funktionen ausgehen, die letztlich nicht alle relevanten Anforderungen erfüllen. Die Intensität der Tests im automobilen Sektor ist für jeden leicht nachvollziehbar, wenn man an das autonome Fahren denkt.

Die Technik hat den digitalen Wertpapierhandel revolutioniert

Beim Trading war die Entwicklung viel weniger linear und Anreize zum Testen gab es eher selten; ein fehlgeschlagener Trade aufgrund eines technischen Fehlers war sowohl in finanzieller Hinsicht als auch aus Sicht des Rufs weniger kostspielig. Einfach ausgedrückt:

Die ultimative Testmethode war die Produktion. Auch die Regulierung war nicht so streng. Dann entstand innerhalb eines vergleichsweise kurzen Zeitraums eine völlig neue Welt.”

Die Technik hat den digitalen Wertpapierhandel in Bezug auf Volumen, Frequenz, Komplexität und Automatisierung revolutioniert. Heterogene Systemlandschaften, komplexere End-to-End-Prozessdesigns, verschiedene Taxonomien und ein nicht minder komplexes Regulierungssystem haben die Branche innerhalb von nicht viel mehr als einem Jahrzehnt auf den Kopf gestellt. Unternehmen, die es sich früher leisten konnten, die Entwicklung jeder einzelnen Lösung auszulagern, oder die extrem komplexen und nicht standardisierten proprietäre Systeme aufgebaut haben, haben es heute schwer, bei der Überwachung des Grundgerüsts ihres Unternehmens jemals “die Nase vorn” zu haben.

Die Regulierung hatte diese Probleme als systemisch für die Tradingbranche identifiziert, wobei mangelnde Prozesstransparenz eines der wichtigsten Themen ist, das viele andere Probleme hervorruft und verstärkt. In einem Basisszenario wäre dies schädlich für den Wettbewerb und benachteiligend für die Anleger. In einem Worst-Case-Szenario könnte die Dysfunktionalität des gesamten Marktes verschärft werden. Mit MiFID II wurde ein System der Vorhandelstransparenz und des Risikomanagements eingeführt. Es schreibt vor, dass Handelsplätze jederzeit in der Lage sein müssen, festzustellen, welcher Mensch oder Algorithmus sich für einen Trade entschieden hat.

Sie müssen Preisobergrenzen, Begrenzungen des Wertes einzelner Aufträge oder des Gesamtvolumens oder der Anzahl der zu empfangenden Nachrichten, Auftragsstornierungen oder Kill-Switch-Funktionen einführen.”

Zusätzlich zu der Notwendigkeit, diese Maßnahmen zur Prävention von Störungen des Marktes zu testen – was sich noch verschärft, wenn Algorithmen ins Spiel kommen – gibt es Überwachungsanforderungen im Rahmen von MiFID II sowie der MAR oder die verschiedenen Testanforderungen, die sich aus den einschlägigen IT-Governance-Vorschriften auf nationaler oder supranationaler Ebene ergeben. Die regulatorisch bedingte Dynamik hat den Druck auf die Testzyklen erhöht, die aufgrund der verkürzten Vorlaufzeiten ohnehin kürzer geworden sind.

Algotrading stellt höhere Ansprüche an die Testumgebung

Ein erheblicher Aufwand ist dem algorithmischen Handel zuzuschreiben, der von den Handelsplätzen verlangt, den Mitgliedern eine Testumgebung zur Verfügung zu stellen, die Simulationsmöglichkeiten zum Testen aller relevanten Auftrags- und Auftragsflussszenarien bietet. Die Kapazitätsprüfung kann sehr anspruchsvoll sein und umfasst die Prüfung der Upstream-Konnektivität, der Auftragsübermittlungskapazität, der Drosselungskapazitäten und der Frage, ob die Aufträge durch den Empfang über verschiedene Gateways ausgeführt werden können. Das elektronische Handelssystem muss im Rahmen der Kapazitätstests überprüft werden und aufzeigen, dass es Aufträge mit akzeptabler Latenzzeit zusammenführen kann. Dies gilt auch für die nachgelagerte Konnektivität und die Überwachungsinfrastruktur, die die Leistung dieser Funktionen misst.

Ein Handelsplatz muss prüfen, ob die Leistung seiner Systeme noch angemessen ist, wenn die Zahl der Nachrichten pro Sekunde die höchste in den letzten fünf Jahren aufgezeichnete Zahl von Nachrichten überschritten hat.”

Ist dies nicht der Fall, muss die zuständige Behörde über die Maßnahmen und den Zeitrahmen informiert werden, die zur Behebung etwaiger Kapazitätsmängel vorgesehen sind. Während sich diese Tests regelmäßig als schwierig erweisen, sind die gravierendsten Probleme im Verlauf der Tests mit den Integrationsaspekten verbunden.

Bei den Trading-Infrastrukturen handelt es sich häufig um gewachsene, anwendungsübergreifende Umgebungen, in denen verschiedene Technologien, APIs und Protokolle aufeinandertreffen. Dies kann das Testdesign und die Leistung kompliziert machen. Aber selbst bei modernsten digitalen Handelsplätzen mit einem branchenführenden Technologie-Stack bleibt die Integration der Schlüssel, da dies nicht nur ihre eigene Infrastruktur betrifft, sondern auch die nahtlose Verarbeitung aller Arten von Flüssen von den Infrastrukturen ihrer Mitglieder zu ihrer eigenen Plattform. Das heißt, die Mitglieder müssen erstens Zugang haben und zweitens müssen ihr Handelssystem, ihr Algorithmus oder ihre Strategie mit den Bedingungen des Handelsplatzes übereinstimmen. Im Rahmen der Konformitätstests sind die Handelsplätze regulatorisch verpflichtet, von ihren Mitgliedern den Nachweis zu verlangen, dass ihr System reibungslos mit dem Matching des Handelsplatzes interagiert und dass der bidirektionale Datenfluss adäquat verläuft. Die Mitglieder müssen sicherstellen, dass die Übermittlung, Änderung oder Stornierung eines Auftrags, IOIs, das Herunterladen von statischen Daten und Marktdaten sowie alle Geschäftsdatenflüsse reibungslos funktionieren. Neben diesen grundlegenden Funktionen müssen die Mitglieder zeigen, dass ihre Systeme den Befehl “Cancel on disconnect”, den Verlust von Marktdateneinspeisungen und Drosselungen, einschließlich deren Wiederherstellung, sowie die Wiederaufnahme des Handels während des Tages und die Handhabung von ausgesetzten Instrumenten oder nicht aktualisierten Marktdaten ausführen.

Verschiedene Versionen von FIX-Protokollen können zu Problemen führen

Idealerweise konzentriert sich ein Handelsplatz auf die Fragen der Konnektivität und verzichtet auf die Verwendung proprietärer Formate oder Protokolle. Gute Dienste liefern hier etwa das FIX-Protokoll, FIXT1.1 für den Sitzungs-Layer und FIX 5.0SP2 für die Anwendungs-Layer.

Es sind allerdings verschiedene Versionen von FIX im Einsatz. Schon geringe Unterschiede können zu Problemen bei der Konnektivität führen, deren Prüfung und Erkennung Zeit und Mühe kostet.”

Eine automatisierte Testlösung bietet ein Höchstmaß an Flexibilität beim Testen. Sie sollte über eine Vielzahl von Funktionen verfügen, die das Testen effizient und bequem macht und gleichzeitig die erforderlichen Berichts- und Analysefunktionen bieten, um wirklich aufschlussreiche Ergebnisse aus den Tests zu gewinnen. Verifix von Itivity bietet beispielsweise eine Sandbox-Umgebung, in der die Kernfunktionalität der Matching Engine getestet werden kann, bevor eine Verbindung zur Produktions- oder sogar zur Testinstanz hergestellt wird. Dies ermöglicht es, die Konformität bzw. das Onboarding des Clients von den Kernfunktionen des Austauschs zu trennen, indem Austauschvorgänge simuliert werden – ein sehr hilfreiches Tool für Kunden, um ihre Tests iterativ zu planen und zu konfigurieren. Eine dedizierte Testrolle ermöglicht es, den Client-Flow zu simulieren und somit Selbsttests im Rahmen unserer obligatorischen regelmäßigen Testverpflichtung durchzuführen oder immer dann, wenn Implementierungen oder Zwischenfälle Tests erfordern. Dabei sind jederzeit wiederholbare Back-Stress-Tests anhand des realen FIX-Verkehrs möglich. Nicht zuletzt kann man mit der Audit-Trail-Kapazität nachweisen, dass vor dem Anschluss, zu Aufsichtszwecken tatsächlich umfangreiche Tests durchgeführt wurden.Steven Townsend, Spectrum Markets