Checklist · Prop Evaluation Rules
Prop Rule Breach Review: Evidence for an Appeal
Build a reproducible rule-breach case using versioned terms, account snapshots and event times, with a review record that makes uncertainty visible.
Published Updated
Published by FxTrusts, a supplier of brokerage and prop firm technology. Prepared with AI-assisted research and drafting; reviewed against the cited public sources. Examples are illustrative. Product links describe our services.
Quick answer
A breach review should connect the applicable rule version to the account inputs, event sequence, calculation and authorized decision. Preserve evidence before changing records. A final balance or screenshot alone may not reproduce an intraday equity event, reset boundary or earlier trailing peak.
Freeze the applicable policy and account context
Record the program, phase, account model, effective rule version and relevant terms. Identify whether the account is simulated and which values are used by the rule. A generic label such as daily drawdown does not identify the formula. Provider objectives demonstrate that baselines and conditions vary. The review should explain the selected policy without retroactively applying a newer or more familiar rule to an earlier event.
Collect the inputs needed to reproduce the decision
Retain balance, equity components, relevant prices, costs, open positions, timestamps and any stored peak or reset baseline. Use original identifiers to join the records. A trailing rule needs its qualifying peak history; a daily rule needs the correct boundary and baseline. If some input is missing, state the gap and its effect on confidence. Do not manufacture an exact event time by interpolating a coarse chart without a supported method.
Separate detection, consequence and human review
The system’s detected condition is one record; a restriction or closure action is another; a reviewer’s decision is a third. Keeping them separate makes corrections and appeals understandable. The reviewer should record the allegation, reproduced calculation, contradictory evidence, outcome and reason. OWASP logging guidance supports retaining useful actor/action/outcome context while protecting sensitive data. It does not establish a legal retention period or prove an immutable product audit trail.
Correct transparently and communicate the result
If the original calculation was wrong, document the cause and authorized remedy without deleting the original evidence. If it was correct, explain the formula and decisive inputs in plain language. A disputed rule outcome is not automatically fraud or cheating. Limit access to the case data, redact unnecessary personal information in shared extracts and track outstanding technical or policy actions separately from the participant-facing decision.
A fictional daily-reset appeal packet
A participant reports that no new trade occurred when a daily loss condition was detected. The packet should include the old and new baselines, the unchanged open-position loss and the reset timestamp. A reviewer can then determine whether the new floor changed the result under the applicable rule. This is a case template, not a real FxTrusts customer incident or a predetermined appeal outcome.
| Evidence field | What it resolves |
|---|---|
| Effective rule and phase | Which formula and consequences applied |
| UTC event time and business timezone | Which side of the reset boundary applies |
| Old/new baseline and floor | Whether reset changed the threshold |
| Account components and open positions | How the measured value was produced |
| Reviewer, decision and reasons | Who assessed the evidence and what remains unresolved |
Implementation checklist
- Preserve the policy version and original decision evidence.
- Collect the full path or boundary inputs required by that specific rule.
- Separate detected condition, operational action and review outcome.
- Document uncertainty, corrections and participant communication without unsupported accusations.
Sources
These documents support the reference. Check the original publication for current requirements and the limits of its scope.
- FTMO program-specific trading objectivesftmo.com
- MQL5 account propertieswww.mql5.com
- OWASP logging guidancecheatsheetseries.owasp.org
- Python time-zone informationdocs.python.org
Continue with the broader guides
Connect this reference to platform selection and the wider operating workflow.