Rithmic Evaluation vs Funded Automation Checks

Rithmic provides trading connectivity; the prop firm defines program rules. An evaluation may use one account, system name, risk profile, and set of credentials, while a funded stage can change any of them. A strategy that authenticated and placed permitted evaluation trades has demonstrated only that the integration worked in that context. It has not demonstrated current funded-stage permission.

At promotion, disarm every strategy and capture the new official rules. Check automation, copy trading, account sharing, device and hosting restrictions, prohibited methods, maximum positions, drawdown behavior, news or session requirements, and whether the stated Rithmic connection is still the allowed rail. Technical connection is not permission; private server order relay and Live Funded API limits must be verified in current official rules.

Rithmic's official API page describes multiple developer interfaces and a path from test development through conformance and production credentials. Application-level production access, broker or FCM credentials, market-data entitlements, and prop-account policy remain distinct. A third-party product should identify the Rithmic rail it uses and the account types it has actually tested.

The trader's login may connect through a named Rithmic environment supplied by the firm. Do not edit environment labels, gateway names, or account strings to make a failed funded login resemble the evaluation. Use credentials delivered through the official firm process. After authentication, discover the entitled accounts and verify that the funded account appears with the expected native identifier before changing any enabled state.

Do not create a universal Rithmic prop rule from one provider. Some firms publish separate restrictions for prohibited activity, fair play, or copy trading. The source set for this guide includes examples from Apex Trader Funding, My Funded Futures, Tradeify, and Earn2Trade to show that firms frame these controls independently. Only the rules for your provider, plan, and current stage govern your account.

Save the page URL, title, review date, applicable plan, and decisive language in the deployment record. If support supplies clarification, keep the ticket or email and scope it narrowly. Marketing pages, Discord summaries, and a successful login are not substitutes for terms. Configure a fresh-review date and automatically disable order submission when the approval expires or the firm publishes a material update.

Topstep's reviewed API-access page says all order-flow activity must originate on the personal device and prohibits VPS, VPN, and private-server placement, modification, cancellation, triggers, routing, or relaying. It allows listed private-server support functions only when they do not touch order flow. Its Live Funded Account page separately says automated trading through the ProjectX API is prohibited in the LFA.

Those are ProjectX and Topstep-specific statements, not Rithmic protocol rules. They are included because traders often generalize a prop firm's permission from one platform or stage to another. Do not infer that an older Rithmic evaluation workflow authorizes a current TopstepX funded workflow, or vice versa. Technical connection is not permission; verify private server order relay and Live Funded API limits in the current official rules.

A funded credential can point to a different Rithmic system or account. Connect read-only first, enumerate entitled accounts, and bind the exact funded account identifier to a new configuration. Preserve the evaluation record for audit but do not reuse it as the active destination. Reject ambiguous account matches and display enough environment context for the operator to catch the wrong gateway.

Recheck product entitlements and current dated contracts. The strategy may continue to emit a root such as MES, but the execution adapter must resolve a listed contract recognized by the funded session. Review roll status, open positions, and provider product restrictions. Confirm exchange tick size and value from primary specifications; do not copy a full-size contract's dollar assumptions into a micro product.

Maximum position, drawdown, daily loss, scaling, consistency, and liquidation rules can differ by firm and stage. Translate only verified current rules into configuration, then apply a conservative local cap. The risk gate should include net position and working orders across every strategy targeting the account. A per-strategy quantity limit alone can exceed the account maximum when several signals arrive together.

Keep risk calculations independent of the webhook. A message can request one unit, but it cannot raise the configured maximum, choose another account, disable a daily stop, or bypass a stale-state lock. If order, fill, balance, or position data is delayed, stop opening exposure. Prop-account liquidation controls are a last boundary, not a substitute for deterministic client limits.

Begin read-only: authenticate with officially issued credentials, confirm system and account, retrieve positions and working orders, and resolve one current micro contract. Verify policy evidence is fresh and the execution process is running only where allowed. If the rules do not permit a test trade, do not place one merely to validate the connector.

When a trade is permitted, correlate the signal, normalized intent, Rithmic order identifiers, execution reports, and final position. Test disconnection and restart, then reconstruct account state before rearming. Simulate a duplicate signal and excessive quantity. Increase size only after several sessions of reconciled behavior and continued rule compliance; do not claim latency or reliability that you have not measured.