Virtual Dealer
Plugin
Risk controls are part of online trading. This dossier explains their legitimate purpose, the limit to unfair execution and the documented effectiveness of the historical Virtual Dealer plugin.
The starting point: A financial service provider must manage the risks of its business and technical systems. A server-side control is therefore not in itself a manipulation document. Its concrete application becomes critical: a rule for limiting risks must not justify unilateral discrimination against customers under this label alone. Public oversight documents on asymmetrical design show why purpose, parameterisation and actual effect have to be assessed separately. [7][5][6]
Open a table of contents
Parameters · Execution examples · Gaps · Cases · Test trail · Sources
Risk management is necessary. Its effects must be verifiable.
Online trading combines client orders, price data, account management, execution and, where applicable, broker hedging. Mistakes in one of these steps can create risks for customers, providers and other market participants. In the case of leveraged positions, even small price changes in relation to the deposited margin can have a significant impact. This leads to good reasons for technical controls, but does not give rise to a general power to modify the results of execution ex post or hidden in favour of the supplier.
For EU investment firms, Article 23 of Delegated Regulation (EU) 2017/565 requires appropriate procedures to identify and manage risks in their activities, processes and systems. Specific requirements for systems and trading limits are set out in Article 17 MiFID II for algorithmic trading and direct electronic access to trading venues. These special rules apply within their respective scope; they are not a blanket legal basis for any OTC retail order or broker extension. [7][8]
| Risk exposure | Possible technical control | Crucial audit question |
|---|---|---|
| Incorrect or duplicate orders | Plausibility check of price, size and repetitions; quantity and request limits. | Is a defined error intercepted and the reason documented in a comprehensible manner? |
| Obsolete price data or system malfunction | Feed monitoring, timestamping, interruption of faulty quotes. | Is the reference price resilient and are comparable situations treated consistently? |
| Margin, credit or concentration risk | Cover check, position limits, exposure monitoring and contractually provided closure rules. | Do the rules comply with the product, contract and applicable customer protection? |
| Liquidity and hedging risk | Monitoring available liquidity, aggregation of risks, hedge and counterparty limits. | Will the client’s order and independent hedging of the broker remain factually separate? |
| Adverse selection or latency effects | Analysis of price age, execution and subsequent price movement; adjustment of a permitted quote or risk policy. | Is the measure justified, proportionate and compatible with execution obligations? |
Illustrative risk categories and controls, no determination about the installation of a particular system. Broker platforms can integrate these functions or map them through additional modules; a representative survey of all broker systems is not based on this analysis.
What “toxic order flow” means — and its limits.
The term describes, from the point of view of a dealer or liquidity provider, an order flow in which executions can be systematically associated with price movements or hedging costs that are detrimental to him. One example is latency strategies, which trade a price that is still displayed, already obsolete, while a faster reference market has already continued. For the institutional FX market, the BIS describes differences in speed, trading protocols and mechanisms such as “last look”. This is a market structure context, not evidence of a particular retail broker configuration. [9]
“Toxic” is not a uniform legal classification and is not synonymous with fraud, market abuse or an improper order. Even a profitable customer, an Expert Advisor or a high trading frequency are not in themselves a proof of wrongdoing. A striking statistic must be checked against price quality, timestamp, liquidity, strategy and other explanations. Whether a specific restriction or rejection is permissible depends on the circumstances and the applicable rules.
The boundary between risk control and unfair outcomes.
A check must be judged by its actual purpose and outcome, not by its name alone. Rules that treat economically comparable favorable and unfavorable price movements unilaterally, obscure restrictions or give the customer a misleading picture of execution can be problematic. The NFA explicitly deals with price and volume limits as well as requotes and their disclosure for affected Forex Dealer Members. The CFTC published a concrete case of asymmetric MT4 execution parameters. These US documents prove the facts described in each case; they do not make any delay or requote inadmissible. [6][5]
An automated dealer on the broker’s server.
The PDF provided is titled “VirtualDealer versus Manual Execution: What Is Better?”, the article date 14 March 2006 and a copyright notice called MetaQuotes Software Corp. This note alone confirms neither the authorship nor the authenticity of the present copy. It describes a paid server plugin for the complete or partial replication of manual dealer actions for selected icon groups. Installation, manager account, group control and server logs locate it in the MT4 broker infrastructure. [1, S. 1–2, 8–10]
The user interface shows the trade request and its result. The rules in between are set on the server. For the investigation, it is therefore crucial to consider software function, concrete broker configuration and actual execution result separately.
Described purpose
Automate dealer work, confirm requests time-delayed, check price deviations and process pending orders, stops and stop-outs.
Presentation of documentation; no independent quality assessment.Consumer protection issue
Are comparable price movements and order sizes treated the same in both directions? Are restrictions disclosed and verifiable?
Editorial test scale.The crucial question is which order is accepted.
For the documented instant execution logic, a request is submitted at a specific price. After the set waiting time, the plugin evaluates the price movement. Within the respective tolerance, it can confirm the original request price; outside a requote takes place. A requote is a new price offer, not an already executed transaction. [1, S. 2–4]
This is an important conceptual distinction: “Slippage” here also refers to the market movement between request and processing. If confirmed at the original price, the request price and the execution price can be identical – although the acceptance rule creates an economic disadvantage compared to the current price. An analysis of only executed trades can completely overlook the rejected favorable requests.
Unfavorable movement
There is a purchase request for 1.1000. The current comparable Ask falls to 1.0995. A confirmation of 1.1000 would now be five pips more expensive than the current Ask. A wide “Max Losing Slippage” tolerance can still allow the original request.
Favorable movement
The Ask increases to 1,1005 instead. The original purchase request of 1.1000 would now be five pips cheaper than the current Ask. A close “Max Profit Slippage” tolerance can translate this request into a requote at a higher price.
Educational example using four decimal places and 0.0001 per pip. It compares the same price reference, excluding spread, fees and liquidity effects. The direction reverses for sell requests. The economic difference is not a complete profit-and-loss calculation.
Even equally large price tolerances can have an unequal effect.
“Max Profit Slippage Volume” additionally limits the volume for which favorable movements are still accepted. A comparison of only the two pip boundaries is therefore not sufficient. Equally relevant are groups, instruments, volumes, execution mode and, if available, human dealers. [1, S. 2–4, 8]
The documented parameters and their implications.
The matrix covers all named setting fields of this version; repeated News Time fields are maintained as a family of parameters. It describes the documentation, not a test of the executable software.
| Parameters | Documented function | What is relevant for users |
|---|---|---|
| Delay | 0 deactivates the plugin; 1–5 seconds activates the processing with waiting time. Actual delay can be up to a second shorter. | Additional time for course changes. An observed delay alone does not identify the plugin. |
| Virtual Manager Account | Manager account number under which the virtual dealer trades. | Assignment in server logs possible; usually no insight for customers. |
| Groups | Groups of accounts, including model and exclusion lists. | Different treatment of groups is possible. No evidence of a targeted selection of profitable individual customers. |
| Symbols | Inclusion or exclusion of instruments through lists and templates. | Execution rules may vary per instrument. |
| Max Volume | With an available, authorized dealer, larger requests are left to him. | No hard protection: If a suitable dealer is missing, the plugin also processes larger requests according to the warning. |
| Max Losing Slippage | Tolerance for a now customer-unfavorable market movement; Instant Execution. 0 leads to requote if the price changes accordingly. | A wide limit can accept a request at the now less favorable original price. Limit details are not consistently clear in the document. |
| Max Profit Slippage | Tolerance for a now customer-favorable market movement; Instant Execution. 0 leads to a requote if the price changes accordingly. | A narrow border can prevent the favorable original request. An example here inconsistently calls the “losing” parameter. |
| Max Profit Slippage Volume | Above the volume, there is always a requote in the case of customer-favorable price movement. | Asymmetry due to size, even at nominally equal pip tolerances. |
| Gap level (spreads) | Gap mode at tick distance ≥ set factor × spread; 0 deactivates the gap control. | Threshold depends on the spread; not just on the absolute jump in price. |
| Gap Safe Level (spreads) | Within a spread-dependent safety distance, a pending/stop is processed at the customer price, otherwise at the gap price. | Can limit price deviations. Text and example are not consistent with equality. |
| Gap Tick Counter | Processing only after the required number of quieter confirmation sticks; renewed gap resets the count. | Intermediate ticks are ignored. The waiting time is tick-dependent, not described as a fixed number of seconds. |
| Gap Pendings Cancel | If Activation and Take Profit are in the Gap: cancel or activate at the Gap Price and remove Take Profit. | A planned transaction can be dispensed with or arise without the planned take profit. |
| Gap Take Profit slide | By parameter name and explanatory text: Allow take-profit execution at the gap price. However, the table assigns the name to Stop Loss. | Cheaper closure is described in the flow text; assignment is not verified in the actual program. |
| Gap Stop Loss slide | By parameter name and flow text: Allow stop-loss execution at the gap price. However, the table assigns the name Take Profit. | Poorer closure is described in the flow text; assignment is not verified in the actual program. |
| News Stops and Freezes | Increases limit/stop and freeze intervals by a factor during given message windows; 0 does not mean an increase. | Placement and change close to the course may be restricted. |
| Allow Pending on News | Allows or prohibits pending operations in the message window. | Introduction calls placement, modification and deletion; parameter table only placement/change. Erasing behavior remains open. |
| News Time 1 ... N | List of date, time and duration in minutes. | Scheduled instead of document-described automatic message recognition. Time base/time zone not clearly specified. |
Operation, conditions and logging
The documented installation is done on the server; replacement of the DLL requires a server restart. After restart, the plugin should first be deactivated. Changes to the settings are immediate, according to the document. The affected icons must be set to manual processing and a certain quick confirmation option; otherwise, the text warns of lost requests for requotes. Actions should be found via “VirtualDealer” or the manager account number in the server log. [1, S. 1, 8–10]
One price movement. Two acceptance rules.
Compare symmetrical tolerances with unequal price or volume limits. The example shows the economic difference of a confirmation at the request price compared to the now current equilateral price.
Simplified teaching model from the document description, no emulation of the DLL and no broker test. Pip = 0,0001. It only models instant execution after an assumed wait; gaps, dealer handover, stops, spread and fees are excluded. At exact pip limits, no acceptance decision is claimed because of the contradictions in the document.
Gap rules also change stops and pending orders.
The document provides for its own gap processing. After a sufficiently large tick jump, activations up to a series of confirmation sticks can be reset. Another gap starts the count again. The decisive factor is the processing course after the confirmation, not necessarily the first course after the jump. [1, S. 4–8]
Stop orders and limit orders are treated differently.
The source describes Buy Stop and Sell Stop at the gap price, Buy Limit and Sell Limit at the requested customer price and expressly describes this scheme as customer unfavorable. The safe-level rule can additionally influence the price choice. This means that price improvements for limits must not simply be implied. The document does not fully explain the interaction of all settings.
A stop loss can be executed beyond its level.
The documented stop-loss slide behavior allows for a worse closing price; the take-profit slide behavior a better one. Even without an abusive plugin, a gap can cause a price to be non-tradable. The verifiable question is whether rules and actual course availability match and whether comparable situations are treated in a balanced manner. The reversed table descriptions remain to be observed.
An order can be activated without its intended take profit.
If a gap captures both the activation level and the take profit, the source describes two options: cancellation or activation at the gap price with take profit removed. This significantly changes the original trading plan. Protocol and order history would be crucial for reconstruction.
Message windows can reduce scope for action.
The given time windows can increase distances and limit pending operations. Risk control and the handling of rapid price movements come into consideration as a factual purpose; this is an editorial classification, not a confirmed manufacturer's justification. Disclosure, proportionality, equal treatment and actual impact are critical.
Described commentary features are [started/gap], [cancelled/gap], [sl/gap] and [tp/gap]. You can support the reconstruction. Their occurrence does not identify a specific DLL or an abusive configuration without further technical evidence. [1, S. 5–8]
Historical decisions explicitly name the plugin.
The existence of a possible disadvantage and its proven use are different questions of evidence. The following sources concern concrete historical undertakings, periods and procedures. They are not a statement about today’s brokers or all MetaTrader users.
GAIN Capital · 2010
The NFA decision in the proceedings 10-BCC-015 Reimbursements of negative slippage for affected trades from May to July 2009 attributed to the Virtual Dealer plug-in used on retail and institutional servers. It sees an overall sanction of $459,000 and symmetrical slippage rules in the future. The sum relates to the procedure as a whole, not only the plugin. The decision accepts a settlement offer; the complaint and its allegations are to be read separately from it. [2][3]
IKON Global Markets · 2010
The Decision of 27 October 2010 describes a settlement without acknowledging or contesting the complaints. He sees refunds for negative slippage attributed to the Virtual Dealer plug-in, a sanction of 320,000 US dollars In the future, there will be symmetrical rules. Here, too, a historical concrete deployment is named. [4]
FXDirectDealer · 2013
The CFTC found asymmetric MT4 execution parameters for December 2009 to June 2011: price movements adverse to clients were treated differently from favourable movements. It ordered $1,828,261 Refund and US$914.131 fine an. This affected 24,904 accounts. The comparison was made without recognising or contesting the findings. [5]
Limit of proof: The evaluated CFTC order names MT4 and the asymmetric mechanics, but not “Virtual Dealer Plugin” as a concrete product. It proves the customer damage by these rules, not the identity of the extension used.
The standard that follows
The NFA Interpretive Notice 9064 deals with unequal price and volume limits as well as one-sided disclosure of price deviations. It calls for balanced application and disclosure of execution rules for affected Forex Dealer Members; symmetrical tolerances and appropriate requotes are not generally prohibited. The scale also covers own systems and extensions of third parties. [6]
US rules and historical decisions are presented here for classification. Their applicability to a particular European or other company must be assessed separately on the basis of legal entity, jurisdiction, period and contract model.
What users can save and compare.
Repeated delays or unfavorable results are a reason for consideration. A certain software or intention cannot be proven alone. Important are complete requests, including requotes and rejections.
Clearly assign the case.
Broker legal entity, server, account model, instrument, trading mode, platform build and timing. Do not compare demo and live accounts unnoticed.
Preserve the original data.
Secure terminal journal, EA logs, history export, screenshots and relevant contract/execution conditions unchanged. Document local and server times including time zone, clock deviation and resolution. do not incorporate access data into a publication.
Reconstruct each request.
Record order/request ID, direction, volume, request price, response, requote, execution, relevant bid/ask ticks and timestamps. An ordinary history report can omit rejected requests and server-side processing steps.
Create comparable situations.
Evaluate favourable and unfavourable movements separately: acceptance rate, requote/rejection rate, latency and volume. Control instrument, order type, time of day, volatility, spread, connection, and message window. Small samples and only executed trades can distort the outcome.
Request an explanation of server-side processing.
Ask about the execution rules, group/symbol assignment, protocols, configuration changes, and reasons for specific rejections or TP removals that apply to the event. Technical detail data is not always available to customers; it is precisely this gap in evidence that should be documented.
Record the result and the limit of proof.
Observation, statistical conspicuity, confirmed rule and proven software identity report separately. Consider counter-arguments and opinions for a specific provider finding; determine competent means of complaint based on the legal entity.
Questions that deserve a robust answer
- Are there any intentional execution delays, and for which accounts or instruments?
- Are price and volume limits the same in both directions?
- Are requotes and rejections fully logged?
- How are Limit Orders, Stop Orders and Take Profits treated on Gap?
- What changes apply in message windows, and where have they been disclosed?
- Can the concrete decision be reproduced from the rules and data at that time?
Technical possibility is not yet proof of use.
| Statement | Status of supporting documents |
|---|---|
| Decelerations and separate tolerances are described. | Documented in the provided historical PDF; provenance limited. |
| The plugin has historically been used by specific brokers. | Specifically named in NFA decisions. |
| The plugin generates artificial cursticks or “hunts stops”. | Not supported by this document. The processing of a gap is not a proven generation of a gap. |
| The plugin automatically recognizes profitable traders. | Not described. Group control is documented; behavioral classification is not. |
| All MT4 or MT5 brokers use it. | Not used. No representative current installation or configuration database. |
| Every slippage is manipulation. | Incorrect generalization; real price movement, liquidity and transmission time are alternative causes. |
| This analysis verifies the binary code. | No. There is no DLL, server test environment or complete change history documentation. |
Open research points
An independently authenticated manufacturer copy, exact plugin/server versions, later change statuses and, if necessary, an authorized test are required. Equally open are the exact priority of overlapping gap rules, stop-out processing, limit behavior and message time base. The historical source describes stop-outs as a functional area, but does not fully explain their algorithm.
Today’s individual case also requires the actual broker configuration and execution data at that time. Without these basics, this site can fully capture the documented functionality, but cannot claim a full execution or current distribution analysis.
Make information asymmetries visible and verifiable.
Consumer protection begins where decision-relevant knowledge becomes accessible – and its limits remain traceable.
This dossier serves as the first use case of a reusable research methodology in the sense of unmasked.info. The method is formulated here as a working standard; an installable skill has not yet been created.
- Question to be specified: Delineate tool, function statement, possible disadvantage, affected persons and time period.
- Sources obtained: Enter origin, date of retrieval/receipt, version, page reference and checksum; preserve originals unchanged.
- Reconstructing Mechanics: Translate parameters and prerequisites into comprehensible decision steps. Let the contradictions be visible.
- Cross supporting documents: Weight documentation, decision by authorities, protocol and report of experience according to their respective significance. Mirrored copies do not count as independent confirmation.
- Examine alternatives: Consider regular market mechanics, technical errors, legitimate controls and different products as counter-hypotheses.
- Assign case and responsibility: Software providers, brokers, infrastructure operators and specific legal entities. Correctly identify accusation, comparison and determination.
- Enable users to: Explain effects, offer test questions, identify gaps in evidence and date findings.
- Enable revision: Provide a documented update step for new sources, corrections and, where applicable, provider comments.
For a later skill, a structured result from source register, claim/document matrix, function matrix, counter-hypotheses, open questions and publication review would be required. Searches are based on provided or lawfully accessible documents; protected industry information is neither automatically true nor automatically misconduct.
Sources and editorial status.
- Published PDF: “VirtualDealer versus Manual Execution: What Is Better?”
Article date 14.03.2006; 10 PDF pages; copyright note MetaQuotes Software Corp. PDF metadata name 11.09.2006 as the creation date. Originally provided link:
support.metaquotes.net/articles/349, not accessible in the research run. Received: 30.09.2026. No public copy or manufacturer screenshots are distributed with this page.SHA-256: be214402703f5f3ead4c851258e45e67c954bf5af8568f0af24646bcc76f8f90
References: Function/Installation S. 1; Selection/Delay S. 2; Slippage S. 2–4; Gap Rules S. 4–8; News/Dealer reservation S. 8; Setup/Operation/Logs S. 8–10.
- NFA: GAIN Capital / Glenn H. Stevens · Complaint
30 June 2010; 10-BCC-015. Complaint/accusations, in particular Virtual Dealer and Slippage settings. Not to be equated with the later decision.
- NFA: GAIN Capital / Glenn H. Stevens · Decision
27.10.2010; 10-BCC-015. In particular, Sections II–IV, Comparison, Findings and Sanctions. Original from the NFA provider in this search run not fully readable as a document; relevant passages from the search index of the official NFA documents evaluated. Complete original examination remains open.
- IKON Global Markets / Diwakar Jagannath · Decision
27.10.2010. Comparison passages with explicitly named plugin, refund and sanction are evaluated from the search index of the official document. Complete original examination remains open.
- CFTC: FXDirectDealer · Order
18 September 2013. Sections III–VI, in particular PDF-S. 2–6. Authority findings and settlement; product identity of the plugin not named. Additional: CFTC Notice 6697-13.
- NFA Interpretive Notice 9064 · Forex Transactions
Board 02.09.2011; effective 26.03.2012. Section on Price Slippage/Requoting and Disclosure; viewed 30.09.2026. U.S. membership scale.
- EU: Delegated Regulation (EU) 2017/565, Article 23
risk management of investment firms. Linked consolidated version of 22.08.2021; used for the general organisational scale, not as a complete presentation of all subsequent changes. Source testing 01.10.2026.
- ESMA: MiFID II, Art. 17 – Algorithmic trading
Systems, controls and trading limits within the specific scope of algorithmic trading and direct electronic access. Source testing 01.10.2026.
- BIS: FX trade execution – complex and highly fragmented
December 2019 quarterly report; institutional FX market structure, speed and execution protocols. No statement about the identity of a retail plugin. Source testing 01.10.2026.
Independent research dossier; no official MetaQuotes documentation. Product and company names are used for a clear assignment. The source information identifies the evaluated material and does not contain any claim of document origin confirmed by the manufacturer.