Exchange Conformance Testing And Certification

Before a new trading system is allowed to send live orders to an exchange, the exchange requires it to pass conformance testing — a scripted certification process run against the exchange's test environment, confirming the system correctly implements that exchange's specific message formats, order types, and error handling rather than just a generic version of the protocol. Two exchanges both "supporting FIX" can still differ meaningfully in required fields, session-level behavior, and how they reject malformed messages, so passing conformance for one venue says nothing about readiness for another.

A typical conformance suite walks through a fixed script: sending valid new orders and confirming correct acknowledgments, sending orders with invalid fields and confirming the system produces the expected rejection rather than crashing or hanging, testing cancel and replace messages including edge cases like canceling an order that's already partially filled, and verifying the system handles the exchange's specific sequence-number and heartbeat conventions for session recovery after a disconnect. Only after all scripted scenarios pass does the exchange issue certification and allow the connection to go live.

A firm rolling out a new low-latency order gateway to a second exchange can't reuse the certification from its first venue — even if the underlying code is largely shared, the second exchange's specific rejection codes and order-type nuances must be re-verified from scratch through that exchange's own conformance process.