Trading AI | MiFID II, DORA, SFTR

Pre-trade, execution, and post-trade decisions ship deterministic constraint traces your auditor can replay. Built for MiFID II, DORA, and SFTR workflows.

Der Händler wird zum Ausführungszeitpunkt benannt

Die Wahl des Handelsplatzes wird bei der Ausführung erfasst

Der Händler wird aus dem Gedächtnis benannt

Die Regel befindet sich in einem Richtliniendokument

Review spielt dieselben Eingaben erneut ab

Die Wahl des Handelsplatzes wird später erläutert

Der Ort, der Preis und die verantwortliche Person bleiben bei Ihrem Auftrag.

Ihre Bestellung geht an einen gewählten Ort.

Ihre Bestätigung nennt den Weg, den sie genommen hat.

Der Ort, der Preis und die Zeit werden zusammen aufbewahrt.

Bestehende OMS-, EMS- und FIX-Gateways funktionieren weiter. Dweve umhüllt sie mit einer deterministischen Entscheidungsebene, die jede Order, jede Regel und jede Trader-Aktion zum Zeitpunkt der Ausführung aufzeichnet.

Geschlossenes Bundle für die sensibelsten Clearing-Daten.

Betrieb innerhalb von Euronext AMS oder in Ihrem In-House-Co-Lo.

Von Dweve betriebenes öffentliches Mesh; Verarbeitungsgrenze im Vertrag dokumentiert.

Integration über REST, gRPC oder FIX gegen eine typisierte Oberfläche. Verwaltet über Fabric auf dem öffentlichen Dweve Mesh für Piloten. Lizenziert für Ihre Co-Location. Air-gapped für die sensibelsten Clearing-Daten. Gleiche API, gleiches Trace-Format, gleiche Replay-Pakete über alle drei hinweg.

Der Trader signiert die endgültige Ausführung.

Auf die Route angewendete Venue-Version.

Routing-Regel erzeugt eine Roh-Entscheidung.

Order protokolliert, bevor die Regel läuft.

Bestehende OMS-, EMS- und FIX-Gateways funktionieren weiter. Dweve umhüllt sie mit einer deterministischen Entscheidungsebene, die jede Order, jede Regel und jede Trader-Aktion zum Zeitpunkt der Ausführung aufzeichnet. Das Replay-Paket ist das Prüf-Artefakt. Die Order wird protokolliert, bevor die Regel läuft, die Routing-Regel erzeugt die Roh-Entscheidung, die geltende Venue-Version wird angewendet, und der Trader signiert die endgültige Ausführung.

Trader signiert; Paket ist das Prüf-Artefakt.

Deterministische Berechnung wählt die Venue.

Jede Route zeichnet die verwendete Regelversion auf.

Order-Routing ist der Workflow, der am stärksten unter Float-Drift und Marktdaten-Skew leidet. Dweve führt die Routing-Entscheidung auf Integer-Arithmetik aus, pinnt an eine spezifische Venue-Auswahl-Regelversion und liefert jedes Mal dasselbe Routing. Das Paket ist das Prüf-Artefakt, wenn die AFM anruft. Die NewOrderSingle wird aus dem FIX-Feed gezogen, die verwendete Regelversion wird mit der Route aufgezeichnet, deterministische Berechnung wählt die Venue, und der Trader signiert. Wenn die Frage ist, welche Venue die Order genommen hat und warum, ist die Antwort dieses replizierte Paket, nicht eine Rekonstruktion aus OMS, Marktdaten-Feed und Postfach.

Die Entscheidungsebene überschreitet nie eine Vertrauensgrenze, die gegen die MiFID-II- oder DORA-Regeln verstößt. Dieselbe Topologie läuft auf allen drei Haltungen.

Keine ausgehenden Aufrufe. Optionaler EU-only-AFM-Endpunkt.

Signierte Pakete werden einmal geschrieben und oft gelesen, EU-only Replikat.

CPU-nativer Motor, keine GPU-Farm, keine Cloud-ML-APIs.

TLS-Terminierung in der EU, mTLS zur Entscheidungsebene.

Drei Betriebsmodelle, eine Beweisarchitektur. Managed Fabric läuft auf dem öffentlichen Mesh. Lizenzierter Betrieb bringt direkte Produkte in Ihre Co-Location. Luftspaltbetrieb schützt die sensibelsten Clearing-Daten. Jedes Modell hält Entscheidungen und Beweise innerhalb seiner erklärten Vertrauensgrenze. Der Eingang terminiert TLS in der EU und spricht mTLS zur Entscheidungsebene, die Entscheidung selbst läuft auf einem CPU-nativen Motor ohne GPU-Farm und ohne Cloud-ML-API im Pfad, signierte Pakete werden einmal geschrieben und oft gelesen auf einem EU-only Replikat, und der Ausgang tätigt keine ausgehenden Anrufe.

Determinismus wird in der Suite behauptet, nicht in Prosa versprochen. Derselbe Orakellauf auf Ihrer Hardware erzeugt dieselbe Antwort wie auf unserer.

Kein Rundungsfehler überschreitet die Einheit-der-letzten-Stelle-Schwelle.

Ecken und Bereiche werden automatisch in CI geübt.

Jedes Ergebnis wird mit einer hochpräzisen Referenz verglichen.

Begrenzte Iterationsanzahl, keine Gleitkommaeinheit.

Jede numerische Berechnung im Preis- und Best-Ex-Pfad wird gegen MPFR mit 256-Bit-Präzision verifiziert. Das veröffentlichte Ergebnis ist 0 ULP, korrekt gerundet über den dokumentierten Eingabebereich, mit eigenschaftsbasierten Tests, die die Ecken bei jeder Veröffentlichung antreiben. Das Tor sitzt in CI, sodass eine numerische Änderung, die den Preispfad bewegt, ein fehlgeschlagener Build ist und nicht eine Entdeckung während einer Überprüfung.

Bei der NCA eingereicht, Beleg protokolliert.

ISO-20022-Nachricht deterministisch kompiliert.

Instrument, Handelsplatz, Händler, Währung anhängen.

Transaktionsberichterstattung ist der kanonische Kapitalmarkt-Workflow, der am meisten durch Float-Drift und Handelsplatz-Datenschiefe beschädigt wird. Dweve führt den Bericht auf Integer-Arithmetik aus, pinnt auf eine bestimmte Handelsplatz- und Instrumentenversion und liefert jedes Mal dieselben Felder. Der Handel wird aus dem FIX-Feed gezogen, mit Instrument, Handelsplatz, Händler und Währung angereichert, deterministisch in die ISO-20022-Nachricht formatiert und an die nationale zuständige Behörde übermittelt, wobei der Beleg protokolliert wird. Jeder dieser vier Schritte wird aufgezeichnet, sodass gezeigt werden kann, dass der Bericht aus dem Handel erstellt wurde und nicht dagegen getippt.

automatisch pro Handel zusammengestellt.

Managed Fabric, lizenziert in Ihrer Co-Location oder luftspaltgetrennt.

OpenAPI-3.1-Spezifikation, typisierte Fehler (RFC 7807), FIX 4.4.

FIX-Quelle, Regel, Händler, Ausführung, Signatur.

Gleiche Eingabe, gleiche Ausgabe, jede Maschine, jede Veröffentlichung.

Jeder Orderbuch-Snapshot läuft auf einer deterministischen Engine. Bitgenaue Wiedergabe über Maschinen und Releases hinweg. Dasselbe Buch am Handelsschreibtisch, in der Cloud und auf einem Laptop. Kein Gleitkomma-Drift, keine chipabhängige Rundung. Jeder Snapshot hinterlässt ein signiertes Paket mit der FIX-Quelle, der Regel, dem Trader, dem Fill und der Signatur, ob es als verwaltetes Fabric, lizenziert in Ihrer Kollokation oder air-gapped läuft.

Sie brauchen keinen Anwalt, um einen Fill anzufechten. Das Paket ist in einfacher Sprache verfasst, und der Handelsplatz, die Regel und der Trader werden auf der Bestätigung genannt.

Beschwerdestelle der niederländischen Aufsichtsbehörde.

Jeder Fill, den Ihr Broker macht, ist anfechtbar. Dieselbe Aufzeichnung, die der Trader signiert hat, ist die Aufzeichnung, die Sie anfechten können. Wenn Sie mit dem Handelsplatz, dem Preis oder dem Slippage nicht einverstanden sind, ist der Beschwerdeweg auf der Bestätigung. Er beginnt mit einer Überprüfung durch den benannten Trader und Desk, dann die AFM-Beschwerdestelle, dann ein Finanzgericht ohne Vorabgebühr, und jeder liest dasselbe signierte Paket.

Clearing eingereicht, CCP-Marge protokolliert.

Gegen das Buch abgeglichen, Fill aufgezeichnet.

Order gemäß Ausführungsregel des Handelsplatzes geroutet.

Ein Trade ist keine Blackbox mehr. Die Schritte Routen, Abgleichen, Clearen und Abwickeln haben jeweils einen benannten Trader, einen Zeitstempel und eine Regel. Die Order wird gemäß der geltenden Ausführungsregel des Handelsplatzes geroutet, gegen das Buch abgeglichen und der Fill aufgezeichnet, zum Clearing eingereicht und die CCP-Marge protokolliert, und zu T+2 abgewickelt und das Register aktualisiert. Jeder Schritt behält den Trader, der ihn signiert hat, und die Zeit, zu der er passiert ist, sodass eine Frage zu Ihrem Fill aus einer Aufzeichnung beantwortet wird.

Der Handelsplatz, der Ihre Order angenommen hat.

Wenn Ihr Broker Dweve verwendet, ist Ihr Fill keine Vermutung einer Maschine. Er ist an einen Handelsplatz, einen Preis und einen benannten Trader gebunden, der den Slippage erklären kann. Wenn Sie fragen, warum, ist die Antwort schriftlich. Sie nennt den Handelsplatz, der Ihre Order angenommen hat, den Preis, den Sie erhalten haben, und den Desk, der signiert hat, und derselbe Fill kommt jedes Mal auf dieselbe Weise zurück, wenn Sie fragen.

Jeder Handel trägt dasselbe Paket vom Desk über die CCP bis zum CSD. Die CSDR-Abwicklungsdisziplinprüfung ist eine Wiederherstellung, keine Rekonstruktion.

Register aktualisiert, Signierung erfasst.

Position gemäß CCP-Regel netto bewertet.

Handel an CCP übermittelt, Marge berechnet.

Clearing und Abwicklung sind die Workflows, die am stärksten unter CCP-Margenverzerrung und Registerverzögerung leiden. Dweve umhüllt den Handelslebenszyklus mit einer deterministischen Entscheidungsebene, sodass jeder Fill, jede Margin-Call und jede Abwicklungsinstruktion dasselbe signierte Paket durch die CCP und den CSD trägt. Der Handel wird an die CCP übermittelt und die Marge wird gegen dieses Paket berechnet, die Position wird gemäß der CCP-Regel netto bewertet, die Abwicklungsinstruktion geht an den CSD, und die Registeraktualisierung und die Signierung landen auf demselben Datensatz. Zwischen Desk und Depotbank wird nichts neu erfasst.