RTX5 Technology forProp Firm Rules and Accounts
Preview technology requirements for challenge rules, drawdown formulas, breach lifecycle, account types and evaluation workflows. Confirm supported enforcement and API/SDK versions before deployment.
Drawdown Definitions
Illustrative rule definitions; each firm must approve its formula, clock, cashflow policy and tested enforcement.
Daily Drawdown
Illustrative daily-loss policy: subtract the allowed loss from the higher of starting balance or equity at the defined day boundary. Actual reference and cashflow rules must be stated.
Static Drawdown
Maximum cumulative loss from the initial account balance. The drawdown limit does not change as the account grows. Breach occurs when equity falls below (initial balance − drawdown limit).
Trailing Drawdown
Drawdown limit that increases as the account reaches new high-water marks. The permitted loss floor rises with peak equity but never decreases.
Balance vs Equity
Balance reflects booked cashflows, closed P&L and applicable charges. Equity also includes floating P&L and defined adjustments. State credit, fee and cashflow treatment explicitly.
Trading Day Definition
The timezone and exact time that defines the start/end of a trading day. EOD vs intraday calculations must be explicitly configured.
Breach & Reset
Define whether equality or strictly crossing the floor triggers a breach, then specify supported account restrictions, reset eligibility, costs and cooldown.
Make every loss rule reproducible
A loss rule needs an exact reference value, loss amount, comparison, clock and cashflow policy. The examples below use a fictional $100,000 evaluation account and do not define an RTX5 or firm default.
Swipe horizontally to view all columns.
| Rule | Formula and inputs | Worked result |
|---|---|---|
| Daily loss: fixed $5,000 allowance | Day reference = max(starting balance, starting equity). Daily floor = day reference − $5,000. | Balance $100,000; equity $102,000; floor $97,000. Equity $97,000 does not breach this example; $96,999.99 does. |
| Static loss: 10% of initial balance | Static floor = initial balance × (1 − 0.10). It does not rise with profits. | $100,000 × 0.90 = $90,000. A later equity high of $108,000 leaves the floor at $90,000. |
| Trailing loss: fixed $5,000 allowance | Peak = highest observed equity under the chosen sampling rule. Floor = peak − $5,000; the floor never moves downward. | Peak $108,000 gives a $103,000 floor. A fall to $104,000 leaves the floor at $103,000; $102,999.99 breaches. |
Swipe horizontally to view all columns.
| Setting | What the rule must specify | Example consequence |
|---|---|---|
| Intraday or end-of-day peak | Whether every accepted equity update or only the day-close observation can increase the trailing peak. | An intraday high of $108,000 and a close of $104,000 produce different floors under the two policies. |
| Cashflow treatment | Whether permitted deposits/withdrawals adjust the reference and floor, are excluded from performance, or are prohibited during evaluation. | Under an explicitly cashflow-adjusted policy, a $2,000 deposit raises both a $100,000 reference and $95,000 floor to $102,000 and $97,000; it does not count as trading profit. |
| Trading days and resets | Timezone, daylight-saving handling, qualifying activity, minimum/maximum days and which events start a new evaluation. | A daily reset can set a new daily reference while preserving a static or trailing limit. A challenge restart needs a new evaluation ID and rule version. |
| Combined limits | Which rules are active and how each is evaluated against the same timestamped account snapshot. | With active floors of $97,000 and $90,000, equity $96,000 breaches the first rule even though the second still passes. |
Account Types & Features
Simulated Accounts
Proposed simulated evaluation accounts need a disclosed execution model, versioned rules and verified performance/permission records.
Live Funded Accounts
A live account requires a separate approved transition, provider eligibility and trading permissions. Passing a simulated challenge does not automatically create one.
Contests & Leaderboards
Proposed contests need approved eligibility, scoring windows, rule versions and display consent. Confirm supported group and leaderboard permissions.
API & SDK Integration
Proposed integration scope covers challenge status, metrics and breach events. Endpoint schemas, SDK methods, versioned rules and enforcement tests remain unpublished.
Follow breaches, resets and account permissions
Keep an evaluation's state, trading permissions and account type separate. A simulated evaluation does not become a live funded account simply because a performance target is reached.
- 01
Assign and activate
Assign a versioned ruleset, account type and effective time. Record the starting balance, timezone, qualifying-day definition and fees before evaluation begins.
- 02
Evaluate and record
Evaluate each account snapshot under its assigned version. A breach record should include the rule ID, equity or balance used, reference, floor, comparison and source timestamp.
- 03
Apply the agreed breach policy
Define whether the account becomes read-only, new orders are blocked, pending orders are cancelled or positions are closed. These are separate controls to confirm and test; a breach notification alone does not demonstrate enforcement.
- 04
Review, reset or graduate
Record review decisions and exceptions. A reset needs explicit eligibility, cost, cooldown and treatment of previous history. Live account creation, allocation and withdrawal permissions require a separate approved transition.
Swipe horizontally to view all columns.
| Operation or event | Required context | Permission and reconciliation |
|---|---|---|
| Create or assign evaluation | Evaluation ID, account ID, account type, rule version and effective timestamp. | Challenge-management scope; repeated requests need an agreed idempotency key. |
| Read metrics or receive breach event | Balance/equity snapshot, observed time, rule inputs, comparison and resulting state. | Access only assigned accounts; deduplicate events and fetch current state after a reconnect. |
| Reset or change rules | Reason, approver, previous/new rule versions and effective time. | Privileged action with an audit record; define treatment of orders and metrics at the boundary. |
| Contest and leaderboard | Contest group, scoring window, eligible account types, score method and disqualification rules. | Separate private account access from public display consent; use permitted display names and fields. |