Risk guide
Risk authority: one system has to decide.
Key takeaways
- Split risk authority guarantees eventual disagreement, and the trader sees it before the firm does.
- A breach should be a record — what fired, against what state, when — not a value recomputed on demand.
- If answering 'why did this account fail' requires an engineer, authority is not where you think it is.
How authority gets split without anyone deciding to
Rarely by design. A firm starts with a trading vendor that enforces basic limits, then adds a CRM that needs to know evaluation state, so it computes it. Then payout eligibility needs a drawdown figure, so that gets computed somewhere else too.
Nobody chose to have three risk engines. But now a trader can see a breach in one place, a different number in another, and a payout decision made against a third — and every dispute becomes an investigation.
What singular authority actually requires
One system evaluates rules against one account record and writes the outcome. Everything else — the trading interface, the dashboard, the CRM, payout review, support — reads that outcome rather than deriving its own.
That is a stronger claim than 'the systems are integrated'. Integration synchronises copies; authority removes them.
Symptoms of split authority
The reconciliation job
A scheduled process exists to make two systems agree about account state. Its existence is the diagnosis.
The trader knew first
Traders report discrepancies before monitoring does, because they are watching one number closely and you are watching an aggregate.
Disputes need engineers
Explaining a breach requires someone to query several systems and assemble a narrative, rather than reading a record.
The spreadsheet
Payout review happens partly in a spreadsheet because no system holds everything the reviewer needs.
How to test your own stack
- Name the single system authoritative for evaluation state — if two are named, authority is split
- Pick a historical breach and reconstruct it from a record, timing how long it takes
- Check whether payout eligibility reads the risk engine's output or recomputes it
- Look for reconciliation jobs between trading and back office
- Ask support how often they escalate 'why did this fail' to engineering
Keep reading
Back to hub
Risk & operations
Guides on evaluation rule design, risk authority, payout operations and support workflows for firms running funded-trader programs at scale.
ReadRelated
Evaluation requirements
The trading platform requirements a funding evaluation program creates, from account-aware controls and rule enforcement to the evidence a breach needs.
ReadRelated
Payout operations
Designing payout operations traders trust: eligibility rules, review queues, fraud checks, evidence retention and the controls auditors expect to see.
ReadNext step
Risk management
Configure evaluation rules, monitor account state in real time, review breaches and keep every risk decision connected to the underlying account record.
ReadReview where your authority actually sits.
Bring your hardest historical dispute. It usually maps directly onto the split.