Martin Najat
Risk management in a prop firm is not one system. It is four, and founders who buy it as one thing end up with a screen that watches equity curves and nothing that decides anything.
Prop trading risk management, as it actually runs, is a set of decisions with owners attached: what the software decides alone, what a trained reviewer decides with evidence in front of them, and what only a named person signs off. Writing the rules is the easy part. The operating layer around them is what separates a firm that can defend its decisions from one that argues with its traders in public.
What follows is that operating layer: the limits, the escalation tiers, the daily rhythm and the failure modes. If you are still assembling the firm around it, the full launch sequence for prop firm founders puts risk in the order of work.
What prop trading risk management actually covers
Four different jobs sit under the same phrase, and conflating them is how firms end up buying one and assuming they bought all four.
- Rule enforcement. Deciding, automatically, whether an account has breached. It is a software problem with a drafting problem underneath it, and it fails when the rule has two readings.
- Abuse detection. Spotting behaviour that games the evaluation without breaching anything. It is a pattern problem across accounts, and it fails when the system only looks inside one account at a time.
- Exposure management. Knowing what the firm itself is carrying: concentration in one instrument, positions correlated across many funded accounts, what the book looks like when a scheduled release lands and most of your traders are on the same side. It fails when nobody owns the aggregate view.
- Payout integrity. Deciding whether money leaves, and being able to show why. It is a workflow problem with an evidence requirement, and it fails when an override leaves no trace.
Four jobs, four failure modes, and not the same people. A platform with a risk tab usually covers the first. The other three are operating decisions that exist whether or not anybody has been made responsible for them.
Writing limits so software can decide
Every limit is a sentence somebody will argue with. Write it so the argument is settled before it starts.
Take drawdown. Measured against balance or equity. Intraday or at the close. Against the starting balance, a static threshold, or a trailing high that moves as the account grows. Applied to closed positions only, or to floating loss in the seconds before the platform reports it. Each of those is a fork, and every fork you leave open is a reading a trader can defend. Pick one, write it down, and make the platform enforce that exact version rather than an approximation of it.
The same discipline applies to the rules that are harder to phrase. A consistency rule that caps how much of total profit can come from a single day needs to say which day, measured how, and what happens to an account that breaches it after passing. A prohibited strategy clause that says prohibited strategies are not permitted has said nothing. Name the behaviour, describe how it is identified, and state the consequence.
Then test the rulebook before launch. Hand it to somebody who has never traded, give them five borderline cases, and ask them to decide each one using nothing but the document. If they cannot, your software cannot either, and the gap gets filled by whichever support agent is on shift, differently each time.
Numbers in this section are yours to choose. A limit is not better for being tighter. It is better for being unambiguous at the moment it triggers.
Escalation and sign off: who decides what
This is the part almost nobody writes down, and it is the part that decides whether your risk rules survive their first real dispute.
Three tiers. The system decides alone, with no human in the loop, when a hard limit is hit and the evidence is unambiguous: the trigger fires, the account is marked, the data behind it is stored. A trained reviewer decides, with evidence attached, when the question needs judgement: a flagged pattern, a payout held pending a behaviour review, a rule that applies but sits close to the edge. A named person signs off the decisions that cannot be undone or that change the deal: closing a funded account for abuse, overturning a breach in a trader’s favour, changing a rule that funded traders are already trading under.
Two things to be honest about. The default state in a new firm is that the founder decides everything, which works until volume arrives and then becomes the bottleneck that leaves held payouts waiting on one person’s inbox. It is a stage to grow out of deliberately, by writing down which decisions leave your desk first. And an override with no audit trail is the same as no rule at all. If a decision can be reversed without a record of who reversed it and why, the rulebook describes something other than what your firm does.
The matrix below is the artefact worth copying into your own operations document. Fill in the names.
| Decision | Decided by | Evidence required | Where it is recorded |
|---|---|---|---|
| Hard limit breach, daily or overall loss | System, no human in the loop | Equity and position state at the moment of the trigger | Account record, written automatically |
| Soft rule breach, consistency or prohibited strategy | Reviewer, from a queued flag | Trade list, the rule text applied, reviewer’s note | Case record, linked to the account |
| Payout inside policy with no flags | System, no human in the loop | Rule checks passed, KYC current | Payout ledger |
| Payout held pending behaviour review | Reviewer, with a stated reason | Matched trades, timings, device and payment signals | Case record, plus the reason shown to the trader |
| Payout released after a hold | Named person, not the reviewer who held it | Review conclusion and what cleared it | Case record, carrying both names |
| Closing a funded account for abuse | Named person, on a reviewer’s recommendation | Evidence pack, the rule relied on, the trader’s response | Case record, retained for the life of the account |
| Overturning a breach in the trader’s favour | Named person | What the rule said, why it was applied wrongly | Case record, plus a rule change note if the wording caused it |
| Rule wording change | Named person, dated | Old wording, new wording, which accounts it applies to | Rulebook version history |
| Threshold change on a live program | Named person | Reason, expected effect, accounts affected | Program version history |
| KYC rejection or escalation to enhanced checks | Reviewer, against documented criteria | Documents, check results, the criterion applied | Onboarding record |
| Anything promised to a trader in a dispute | Named dispute owner | The ticket, the rule, the decision and its wording | Ticket, and the case record if money moved |
Abuse detection is a daily operation, not a feature
A flag is not a decision. Somebody has to read the evidence, make the call, and then defend that call to a trader who is waiting on money and has read your terms more carefully than you have.
The two rules that generate the most disputes in this industry are one sided betting and margin rules. One sided betting is exposure that can only pay in one direction: hedged positions split across two accounts so one is guaranteed to pass, grid structures that survive on the size of the next position, risk parked ahead of a scheduled release with the offsetting leg somewhere your rules do not look. Margin rules generate disputes because the threshold is ambiguous at the moment of breach and because enforcement lands after the fact, when the trader has already decided what they think happened.
Both share a property that decides how you detect them. Neither is visible inside a single account. A hedge looks like a strategy until you see the second account. A copy cluster looks like coincidence until you see the device. So detection has to compare accounts against each other continuously, across several signal families at once: entry timing, direction, size and instrument matched across the whole book, device and network fingerprints, payment beneficiary reuse, and a behavioural baseline per trader so a change in habit is visible against how that person normally trades. That is what continuous cross account fraud detection has to do to be worth anything.
And the flag has to arrive with its evidence attached. A flag your reviewer cannot defend is a flag nobody will act on, which means the detection was theatre.
The daily and weekly rhythm
Risk management is a rota before it is a philosophy. Here is what a week actually contains.
Every day of the trading week, which runs from Sunday evening to Friday evening: someone watches the book while positions are open, the flag queue gets worked with evidence rather than intuition, the payout window is processed with holds explained rather than silent, KYC checks clear at the speed marketing delivers buyers, and every dispute has a named owner rather than a group chat.
Then the layer almost every firm skips. Weekly, look at which rules produced disputes and whether the wording or the threshold caused them. Look at which flags turned out to be nothing, because a detection system with a high false positive rate trains your own team to dismiss it. Monthly, ask of each limit whether it is still doing the job it was written for, given the book you have now rather than the book you imagined when you launched.
Rules that are never reviewed drift. Not because anybody changed them, but because the traders, the instruments and the volumes around them changed. A limit written for a small cohort of discretionary traders behaves differently once a third of your funded accounts run automated strategies on the same instrument.
The failure modes, named
Every one of these is recoverable early and expensive late. What they have in common is that the cost lands on the trader’s side of the relationship first.
- A rule with two readings. The trader reads it their way, your reviewer reads it yours, and both are defensible. From the trader’s side, this is a firm that changes its mind.
- Enforcement after the fact with nothing stored. The breach is decided days later and the data behind it was never captured. From the trader’s side, this is an accusation without proof.
- Detection inside a single account. Coordinated groups stay invisible while honest traders get flagged for anomalies. From the trader’s side, this is a firm that punishes the wrong people.
- No named owner for disputes. Tickets bounce, answers contradict each other, and the founder arrives last. From the trader’s side, this is being passed around.
- Overrides with no audit trail. The same case gets two outcomes depending on who was on shift. From the trader’s side, this is favouritism, whether or not it is.
- A rulebook changed under pressure mid cohort. New wording lands on traders who passed under the old wording. From the trader’s side, this is the goalposts moving, and it is the one that gets screenshotted.
Who does this work
Rule enforcement is software. The rest is people, and specifically people with trained judgement whose decisions are exercised on your traders in public.
That work needs cover across the trading week rather than an office day, because breaches, payout requests and disputes do not arrive inside one office day in your own time zone. It needs someone who can read a flag and defend the conclusion. It needs a named owner for disputes, and a second name for the decisions that cannot be undone.
Whether you hire that or buy it, price it properly first: the full cost model for an in-house desk against an outsourced one sets out every line on both sides. If you would rather not build the rota, a managed operational team for prop firms covers trader support, withdrawal validation, behaviour review and compliance monitoring with agents trained on prop firm operations.
Whichever way you go, write the escalation matrix before you need it. The firms that handle their first serious abuse case well are the ones who decided who signs off what while nothing was happening. If you want that reviewed against your own rulebook, book a scoping call and bring the rulebook with you.
