Build a risk review for alerts, execution and automation

Write the experiment before configuring the alert

Start with a written experiment card. Our proposed workflow is an educational method for reviewing data and automation; it does not recommend a trade, asset allocation or expected return. Use simulation for the exercises below. Every example interval and threshold is an illustrative assumption, not a suggested trading setting.

The English alert guide describes an Alert as a notification based on one condition and a Pro Alert as a combination of several conditions. Pro Alerts documentation.

In our workflow, give notification logic and permission to act separate sections. Write the condition in the first section. In the second, list the observations and approvals your experiment requires before any simulated action. A third section should specify how you will review the result.

Identify the instrument, trading pair, market, data source and configuration version. Choose an observation interval and an evaluation horizon separately: for example, a five-minute observation interval and a one-hour review horizon. These are exercise settings. Add a sentence stating what would invalidate the interpretation, such as missing observations, an unexpected instrument or data older than your chosen acceptance threshold.

Give position size more than one field

The automation guide describes purchases using a fixed amount or a percentage of capital. It also describes a purchase-size limit relative to the token's 24-hour trading volume. We are citing the documented controls without attributing a guaranteed outcome to them. Automation guide.

Our proposed experiment card uses three limits: the amount assigned to one action, the total assigned across open actions, and the number of repeat activations allowed for one scenario. Choose all three before reviewing the test result. Give each limit a unit and a clear check point.

For a paper exercise, nominate a fictional account balance and a reporting currency. Record an individual action cap and an aggregate cap without treating either as an appropriate amount for a real account. When two conditions concern the same instrument, require a combined review in this workflow rather than maintaining two isolated experiment cards.

Keep purchase amount and permitted loss in separate fields. For the loss field, specify your accounting convention, included costs and review time. Do not approve the next test stage if you cannot reconstruct the calculation from the recorded inputs. This is our proposed review rule, not a claim that a particular cap will deliver a particular result.

Make volatility and liquidity observable

For this article, our working convention is to use the volatility field for a selected measure of price movement over a stated period. Use the liquidity field for your observation of executing a specified order size. These are worksheet conventions, not comprehensive definitions or an asserted industry standard.

Replace labels such as “volatile” and “liquid” with an observation record. Our proposed record includes the measure, unit, source, observation time and acceptance rule. If you choose a high-to-low price range, specify the measurement period. If you inspect available offers, specify the market side, intended size and permitted distance from a reference price.

Keep 24-hour volume and your order-book observation in separate worksheet fields. Require an explicit entry for each field you consider necessary. Where an observation is unavailable, use “not assessed” instead of supplying a favorable assumption.

Write alternative interpretations beside the observation. One proposed label is “price condition satisfied.” Another is “price condition satisfied; execution observation incomplete.” These labels organize decisions in the exercise. They do not assign a cause to the market move or predict its continuation.

Record data age and execution separately

The Pro Alerts guide describes a window for satisfying conditions, a sleep period after activation and selectable inputs including open, close, minimum, maximum and average. Alert parameters.

Our proposed worksheet gives the condition window, observation interval and maximum accepted data age their own fields. Do not reuse one number across all three merely because the units match. For each field, state the purpose and who may change it.

Create a timestamp record with source observation, data receipt, alert activation, notification receipt and execution confirmation. Specify the timezone and origin of each timestamp. Mark unavailable values as missing. For typical delay, enter a measurement from your own stated sample, or write “not measured.”

For this exercise, define slippage as the difference between a recorded reference price and the execution price under your chosen sign convention. Specify how you would combine partial executions. Keep fees in a separate field. This is a proposed accounting convention for the worksheet, not a statement about a product's calculation method.

Establish an acceptance threshold for both data age and execution discrepancy before the simulation. If a required timestamp or execution observation is missing, our proposed rule is to classify the event as unassessed. Keep that classification visible in the final report rather than silently dropping the event.

Decide what “false signal” means in the test

Our proposed review convention distinguishes a configuration mismatch from an unmet hypothesis. Use “configuration mismatch” for a recorded departure from your rule, such as the wrong input source. Use “hypothesis not met” when the condition was recognized as specified but the prewritten evaluation criterion was not satisfied within the chosen horizon.

Define the evaluation criterion before inspecting the results. Write the price observation method, review deadline, cost assumptions and treatment of incomplete events. Add a third status, “cannot assess,” for records that do not meet your data requirements. Do not force every observation into success or failure.

The English backtest guide describes checking historical trigger counts and displaying average and median price changes before and after an alert. It also describes selecting the backtest period and testing either a single condition or several conditions together. Backtests documentation.

Our proposed review sheet records the date range, event count, missing observations, variants tried and settings selected after inspecting results. Assign one period to developing the configuration and another to evaluating the frozen version. Treat historical fitting as an explicit review question: which choices were made using the outcomes you are now reporting?

Use a separate section for future expectations and mark it “unverified.” In this workflow, historical average and median observations belong only in the historical-results section. Record the sample size alongside them. Add the costs and execution assumptions used in your exercise instead of leaving the reader to guess what the reported result includes.

Write the interruption procedure as a set of decisions

Our proposed interruption procedure starts with prewritten triggers. Examples for a simulation include an unconfirmed execution, a balance mismatch, a breached allocation cap or missing required data. Choose your own triggers and assign a person responsible for reviewing each one.

Separate three decisions in the procedure: stopping new actions, reviewing outstanding orders and deciding what to do about existing positions. Give each decision its own confirmation requirement. Do not use a single “stopped” checkbox for the whole exercise.

After an interruption, record the configuration version, incident time, observed state and unresolved questions. Reconcile the experiment log with execution confirmations and the account state used in the simulation. Our proposed restart gate requires a documented explanation, a tested correction and approval of a new configuration version. Elapsed waiting time is a separate field, not the restart approval itself.

Finish with a reproducible review packet

Our proposed packet contains the data definition and source, observation interval, measured or unmeasured delay, evaluation horizon, size limits, execution observations, cost assumptions and invalidation conditions. Add alternative interpretations, sample size, limitations and the interruption instructions. Mark every incomplete mandatory field as an open task.

For a beginner, we propose completing one experiment card manually. For an active analyst, we propose comparing frozen versions using the same review fields. For an automation tester, we propose adding simulated interruption events and documenting the restart decision. These are editorial learning paths, not claims of proven effectiveness.

The official Help Hub introduces MaxData Info Bot as an assistant for questions about MaxData and the workspace. MaxData Help Hub.

Our suggested question is: “Which documentation explains this setting, what does the input mean, and how can I inspect my configuration?” Include the setting name and the experiment assumptions. Save the response with your review packet, then apply your written completion criteria before advancing the exercise.