Virtual Dealer
Plugin
Risikokontrollen gehören zum Online-Trading. Dieses Dossier erklärt ihren legitimen Zweck, die Grenze zur unfairen Ausführung und die dokumentierte Wirkweise des historischen Virtual Dealer Plugins.
Der Ausgangspunkt: Ein Finanzdienstleister muss die Risiken seines Geschäfts und seiner technischen Systeme beherrschen. Eine serverseitige Kontrolle ist deshalb für sich genommen kein Manipulationsbeleg. Kritisch wird ihre konkrete Anwendung: Eine Regel zur Begrenzung von Risiken darf nicht allein unter diesem Etikett eine einseitige Benachteiligung von Kunden rechtfertigen. Öffentliche Aufsichtsunterlagen zu asymmetrischer Ausführung zeigen, weshalb Zweck, Parametrisierung und tatsächliche Wirkung getrennt zu prüfen sind. [7][5][6]
Risikomanagement ist notwendig. Seine Wirkung muss überprüfbar bleiben.
Online-Handel verbindet Kundenaufträge, Kursdaten, Kontoführung, Ausführung und gegebenenfalls das Hedging des Brokers. Fehler in einem dieser Schritte können Risiken für Kunden, Anbieter und weitere Marktteilnehmer erzeugen. Bei gehebelten Positionen können schon kleine Kursänderungen im Verhältnis zur hinterlegten Margin erhebliche Auswirkungen haben. Daraus ergeben sich gute Gründe für technische Kontrollen; daraus folgt jedoch keine allgemeine Befugnis, Ausführungsergebnisse nachträglich oder verdeckt zugunsten des Anbieters zu verändern.
Für EU-Wertpapierfirmen verlangt Art. 23 der Delegierten Verordnung (EU) 2017/565 angemessene Verfahren zur Identifikation und Steuerung von Risiken ihrer Tätigkeiten, Prozesse und Systeme. Spezifische Anforderungen an Systeme und Handelslimits enthält Art. 17 MiFID II für algorithmischen Handel und direkten elektronischen Zugang zu Handelsplätzen. Diese besonderen Regeln gelten innerhalb ihres jeweiligen Anwendungsbereichs; sie sind keine pauschale Rechtsgrundlage für jede OTC-Retail-Order oder jede Brokererweiterung. [7][8]
| Risiko | Mögliche technische Kontrolle | Entscheidende Prüffrage |
|---|---|---|
| Fehlerhafte oder doppelte Aufträge | Plausibilitätsprüfung von Preis, Größe und Wiederholungen; Mengen- und Anfragelimits. | Wird ein definierter Fehler abgefangen und der Grund nachvollziehbar dokumentiert? |
| Veraltete Kursdaten oder Systemstörung | Feedüberwachung, Zeitstempelprüfung, Unterbrechung einer gestörten Quotierung. | Ist der Bezugskurs belastbar und werden vergleichbare Situationen konsistent behandelt? |
| Margin-, Kredit- oder Konzentrationsrisiko | Deckungsprüfung, Positionslimits, Exposureüberwachung und vertraglich vorgesehene Schließungsregeln. | Entsprechen die Regeln dem Produkt, Vertrag und anwendbaren Kundenschutz? |
| Liquiditäts- und Hedgingrisiko | Überwachung verfügbarer Liquidität, Aggregation von Risiken, Hedge- und Gegenparteigrenzen. | Bleiben Kundenauftrag und eigenständige Absicherung des Brokers sachlich getrennt? |
| Nachteilige Selektion oder Latenzeffekte | Analyse von Kursalter, Ausführung und anschließender Preisbewegung; Anpassung einer zulässigen Quotierungs- oder Risikopolitik. | Ist die Maßnahme begründet, verhältnismäßig und mit Ausführungspflichten vereinbar? |
Illustrative Risikokategorien und Kontrollen, keine Feststellung über die Installation eines bestimmten Systems. Brokerplattformen können diese Funktionen integriert oder durch zusätzliche Module abbilden; eine repräsentative Erhebung aller Brokersysteme liegt dieser Analyse nicht zugrunde.
Was „toxischer Orderflow“ bedeutet — und was nicht.
Der Ausdruck beschreibt aus Sicht eines Dealers oder Liquiditätsanbieters einen Orderfluss, bei dem Ausführungen systematisch mit für ihn nachteiligen Preisbewegungen oder Absicherungskosten verbunden sein können. Ein Beispiel sind Latenzstrategien, die einen noch angezeigten, bereits veralteten Kurs handeln, während ein schnellerer Referenzmarkt schon weitergelaufen ist. Die BIS beschreibt für den institutionellen FX-Markt Unterschiede in Geschwindigkeit, Handelsprotokollen und Mechanismen wie „Last Look“. Das ist ein Marktstrukturkontext, kein Nachweis einer bestimmten Retail-Brokerkonfiguration. [9]
„Toxisch“ ist keine einheitliche rechtliche Einstufung und kein Synonym für Betrug, Marktmissbrauch oder einen unzulässigen Auftrag. Auch ein profitabler Kunde, ein Expert Advisor oder eine hohe Handelsfrequenz sind für sich genommen kein Fehlverhaltensbeleg. Eine auffällige Statistik muss gegen Kursqualität, Zeitstempel, Liquidität, Strategie und andere Erklärungen geprüft werden. Ob eine konkrete Beschränkung oder Ablehnung zulässig ist, hängt von den Umständen und den anwendbaren Regeln ab.
Die Grenze verläuft zwischen Risikokontrolle und unfairer Wirkung.
Eine Kontrolle ist nach ihrem tatsächlichen Zweck und Ergebnis zu beurteilen, nicht allein nach ihrem Namen. Problematisch können Regeln sein, die wirtschaftlich vergleichbare günstige und ungünstige Kursbewegungen einseitig behandeln, Einschränkungen verschleiern oder dem Kunden ein irreführendes Bild der Ausführung vermitteln. Die NFA behandelt für betroffene Forex Dealer Members ausdrücklich Preis- und Volumengrenzen sowie Requotes und deren Offenlegung. Die CFTC veröffentlichte einen konkreten Fall asymmetrischer MT4-Ausführungsparameter. Diese US-Unterlagen belegen die jeweils beschriebenen Sachverhalte; sie machen nicht jede Verzögerung oder jeden Requote unzulässig. [6][5]
Ein automatisierter Dealer auf der Brokerseite.
Die bereitgestellte PDF trägt den Titel „VirtualDealer versus Manual Execution: What Is Better?“, das Artikeldatum 14. März 2006 und einen Copyrightvermerk mit der Bezeichnung MetaQuotes Software Corp. Dieser Vermerk allein bestätigt weder die Urheberschaft noch die Authentizität der vorliegenden Kopie. Sie beschreibt ein kostenpflichtiges Server-Plugin zur vollständigen oder teilweisen Nachbildung manueller Dealeraktionen für ausgewählte Symbolgruppen. Installation, Managerkonto, Gruppensteuerung und Serverprotokolle verorten es in der MT4-Brokerinfrastruktur. [1, S. 1–2, 8–10]
Die Nutzeroberfläche zeigt die Handelsanfrage und deren Ergebnis. Die Regeln dazwischen werden auf dem Server gesetzt. Für die Untersuchung ist daher entscheidend, Softwarefunktion, konkrete Brokerkonfiguration und tatsächliches Ausführungsergebnis getrennt zu betrachten.
Beschriebener Zweck
Dealerarbeit automatisieren, Anfragen zeitversetzt bestätigen, Kursabweichungen prüfen sowie Pending Orders, Stops und Stop-outs verarbeiten.
Darstellung der Dokumentation; keine unabhängige Qualitätsbewertung.Verbraucherschutzfrage
Werden vergleichbare Kursbewegungen und Ordergrößen in beide Richtungen gleich behandelt? Sind Einschränkungen offengelegt und nachprüfbar?
Redaktioneller Prüfmaßstab.Die entscheidende Frage ist, welche Order angenommen wird.
Für die dokumentierte Instant-Execution-Logik wird eine Anfrage zu einem bestimmten Preis eingereicht. Nach der eingestellten Wartezeit bewertet das Plugin die Kursbewegung. Innerhalb der jeweiligen Toleranz kann es den ursprünglichen Anfragepreis bestätigen; außerhalb erfolgt ein Requote. Ein Requote ist ein neues Preisangebot, keine bereits ausgeführte Transaktion. [1, S. 2–4]
Das ist eine wichtige begriffliche Unterscheidung: „Slippage“ bezeichnet hier auch die Marktbewegung zwischen Anfrage und Verarbeitung. Wird zum ursprünglichen Preis bestätigt, können Anfrage- und Ausführungspreis identisch sein — obwohl die Annahmeregel einen wirtschaftlichen Nachteil gegenüber dem inzwischen aktuellen Kurs erzeugt. Eine Analyse nur ausgeführter Trades kann die abgelehnten günstigen Anfragen vollständig übersehen.
Ungünstige Bewegung
Eine Kaufanfrage zu 1,1000 liegt vor. Der aktuelle vergleichbare Ask fällt auf 1,0995. Eine Bestätigung zu 1,1000 wäre nun fünf Pips teurer als der aktuelle Ask. Eine weite „Max Losing Slippage“-Toleranz kann die ursprüngliche Anfrage weiterhin zulassen.
Günstige Bewegung
Der Ask steigt stattdessen auf 1,1005. Die ursprüngliche Kaufanfrage zu 1,1000 wäre nun fünf Pips günstiger als der aktuelle Ask. Eine enge „Max Profit Slippage“-Toleranz kann diese Anfrage in einen Requote zum höheren Preis überführen.
Didaktisches Beispiel mit vier Dezimalstellen und 0,0001 pro Pip. Verglichen wird derselbe Kursbezug, ohne Spread, Gebühren oder Liquiditätseffekte. Für Verkaufsanfragen kehrt sich die Richtung um. Die wirtschaftliche Differenz ist keine vollständige Gewinn-/Verlustrechnung.
Auch gleich große Preistoleranzen können ungleich wirken.
„Max Profit Slippage Volume“ begrenzt zusätzlich das Volumen, für das günstige Bewegungen noch akzeptiert werden. Ein Vergleich nur der beiden Pip-Grenzen reicht deshalb nicht aus. Ebenso relevant sind Gruppen, Instrumente, Volumen, Ausführungsmodus und gegebenenfalls verfügbare menschliche Dealer. [1, S. 2–4, 8]
Alle beschriebenen Parameter — mit ihren Folgen.
Die Matrix erfasst sämtliche benannten Einstellungsfelder der vorliegenden Fassung; wiederholte „News Time“-Felder werden als eine Parameterfamilie geführt. Sie beschreibt die Dokumentation, keinen Test der ausführbaren Software.
| Parameter | Dokumentierte Funktion | Was für Nutzer relevant ist |
|---|---|---|
| Delay | 0 deaktiviert das Plugin; 1–5 Sekunden aktiviert die Verarbeitung mit Wartezeit. Tatsächliche Verzögerung kann bis zu eine Sekunde kürzer sein. | Zusätzliche Zeit für Kursänderungen. Eine beobachtete Verzögerung allein identifiziert das Plugin nicht. |
| Virtual Manager Account | Managerkontonummer, unter der der virtuelle Dealer handelt. | Zuordnung in Serverlogs möglich; für Kunden normalerweise kein Einblick. |
| Groups | Kontogruppen einschließlich Muster- und Ausschlusslisten. | Unterschiedliche Behandlung von Gruppen möglich. Kein Beleg für eine gezielte Auswahl profitabler Einzelkunden. |
| Symbols | Einbeziehung oder Ausschluss von Instrumenten über Listen und Muster. | Ausführungsregeln können je Instrument variieren. |
| Max Volume | Bei verfügbarem, berechtigtem Dealer werden größere Anfragen diesem überlassen. | Kein harter Schutz: Fehlt ein geeigneter Dealer, verarbeitet das Plugin laut Warnung auch größere Anfragen. |
| Max Losing Slippage | Toleranz für eine inzwischen kundenungünstige Marktbewegung; Instant Execution. 0 führt bei entsprechender Kursänderung zum Requote. | Eine weite Grenze kann eine Anfrage zum nun ungünstigeren ursprünglichen Preis akzeptieren. Grenzwertdetails sind im Dokument nicht durchgehend eindeutig. |
| Max Profit Slippage | Toleranz für eine inzwischen kundengünstige Marktbewegung; Instant Execution. 0 führt bei entsprechender Kursänderung zum Requote. | Eine enge Grenze kann die günstig gewordene ursprüngliche Anfrage verhindern. Ein Beispiel nennt hier widersprüchlich den „Losing“-Parameter. |
| Max Profit Slippage Volume | Oberhalb des Volumens erfolgt bei kundengünstiger Kursbewegung stets ein Requote. | Asymmetrie durch Größe, selbst bei nominell gleichen Pip-Toleranzen. |
| Gap Level (spreads) | Gap-Modus bei Tick-Abstand ≥ eingestellter Faktor × Spread; 0 deaktiviert die Gap-Kontrolle. | Schwelle hängt vom Spread ab; nicht allein vom absoluten Kurssprung. |
| Gap Safe Level (spreads) | Innerhalb eines spreadabhängigen Sicherheitsabstands wird ein Pending/Stop zum Kundenpreis verarbeitet, sonst zum Gap-Preis. | Kann Preisabweichungen begrenzen. Text und Beispiel sind bei Gleichheit nicht konsistent. |
| Gap Tick Counter | Verarbeitung erst nach der erforderlichen Zahl ruhigerer Bestätigungsticks; erneuter Gap setzt die Zählung zurück. | Zwischenticks werden ignoriert. Die Wartezeit ist tickabhängig, nicht als feste Sekundenanzahl beschrieben. |
| Gap Pendings Cancel | Wenn Aktivierung und Take Profit im Gap liegen: stornieren oder am Gap-Preis aktivieren und Take Profit entfernen. | Eine geplante Transaktion kann entfallen oder ohne den vorgesehenen Take Profit entstehen. |
| Gap Take Profit Slide | Nach Parametername und erläuterndem Fließtext: Take-Profit-Ausführung am Gap-Preis erlauben. Die Tabelle ordnet dem Namen allerdings Stop Loss zu. | Günstigere Schließung wird im Fließtext beschrieben; Zuordnung im tatsächlichen Programm nicht verifiziert. |
| Gap Stop Loss Slide | Nach Parametername und Fließtext: Stop-Loss-Ausführung am Gap-Preis erlauben. Die Tabelle ordnet dem Namen allerdings Take Profit zu. | Schlechtere Schließung wird im Fließtext beschrieben; Zuordnung im tatsächlichen Programm nicht verifiziert. |
| News Stops & Freezes | Erhöht während vorgegebener Nachrichtenfenster Limit-/Stop- und Freeze-Abstände um einen Faktor; 0 bedeutet keine Erhöhung. | Platzierung und Änderung nahe am Kurs können eingeschränkt werden. |
| Allow Pendings on News | Erlaubt oder untersagt Pending-Operationen im Nachrichtenfenster. | Einleitung nennt Platzierung, Änderung und Löschung; Parametertabelle nur Platzierung/Änderung. Löschverhalten bleibt offen. |
| News Time 1 … N | Liste mit Datum, Uhrzeit und Dauer in Minuten. | Geplante statt im Dokument beschriebene automatische Nachrichtenerkennung. Zeitbasis/Zeitzone nicht eindeutig angegeben. |
Betrieb, Voraussetzungen und Protokollierung
Die dokumentierte Installation erfolgt auf dem Server; Austausch der DLL erfordert einen Serverneustart. Nach Neustart soll das Plugin zunächst deaktiviert sein. Änderungen der Einstellungen wirken laut Dokument sofort. Die betroffenen Symbole müssen auf manuelle Verarbeitung und eine bestimmte schnelle Bestätigungsoption eingestellt sein; andernfalls warnt der Text vor verlorenen Anfragen nach Requotes. Aktionen sollen über „VirtualDealer“ oder die Managerkontonummer im Serverlog auffindbar sein. [1, S. 1, 8–10]
Eine Kursbewegung. Zwei Annahmeregeln.
Vergleichen Sie symmetrische Toleranzen mit ungleichen Preis- oder Volumengrenzen. Das Beispiel zeigt die wirtschaftliche Differenz einer Bestätigung zum Anfragepreis gegenüber dem inzwischen aktuellen gleichseitigen Kurs.
Vereinfachtes Lehrmodell aus der Dokumentbeschreibung, keine Emulation der DLL und kein Broker-Test. Pip = 0,0001. Es modelliert nur Instant Execution nach einer angenommenen Wartezeit; Gaps, Dealerübergabe, Stops, Spread und Fees sind ausgeschlossen. An exakten Pip-Grenzen wird wegen der Widersprüche im Dokument keine Annahmeentscheidung behauptet.
Gap-Regeln verändern auch Stops und Pending Orders.
Das Dokument sieht eine eigene Gap-Verarbeitung vor. Nach einem ausreichend großen Tick-Sprung können Aktivierungen bis zu einer Reihe von Bestätigungsticks zurückgestellt werden. Ein weiterer Gap startet die Zählung erneut. Entscheidend ist dann der Verarbeitungskurs nach der Bestätigung, nicht zwingend der erste Kurs nach dem Sprung. [1, S. 4–8]
Stop Orders und Limit Orders werden unterschiedlich behandelt.
Die Quelle beschreibt Buy Stop und Sell Stop am Gap-Preis, Buy Limit und Sell Limit dagegen am angefragten Kundenpreis und bezeichnet dieses Schema ausdrücklich als kundenungünstig. Die Safe-Level-Regel kann die Preiswahl zusätzlich beeinflussen. Damit dürfen Preisverbesserungen für Limits nicht einfach unterstellt werden. Das Dokument erläutert das Zusammenwirken aller Einstellungen nicht vollständig.
Ein Stop Loss kann jenseits seines Levels ausgeführt werden.
Das dokumentierte Stop-Loss-Slide-Verhalten erlaubt einen schlechteren Schließungskurs; das Take-Profit-Slide-Verhalten einen besseren. Ein Gap kann auch ohne missbräuchliches Plugin dazu führen, dass ein Preis nicht handelbar ist. Die prüfbare Frage lautet, ob Regeln und tatsächliche Kursverfügbarkeit übereinstimmen und ob vergleichbare Situationen ausgewogen behandelt werden. Die vertauschten Tabellenbeschreibungen bleiben zu beachten.
Eine Order kann ohne ihren vorgesehenen Take Profit aktiviert werden.
Erfasst ein Gap sowohl das Aktivierungslevel als auch den Take Profit, beschreibt die Quelle zwei Optionen: Stornierung oder Aktivierung zum Gap-Preis mit entferntem Take Profit. Das verändert den ursprünglichen Handelsplan erheblich. Protokoll und Orderhistorie wären für die Rekonstruktion entscheidend.
Nachrichtenfenster können Handlungsspielräume reduzieren.
Die vorgegebenen Zeitfenster können Abstände vergrößern und Pending-Operationen einschränken. Als sachlicher Zweck kommen Risikokontrolle und der Umgang mit raschen Kursbewegungen in Betracht; das ist eine redaktionelle Einordnung, keine bestätigte Herstellerbegründung. Kritisch sind Offenlegung, Verhältnismäßigkeit, Gleichbehandlung und tatsächliche Auswirkung.
Beschriebene Kommentarmerkmale sind [started/gap], [cancelled/gap], [sl/gap] und [tp/gap]. Sie können die Rekonstruktion unterstützen. Ihr Auftreten identifiziert ohne weitere technische Belege weder eine bestimmte DLL noch eine missbräuchliche Konfiguration. [1, S. 5–8]
Historische Entscheidungen benennen das Plugin ausdrücklich.
Die Existenz eines möglichen Nachteils und sein nachgewiesener Einsatz sind unterschiedliche Beweisfragen. Die folgenden Quellen betreffen konkrete historische Unternehmen, Zeiträume und Verfahren. Sie sind keine Feststellung über heutige Broker oder sämtliche MetaTrader-Nutzer.
GAIN Capital · 2010
Die NFA-Entscheidung im Verfahren 10-BCC-015 verlangt Erstattungen negativer Slippage für betroffene Trades von Mai bis Juli 2009, die dem auf Retail- und institutionellen Servern eingesetzten Virtual Dealer Plug-in zugerechnet wurden. Sie sieht eine Gesamtsanktion von 459.000 US-Dollar sowie künftig symmetrische Slippage-Regeln vor. Die Summe betrifft das Verfahren insgesamt, nicht ausschließlich das Plugin. Die Entscheidung akzeptiert ein Vergleichsangebot; die Beschwerde und ihre Vorwürfe sind davon getrennt zu lesen. [2][3]
IKON Global Markets · 2010
Die Entscheidung vom 27. Oktober 2010 beschreibt einen Vergleich ohne Anerkennung oder Bestreiten der Beschwerdevorwürfe. Er sieht Erstattungen für dem Virtual Dealer Plug-in zugerechnete negative Slippage, eine Sanktion von 320.000 US-Dollar und künftig symmetrische Regeln vor. Auch hier ist ein historischer konkreter Einsatz benannt. [4]
FXDirectDealer · 2013
Die CFTC stellte für Dezember 2009 bis Juni 2011 asymmetrische Ausführungsparameter auf MT4 fest: Kundenungünstige Bewegungen wurden anders behandelt als kundengünstige. Sie ordnete 1.828.261 US-Dollar Erstattung und 914.131 US-Dollar Geldbuße an. Betroffen waren 24.904 Konten. Der Vergleich erfolgte ohne Anerkennung oder Bestreiten der Feststellungen. [5]
Beweisgrenze: Die ausgewertete CFTC-Order benennt MT4 und die asymmetrische Mechanik, aber nicht „Virtual Dealer Plugin“ als konkretes Produkt. Sie belegt die Kundenschädigung durch diese Regeln, nicht die Identität der eingesetzten Erweiterung.
Welcher Maßstab daraus folgt
Die NFA Interpretive Notice 9064 behandelt ungleiche Preis- und Volumengrenzen sowie einseitige Weitergabe von Kursabweichungen. Sie fordert für betroffene Forex Dealer Members eine ausgewogene Anwendung und Offenlegung der Ausführungsregeln; symmetrische Toleranzen und sachgerechte Requotes werden nicht generell untersagt. Der Maßstab erfasst auch eigene Systeme und Erweiterungen Dritter. [6]
US-Regeln und historische Entscheidungen werden hier zur Einordnung dargestellt. Ihre Anwendbarkeit auf eine bestimmte europäische oder andere Gesellschaft muss gesondert anhand Rechtsträger, Zuständigkeit, Zeitraum und Vertragsmodell geprüft werden.
Was Nutzer sichern und vergleichen können.
Wiederholte Verzögerungen oder ungünstige Ergebnisse sind ein Anlass zur Prüfung. Eine bestimmte Software oder Absicht lässt sich damit allein nicht nachweisen. Wichtig sind vollständige Anfragen einschließlich Requotes und Ablehnungen.
Den Fall eindeutig zuordnen.
Broker-Rechtsträger, Server, Kontomodell, Instrument, Handelsmodus, Plattform-Build und Zeitpunkt festhalten. Demo- und Live-Konten nicht unbesehen vergleichen.
Die Originaldaten erhalten.
Terminaljournal, EA-Logs, Historienexport, Screenshots und relevante Vertrags-/Ausführungsbedingungen unverändert sichern. Lokale und Serverzeiten samt Zeitzone, Uhrabweichung und Auflösung dokumentieren. Zugangsdaten nicht in eine Veröffentlichung übernehmen.
Jede Anfrage rekonstruieren.
Order-/Request-ID, Richtung, Volumen, Anfragekurs, Antwort, Requote, Ausführung, relevante Bid-/Ask-Ticks und Zeitstempel erfassen. Ein gewöhnlicher Historienreport kann abgelehnte Anfragen und serverseitige Verarbeitungsschritte auslassen.
Vergleichbare Situationen bilden.
Günstige und ungünstige Bewegungen getrennt auswerten: Annahmequote, Requote-/Ablehnungsquote, Latenz und Volumen. Kontrollieren Sie Instrument, Ordertyp, Tageszeit, Volatilität, Spread, Verbindung und Nachrichtenfenster. Kleine Stichproben und nur ausgeführte Trades können das Ergebnis verzerren.
Serverseitige Erklärung anfordern.
Nach den zum Ereignis gültigen Ausführungsregeln, Gruppen-/Symbolzuordnung, Protokollen, Konfigurationsänderungen und Gründen für konkrete Ablehnungen oder TP-Entfernungen fragen. Technische Detaildaten sind nicht immer für Kunden verfügbar; genau diese Beweislücke sollte dokumentiert werden.
Ergebnis und Beweisgrenze festhalten.
Beobachtung, statistische Auffälligkeit, bestätigte Regel und nachgewiesene Softwareidentität getrennt berichten. Für einen konkreten Anbieterbefund Gegenargumente und Stellungnahme berücksichtigen; zuständige Beschwerdewege anhand des Rechtsträgers bestimmen.
Fragen, die eine belastbare Antwort verdienen
- Gibt es absichtliche Ausführungsverzögerungen, und für welche Konten oder Instrumente?
- Sind Preis- und Volumengrenzen in beide Richtungen gleich?
- Werden Requotes und Ablehnungen vollständig protokolliert?
- Wie werden Limit Orders, Stop Orders und Take Profits bei Gaps behandelt?
- Welche Änderungen gelten in Nachrichtenfenstern, und wo wurden sie offengelegt?
- Lässt sich die konkrete Entscheidung aus den damaligen Regeln und Daten reproduzieren?
Technische Möglichkeit ist noch kein Einsatznachweis.
| Aussage | Stand der Belege |
|---|---|
| Verzögerungen und getrennte Toleranzen sind beschrieben. | In der bereitgestellten historischen PDF dokumentiert; Herkunftsprüfung begrenzt. |
| Das Plugin wurde historisch bei konkreten Brokern eingesetzt. | In NFA-Entscheidungen ausdrücklich benannt. |
| Das Plugin erzeugt künstliche Kursticks oder „jagt Stops“. | Von diesem Dokument nicht belegt. Die Verarbeitung eines Gaps ist keine nachgewiesene Erzeugung eines Gaps. |
| Das Plugin erkennt automatisch profitable Trader. | Nicht beschrieben. Gruppensteuerung ist dokumentiert; Verhaltensklassifikation nicht. |
| Alle MT4- oder MT5-Broker verwenden es. | Nicht belegt. Keine repräsentative aktuelle Installations- oder Konfigurationsdatenbasis. |
| Jede Slippage ist Manipulation. | Unzutreffende Verallgemeinerung; reale Kursbewegung, Liquidität und Übertragungszeit sind alternative Ursachen. |
| Diese Analyse verifiziert den Binärcode. | Nein. Keine DLL, Server-Testumgebung oder vollständige Änderungsverlauf-Dokumentation vorhanden. |
Offene Recherchepunkte
Benötigt werden ein unabhängig authentifiziertes Herstellerexemplar, exakte Plugin-/Serverversionen, spätere Änderungsstände und gegebenenfalls ein autorisierter Test. Ebenso offen sind die genaue Priorität sich überschneidender Gap-Regeln, Stop-out-Verarbeitung, Grenzwertverhalten und Nachrichten-Zeitbasis. Die historische Quelle beschreibt Stop-outs als Funktionsbereich, erläutert aber deren Algorithmus nicht vollständig.
Ein heutiger Einzelfall erfordert zudem die tatsächliche damalige Brokerkonfiguration und Ausführungsdaten. Ohne diese Grundlagen kann diese Seite den dokumentierten Funktionsumfang vollständig erfassen, aber keine vollständige Implementierungs- oder aktuelle Verbreitungsanalyse behaupten.
Informationsasymmetrien sichtbar und überprüfbar machen.
Verbraucherschutz beginnt dort, wo entscheidungsrelevantes Wissen zugänglich wird — und seine Grenzen nachvollziehbar bleiben.
Dieses Dossier dient als erster Anwendungsfall einer wiederverwendbaren Recherchemethodik im Sinne von unmasked.info. Die Methode ist hier als Arbeitsstandard formuliert; ein installierbarer Skill wurde noch nicht erstellt.
- Frage präzisieren: Werkzeug, Funktionsbehauptung, möglicher Nachteil, Betroffene und Zeitraum abgrenzen.
- Quellen erhalten: Herkunft, Abruf-/Erhaltsdatum, Version, Seitenfundstelle und Prüfsumme erfassen; Originale unverändert bewahren.
- Mechanik rekonstruieren: Parameter und Voraussetzungen in nachvollziehbare Entscheidungsschritte übersetzen. Widersprüche sichtbar lassen.
- Belege kreuzen: Dokumentation, Behördenentscheidung, Protokoll und Erfahrungsbericht nach ihrer jeweiligen Aussagekraft gewichten. Gespiegelte Kopien nicht als unabhängige Bestätigung zählen.
- Alternativen prüfen: Reguläre Marktmechanik, technische Fehler, legitime Kontrollen und abweichende Produkte als Gegenhypothesen berücksichtigen.
- Fall und Verantwortung zuordnen: Softwareanbieter, Broker, Infrastrukturbetreiber und konkreten Rechtsträger unterscheiden. Vorwurf, Vergleich und Feststellung korrekt kennzeichnen.
- Nutzer befähigen: Wirkungen erklären, Prüffragen anbieten, Beweislücken benennen und Erkenntnisse datieren.
- Revision ermöglichen: Für neue Quellen, Korrekturen und gegebenenfalls Anbieterstellungnahmen einen dokumentierten Aktualisierungsschritt vorsehen.
Für einen späteren Skill wäre ein strukturiertes Ergebnis aus Quellenregister, Behauptungs-/Belegmatrix, Funktionsmatrix, Gegenhypothesen, offenen Fragen und Publikationsprüfung erforderlich. Recherchen stützen sich auf bereitgestellte oder rechtmäßig zugängliche Unterlagen; eine geschützte Brancheninformation ist weder automatisch wahr noch automatisch ein Fehlverhalten.
Quellen und redaktioneller Stand.
- Bereitgestellte PDF: „VirtualDealer versus Manual Execution: What Is Better?“
Artikeldatum 14.03.2006; 10 PDF-Seiten; Copyrightvermerk MetaQuotes Software Corp. PDF-Metadaten nennen 11.09.2006 als Erstellungsdatum. Ursprünglich angegebener Link:
support.metaquotes.net/articles/349, im Recherchelauf nicht zugänglich. Erhalt: 30.09.2026. Keine öffentliche Kopie oder Hersteller-Screenshots werden mit dieser Seite verteilt.SHA-256: be214402703f5f3ead4c851258e45e67c954bf5af8568f0af24646bcc76f8f90
Fundstellen: Funktion/Installation S. 1; Auswahl/Delay S. 2; Slippage S. 2–4; Gap-Regeln S. 4–8; News/Dealer-Vorbehalt S. 8; Setup/Betrieb/Logs S. 8–10.
- NFA: GAIN Capital / Glenn H. Stevens · Complaint
30.06.2010; 10-BCC-015. Beschwerde/Vorwürfe, insbesondere Virtual Dealer und Slippage-Einstellungen. Nicht mit der späteren Entscheidung gleichzusetzen.
- NFA: GAIN Capital / Glenn H. Stevens · Decision
27.10.2010; 10-BCC-015. Insbesondere Abschnitte II–IV, Vergleich, Feststellungen und Sanktionen. Original beim NFA-Anbieter in diesem Recherchelauf nicht voll als Dokument auslesbar; relevante Passagen aus dem Suchindex der offiziellen NFA-Dokumente ausgewertet. Vollständige Originalprüfung bleibt offen.
- NFA: IKON Global Markets / Diwakar Jagannath · Decision
27.10.2010. Vergleichspassagen mit ausdrücklich benanntem Plugin, Erstattung und Sanktion aus dem Suchindex des offiziellen Dokuments ausgewertet. Vollständige Originalprüfung bleibt offen.
- CFTC: FXDirectDealer · Order
18.09.2013. Abschnitte III–VI, insbesondere PDF-S. 2–6. Behördenfeststellungen und Vergleich; Produktidentität des Plugins nicht benannt. Ergänzend: CFTC-Mitteilung 6697-13.
- NFA: Interpretive Notice 9064 · Forex Transactions
Board 02.09.2011; wirksam 26.03.2012. Abschnitt zu Price Slippage/Requoting und Offenlegung; eingesehen 30.09.2026. US-Mitgliedschaftsbezogener Maßstab.
- EU: Delegierte Verordnung (EU) 2017/565, Art. 23
Risikomanagement von Wertpapierfirmen. Verlinkte konsolidierte Fassung vom 22.08.2021; herangezogen für den allgemeinen Organisationsmaßstab, nicht als vollständige Darstellung aller späteren Änderungen. Quellenprüfung 01.10.2026.
- ESMA: MiFID II, Art. 17 – Algorithmic trading
Systeme, Kontrollen und Handelslimits im spezifischen Anwendungsbereich des algorithmischen Handels und direkten elektronischen Zugangs. Quellenprüfung 01.10.2026.
- BIS: FX trade execution – complex and highly fragmented
Quartalsbericht Dezember 2019; institutionelle FX-Marktstruktur, Geschwindigkeit und Ausführungsprotokolle. Keine Aussage über die Identität eines Retail-Plugins. Quellenprüfung 01.10.2026.
Unabhängiges Recherche-Dossier; keine offizielle MetaQuotes-Dokumentation. Produkt- und Unternehmensnamen dienen der eindeutigen Zuordnung. Die Quellenangaben identifizieren das ausgewertete Material; sie enthalten keine Behauptung einer vom Hersteller bestätigten Dokumentherkunft.