Connecting a venue takes about ninety seconds. Certifying one takes a couple of weeks, and the asymmetry between those two numbers is why desks end up with live mandate flow running through an integration nobody ever tested past the happy path.
Certification is not a due diligence questionnaire and it is not the counterparty credit work, both of which happen elsewhere and answer different questions. It answers one operational question. When this venue misbehaves, and it will, do we find out from our own systems within minutes, or do we find out from a client at the end of the month.
What paper and dry runs actually prove
Start by being clear about what the pre live surfaces do and do not establish, because this is where most onboarding programmes quietly declare victory too early.
The platform carries a paper trading surface and a paper leaderboard alongside the live modules. Paper flow is genuinely useful. It proves your signal plumbing, your position keeper, your sizing logic and your alerting. It proves none of them against this venue, because a paper fill never reaches the venue's matching engine, never encounters its tick rules and never gets rejected by it.
The same applies to route previews. The Smart Routing surface describes its plan step as a dry run preview that places no orders. That is exactly the right design and it certifies the planner, not the counterparty.
So the gauntlet has one hard prerequisite. Real orders, on the firm's own capital, at minimum size, through the same code path that will later carry mandate flow. If your production path differs from your test path in any respect, including which credential it uses, you have certified something other than what you are about to run.
The conformance matrix, and the cell that hurts
Build a matrix with your order types down one side and the outcomes across the top. Accepted and behaved as specified. Rejected with a reason. Accepted and silently transformed.
The third column is the one that causes incidents. A venue that rejects an order type you do not support is a nuisance you find in an afternoon. A venue that accepts your post only order and crosses the spread with it, or accepts a stop limit and manages it as a stop market, has handed you a position you did not ask for at a price you did not choose, and your logs will show a clean acknowledgement.
Work through at minimum market, limit, stop, stop limit, immediate or cancel, fill or kill, post only and reduce only, plus whatever your strategies actually emit. Note that the Trade Alpha feed showed MARKET in the Order column on every visible row at capture. If that is your production reality then your matrix is small today, and it should still be complete, because the day someone enables limit orders is not the day to discover how this venue rounds a price to tick.
For each accepted order, verify three things independently of the acknowledgement message. The order exists at the venue with the parameters you sent. The fill price and quantity match. The fee is what the schedule says it is, on the correct side, in the correct currency.
Rejects and ambiguity, which is the half nobody tests
Every integration is tested on orders that work. The failure states are where the money is, and most of them can be provoked deliberately in an afternoon.
- Insufficient balance. Harmless, and it establishes what the reject looks like.
- Size below the venue minimum, and size or price violating a tick or lot rule.
- Symbol not tradable, suspended, or in an auction or maintenance window.
- Rate limit exceeded. Provoke it once, on purpose, and observe what your retry logic does. A naive retry loop against a rate limit is how a desk gets its credential throttled during the one hour it needed it.
- Authentication failure with a rotated or revoked key.
Then test the case that is not a reject at all, which is ambiguity. Sever the connection mid order and answer one question. Can you determine the true state of that order from the venue itself, rather than inferring it from your own outbound log. If the answer is no, you have a system that will double fill under exactly the conditions where a double fill is most expensive.
Partial fills belong in the same bucket. The Smart Routing route history carries partial as a distinct state alongside pending, open, closed and failed, which is the right modelling. Confirm your own books do the same, and specifically that a partial is never rounded up into a full fill by a downstream position keeper.
Clock accuracy is your problem, not the venue's
If any part of your transaction cost work anchors on timestamps, and it should, then venue clock behaviour is a first class certification item rather than an infrastructure footnote.
Measure two things over the burn in period. The offset between the venue's reported execution timestamp and your own reference clock, and the drift in that offset over days. A stable offset of a few hundred milliseconds is a fact you can correct for. An offset that wanders by seconds is a fact that makes delay attribution meaningless, and you need to know which one you have before you publish a cost report built on it.
Record the finest resolution the venue actually reports, not the resolution its documentation implies. Then record the resolution that survives into your own store, because a stamp that arrives with millisecond precision and lands in a column typed to the minute has lost the thing you were measuring.
Three way reconciliation, run to a count rather than a date
The last gate is reconciliation, and it runs at three levels every day of the burn in period.
- Order level. Every order your system emitted has a terminal state at the venue, and every order the venue has a record of was emitted by your system. Orphans in either direction are a stop.
- Fill level. Every fill on the venue statement appears in your books at the same price, quantity, side, timestamp and fee. Aggregated fills that your system stores as one line must reconcile to the underlying prints.
- Position and cash level. End of day positions and balances tie to the venue, including financing, funding payments where relevant, and any fee rebates.
Sign the venue off on a count of consecutive clean days, not on a calendar date. A date lets a project deadline overrule an unexplained break. A count forces the break to be explained, which is the entire point of running the exercise.
Before the first mandate order, confirm two more things and write down who confirmed them. That the credential is scoped to trading only, verified by attempting a withdrawal with it and recording the refusal rather than trusting the setting. And that you have a rollback that a named person can execute in one action under pressure. The Smart Routing surface describes live and close actions as admin gated server side and mentions a platform kill switch, which tells you the concept exists in the product. What it does not tell you is what your specific stop control is for direct broker flow, and finding that out at three in the morning during an incident is a considerably worse experience than finding it out now.