---
title: "Operations Runbook Generator"
description: "This operations runbook generator answers prompts about your trading system architecture to build a structured OMS runbook covering startup and outage recovery."
canonical: https://www.getswoopr.com/trading-technology/oms-ems-reconciliation/operations-runbook-generator/
source: "Swoopr Investment: https://www.getswoopr.com"
---

## Direct Answer



> An operations runbook generator produces a structured operations runbook, covering OMS startup, intraday reconciliation, break escalation, outage recovery, and end-of-day procedures, from a short questionnaire about your trading system's architecture. It uses only the data you enter. A written runbook turns tribal knowledge about handling an outage or reconciliation break into a repeatable procedure the whole team can follow.





      

# Operations Runbook Generator



Answer a few questions about your trading system architecture and generate a structured operations runbook covering OMS startup, intraday reconciliation, break escalation, outage recovery, and end-of-day procedures. Uses user-entered data only.




![Close-up of a person using a smartphone calculator on a table with documents for financial calculations.](https://www.getswoopr.com/images/hero/trading-technology-oms-ems-reconciliation-operations-runbook-generator.webp)
*Photo by [Tima Miroshnichenko](https://www.pexels.com/@tima-miroshnichenko/) via [Pexels](https://www.pexels.com/photo/a-man-with-wedding-ring-computing-with-a-mobile-app-calculator-6694533/)*







## Tool









Firm / System Name








OMS vendor / type




Proprietary (in-house)


Third-party (e.g. Charles River, Aladdin)


Hybrid (vendor core + in-house extensions)








Primary asset class




US Equities


Global Equities


Fixed Income


Multi-asset


Derivatives / Options








Intraday recon frequency




Continuous (real-time)


Every 30 minutes


Hourly


End-of-day only








Qty break escalation threshold (shares)


Breaks at or above this quantity trigger Tier 2 escalation








MV break escalation threshold ($)


Breaks at or above this market value trigger Tier 2 escalation








OMS high-availability mode




Single instance (no HA)


Active-passive failover


Active-active








Recovery time objective (RTO)




5 minutes


15 minutes


30 minutes


1 hour








Primary broker / custodian name








Regulatory environment




SEC / FINRA (US)


MiFID II (EU)


US + EU


Other / unlicensed











Generate Runbook


Reset









Uses user-entered data only. No data is transmitted or stored.








## How to use this tool



Fill in the configuration fields that describe your trading system: your firm name, OMS type, primary asset class, intraday reconciliation frequency, escalation thresholds, high-availability setup, recovery time objective, broker name, and regulatory environment. Then click "Generate Runbook."



The output is a structured runbook organized into five sections: (1) Pre-market startup checklist, (2) Intraday reconciliation procedures, (3) Break escalation protocols, (4) Outage recovery procedures, and (5) End-of-day closedown checklist. Each section generates context-appropriate steps based on your inputs, for example, an active-passive HA configuration gets failover-specific startup steps that a single-instance configuration omits.



The runbook is intended as a starting framework. Copy it into your firm's documentation system and customize it to match your exact vendor procedures, FIX session identifiers, and operations team contacts.








## Understanding the outputs



The generated runbook uses placeholder values in angle brackets, for example, `[PRIMARY_OMS_HOST]` or `[OPERATIONS_PHONE]`, for configuration items specific to your environment. Replace these with actual values before distributing the runbook to your operations team.

![Vintage control panel with colorful buttons and industrial labels.](https://www.getswoopr.com/images/accent/trading-technology-oms-ems-reconciliation-operations-runbook-generator-accent-1.webp)
*Photo by [Giant Asparagus](https://www.pexels.com/@giantasparagus/) via [Pexels](https://www.pexels.com/photo/close-up-of-vintage-control-panel-with-buttons-35516949/)*



Break escalation thresholds in the runbook are derived from your inputs. The quantity threshold defines the share count at which a break moves from Tier 1 (operations team self-resolves) to Tier 2 (escalation to portfolio management and risk). The market value threshold provides a dollar-based escalation trigger for the same purpose, useful for symbols with high or low per-share prices where quantity alone is misleading.



The regulatory section cites specific rule numbers based on your selected regulatory environment. US firms get SEC Rule 17a-4 retention requirements and CAT reporting timelines. EU firms get the MiFID II Article 50 and RTS 25 clock synchronization requirements, with maximum divergence from UTC of 100μs for high-frequency algorithmic trading, 1ms for other algorithmic trading and 1s for voice trading. Both-environment selection includes requirements from both frameworks.








## Assumptions and limitations



- The runbook is a template framework based on industry-standard OMS operations practices. It is not tailored to any specific vendor's product or a specific firm's regulatory registration.
- Step timing estimates (e.g., "complete within 10 minutes") are approximations based on common industry practice and may not match your system's actual performance.
- The tool does not account for asset-class-specific nuances such as options expiry management, bond settlement date handling, or FX settlement cutoffs. Derivative and fixed-income firms should supplement the output with asset-class-specific procedures.
- Escalation contacts, FIX session identifiers, system hostnames, and phone numbers are placeholders. The tool does not store or transmit any entered data.








## Frequently Asked Questions




### What is a runbook in the context of OMS operations?



A runbook is a set of documented procedures that define what to do in specific operational situations, startup, normal operation, incidents, and shutdown. In OMS operations, a runbook tells the operations team how to start the OMS and verify its state, how to run reconciliation and investigate breaks, how to recover from outages, and how to close down at end-of-day. A good runbook can be executed by any trained operator regardless of whether the primary OMS expert is available.




### What is the difference between Tier 1 and Tier 2 breaks?



Tier 1 breaks are small quantity or price discrepancies that the operations team resolves independently within the current trading day, without escalating to portfolio management or risk. Tier 2 breaks exceed the quantity or market value thresholds you configured and require escalation, the portfolio management team must be informed because the position error may affect active trading decisions, and the risk team must be informed because the unresolved discrepancy represents unquantified exposure.




### Why does the runbook include event-log replay in the outage recovery section?



For OMS systems that use event sourcing (writing each order event to a persistent log before processing it), recovery after an outage means replaying events from the log rather than relying on the in-memory state at the time of the crash. This guarantees that no events are lost and the OMS state is deterministic, the same events always produce the same result. Without event-log replay, fills received during the outage window may be missed, causing position breaks that can persist all day. See the [Deterministic Recovery guide](https://www.getswoopr.com/trading-technology/oms-ems-reconciliation/deterministic-recovery-after-outages/) for full details.




### How often should the runbook be reviewed?



Runbooks should be reviewed at minimum annually and after any material system change, a new broker connection, a new trading strategy type, an OMS version upgrade, or a regulatory change affecting recordkeeping requirements. The review should be conducted by both operations staff (who execute the runbook) and technology staff (who maintain the systems). Runbooks that go unreviewed for more than 18 months often contain obsolete host names, outdated contact information, or missing steps for new system components.




### Can I use this runbook output in a regulated environment?



This tool generates an illustrative framework for educational purposes. Before using any part of it in a regulated trading environment, it must be reviewed and approved by your compliance team, technology staff, and operations management. Regulatory requirements vary by firm type, registration, and jurisdiction. The placeholder citations in the output are accurate as of the tool's knowledge date but should be verified against current regulatory text before inclusion in official procedures.



### What does the generator produce, and what still has to be written by hand?

It produces the structure and the standard procedural content for startup, intraday reconciliation, break escalation, outage recovery, and end-of-day, shaped by the answers given. What it cannot supply is anything specific to a particular environment: hostnames, dashboard locations, named contacts and their escalation order, counterparty support arrangements, and the thresholds an organization has actually agreed. The output is a scaffold that removes the blank page rather than a finished document.

### Is the questionnaire data sent anywhere?

No. The generation runs in the browser on the page itself using only what is entered, and nothing is transmitted or stored between visits. That matters because runbook inputs describe operational architecture, which is information most organizations would not paste into a remote service. It also means the output has to be copied out before leaving the page, since reloading discards both the answers and the generated document.

### How should a generated runbook be validated before it is relied on?

By walking through each procedure against the real system, ideally as an exercise rather than during an incident. The test is whether someone who was not involved in writing it can follow each step and reach the described outcome, which reliably exposes assumed knowledge, missing access, and steps that no longer match the system. Recording the date of the last walkthrough on the document itself makes staleness visible.

### How does a runbook relate to an incident record and a post-incident review?

The runbook says what to do; the incident record captures what was actually done, when, and by whom; the review compares the two. That comparison is the main source of runbook improvements, because the places where the procedure was abandoned or improvised are exactly where it was wrong or incomplete. Treating each incident as an input to the next revision keeps the document connected to how the system actually fails rather than to how it was expected to.










## References



- [Deterministic Recovery After Outages](https://www.getswoopr.com/trading-technology/oms-ems-reconciliation/deterministic-recovery-after-outages/): Event sourcing, log replay, and HA failover concepts the recovery section of this runbook is based on.
- [Intraday Position Reconciliation](https://www.getswoopr.com/trading-technology/oms-ems-reconciliation/intraday-position-reconciliation/): Full guide on reconciliation cycles and break escalation procedures.
- [Audit Trails and Regulatory Recordkeeping](https://www.getswoopr.com/trading-technology/oms-ems-reconciliation/audit-trails-and-regulatory-recordkeeping-concepts/): SEC, MiFID II, CAT, and CFTC requirements cited in the regulatory section of the runbook.








## Disclaimer



This tool generates an educational template only. It does not constitute compliance, legal, or operational advice. Do not use the output as a production runbook without review by your firm's compliance, technology, and operations teams. Uses user-entered data only, no data is transmitted or stored.






## Related Reading

- [OMS / EMS Architecture & Reconciliation](https://www.getswoopr.com/trading-technology/oms-ems-reconciliation/) the section this guide belongs to
- [Audit Trails and Regulatory Recordkeeping](https://www.getswoopr.com/trading-technology/oms-ems-reconciliation/audit-trails-and-regulatory-recordkeeping-concepts/) a companion guide in this cluster
- [Average Price, Allocations, and Partial Fills](https://www.getswoopr.com/trading-technology/oms-ems-reconciliation/average-price-allocations-and-partial-fills/) a companion guide in this cluster
- [Cash and Buying-Power Reconciliation](https://www.getswoopr.com/trading-technology/oms-ems-reconciliation/cash-and-buying-power-reconciliation/) a companion guide in this cluster
- [Corrections, Busts, and Trade Amendments](https://www.getswoopr.com/trading-technology/oms-ems-reconciliation/corrections-busts-and-trade-amendments/) a companion guide in this cluster
- [Deterministic Recovery After Outages](https://www.getswoopr.com/trading-technology/oms-ems-reconciliation/deterministic-recovery-after-outages/) a companion guide in this cluster
- [End-of-Day Reconciliation and Break Management](https://www.getswoopr.com/trading-technology/oms-ems-reconciliation/end-of-day-reconciliation-and-break-management/) a companion guide in this cluster
- [Intraday Position Reconciliation](https://www.getswoopr.com/trading-technology/oms-ems-reconciliation/intraday-position-reconciliation/) a companion guide in this cluster
- [OMS State Consistency Checker](https://www.getswoopr.com/trading-technology/oms-ems-reconciliation/oms-state-consistency-checker/) a companion guide in this cluster
- [OMS vs. EMS: Responsibilities and Boundaries](https://www.getswoopr.com/trading-technology/oms-ems-reconciliation/oms-vs-ems-responsibilities-and-boundaries/) a companion guide in this cluster
