How to evaluate trading risk-management software

1. Separate monitoring, checks and intervention

Monitoring displays a state or issues an alert. Pre-trade checking evaluates a request before passing it through a defined channel. In-trade intervention acts on a position that is already open. Do not treat these as interchangeable when comparing products.

Request a simple order-path diagram: where the message starts, where the decision occurs, who submits the order, and what happens outside that channel. If not every order passes through the gate, do not describe coverage as universal prevention.

2. Turn every limit into a testable definition

A daily limit needs a calculation basis. Specify balance or equity, open positions, commissions, reset time and any trailing high-water mark. Test a case where balance and equity disagree.

For funded accounts, retain a dated copy of the account's official rules and document the software mapping. A generic claim of prop-firm support is insufficient. Do not carry one account's configuration into another without checking its definitions.

3. Ask what happens when the system does not know

Data may be stale, a service may fail, or a request may be retried. Request the behavior for each case and how the software distinguishes no risk from insufficient information to calculate risk.

For a pre-trade gate, discuss blocking new risk when necessary data is unavailable while distinguishing risk-reducing from risk-increasing orders. Intervention in an existing position requires its own failure policy: a closing order can be delayed or rejected, so it is not a guaranteed exit price.

4. Separate trading authority from policy changes

Who can raise a limit, who approves it, and is the change recorded? Test an ordinary-user session, not just an administrator session, including alternative paths around the intended permission boundary.

Request connection type, permission scope, revocation procedure and secret-storage design. Comparing products does not require sharing your account password or granting broad access unrelated to the evaluation.

5. Request a record that explains the outcome

Each test should identify inputs, policy version, timestamps, expected decision and observed result. Distinguish what the software decided from what the execution channel confirmed: a correct decision can be recorded without its action reaching the destination.

Exportability alone does not prove a record cannot be altered. Ask about integrity controls, review procedures and retention; distinguish an internal design from test evidence and independent assessment. Rejected-request counts do not establish prevented market losses.

6. Make acceptance testing part of selection

Run the scenarios below in a demo account or an authorized non-live test environment. State the expected outcome beforehand; retain the observations, evidence, discrepancies and remaining limitations.

One ordinary successful case is not overall acceptance. Mark each capability as demonstrated in scope, conditional, unsupported or untested. Compare vendors against the same environment and version assumptions, then select against your actual requirements.

Eight proposed acceptance scenarios — not test results

Within-policy request

Trace the request through the agreed channel and reconcile the record, decision and expected outcome.

Over-limit request

Establish the actual interception point, or disclose alert-only behavior rather than relying on a screen message.

Two concurrent requests

Check that remaining budget is not allocated twice and that both results can be explained.

Stale or missing data

Check permitted data age and behavior beyond it rather than assuming the last number is current.

Disconnect and restart

Check state recovery, reconciliation and protection against repeating an action on retry.

Unauthorized policy change

Use an unprivileged role and verify rejection and the change-attempt record.

Uncovered order channel

Document the exclusion or test an additional integration; do not generalize one channel's success.

Reset boundary

Test daily and weekly limits and the agreed timezone on both sides of the reset boundary.

A useful demo request: evaluate these defined limits and channels, provide documented observations and written coverage boundaries before any live use. Apply that request to MADO and to every alternative you compare.

A practical evaluation worksheet

Start with eight non-live scenarios and record the product and policy versions, covered channel, observed outcome and evidence reference. Every case in the template is unexecuted: define expectations before testing and do not treat this worksheet as a success report or certification.

Reference and scope of this guide

For background on system development, testing and supervision, see FINRA Regulatory Notice 15-09. It concerns its own US regulatory context; it is not an endorsement of MADO or a claim that this checklist achieves legal compliance or that its rules apply to every reader. The scenarios above are MADO evaluation proposals, not quotations from the notice or operational results.