Per strategy limits are easy to set and easy to defend individually. The problem appears the first time two of them are right at the same moment. Each profile checks its own ceiling, each finds headroom, each fires, and the book ends up somewhere no single limit was ever breached and no single owner did anything wrong. There is nobody to attribute it to, which is precisely why it keeps happening.
Autopilot is built around exactly this structure. Multiple profiles, per source rules, each configured on its own. My overview at the time of writing showed PROFILES 11 and ENABLED 10, with two of the visible ones named for the feeds they follow, along the lines of Follow: NDX MTE 1day and Follow: XAG/USD MTE 4h. That is ten independent consumers of one balance sheet, and no tile on that page reports a book level number, because the module does not know your book limit. You do.
Ten caps do not add up to a limit
Take a desk with a gross exposure ceiling of twenty percent of NAV allocated to automated execution, and ten enabled profiles each capped at four percent. Every profile is comfortably inside its own limit at all times. The sum of the caps is forty percent, which is twice the book limit, and the only thing keeping you inside twenty is that the profiles are not usually full simultaneously.
That is not a limit. It is a bet on correlation, and it is a bet you would not accept if someone described it to you in those words. Worse, it is a bet on the least reliable version of correlation, because the profiles are not independent draws. They run off related signal families, they read the same regime, and momentum sources in particular fire in clusters. The scenario where all ten want capital at once is not the tail. It is the scenario where the strategies are doing what you hired them to do.
State it honestly in the limit document. If the sub limits sum past the book limit, write down by how much and what enforces the difference. If the answer is that in practice they never all fill at once, you have documented a hope rather than a control, which is still more than most desks manage.

The three ways two profiles collide
They are worth separating because they need different controls and they get conflated constantly.
The first is the same instrument on the same side. Two profiles both go long the same name, from different signal sources, within minutes of each other. Gross and net both rise, position level concentration limits are the binding constraint, and this is the collision that pre trade checks catch most easily because it is visible in a single symbol lookup.
The second is the same instrument on opposite sides. One profile is long, another is short, the net position is close to flat, and gross is twice what either intended. Whether this is a problem depends on which limit you care about. For market risk the net is what matters and the desk is fine. For financing, borrow, venue exposure and the operational surface it is the gross that matters and the desk is paying two spreads to hold nothing. This one also produces the most awkward performance conversation, because both profiles will report their own P&L honestly and the book will have paid for a round trip nobody chose.
The third is different instruments driven by the same factor. Two profiles, two symbols, no overlap that any symbol level check will find, and one underlying exposure. Instrument level limits never catch it. The only defence is a limit expressed in factor or sector terms and computed outside the execution layer, which for most desks will be a daily check rather than a pre trade one.
Reservation, not measurement
The failure at the centre of all of this is a timing failure, and it is worth naming precisely, because it explains why adding a book level exposure report does not fix anything. Two profiles read the current book exposure, both see headroom, both decide to act, and both act. The measurement was correct for both of them at the moment it was taken. The state changed between the check and the order.
The fix is to stop treating the limit as a threshold that each strategy tests independently and start treating it as a scarce resource with a balance. A reservation ledger has four properties, and all four are load bearing.
- Reservation happens on intent, not on fill. The limit is consumed the moment a profile decides to send, and released only if the order is rejected, cancelled or expires.
- Reservation is made at the worst case size, not the intended size. If the order can slip, fill larger, or convert at a rate that has moved, reserve the bad version. Releasing unused limit afterwards is trivial. Discovering you under reserved is not.
- Reservations carry a time to live. An abandoned order that holds limit forever will silently shrink the book's capacity, and this failure is quiet enough to run for months.
- The ledger is one place. Two ledgers that reconcile hourly is the same race condition with an extra step.
Netting inside that ledger is a separate decision from netting for reporting. If a short in one profile frees limit for a long in another, you have decided your binding constraint is net market risk, and you should be able to say why the gross constraints do not bind. Netting for limit purposes also does not imply netting for execution. Stopping the two orders from reaching the venue is a far larger project than agreeing they cancel on a risk report, and conflating the two is how a desk ends up believing it has an internal cross when what it has is a spreadsheet.
Allocating a book limit you cannot enforce centrally
Most desks running this kind of setup do not have a single pre trade gate that every automated profile routes through, and building one is a real project. Until it exists, you have three options and only two of them are choices.
Hard allocation means the sub limits sum to no more than the book limit. It never breaches, and it leaves capacity permanently unused, because the profiles that are quiet this month hold limit the busy ones cannot borrow. Across ten strategies that waste is large and invisible, which is why it gets accepted for far too long.
Over allocation with a central gate is the version you want. Sub limits sum to more than the book limit, utilisation is high, and the gate rejects at the boundary. This requires the reservation ledger above and is the thing worth building.
Over allocation without a gate is the third, and it is what most desks have without having decided to. The interim control there is a buffer sized against plausible simultaneous load rather than the theoretical maximum: take the largest number of profiles your own history shows concurrently at their ceiling, add margin for the day the regime turns, and cut the sub limits until that scenario fits. Crude, costly in capacity, honest.
Deciding in advance who gets cut
The last piece is the one that only matters for about ninety seconds a year, which is why it is always missing. When the boundary is hit and two profiles both want the last increment, something has to give, and the rule needs to exist before the moment.
The default rule is last in loses, because it is what an unmodified system does. It is also the rule least connected to anything you believe, rewarding whichever profile runs on the shorter timeframe rather than whichever has the better claim. The alternatives are a documented priority ranking across strategies, or a pro rata cut applied to everyone. Priority ranking is defensible and produces predictable behaviour. Pro rata is fairer and produces partial fills across the board, which some strategies tolerate badly.
Pick one, write it in the limit document alongside the numbers, and pair it with a rehearsed per profile disable path. The reason for that last part is on the screenshot above: the fast controls on the overview are PAUSE ALL and EMERGENCY KILL SWITCH, both of which are book wide. If the only stop you have practised is the global one, then your response to a single strategy breaching is to halt the other nine as well, and you will be explaining that decision to an investment committee that will reasonably ask why the well behaved strategies were switched off.