What you will learn
- Market and order events
- Event ordering
- Clock and latency
- State transitions
Market and order events
An event-driven simulator represents market observations, order requests, acknowledgements and executions as distinct events. Specify which event can change which state. A price update should not silently imply an order fill without applying the fill rules.
Event ordering
Ordering matters when events share a timestamp. Use a deterministic tie-break policy consistent with the available data and state its limitations. Choosing favorable order sequences retrospectively can create artificial performance.
Clock and latency
Decision, submission and arrival times differ. Model latency explicitly where it matters, including uncertainty. A strategy cannot execute before its input is available or before the modeled order could reach the venue.
State transitions
State transitions should be explicit: created, submitted, accepted, partially filled, filled, cancel pending, cancelled or rejected as appropriate. Invalid transitions should fail visibly rather than be repaired by silently inventing an event.
Worked example
A signal uses the closing value at 10:00, but the simulator fills at 09:59:59. That execution precedes the information required to create the signal and violates causality.
Try it yourself
Write an invariant connecting feature availability, decision time, submission and earliest fill time.
Show the worked solution
Require availability no later than decision, decision no later than submission and fill no earlier than the assumed executable arrival. Document any timestamp uncertainty instead of using it to justify a favorable impossible sequence.
Apply this to your course project
Implement or specify a simulator and demonstrate its behavior on adversarial price paths.
Keep the calculation inputs, assumptions and decisions with your work. Practical exercises are self-reviewed; the scored knowledge checks assess the questions shown, not an independent certification of practical competence.