Manual trading comes with a human memory attached to every fill. Somebody placed the order, somebody watched it work, and when the custodian statement says something different, that person has an opinion about which record is wrong. Automated fills arrive without any of that. Nobody remembers the trade, nobody has a view on the price, and a break sits in the file being equally plausible from either side until somebody does the work.
That is the whole difficulty, and it gets worse with volume. A desk running ten enabled profiles across multiple venues is generating fills faster than anyone can hold in their head, which means the reconciliation cannot depend on judgement at the item level. It has to be a rule set that produces a small, well typed break file, and an escalation path that runs on a clock rather than on someone's attention.
Start by assuming the engine disagrees with itself
A useful prior before designing any of this: systems disagree internally more often than people expect, and internal disagreement is the leading indicator of external disagreement.
At the time of writing my own Autopilot overview showed two position counters on the same screen with different values. The summary strip along the top read OPEN POS. 0, and the tile row underneath read OPEN POSITIONS 1. There are innocent explanations, and they are the same ones you will hear about every reconciliation break you ever raise: different scopes, one view filtered while the other spans all profiles, or two refresh cadences caught mid update.
The point is not that something is broken. The point is that "the two numbers mean slightly different things" is exactly what a genuine break also looks like from the outside, and the only way to tell the difference is to have defined in advance what each number is supposed to represent. If you cannot state the definition, you cannot adjudicate the break, and you will end up doing what tired operations teams do, which is deciding that the difference is probably fine.
Two way matching is not enough
The instinct is to compare the execution engine's fills against the custodian and call it done. That misses the failure that costs the most, which is an order that exists at the venue and never made it into your books at all, or a booking that exists in your books with no venue behind it.
Match three ways. The engine's own record, taken from the History tab or the underlying export, is what the strategy believes it did. The order management system or books and records is what the firm believes happened. The custodian and the venue statement is what the outside world says. Each pair tells you something different.
Engine against OMS catches booking failures, dropped messages and mapping errors, and it catches them within hours rather than the next day. OMS against custodian catches settlement, fee and corporate action issues on the standard cycle. Engine against custodian directly, skipping the middle, is the one people leave out and it is the one that catches the fill your OMS never heard about, which is the break that can sit undetected for weeks because both of the other comparisons look clean.
Tolerances have to be numbers with owners
A tolerance expressed as "material differences" is not a control, it is a conversation. Write the numbers down, put a name against each one, and give each a review date. The values below are illustrative of the shape rather than a recommendation for your book, since the right numbers depend on your instruments, your venues and your fee schedule.
- Quantity: zero tolerance. Any difference in shares, contracts or units is a break, full stop, regardless of size. There is no small quantity break, only a small quantity break you have not yet traced to its cause.
- Price: a stated number of basis points against the volume weighted average of the fills, tighter on liquid instruments and wider elsewhere. Compare like with like, which means deciding explicitly whether your reference is the average fill price or the last fill price, because a partially filled order will produce a break every single day if the two sides use different conventions.
- Fees and commissions: the greater of an absolute currency amount and a percentage of the expected fee. Maker and taker schedules, rebates and tiered volume discounts make this the noisiest line on the file, and a percentage only tolerance will drown you in trivial breaks on small orders.
- Timestamps: a stated number of seconds between the engine's decision time and the venue acknowledgement. This is a latency monitor riding along in the same file, and it is worth having because a widening distribution shows up here before it shows up in performance.
- Currency and FX: for anything not booked in base currency, the rate and the rate timestamp both have to match to a stated tolerance. A price break that is really an FX rate break will otherwise be investigated repeatedly by different people.
The break taxonomy, because the type decides the response
Every break should be classified before it is investigated, because the class determines urgency and who owns it. Five types cover almost everything.
Timing. The fill is in both records but booked to different dates, typically around a session boundary or across a venue that runs on a different day convention. These self resolve and should be identified automatically rather than worked by hand, but they need to age out rather than be suppressed, because a timing break that has not resolved by T+2 is not a timing break.
Quantity. Different sizes on the two sides. The most common benign cause is aggregation, where one side rolls up partial fills into a single line and the other lists each child fill separately. The most common serious cause is a partially filled order where a cancel and the remaining fill crossed each other. Serious until proven otherwise.
Price. Usually an averaging convention difference, sometimes a genuine misbooking. Cheap to investigate, and the first thing to check is whether the order had more than one fill.
Fees. Schedule changes, tier thresholds crossing mid month, and fees charged in a currency other than the trade currency. Individually small, and worth tracking in aggregate over the month because systematic fee breaks are usually a stale fee table on your side, which is a quiet cost that compounds.
Existence. A fill on one side with no counterpart on the other. This is the one that stops things. Treat a phantom or missing fill as a potential unmanaged position until proven otherwise, because that is what it functionally is.
An escalation clock the desk can actually run
The process fails when it depends on someone remembering. Put it on a timetable with named roles and a hard action at the end.
The three way match runs automatically before the operations team arrives and produces a typed break file, including a line stating the count of records from each source. That count line matters more than it sounds: the way this control dies is a feed that silently returns zero rows, and a break file that is empty because there was nothing to compare looks identical to a break file that is empty because everything matched.
The named operations owner reviews the file within the first hour and classifies anything the rules could not. By mid morning, any unresolved existence or quantity break escalates to the head of trading, and the associated profile is disabled pending resolution. That last part is the piece with teeth, and it needs to be granular. Disabling one profile is proportionate. Reaching for PAUSE ALL or the EMERGENCY KILL SWITCH on the overview, which act across the whole set, means halting nine strategies that reconciled perfectly, and you will have to justify that to whoever owns their return.
Nothing carries past T+2 without a named owner and a written explanation on the record. Aged breaks are where reconciliation processes go to die, because each individual one is old news and none of them is today's problem.
One last thing worth stating plainly. My overview showed TOTAL TRADES 1 and TODAY 1 at capture, which is a very quiet engine. A reconciliation process designed and tested at one fill a day has not been tested. Before you scale the profiles, generate a realistic day of volume in paper and run the whole chain against it, including the escalation, because the failure you are looking for is the one that only appears when the break file has forty lines instead of none.