Trading validators are not - currently - used by any built-in part of the MyTrader software itself. They are a service which is provided solely for use by third-party code, to extend the platform.
A trading validator receives notification of all trading requests passing through MyTrader, and has the option to block them. The idea is that a trading validator can implement custom checks on trading activity such as the following:
Is the spread on a market too wide?
Is the time too close to a high-impact event in the economic calendar?
Does the open volume on a market mean that we don't want to allow a further trade?
Do we want to prevent pending orders without expiry?
Do we want to block trading entirely?
You register your widget or script (or even UDIX) as a trading validator by calling Framework.AddTradingValidator(). To deregister it, and stop receiving validation messages, you call Framework.RemoveTradingValidator().
Note: if a trading validator is implemented in/as a widget, then the widget will typically want to ensure that it remains permanently loaded. Otherwise, the validator and OnTradeValidation() will only be called while the widget is visible on screen, and will stop operating if the user switches to a different page/tab where the widget is not loaded.
Once you have called AddTradingValidator(), all trading requests throughout the platform get submitted for approval to your widget or script. This happens after a request has passed all MyTrader's internal validity checks, but before the request is sent to the broker for execution.
Requests are sent to a function called Framework.OnTradeValidation(). This must return a synchronous response, in order not to delay trading unduly. You cannot look up some asynchronous data, such as the economic calendar, and then later send a response to the validation request once you have the data you need. To set up a check such as the economic calendar, you will typically request the calendar (asynchronously) while simultaneously registering as a validator. If you get a validation request before you have the calendar data to verify it, it is up to you whether you accept or reject the validation request.
OnTradeValidation() rejects a request by returning {status: "block"}, or specifies that the user must manually confirm it by returning {status: "confirm"}. Any other return value allows the request to go ahead. For example:
Framework.OnTradeValidation = function(Msg) {
if ( … some condition we don't like … ) {
// Block and reject the request
return {status: "block"};
} else if ( … some condition we're not sure about … ) {
// Show a confirmation dialog to the user (which may
// happen anyway, depending on other settings and controls)
return {status: "confirm"};
} else {
// Allow the trading action to proceed
return null; // or {status: "okay"}, or anything apart from status:"block"/"confirm"
}
};
If you return {status: "block"} then you can also add blockText into your response. This message is added to the standard rejection message to the user. For example:
return {status: "block", blockText: "Are you mad?"};
Similarly, if you return {status:"confirm"} then you can add confirmText to the response.
Your validator receives two pieces of information in the Msg message which is passed into OnTradeValidation():
| Property | Description |
| fromWidgetType | Type of widget making the request. For example, you might choose to allow all requests from some known widget types such as the dealticket, because by definition the user has seen and manually actioned the request. |
| tradingJobs[] | List of trading actions which are being requested. |
There are two things to note about the array of tradingJobs[]:
You cannot approve or reject individual requests within the array. You can only approve the whole batch or reject the whole batch.
What you receive in tradingJobs[] is a list of trading actions dis-aggregated into the low-level requests such as opening or closing individual orders. For example, if the user clicks Close > All in the built-in MyTrader trade list widget, or a script uses the equivalent FLATTEN trading action, then what you will get in tradingJobs[] is not a single FLATTEN request but instead a separate entry in the array for each individual ticket which is going to be closed/deleted.
