Automatisierter Quotenhandel: Datenfeeds und Befugnisse trennen

Datenfeeds im automatisierten Quotenhandel beschreiben unterschiedliche Tatsachen

Ein Ereignisfeed meldet Informationen über die Bedingung, die prognostiziert wird oder deren Ergebnis festgestellt wird. Ein Marktfeed meldet Preisangebote, Abschlüsse oder andere Marktzustände. Ein Kontofeed meldet Orders, Ausführungen, Positionen und Guthaben. Jeder benötigt eigene Kennungen, Zeitstempel und Gültigkeitsregeln. Werden sie in einem einzigen Feld für die letzte Aktualisierung zusammengeführt, kann das System aktuell erscheinen, während eine wesentliche Eingabe weiterhin veraltet ist.

Bewahren Sie beim Ereignisfeed die Quelle, den Veröffentlichungszeitpunkt, den Beobachtungszeitraum und das relevante Feld auf. Bewahren Sie beim Marktfeed den Kontrakt, die Ergebnisseite, das Kauf- oder Verkaufsangebot, die Menge und den Beobachtungszeitpunkt auf. Bewahren Sie beim Kontofeed die Identitäten von Orders und Ausführungen sowie den Zustand der Verpflichtungen auf. Diese Datensätze können verknüpft werden, aber einer sollte nicht die Bedeutung eines anderen überschreiben.

Eine Schlagzeile kann weitere Recherche rechtfertigen, ohne unmittelbar das Ergebnis eines Kontrakts zu bestimmen. Eine Bewegung im Orderbuch kann verändertes Handelsinteresse zeigen, ohne dessen Ursache zu beweisen. Eine Guthabenänderung kann auf eine Gebühr oder Übertragung statt auf eine neue Ausführung zurückgehen. Das System sollte jede Beobachtung anhand der passenden Zuordnung interpretieren, anstatt jede Aktualisierung als allgemeines positives oder negatives Signal zu behandeln.

Der ältere Leitfaden zur Handels-API für Prognosemärkte hilft, diese Zuständigkeiten der Schnittstellen zu ordnen. Der zentrale Gestaltungsgrundsatz lautet: Ein Feed liefert Belege für eine bestimmte Tatsache. Seine technische Verfügbarkeit verleiht dieser Tatsache nicht mehr Bedeutung oder Autorität, als ihre Quelle rechtfertigt.

Die Kontraktzuordnung verbindet die Feeds, ohne sie zu verschmelzen

Eine geprüfte Zuordnung verbindet Ereignisbelege mit der Kontraktbedingung und den Kontrakt mit seinen Markt- und Ergebniskennungen. Sie umfasst Quelle, Feld, Schwellenwert, Frist, Auszahlung und die Behandlung von Ausnahmefällen. Mithilfe dieser Zuordnung kann das System feststellen, ob eine Quellenaktualisierung für ein bestimmtes Preisangebot relevant ist. Ohne sie kann ein schneller Feed korrekte Informationen zur falschen Frage liefern.

Angenommen, eine fiktive Wirtschaftsquelle veröffentlicht sowohl einen Erstwert als auch einen revidierten Vorperiodenwert. Der Kontrakt verwendet den Erstwert für den aktuellen Monat. Der Parser für Ereignisdaten sollte dieses Feld erkennen und die Veröffentlichungsversion aufbewahren. Ein Markttitel, der denselben Index erwähnt, genügt nicht, um die Zuordnung festzustellen, insbesondere wenn benachbarte Kontrakte einen anderen Schwellenwert oder Monat verwenden.

Kalshis Hinweise zur Regelzusammenfassung verweisen über die Zusammenfassung hinaus auf die vollständigen Regeln. Eine automatisierte Zuordnung sollte auf den Bedingungen beruhen, die zur Auslegung des tatsächlichen Kontrakts notwendig sind. Wenn eine Klarstellung oder Quellenänderung die Zuordnung beeinflusst, sollten Empfehlungen, die sie verwenden, bis zur Prüfung ablaufen oder pausieren.

Der verwandte Artikel über Märkte für Wahrscheinlichkeitshandel untersucht Vergleiche zwischen unterschiedlichen Kontraktumgebungen. Die Automatisierung sollte diese Unterschiede bewahren. Ein gemeinsames Datenschema kann mehrere Handelsplätze ordnen, sollte aber nicht den Eindruck erwecken, ihre Definitionen, Konten oder Befugnisse seien austauschbar.

Belege auf den Entscheidungszeitpunkt abstimmen

Eine Empfehlung sollte angeben, welche Beobachtungen bei ihrer Entstehung verfügbar waren. Angenommen, eine fiktive Veröffentlichung erscheint um 9:00:00 und erreicht den Ereignisdatensammler um 9:00:04. Eine um 9:00:03 beobachtete Orderbuchaufnahme erreicht den Marktdatensammler um 9:00:05. Beide treffen kurz nacheinander ein, doch das Orderbuch kann bereits Informationen widerspiegeln, deren Interpretation die lokale Strategie noch nicht abgeschlossen hat. Das System sollte nicht annehmen, dass die Reihenfolge des Eingangs die ursächliche Reihenfolge belegt.

Bewahren Sie Quellen- und Empfangszeitpunkte auf und wenden Sie anschließend die Aktualitäts- und Abstimmungsregeln der Strategie an. Manche Strategien können ein neues Orderbuch verlangen, nachdem die Ereignisbeobachtung überprüft wurde. Andere können eine Prognose vor einer Bekanntgabe nur bewerten, bevor das Quellenereignis eintritt. Die Regel sollte angeben, welchen Informationsstand sie verwenden will. Ein Kalenderzeitstempel allein kann nicht beweisen, dass die erforderlichen Daten im Entscheidungszeitpunkt verfügbar oder verstanden waren.

Für fehlende Zeitstempel ist eine ausdrückliche Regelung nötig. Das System kann zeitkritische Aktionen zurückhalten, auf eine geprüfte konservative Ersatzlösung zurückgreifen oder die Beobachtung zur Prüfung weiterleiten. Es sollte nicht den lokalen Einfügezeitpunkt einsetzen und die Quelle als aktuell bezeichnen. Dadurch würde sich die Bedeutung der Aktualitätsregel ohne Wissen des Betreibers ändern.

Die Abstimmung ist auch bei historischen Bewertungen wichtig. Ein Datensatz mit dem endgültigen revidierten Quellenwert und einem späteren Orderbuch kann eine frühere Live-Entscheidung nicht nachbilden. Die ältere Erörterung zum automatisierten Handel auf Prognosemärkten liefert Kontext dafür, diese Grenzen zu bewahren. Eine Wiederholung sollte die Informationen verwenden, die das System damals tatsächlich hätte beobachten können.

Eine Empfehlung ist ein Vorschlag mit Ablaufzeit

Sobald Zuordnung und Belege gültig sind, kann eine Strategie eine Aktion vorschlagen. Die Empfehlung sollte den Kontrakt, die Seite, den Kauf oder Verkauf, die gewünschte Menge, die Preisobergrenze, die geschätzten Kosten und die Begründung enthalten. Sie sollte auf die verwendeten Beleg- und Prognoseversionen verweisen. Sie sollte außerdem ablaufen, wenn diese stützenden Beobachtungen nach den Strategieregeln nicht mehr gültig sind.

Eine normalisierte implizite Wahrscheinlichkeit ist nur eine Eingabe. Die Strategie kann sie mit einer unabhängigen Prognose, einer Auszahlungsbeziehung oder einem anderen geprüften Entscheidungskriterium vergleichen. Die Empfehlung sollte erklären, welche Art von Überlegung sie stützt. Ein in einen Prozentsatz umgerechneter Preis wird nicht allein dadurch zu einer objektiven Wahrscheinlichkeit, dass die Umrechnung automatisiert erfolgt.

Der Leitfaden zum Wahrscheinlichkeitshandel vertieft diesen Unterschied zwischen Einschätzung und Preis. Lassen Sie in der Software beide Felder sichtbar und benennen Sie sie. Ein Konfidenzwert eines Klassifikators oder Sprachmodells sollte nicht als kalibrierte Ergebniswahrscheinlichkeit gelten, sofern eine gesonderte Bewertung diese Auslegung nicht belegt. Solange diese Arbeit unvollständig ist, kann die Empfehlung auf die Recherche beschränkt bleiben.

Der Ablauf sollte unmittelbar vor der Aktion durchgesetzt werden. Wenn das Orderbuch der Empfehlung veraltet oder sich ihre Quellenzuordnung vor der Übermittlung ändert, sollte die Ausführungskomponente ablehnen oder eine neue Entscheidung anfordern. Das System sollte die Befugnis nicht allein deshalb erhalten, weil der Kandidat einmal attraktiv war. Eine Empfehlung beschreibt eine vorgeschlagene Aktion unter bestimmten Bedingungen und ist keine Anweisung, das Ereignis später zu jedem beliebigen Preis zu verfolgen.

Kontofreigaben für automatisierten Quotenhandel berücksichtigen aktuelle Verpflichtungen

Die Kontoprüfung kontrolliert, ob die vorgeschlagene Aktion zu Befugnissen, Mitteln und Expositionsgrenzen passt. Sie benötigt einen ausreichend abgeglichenen Überblick über Positionen und Orders, einschließlich Versuchen, deren Ergebnis weiterhin ungewiss ist. Ein funktionierender öffentlicher Marktfeed kann diese Kontobelege nicht ersetzen. Wenn der lokale Datensatz nicht weiß, ob eine frühere Order ausgeführt wurde, kann er nicht sicher die gesamte scheinbar vorhandene Kapazität als frei behandeln.

Angenommen, für eine fiktive Ereignisgruppe gilt eine Verpflichtungsgrenze von 150 $. Bestehende Positionen beanspruchen 40 $, und offene Orders reservieren weitere 20 $. Damit verbleiben innerhalb der Grenze 90 $. Ein vorgeschlagener Kauf von 250 Einheiten zu höchstens 0,48 $ kostet 120 $, bevor ein angenommener Kostenpuffer von 4 $ hinzukommt; insgesamt sind es 124 $. Er überschreitet die verfügbare Gruppenkapazität, selbst wenn das Kontoguthaben größer ist.

Ein überarbeiteter Vorschlag über 150 Einheiten zum selben Höchstpreis kostet 72 $. Mit einem hypothetischen Kostenpuffer von 3 $ für diese gesonderte Größe beträgt die Verpflichtung 75 $. Zusammen ergeben sich für die Gruppe 40 $ plus 20 $ plus 75 $, also 135 $, innerhalb der Grenze von 150 $. Diese erfundenen Kosten veranschaulichen eine größenabhängige Freigabe; reale Gebührenordnungen müssen für die tatsächliche Aktion bewertet werden, anstatt proportionale Kosten anzunehmen.

Die Freigabe sollte die genehmigte Höchstmenge und die maximalen Kosten nennen und nicht lediglich den Markt genehmigen. Benötigt die Ausführungskomponente später einen höheren Preis oder zusätzliche Einheiten, braucht sie eine neue begrenzte Entscheidung. Der ältere Leitfaden zur Automatisierung des Handels auf Prognosemärkten liefert Kontext dafür, diese Trennung zwischen Strategieinteresse und Kontobefugnis zu bewahren.

Während einer Handelspause bleibt lesende Arbeit nützlich

Eine Pause der Handelsbefugnis erfordert nicht immer, die Sammlung von Recherchedaten einzustellen. Wenn der Kontoabgleich unvollständig ist, können öffentliche Ereignis- und Marktfeeds innerhalb ihres eigenen Zuständigkeitsbereichs häufig weiterarbeiten. Das System kann Prognosen aktualisieren, Kandidatenpreise aufzeichnen und Prüfmaterial vorbereiten, während es neue Verpflichtungen verhindert. So kann der Betreiber verstehen, was sich während der Unterbrechung verändert hat, ohne das Konto einem ungewissen Zustand auszusetzen.

Machen Sie den Unterschied sichtbar. Ein Dashboard sollte angeben, dass die Belegsammlung aktiv ist, während die Handelsfreigabe deaktiviert ist, und den Grund nennen. Andernfalls kann ein sich bewegender Chart den Eindruck erwecken, der Bot sei vollständig betriebsbereit, oder eine rote Kontoanzeige kann den Nutzer vermuten lassen, jede Recherche sei angehalten. Fähigkeitszustände sollten den Tatsachen entsprechen, die sie beschreiben.

Verwenden Sie getrennte Zugänge, soweit die unterstützten Schnittstellen dies erlauben. Ein öffentlicher Datensammler sollte nicht allein deshalb Handelszugangsdaten erben, weil er dieselbe Bereitstellungsinfrastruktur wie eine Ausführungskomponente nutzt. Eine private Überwachung kann Leseberechtigung für das Konto benötigen, ohne Orders übermitteln zu dürfen. Das Berechtigungsmodell der tatsächlichen Plattform bestimmt die Umsetzung, doch die beabsichtigte Trennung sollte im Entwurf ausdrücklich erhalten bleiben.

Diese Trennung vereinfacht auch die Untersuchung von Vorfällen. Der Betreiber kann fragen, ob die Ereignisbelege, die Marktbeobachtung oder die Kontofreigabe versagt haben. Ein einziger globaler Zustand wie „nicht verbunden“ verbirgt diese Information. Eine gezielte Pause lässt das System nützliche Arbeit fortsetzen und bewahrt gleichzeitig die Grenze, die verhindert, dass fehlende Belege zu einem nicht autorisierten Handel führen.

Die Übermittlung benötigt eine dauerhafte Identität und eine abschließende Prüfung

Bewahren Sie vor dem Senden einer autorisierten Anweisung deren Identität und maximale Verpflichtung in einem dauerhaften Datensatz auf. Bestätigen Sie, dass die relevante Freigabe nicht abgelaufen ist und die Ausführungskomponente weiterhin die genehmigte Kontraktzuordnung verwendet. Der genaue Konsistenzmechanismus hängt vom System ab. Ziel ist jedoch, einen Zustand zu vermeiden, in dem eine externe Order existieren kann, während der neu gestartete lokale Prozess keine Aufzeichnung darüber hat, sie versucht zu haben.

Zeichnen Sie die Antwort des Handelsplatzes auf, ohne anzunehmen, sie bedeute die Ausführung der gesamten Menge. Eine angenommene Anfrage kann eine ruhende Order, eine Teilausführung oder einen anderen handelsplatzspezifischen Zustand erzeugen. Der Adapter sollte diese Zustände sorgfältig zuordnen und die ursprüngliche Antwort zur Diagnose aufbewahren. Ein einzelnes Erfolgskennzeichen reicht nicht aus, um die Exposition des Kontos zu beschreiben.

Polymarkets Dokumentation zum Orderlebenszyklus unterscheidet mehrere Order- und Handelsstufen. Eine Umsetzung sollte dem aktuellen Verhalten des tatsächlichen Produkts folgen, einschließlich etwaiger Zwischenzustände. Leiten Sie nicht ab, dass eine Antwort eines Handelsplatzes dieselbe Bedeutung hat wie eine ähnlich benannte Antwort eines anderen.

Die abschließende Prüfung sollte die Strategie nicht stillschweigend umgestalten. Wenn sich Bedingungen so stark verändert haben, dass die beabsichtigte Order nicht mehr in die Freigabe passt, lehnen Sie sie ab. Eine Grenze anzuheben, um die gewünschte Menge zu erhalten, oder die gewählte Seite zu ändern, ist eine neue Entscheidung. Die Aufgabe der Ausführungskomponente ist, begrenzte Befugnisse umzusetzen und über das Geschehen zu berichten, und nicht, eine neue wirtschaftliche Begründung zu improvisieren, wenn die Ausführung unbequem wird.

Die Wiederherstellung beim automatisierten Quotenhandel bewahrt Ungewissheit

Wenn eine Übermittlungsantwort fehlt, behalten Sie den ursprünglichen Versuch und die Reservierung bei. Prüfen Sie die unterstützten Order-, Ausführungs- und Positionsaufzeichnungen, bevor Sie eine weitere unabhängige Anfrage erwägen. Die Zeitüberschreitung belegt ein Kommunikationsproblem und keine bestätigte Ablehnung. Eine neue Anfrage kann doppelte Exposition schaffen, wenn die erste angenommen wurde, lokal aber noch nicht sichtbar ist.

Wird nur ein Teil einer Order ausgeführt, aktualisieren Sie die bestätigte Menge und behalten den offenen Rest bei, bis dessen Ergebnis feststeht. Eine Stornierungsanfrage sollte auf verspätete Ausführungen überwacht werden. Wird die Kontoansicht widersprüchlich, pausieren Sie die betroffenen Aktionen, die Exposition erhöhen, während der Abgleich fortgesetzt wird. Das System sollte erklären, welche Menge bestätigt ist und welche weiterhin möglich bleibt.

Ein Neustart sollte damit beginnen, ungeklärte Verpflichtungen zu laden. Neue Feednachrichten können eintreffen, bevor das Konto abgeglichen ist, sollten die Handelsbefugnis aber nicht automatisch wiederherstellen. Die Strategie kann Beobachtungen verarbeiten, während die Risikoprüfung auf die benötigten Belege wartet. So wird verhindert, dass das Wiederverbindungsverhalten zu einer verborgenen Umgehung der Freigabe wird.

Die Wiederherstellungsregelung sollte angeben, wann eine menschliche Prüfung erforderlich ist und welche Informationen die prüfende Person erhält. Stellen Sie Kontrakt, Seite, bekannte Menge, ungeklärte Versuche, aktuelle Grenzen und Alternativen bereit, die innerhalb der Befugnis bleiben. Eine allgemeine Fehlermeldung genügt nicht, wenn die nächste Aktion eine finanzielle Position hinzufügen oder entfernen könnte.

Abläufe mit mehreren Teilgeschäften benötigen eine gemeinsame Freigabe

Eine Strategie mit mehreren Kontrakten benötigt eine Freigabe für die Kombination und einen Überblick über den Zustand jedes Teilgeschäfts. Die vorgeschlagene Auszahlungsbeziehung sollte getrennt von den aktuellen Ausführungsbedingungen geprüft werden. Reservieren Sie vor der Übermittlung die erforderlichen lokalen Mittel und die gesamte Ereignisexposition. Ein geplanter Ausgleich wird erst dann zu einem tatsächlich gehaltenen Ausgleich, wenn die erforderlichen Mengen ausgeführt sind.

Arbitragesoftware für Prognosemärkte untersucht die Prüfung aufeinander abgestimmter Kontrakte und Vorfälle mit zwei Teilgeschäften. In einer Architektur mit mehreren Feeds kommt hinzu, dass das Orderbuch oder die Kontoschnittstelle eines Handelsplatzes ausfallen kann, während ein anderer aktiv bleibt. Das System benötigt eine gemeinsame Fallregelung, damit das weiterhin verbundene Teilgeschäft nicht weiterläuft, als sei die ursprüngliche Kombination weiterhin durchführbar.

Der Falldatensatz sollte gepaarte und ungepaarte Mengen, verbleibende offene Orders und die maximal zulässigen Wiederherstellungskosten zeigen. Wird ein ergänzendes Teilgeschäft zu teuer, ist sein Abschluss zu jedem beliebigen Preis nicht automatisch autorisiert. Vergleichen Sie begrenzte Alternativen anhand aktuell ausführbarer Preisangebote und weiterer Informationen und der tatsächlichen Restexposition des Kontos.

Bewahren Sie auch den Abrechnungszeitpunkt und den Aufbewahrungsort der Mittel auf. Selbst eine abgeschlossene Kombination kann Erlöse auf unterschiedlichen Konten oder zu unterschiedlichen Zeiten freigeben. Ein einziges zusammengefasstes Guthaben kann lokale Finanzierungsgrenzen für die nächste Aktion verbergen. Die Kontoprüfung sollte die dort nutzbare Kapazität verwenden, wo die Aktion stattfinden wird, und nicht Geld, das nach einer künftigen Ergebnisfeststellung anderswo erwartet wird.

Ausfälle in den drei Eingabepfaden testen

Ein aussagekräftiger Testsatz sollte Ereignisfeed, Marktorderbuch und Kontoansicht unabhängig voneinander veralten lassen. Prüfen Sie, dass jeder Zustand nur die davon abhängigen Aktionen beeinflusst und dabei unsichere Kombinationen verhindert. Beispielsweise sollte eine frische Ereignisbeobachtung mit einem veralteten Orderbuch Rechercheaktualisierungen erlauben, aber keine preisabhängige Order. Ein aktuelles Orderbuch mit einem nicht abgeglichenen Konto sollte keine Expositionskapazität wiederherstellen.

Testen Sie Ereignisse in vertauschter Reihenfolge und Wiederverbindungen. Liefern Sie eine verspätete alte Quellenbeobachtung nach einer neueren und bestätigen Sie, dass sie die aktuellen Belege nicht ersetzt. Liefern Sie eine Kontoausführung, nachdem die Stornierung angefordert wurde, und bestätigen Sie, dass sich die Position ändert. Starten Sie nach der Übermittlung, aber vor der Aufzeichnung der Antwort neu und bestätigen Sie, dass der ungeklärte Versuch untersucht wird, bevor eine neue Order entstehen kann.

Auch die Freigaberechnung sollte unabhängig getestet werden. Im fiktiven Gruppenbeispiel mit 150 $ lassen 40 $ in gehaltenen Positionen plus 20 $ an Reservierungen noch 90 $ übrig. Der Vorschlag über 124 $ muss scheitern, während der gesonderte Vorschlag über 75 $ diese bestimmte Grenze einhalten kann, sofern alle anderen Bedingungen erfüllt sind. Das Bestehen der Guthabenberechnung allein sollte veraltete Belege oder eine ungültige Kontraktzuordnung nicht umgehen.

Ein nützlicher Test enthält auch Untätigkeit als erwartetes Ergebnis. Automatisierung wird nicht allein dadurch besser, dass sie mehr Orders erzeugt. Sie wird besser, wenn sie den beabsichtigten Entscheidungsprozess konsequent ausführt, einschließlich der Ablehnung, wenn die erforderlichen Tatsachen oder Befugnisse fehlen.

Mehrere Strategien über eine gemeinsame Kapazitätsansicht koordinieren

Zwei Strategien können jeweils gültige Belege sehen und trotzdem um dieselbe Kontokapazität konkurrieren. Wenn beide 90 $ als verfügbar lesen und unabhängig voneinander 75 $ freigeben, übersteigen ihre gemeinsamen Verpflichtungen diesen Betrag. Der Freigabeprozess benötigt einen konsistenten gemeinsamen Reservierungsmechanismus, damit eine Entscheidung die Kapazität berücksichtigt, die bereits der anderen zugewiesen wurde. Getrennte Rechercheprozesse schaffen keine getrennten Guthaben.

Die gemeinsame Ansicht sollte ungeklärte Versuche ebenso wie bestätigte Positionen umfassen. Eine Strategie, die auf eine Orderantwort wartet, besitzt weiterhin eine Reservierung, die andere Strategien berücksichtigen müssen. Wird der Versuch später abgelehnt, kann die Kapazität mit entsprechenden Belegen freigegeben werden. Wird er ausgeführt, wird die Reservierung zu tatsächlichen Positionskosten und gegebenenfalls verbleibenden offenen Verpflichtungen.

Diese Koordination kann nach Konto und Ereignisgruppe abgegrenzt werden. Das System sollte erklären, welche Beschränkung eine Empfehlung abgelehnt hat und welche bestehenden Verpflichtungen die Kapazität beanspruchen. Diese Transparenz hilft dem Betreiber, ein nützliches Recherchesignal von einer Aktion zu unterscheiden, die das Portfolio derzeit nicht tragen kann. Sie verhindert außerdem, dass eine neue Strategie versehentlich Grenzen umgeht, die für das Konto insgesamt festgelegt wurden.

Die Kette von den Belegen bis zum endgültigen Kontozustand prüfen

Rekonstruieren Sie nach einem Ereignis die verwendeten Beobachtungen, die erzeugte Empfehlung, die erteilte Freigabe und die tatsächlichen Ausführungen und Kosten. Vergleichen Sie geplante Menge und Kosten mit dem Kontoergebnis. Überprüfen Sie bei der Ergebnisfeststellung den endgültigen Bestand und die Auszahlung nach den Kontraktbedingungen. Halten Sie Prognosebewertung und betriebliche Korrektheit getrennt, damit ein glücklicher Ausgang keine fehlerhafte Kontrolle bestätigt.

Zeichnen Sie Änderungen an Feedschemata, Kontraktzuordnungen und Freigaberegeln mit ihren Wirksamkeitszeitpunkten auf. Eine spätere Korrektur sollte den historischen Informationsstand nicht umschreiben. Die prüfende Person muss wissen, ob das System anhand verfügbarer Belege eine vernünftige Entscheidung getroffen oder auf Daten gehandelt hat, die es hätte ablehnen müssen. Versionierte Aufzeichnungen machen diese Unterscheidung möglich.

Der Zweck des automatisierten Quotenhandels ist, zuverlässige Beobachtungen mit begrenzten Aktionen und überprüfbaren Ergebnissen zu verbinden. Ereignisbelege, Marktpreisangebote und Kontobefugnisse tragen jeweils etwas anderes bei. Ihre Trennung zu bewahren ermöglicht dem System, bei Ungewissheit nützliche Arbeit fortzusetzen, und verhindert, dass ein einzelner funktionierender Feed vortäuscht, sämtliche Handelsbedingungen seien erfüllt.