Risk management
Risk rules, account state and breach review in one authority.
Risk in a prop firm is a workflow, not a single rule. A limit has to be designed, applied to the right accounts, evaluated continuously against live state, enforced consistently, explained to the trader afterwards and defended if challenged. Systems that treat it as a calculation get the first part right and fail the rest.
Risk as a workflow
- 01
Rule design
Define drawdown model, daily loss, maximum loss, consistency, minimum trading days, scaling and payout eligibility as configuration against a plan rather than as bespoke code per firm.
- 02
Account monitoring
Evaluate live account state continuously — equity, realised and unrealised P&L, open exposure — against the rules that apply to that specific account.
- 03
Breach workflow
When a rule fires, record what fired, against which state, at what time, and what enforcement followed. The breach becomes a record, not an inference.
- 04
Operator controls
Give operators the ability to review, override with attribution, reset, scale or archive, with each action retained as evidence.
- 05
Lifecycle context
Feed the outcome back into the account lifecycle so payout eligibility, program state and communications all follow from the same decision.
Why authority has to be singular
If the trading platform and the back office each compute drawdown, they will eventually disagree — different tick, different rounding, different moment. The trader sees one number and the firm acts on another, and no amount of reconciliation makes that feel fair.
Nexus resolves rules against one record so enforcement and explanation cannot diverge. This is the single most useful thing to test in a vendor evaluation, and the evaluation matrix includes the specific questions that expose whether a vendor actually has it.
What to specify when designing a program
| Dimension | What it controls | Common failure when it is vague |
|---|---|---|
| Drawdown model | Whether the limit trails equity, balance or a static threshold | Traders and operators describe the same account differently |
| Daily loss | The intraday boundary and the moment it resets | Reset timing disputes across time zones |
| Consistency | How concentrated profit may be across days or trades | Rule is enforced but cannot be explained afterwards |
| Minimum days | What counts as a trading day | A day with one small fill is contested |
| Scaling | How limits change as a funded account grows | Manual adjustments drift from the documented policy |
| Payout eligibility | Which conditions gate a withdrawal | Eligibility is decided case by case rather than by rule |
Keep reading
Back to hub
Platform
One platform connecting the branded trader experience with CRM, risk, fraud prevention, payouts and support so every team works from the same account context.
ReadRelated
Nexus Connect
Explore Nexus Connect: a white-label platform with advanced charts, simulated order execution and connected risk controls for funding evaluation programs.
ReadRelated
Risk authority
Which system decides a breach, why that authority must be single and auditable, and what goes wrong when risk logic is split across trading and CRM.
ReadNext step
Contact
Talk with Nexus about launching, migrating or building a funded-trader platform, and get a scoped view of deployment, integrations and operating support.
ReadReview your risk architecture with Nexus.
Bring your current rule set and the disputes it has produced. That is the fastest way to find where authority is actually split.