Deutsche Boerse HFT Exchange Knowledge Base – Megaprompt

PART 1: THE MEGAPROMPT

Section 1: IDENTITY AND TASK

You are an expert technical writer specializing in exchange technology infrastructure and financial market microstructure. You have deep expertise in Deutsche Boerse Group’s T7 trading platform, network infrastructure, trading protocols (ETI, FIX), market data feeds (EOBI, EMDI, MDI, RDI), clearing systems, and European financial regulation (MiFID II, EMIR, German HFT Act).

Your Task

Generate a complete, professional-grade Deutsche Boerse HFT Exchange Knowledge Base consisting of individual markdown files. This knowledge base serves as reference documentation for quantitative traders, trading system developers, fintech professionals, and researchers studying European market microstructure. It is NOT a tutorial or beginner guide – it is reference-grade technical documentation with every factual claim sourced from official Deutsche Boerse Group publications.

Output Structure

Produce your output in 6 sequential batches. Each batch must contain complete, final files ready for deployment. Do not produce partial files or placeholders.

Batch 1: Configuration and Root Files

  • _config.yml
  • README.md
  • TABLE_OF_CONTENTS.md
  • SOURCES.md
  • CONTRIBUTING.md
  • chapters/index.md
  • chapters/appendix/index.md
  • diagrams/index.md

Batch 2: Chapters 1-7 (including sub-pages)

  • chapters/01-exchange-overview/README.md
  • chapters/02-t7-architecture/README.md
  • chapters/03-network-infrastructure/README.md
  • chapters/04-trading-interfaces/README.md
  • chapters/04-trading-interfaces/eti.md
  • chapters/04-trading-interfaces/fix-gateway.md
  • chapters/05-market-data/README.md
  • chapters/05-market-data/eobi.md
  • chapters/05-market-data/emdi.md
  • chapters/05-market-data/mdi.md
  • chapters/05-market-data/rdi.md
  • chapters/06-order-types-matching/README.md
  • chapters/07-market-models/README.md

Batch 3: Chapters 8-12

  • chapters/08-latency-performance/README.md
  • chapters/09-risk-controls/README.md
  • chapters/10-regulatory-framework/README.md
  • chapters/11-simulation-testing/README.md
  • chapters/12-developer-onboarding/README.md

Batch 4: Appendices

  • chapters/appendix/glossary.md
  • chapters/appendix/quick-reference.md
  • chapters/appendix/release-history.md
  • chapters/appendix/pricing-summary.md

Batch 5: Diagrams

  • diagrams/t7-architecture-overview.md
  • diagrams/network-topology.md
  • diagrams/order-flow.md
  • diagrams/market-data-distribution.md
  • diagrams/eti-session-lifecycle.md
  • diagrams/matching-engine-flow.md

Batch 6: Verification Pipeline

  • .github/workflows/daily-verification.yml
  • scripts/verification/run_all.py
  • scripts/verification/check_links.py
  • scripts/verification/check_crossrefs.py
  • scripts/verification/check_facts.py
  • scripts/verification/monitor_circulars.py
  • scripts/verification/generate_report.py
  • scripts/verification/build_registry.py
  • scripts/verification/README.md

Cross-Batch Dependency Handling

Batches 2 and 3 contain forward and backward cross-references between chapters. Follow these rules:

  1. Pre-compute all link targets before generating any batch. The directory structure above is the canonical reference. All relative links use this structure. Do not deviate from the specified directory layout.

  2. Forward references (Batch 2 referencing Batch 3 chapters): Use the exact relative paths specified in the directory structure. Example: a reference from Chapter 4 to Chapter 9 uses ../09-risk-controls/README.md. These paths are deterministic; generate them based on the directory tree, not on previously generated content.

  3. Backward references (Batch 3 referencing Batch 2 chapters): Same rule. Use deterministic paths from the directory tree.

  4. Glossary references: All chapters may reference glossary terms. Use the path ../appendix/glossary.md#term-anchor where the anchor is the lowercase, hyphenated term heading. The glossary is generated in Batch 4; anchors are deterministic from the term list in Section 6.

  5. Consistency checkpoint: After generating each batch, verify that every cross-reference link target matches an entry in the directory tree above.

Quality Standard

  • Professional reference documentation, not tutorial
  • Every factual claim must have an inline citation from approved domains only
  • Technical accuracy is paramount: latency figures in microseconds, pricing in EUR, protocol details must be exact
  • Consistent terminology throughout (e.g., always “Matching Engine” not “matching engine” vs “match engine”)
  • Cross-references between chapters using relative markdown links
  • Mermaid diagrams must render correctly in GitHub Pages with just-the-docs theme

Section 2: SOURCE POLICY (HARD CONSTRAINT)

Approved Source Domains

Only the following 7 domains may be cited as sources. No exceptions.

  1. deutsche-boerse.com (including all subdomains: www.deutsche-boerse.com)
  2. eurex.com (including all subdomains: www.eurex.com)
  3. eurexchange.com (including all subdomains: www.eurexchange.com)
  4. xetra.com (including all subdomains: www.xetra.com)
  5. cashmarket.deutsche-boerse.com
  6. developer.deutsche-boerse.com (including docs.developer.deutsche-boerse.com, console.developer.deutsche-boerse.com)
  7. mds.deutsche-boerse.com

Citation Format

Every factual claim (metrics, dates, prices, technical specifications, regulatory details) must include an inline citation in this exact format:

*(Source: [Display Name](URL))*

Example:

The median latency for order request to response via PS gateways measures less than 55 microseconds.
*(Source: [T7 Trading Architecture](https://www.xetra.com/xetra-en/technology/t7))*

Hard Rules

  1. No third-party sources: No Wikipedia, no blogs, no news articles, no academic papers, no competitor exchange documentation, no financial data vendor sites.
  2. No unsourced factual claims: Every specific number, date, price, or technical specification must have a citation. General architectural descriptions may omit citations if they are self-evident from context.
  3. No FIX Trading Community citations: While ETI has FIX semantics, the FIX protocol standard itself is documented by FIX Trading Community (fixtrading.org). Do not cite fixtrading.org. Instead cite Deutsche Boerse’s own documentation of their FIX support.
  4. Violation of this policy invalidates the entire output. If you cannot find a Deutsche Boerse source for a claim, either omit the claim or note it explicitly as requiring verification.

Citation Decision Rules

Not every sentence requires a citation. Apply this decision tree:

REQUIRES citation (inline source link):

  • Any specific number: latency (us, ns), pricing (EUR), counts (sessions, partitions, participants), percentages, dates
  • Any claim about system behavior that could be different (e.g., “FIFO processing” – this is a design choice, not self-evident)
  • Any claim about regulatory requirements (effective dates, article numbers, thresholds)
  • Any claim about capacity or limits (TPS, daily volume, message rates)

Does NOT require citation (general architecture):

  • Definitions of industry-standard concepts (e.g., “A matching engine executes buy and sell orders”)
  • Logical deductions from cited facts (e.g., “This means participants need co-location to achieve these latencies” following a cited latency figure)
  • Structural descriptions of the document itself (e.g., “This chapter covers…”)
  • Descriptions of how cited components relate to each other, when the relationship is self-evident from the component descriptions

BORDERLINE – cite if available, omit citation with qualifier if not:

  • General behavioral descriptions of Deutsche Boerse-specific systems (e.g., “T7 uses in-memory order books” – cite if the Architecture Factsheet states this, otherwise write “T7 uses in-memory order books by design” without citation)

Never fabricate a citation. If you cannot source a claim, either omit the claim or mark it: [NEEDS VERIFICATION -- no source in approved domains].

Section 3: DIRECTORY STRUCTURE

Complete File Tree 

hft-exchange-knowledge/
├── _config.yml
├── README.md
├── TABLE_OF_CONTENTS.md
├── SOURCES.md
├── CONTRIBUTING.md
├── LICENSE
├── chapters/
│   ├── index.md
│   ├── 01-exchange-overview/
│   │   └── README.md
│   ├── 02-t7-architecture/
│   │   └── README.md
│   ├── 03-network-infrastructure/
│   │   └── README.md
│   ├── 04-trading-interfaces/
│   │   ├── README.md
│   │   ├── eti.md
│   │   └── fix-gateway.md
│   ├── 05-market-data/
│   │   ├── README.md
│   │   ├── eobi.md
│   │   ├── emdi.md
│   │   ├── mdi.md
│   │   └── rdi.md
│   ├── 06-order-types-matching/
│   │   └── README.md
│   ├── 07-market-models/
│   │   └── README.md
│   ├── 08-latency-performance/
│   │   └── README.md
│   ├── 09-risk-controls/
│   │   └── README.md
│   ├── 10-regulatory-framework/
│   │   └── README.md
│   ├── 11-simulation-testing/
│   │   └── README.md
│   ├── 12-developer-onboarding/
│   │   └── README.md
│   └── appendix/
│       ├── index.md
│       ├── glossary.md
│       ├── quick-reference.md
│       ├── release-history.md
│       └── pricing-summary.md
├── diagrams/
│   ├── index.md
│   ├── t7-architecture-overview.md
│   ├── network-topology.md
│   ├── order-flow.md
│   ├── market-data-distribution.md
│   ├── eti-session-lifecycle.md
│   └── matching-engine-flow.md
├── .github/
│   └── workflows/
│       └── daily-verification.yml
└── scripts/
    └── verification/
        ├── run_all.py
        ├── check_links.py
        ├── check_crossrefs.py
        ├── check_facts.py
        ├── monitor_circulars.py
        ├── generate_report.py
        ├── build_registry.py
        └── README.md

Front Matter Patterns

Root-level pages (README.md, TABLE_OF_CONTENTS.md, SOURCES.md, CONTRIBUTING.md):

---
layout: default
title: "<Page Title>"
nav_order: <N>
permalink: /  # Only for README.md (Home)
---

nav_order values for root pages:

  • README.md (Home): nav_order: 0, permalink: /
  • TABLE_OF_CONTENTS.md: nav_order: 1
  • SOURCES.md: nav_order: 50
  • CONTRIBUTING.md: nav_order: 51

Category index pages (chapters/index.md, chapters/appendix/index.md, diagrams/index.md):

---
layout: default
title: <Category>
nav_order: <N>
has_children: true
---

nav_order for category indexes:

  • chapters/index.md: nav_order: 2, title: “Chapters”
  • chapters/appendix/index.md: nav_order: 3, title: “Appendices”
  • diagrams/index.md: nav_order: 4, title: “Diagrams”

Chapter pages (direct children of chapters/):

---
layout: default
title: "<N>. <Short Title>"
nav_order: <N>
parent: Chapters
---

For chapters with sub-pages (04, 05), add has_children: true.

Sub-pages (e.g., eti.md, fix-gateway.md, eobi.md):

---
layout: default
title: "<Sub-page Title>"
nav_order: <N within parent>
parent: "<Parent title exactly as written>"
grand_parent: Chapters
---

Appendix pages:

---
layout: default
title: "<Appendix Title>"
nav_order: <N>
parent: Appendices
---

Diagram pages:

---
layout: default
title: "<Diagram Title>"
nav_order: <N>
parent: Diagrams
---

Section 4: JEKYLL CONFIGURATION

The _config.yml file must contain exactly this content:

# Theme
remote_theme: just-the-docs/just-the-docs@v0.10.1

title: "Deutsche Boerse HFT Exchange Knowledge Base"
description: "Comprehensive tutorial on T7 trading platform architecture, network infrastructure, trading interfaces, market data feeds, and more"

# Markdown
markdown: kramdown
kramdown:
  input: GFM
  syntax_highlighter: rouge

# just-the-docs configuration
color_scheme: light

# Search
search_enabled: true
search:
  button: true

# Aux links (top-right corner of top bar)
aux_links:
  "View on GitHub":
    - "https://github.com/Digital-AI-Finance/hft-exchange-knowledge"

aux_links_new_tab: true

# Footer
footer_content: "This work is licensed under <a href=\"https://creativecommons.org/licenses/by-sa/4.0/\">CC BY-SA 4.0</a>. All content sourced exclusively from official Deutsche Boerse Group publications."

# Mermaid diagram rendering (required -- all 6 diagram files use Mermaid syntax)
mermaid:
  version: "11"

# Back to top link
back_to_top: true
back_to_top_text: "Back to top"

# Heading anchor links
heading_anchors: true

# External navigation links (optional, in top bar)
nav_external_links:
  - title: Eurex
    url: https://www.eurex.com
    opens_in_new_tab: true
  - title: Xetra
    url: https://www.xetra.com
    opens_in_new_tab: true

# Plugins (jekyll-relative-links converts .md links to .html; not bundled with just-the-docs)
plugins:
  - jekyll-relative-links

# Exclude non-content directories from Jekyll processing
exclude:
  - scripts/
  - reports/
  - .omc/
  - node_modules/
  - vendor/
  - "*.py"
  - requirements.txt

Mermaid Version Lock

The mermaid: version: "11" in _config.yml pins the Mermaid rendering version. Add to CONTRIBUTING.md:

Mermaid version: This repository pins Mermaid to version 11. Do not upgrade without testing all 6 diagrams for rendering correctness. When just-the-docs updates its Mermaid dependency, verify diagrams render identically before merging the theme update. Use npx @mermaid-js/mermaid- cli render locally to preview diagrams before committing changes.

The generated diagrams use only features stable since Mermaid 10: subgraph nesting, classDef, style directives, and sequenceDiagram/stateDiagram-v2.

Section 5: CHAPTER SPECIFICATIONS

Chapter 1: Deutsche Boerse Exchange Overview

File: chapters/01-exchange-overview/README.md

Front matter:

---
layout: default
title: "1. Exchange Overview"
nav_order: 1
parent: Chapters
---

Required H2/H3 headings:

  • Introduction
  • Corporate Structure
    • Key Subsidiaries and Business Units (FWB, Eurex Frankfurt AG, Eurex Clearing AG, Clearstream, EEX Group, 360T, Qontigo and ISS STOXX, SimCorp)
  • Business Segments
      1. Investment Management Solutions
      1. Trading & Clearing
      1. Fund Services
      1. Securities Services
  • The 7 Market Technology Suite
  • Trading Venues
    • Xetra
    • Eurex
    • EEX (European Energy Exchange)
  • Historical Context
    • Xetra Launch and IBIS Transition
    • Eurex Ownership Evolution
    • Clearstream Acquisition
  • Organizational Structure (with Mermaid diagram)
  • Regulatory Framework
  • Technology and Market Access
  • Conclusion

Required key facts and metrics:

  • FWB commands approximately 90% of German equity market share
  • Eurex became fully owned by Deutsche Boerse in January 2012
  • Clearstream fully owned since July 2002
  • EEX has over 850 trading participants
  • Xetra launched November 28, 1997, replacing IBIS
  • Xetra: ~90% market share German equities, ~60% DAX components
  • January 2026 Xetra equity turnover: EUR 121 billion
  • Full year 2025 ETF/ETP trading on Xetra: EUR 352.4 billion (52.7% YoY increase)
  • Xetra market capitalization: approximately EUR 2.6 trillion
  • T7 powers exchanges in Budapest, Ljubljana, Malta, Prague, Sofia, Vienna, Zagreb
  • The “7 Suite”: T7, C7, N7, M7, F7, A7, D7
  • Xetra market segments: Regulated Market (Prime Standard, General Standard), Open Market (Scale, Basic Board)
  • Xetra lists shares from more than 60 countries
  • Eurex product classes: Fixed Income Derivatives, Equity and Index Derivatives, Interest Rate Derivatives, Volatility Products, FX Derivatives, Commodity Derivatives

Required source URLs:

  • https://www.xetra.com
  • https://www.eurex.com
  • https://www.deutsche-boerse.com
  • https://www.xetra.com/xetra-en/technology/t7

Required Mermaid diagram (VERBATIM from source):

graph TD
    A[Deutsche Börse AG<br/>Parent Holding Company<br/>Frankfurt/Eschborn] --> B[Trading & Clearing]
    A --> C[Securities Services]
    A --> D[Fund Services]
    A --> E[Investment Management Solutions]

    B --> B1[Eurex Frankfurt AG<br/>Derivatives Trading]
    B --> B2[Xetra / FWB<br/>Cash Equities]
    B --> B3[EEX Group<br/>Commodities & Energy]
    B --> B4[360T<br/>FX Trading]

    B1 --> B1A[Eurex Clearing AG<br/>CCP Services]

    C --> C1[Clearstream<br/>Luxembourg]
    C --> C2[Custody & Settlement]

    D --> D1[Clearstream Fund Services]

    E --> E1[SimCorp<br/>Investment Management Software]
    E --> E2[Qontigo/ISS STOXX<br/>Indices & Analytics]
    E --> E3[STOXX & DAX Indices]

    style A fill:#003d7a,color:#fff
    style B fill:#0066b3,color:#fff
    style C fill:#0066b3,color:#fff
    style D fill:#0066b3,color:#fff
    style E fill:#0066b3,color:#fff

Per-section content requirements:

  • Introduction: Position Deutsche Boerse within global exchange landscape. State purpose of chapter.
  • Corporate Structure > FWB: Explain Frankfurter Wertpapierborse, 90% German equity market share. Cite Xetra.
  • Corporate Structure > Eurex Frankfurt AG: Wholly-owned subsidiary since January 2012. Previously joint venture with SIX Swiss Exchange.
  • Corporate Structure > Eurex Clearing AG: Wholly-owned subsidiary of Eurex Frankfurt AG. CCP clearing services.
  • Corporate Structure > Clearstream: Based in Luxembourg. Fully owned since July 2002. Post-trade services.
  • Corporate Structure > EEX Group: Over 850 trading participants. Power, gas, environmental, freight, agricultural.
  • Corporate Structure > 360T: Global FX trading platform. Spot, forward, swap, options.
  • Corporate Structure > Qontigo/ISS STOXX: STOXX and DAX index families. ESG solutions.
  • Corporate Structure > SimCorp: Investment management software.
  • Business Segments: Four segments: Investment Management Solutions (SimCorp, Axioma, ISS STOXX), Trading & Clearing (Eurex, EEX, Xetra, 360T, Eurex Clearing), Fund Services (Clearstream), Securities Services (Clearstream).
  • The 7 Suite: List all 7: T7 (trading), C7 (clearing), N7 (network), M7 (alternative trading), F7 (specialized markets), A7 (analytics), D7 (digital post-trade). T7 powers exchanges in Budapest, Ljubljana, Malta, Prague, Sofia, Vienna, Zagreb.
  • Xetra: Launched November 28 1997, replaced IBIS. Regulated Market (Prime Standard, General Standard), Open Market (Scale, Basic Board). Lists shares from 60+ countries. 90% German equities, 60% DAX. Jan 2026 turnover EUR 121B. 2025 ETF/ETP EUR 352.4B (+52.7% YoY). Market cap ~EUR 2.6T. Europe’s largest ETF exchange.
  • Eurex: Product classes with specific examples (Euro-Bund, Euro-Bobl, Euro-Schatz futures; STOXX 50; DAX; EURIBOR; VSTOXX).
  • EEX: Power, gas, environmental, freight, agricultural. 850+ participants.
  • Historical Context: Xetra Nov 28 1997 replacing IBIS. Eurex full ownership Jan 2012. Clearstream July 2002.
  • Organizational Structure: Include the Mermaid graph TD organizational chart verbatim from source.
  • Technology and Market Access: ETI, FIX, proximity hosting, N7 network. Brief overview pointing to later chapters.

Target word count: 2,500-3,500 words

Chapter 2: T7 Trading System Architecture

File: chapters/02-t7-architecture/README.md

Front matter:

---
layout: default
title: "2. T7 Architecture"
nav_order: 2
parent: Chapters
---

Required H2/H3 headings:

  • Introduction
  • T7 Platform Overview
    • Global Deployment and Multi-Asset Support
    • Current Release Status
  • Core Components
    • Matching Engine
    • Gateway Layer (PS Gateways, LF Gateways, FIX Gateways)
    • Market Data Engine
    • Persistence Layer
    • Risk Engine
  • Partition Model
    • Partitions as Failure Domains
    • Product Assignment Hierarchy
    • Production and Simulation Partition Expansion
    • Dynamic Product Distribution
    • High-Frequency Session Implications
  • Processing Model
    • FIFO Order Processing
    • No Batching at Matching Engine
    • Deterministic Processing
    • CoLo 2.0 Infrastructure
    • Public Data First Principle
  • Session Types
    • High Frequency (HF) Sessions (Light, Full)
    • Low Frequency (LF) Sessions
    • Back Office Sessions
  • Failover and Redundancy
    • Geographic Redundancy
    • Side A and Side B Redundancy
    • Redundancy Link
    • ServiceAvailabilityBroadcast
    • Market Reset Process
    • FIX Session Failover
  • Capacity Specifications
    • Daily Transaction Capacity
    • Peak Message Rate
    • Order Request/Response Latency
    • Order to Market Data Latency
    • Minimum Reaction Time
  • T7 Release History (table)
  • Conclusion

Required key facts and metrics:

  • T7 Release 14.0 launched November 10, 2025
  • T7 Release 14.1 scheduled May 18, 2026
  • PS Gateways introduced Q1 2018
  • PS gateways consolidated with MEs on same server H1 2021
  • LF gateways historically added ~75 microseconds; now ~12 microseconds same-side, ~1 microsecond cross-side (as of January 2025)
  • FIX Gateway support since March 2021 (Release 10.0)
  • “Public data first” principle: market data published before execution reports
  • EMDI integrated into ME process since Release 12.0
  • Originally 10 partitions; expanded to 11 in February 2022; simulation expanded 5 to 6 partitions in February 2024
  • HF Light: 50 TPS, EUR 250/month; HF Full: 150 TPS, EUR 500/month
  • Room A (active) / Room B (backup) geographic redundancy
  • Market Reset sequence: TradingSessionEvent 102, ExtendedOrderInformation, TradingSessionEvent 103
  • Over 320 million transactions per day capacity
  • Peak message rate June 2024: 201,000 messages/second (Eurex 118K, Xetra 92K)
  • Median order-to-response latency: <55 microseconds
  • Order-to-market-data latency: <40 microseconds
  • Minimum reaction time: 2,787 nanoseconds (~2.8 microseconds)
  • 10GbE co-location connections
  • Release history table: 10.0 (March 2021) through 14.1 (May 2026 planned)

Required source URLs:

  • https://www.xetra.com/xetra-en/technology/t7
  • https://www.eurex.com
  • https://www.deutsche-boerse.com

Per-section content requirements:

  • Global Deployment: T7 powers Eurex, Xetra, EEX, Nodal Exchange (North America). Also Budapest, Ljubljana, Malta, Prague, Sofia, Vienna, Zagreb.
  • Current Release: Release 14.0 launched November 10, 2025. Features: Extended Retail Trading, SMP enhancements, T7 Clearer Web GUI. Release 14.1 planned May 18, 2026 with ~6 month release cadence.
  • Matching Engine: In-memory, non-persistent by default. PS Gateway consolidation H1 2021 eliminated inter-server hops. No batching. FIFO processing. Deterministic.
  • PS Gateways: Introduced Q1 2018. One-to-one partition mapping. Co-located with ME since H1 2021: this consolidation eliminated the inter-process communication (IPC) layer between separate PS gateway and ME processes that previously ran on different physical servers. After consolidation, the PS gateway and ME share the same NUMA domain within a single server, avoiding cross-socket memory access. The latency improvement (~5-8 microseconds) came from eliminating IPC overhead, not merely from physical proximity. Do not describe this as simply “moving two servers together” – emphasize the IPC elimination as the mechanism.
  • LF Gateways: Multi-partition access via single session. Historical overhead ~75 us. As of January 2025: ~12 us same-side, ~1 us cross-side. Critical terminology (do not conflate with “cross-partition”):
    • “Same-side” = order enters from the same network side (A or B) as the target partition’s primary PS gateway. The order stays within one side’s internal network.
    • “Cross-side” = order must traverse the redundancy link between Side A and Side B to reach the target partition, adding the link traversal latency.
    • “Cross-partition” is a different concept: it means accessing an instrument on a different partition via the LF gateway’s multi-partition routing. Cross-partition access may be same-side or cross-side depending on network topology. Do not describe “cross-side” as “cross-partition.” They are independent dimensions.
  • FIX Gateways: Since March 2021 (Release 10.0). Routes via PS gateways. Protocol translation FIX to ETI.
  • Market Data Engine: Generates EOBI, EMDI, MDI, RDI. “Public data first” principle (see Ch8 for distinction between principle and measured timing). Since Release 12.0, EOBI and EMDI serialization code runs within the same OS process as the matching engine, sharing the same address space. This eliminated the separate Market Data Distributor (MDD) process that previously received matching events via IPC/shared memory and serialized them into EOBI/EMDI format. The ~4 us latency reduction came from eliminating IPC overhead. Important distinction: the serialization step moved into the ME process, but EOBI multicast and ETI TCP responses exit through different NIC queues with different kernel scheduling. EOBI serialization happens first within the ME process; both then exit via separate network paths.
  • Persistence Layer: Non-persistent (default, in-memory) vs persistent (GTC/GTD, written to storage, survive Market Reset).
  • Risk Engine: MOV, ARP, PTR limits (Release 13.1). Microsecond-level overhead.
  • Partition Model: Independent failure domains. 3-level hierarchy (Product Assignment Groups, Products, Instruments). Dynamic product redistribution. Partition counts differ by market (do not conflate):
    • Eurex: Originally 10 production partitions, expanded to 11 in February
      1. Simulation expanded from 5 to 6 partitions in February 2024.
    • Xetra: Operates with 2 partitions – Partition 1 for German equities, Partition 55 for non-German equities (added February 16, 2024, also reflected in simulation as P55). Do not state “11 partitions” as if all serve both Eurex and Xetra equally. Eurex has 11; Xetra has 2. The partition numbers are distinct.
  • Processing Model: FIFO, no batching, deterministic. CoLo 2.0 with 10GbE. Public data first.
  • Session Types: HF Light 50 TPS EUR 250/mo, HF Full 150 TPS EUR 500/mo. Co-location via 10GbE required. LF sessions for multi-partition. Back Office for admin.
  • Failover: Room A (active) / Room B (backup). Side A / Side B. Redundancy link (state sync, emergency backup). ServiceAvailabilityBroadcast. Market Reset sequence: event 102, ExtendedOrderInformation for persistent orders, event 103. No automatic FIX failover.
  • Capacity: 320M+ transactions/day. Peak 201K msg/sec (June 2024): Eurex 118K, Xetra 92K. Median order-to-response <55 us. Order-to-market-data <40 us. Minimum reaction time 2,787 ns.
  • Release History Table: Release 10.0 (March 2021) through 14.1 (May 2026 planned) with dates and key features.

Target word count: 4,000-5,500 words

Chapter 3: Network Infrastructure and Co-Location

File: chapters/03-network-infrastructure/README.md

Front matter:

---
layout: default
title: "3. Network Infrastructure"
nav_order: 3
parent: Chapters
---

Required H2/H3 headings:

  • Introduction
  • Co-Location Facility (Equinix FR2 Frankfurt)
    • Strategic Partnership with Equinix
    • Purpose and Benefits
  • Network Architecture
    • Separation of Transaction and Market Data Networks
    • No Single Point of Failure Design
    • 10 Gigabit Latency-Optimized Network
    • Distinct Physical Pathways for Eurex and Xetra
  • CoLo 2.0 Connection Pricing
    • Xetra Market Data Feeds (EMDI: EUR 6,000/mo; EOBI: EUR 7,200/mo; Combined: EUR 8,400/mo)
    • Xetra Transaction Connectivity (ETI: EUR 6,000/mo)
  • Network Segments
    • Trading Network (ETI) – TLS 1.3, PS/LF gateways
    • Market Data Networks (EOBI, EMDI, MDI, RDI with protocols and transport)
    • GUI Network
    • Back-Office Network
  • Connection Types
    • Co-Location (10GbE)
    • Leased Lines (7 Mbit/s, 80 Mbit/s, 200 Mbit/s)
    • iAccess (VPN via IPSec)
  • PTP Time Synchronization
    • Standard PTP (IEEE 1588, ±50 ns, EUR 400/mo)
    • White Rabbit Protocol (<1 ns, sub-nanosecond)
    • GPS Antenna Roof Space (EUR 850/mo)
  • High Precision Timestamps (HPT)
    • Capture Point and Precision
    • HPT Executions
    • HPT All
    • Delivery Format and Schedule (CSV, T+1)
    • Availability
  • Rack Space Pricing (Equinix FR2)
    • 3 kVA: EUR 2,330/mo; 4 kVA: EUR 2,870/mo; 5 kVA: EUR 3,390/mo; 6 kVA: EUR 3,910/mo
    • Cross-Connect Pricing: EUR 150/mo per connection
  • Disaster Recovery
  • Contact Information
  • Conclusion

Required source URLs:

  • https://www.deutsche-boerse.com
  • https://www.xetra.com/xetra-en/technology/co-location-services

Per-section content requirements:

  • Equinix FR2: Address Rebstocker Strasse 33, 60326 Frankfurt. Primary hosting for T7 matching engines. Strategic partnership with Equinix since 2010. Carrier-neutral facility enabling competitive network service provider selection.
  • Purpose and Benefits: Minimize network latency for algorithmic trading. Sub-microsecond network latency to MEs. 10GbE bandwidth. Direct physical proximity. Essential for market making, statistical arbitrage, liquidity provision.
  • Network Architecture: Strict separation of transaction and market data networks (performance isolation, security segmentation, fault isolation). Physically separate switches, routers, NICs. No single point of failure: dual physical paths, Side A/B, Room A/B. 10GbE latency-optimized links for orders and market data. Distinct physical pathways for Eurex and Xetra.
  • CoLo 2.0 Pricing: Xetra EMDI EUR 6,000/mo, EOBI EUR 7,200/mo, combined EUR 8,400/mo, ETI EUR 6,000/mo. All 10GbE. Fees cover network connectivity only (not rack space, power, cross-connects).
  • Network Segments: Trading Network (ETI): TCP/IP with TLS 1.3, PS gateways (ultra-low latency, partition-dedicated), LF gateways (multi-partition). Market Data Networks: EOBI (native binary, UDP multicast, live-live A/B, for HFT), EMDI (FIX 5.0 SP2 with FAST, UDP multicast, live-live A/B, for Xetra), MDI (FIX/FAST, UDP multicast or TCP, for non-HFT), RDI (FIX/FAST, UDP multicast, for reference data). GUI Network (HTTPS, Eurex Trader GUI, T7 Web Apps). Back-Office Network (account management, trade reporting, drop copy, risk config, separate from production).
  • Connection Types: Co-Location 10GbE (sub-microsecond latency, deterministic, requires rack space at FR2). Leased Lines (7 Mbit/s standard, 80/200 Mbit/s enhanced, dual lines from different providers for HA, several milliseconds latency, unsuitable for HFT). iAccess VPN via IPSec (lower cost, rapid provisioning, variable latency, suitable for simulation/testing/DR/back-office, standard IPSec protocols).
  • PTP Time Sync: Standard PTP IEEE 1588: sub-microsecond accuracy, ±50 ns best-case, 1 Gbps SMF cross-connect, EUR 400/mo. White Rabbit: <1 ns sub-nanosecond, fully deterministic Ethernet, BiDi SFPs, enhanced PLL algorithms, developed at CERN, premium service. GPS Antenna: EUR 850/mo, 10-100 ns, roof-mounted, participant-supplied receivers, independent time source.
  • HPT: Nanosecond-precise timestamps captured at network boundary. HPT Executions: only executed orders (submission + execution + latency). HPT All: all lifecycle events (additions, modifications, deletions, executions). Delivery: CSV format, T+1 basis. Available for Eurex, Xetra, EEX.
  • Rack Space Pricing: 3 kVA EUR 2,330/mo, 4 kVA EUR 2,870/mo, 5 kVA EUR 3,390/mo, 6 kVA EUR 3,910/mo. Includes space, power, cooling, physical security, 24/7 monitoring. Cross-Connect: EUR 150/mo per connection. Typical participant needs 5+ (ETI Side A/B, EMDI Side A/B, PTP).
  • Disaster Recovery: Regular DR tests (March 2025, June 2023). Production MEs in Room A rendered inaccessible, fail over to Room B. Co-located infrastructure remains accessible during DR. Network Operations Team 24/7/365 monitoring with proactive detection, automatic corrective actions, participant notification.
  • Contact: Equinix FR2: Elke Ay (elke.ay@eu.equinix.com, +49 151 61352692). Deutsche Boerse Connectivity Services: accessproducts@deutsche-boerse.com, +49 69 21111690.

Target word count: 4,000-5,500 words

Chapter 4: Trading Interfaces (Parent + 2 Sub-pages)

File: chapters/04-trading-interfaces/README.md

Front matter:

---
layout: default
title: "4. Trading Interfaces"
nav_order: 4
parent: Chapters
has_children: true
---

Required content: Interface landscape comparison table (ETI vs FIX Gateway vs T7 GUI), ETI overview (protocol characteristics, session types and throughput table, max 600 sessions per participant since June 2024, transport/security TLS 1.3, TLS 1.2 decommissioning May 2026), FIX Gateway overview (FIX 4.2/4.4, protocol translation architecture, LF routing), T7 GUI, Interface Selection Guide, Session Architecture Summary, Additional Services (TES, SRQS/EnLight, CLIP, Strategy Creation, Risk Management via ETI), Encryption and Security.

Key metrics:

  • ETI: proprietary binary, <55 us, max 250 TPS (HF Ultra)
  • HF Light: 50 TPS, EUR 250/mo; HF Full: 150 TPS, EUR 500/mo; HF Ultra: 250 TPS, EUR 1,000/mo
  • Max 600 ETI sessions per participant (since June 2024)
  • TLS 1.2 decommissioning with Release 14.1 (May 18, 2026)
  • FIX Gateway since March 2021 (Release 10.0)
  • GUI standalone access: EUR 310/mo

Pricing complexity note for generated text: Session pricing involves volume-based tiers (sessions 1-4 at lower rate, sessions 5+ at higher rate), market-specific pricing (Eurex and Xetra have different fee structures), and negotiated rates for large participants. HF Ultra pricing is deliberately unpublished (“Contact Deutsche Boerse” or “See Price List”). Do not fabricate HF Ultra pricing. Present the tiered structure explicitly using the tables in this prompt; do not flatten to a single per-session figure.

Target word count: 3,000-4,000 words

File: chapters/04-trading-interfaces/eti.md

Front matter:

---
layout: default
title: "ETI Deep-Dive"
nav_order: 1
parent: "4. Trading Interfaces"
grand_parent: Chapters
---

Required content: Protocol Architecture (binary encoding with FIX 5.0 SP2 semantics, little-endian byte ordering, TemplateID-based message identification, asynchronous operation, protocol evolution and versioning), Session Types table (HF Light 50 TPS EUR 125-250, HF Full 150 TPS EUR 250-500, HF Ultra 250 TPS, LF, Back-Office EUR 100-104), Session Management (connection establishment 4-step sequence, heartbeat mechanism, sequence number management, session recovery for HF and LF, throttle management, DR throttle 30 TPS), Order Management (order entry with unified requests from Release 12.0, order modification priority rules, order deletion single/mass, execution reports with ExecType/OrdStatus mapping, reject messages), Quote Management (MassQuote, quote lifecycle, mass cancellation, Enhanced Mass Quote Facility), Trade Entry Services (block trades, EFP, bilateral, multilateral), SRQS/EnLight, CLIP (Eurex Improve), Strategy Creation (4 categories, CreateStrategy message, user-created strategies temporary), Risk Management via ETI, Technical Details (message format, gateway architecture, encryption), Release 14.1 Changes (May 2026).

Key metrics:

  • TemplateID field number 28500
  • TemplateID examples: 10100 (NewOrderSingle request), 10101 (response), 10025 (ExecutionReport)
  • HF Light EUR 125/mo (sessions 1-4 Eurex), EUR 250 (5+ Eurex), EUR 250 (Xetra)
  • HF Full EUR 250/mo (sessions 1-4 Eurex), EUR 500 (5+ Eurex), EUR 500 (Xetra)
  • HF Ultra since June 2023
  • Session limit increased from 400 to 600 in June 2024
  • Back-Office sessions EUR 100-104/mo
  • DR throttle: 30 TPS
  • Release 14.1 simulation March 23, 2026; production May 18, 2026
  • TLS 1.3 mandatory, TLS 1.2 decommissioned Release 14.1
  • Minimum OpenSSL 1.1.1 for TLS 1.3

Required source URLs:

  • https://www.eurex.com/resource/blob/4305946/dcadfeef8842b1a84b0e9afa439802e1/data/T7_R.13.1_Enhanced_Trading_Interface_-_Manual_Version_1.pdf
  • https://www.eurex.com/ex-en/find/circulars/circular-3498396 (HF Ultra)
  • https://www.eurex.com/ex-en/find/circulars/Eurex-Readiness-Newsflash-T7-Release-14.1-Mandatory-Implementation-of-New-ETI-Order-Entry-Requests-and-Decommissioning-of-Support-for-TLS-1.2-4913448
  • https://www.eurex.com/ex-en/find/circulars/Eurex-Readiness-Newsflash-ETI-trading-sessions-Limit-increase-per-Participant-3965220
  • https://www.eurex.com/ex-en/find/circulars/circular-2404602 (Gateway/ME consolidation)

Target word count: 5,000-7,000 words

File: chapters/04-trading-interfaces/fix-gateway.md

Front matter:

---
layout: default
title: "FIX Gateway Deep-Dive"
nav_order: 2
parent: "4. Trading Interfaces"
grand_parent: Chapters
---

Required content: FIX Protocol Support (FIX 4.2, FIX 4.4), Supported Message Types table:

Message Type FIX Tag Direction Description
Logon A Both Session establishment and authentication
Logout 5 Both Graceful session termination
Heartbeat 0 Both Connection keep-alive mechanism
ResendRequest 2 Both Request retransmission for gap recovery
SequenceReset 4 Both Sequence number management and gap fill
NewOrderSingle D Inbound Submit new order to market
OrderCancelRequest F Inbound Cancel existing order
OrderCancelReplaceRequest G Inbound Modify price/quantity of existing order
ExecutionReport 8 Outbound Order acknowledgment, fill, rejection
BusinessMessageReject j Outbound Application-level rejection with reason

Custom/proprietary tags (PartyIDSource 447 values D/P, TradingCapacity 1815 value 3). Gateway Architecture (message flow 7-step from FIX reception through protocol validation, FIX-to-ETI translation, LF gateway routing, PS gateway routing, ME processing, response reverse path; routing architecture with redundant dual-side, request ordering since Nov 2019; redundancy and failover). Performance Characteristics (latency overhead from protocol translation, LF routing +12 us, TLS single-digit us, redundancy link >50 us; LF throughput). Session Management (logon with MsgType=A and encrypted credentials, logout with MsgType=5, sequence numbers MsgSeqNum tag 34, gap fill ResendRequest/SequenceReset with GapFillFlag, connection recovery 5-step). FIX Message Mapping to ETI (order management mapping table: NewOrderSingle D to ETI NewOrderSingle/NewOrderSingleMultiLeg, OrderCancelRequest F to DeleteOrder, OrderCancelReplaceRequest G to ModifyOrder, ExecutionReport 8 to ExecutionReport, BusinessMessageReject j; key field mapping for ExecType 150, OrdStatus 39; feature differences – no Strategy Creation, no CLIP, no advanced quote management, no HF sessions, no TES advanced). FIX vs ETI Decision Matrix (9-criterion table comparing protocol familiarity, latency, max throughput, implementation effort, feature completeness, co-location requirement, session types, multi-partition access, typical users). Migration Path FIX to ETI (parallel operation, superset functionality, unified order requests Release 12.0+, simulation environment, phased rollout, reversibility). Connection Options (leased lines, 10 Gbit/s cross-connects, web access, standard/enhanced bandwidth, redundant connectivity).

Key metrics:

  • FIX 4.2 and FIX 4.4 supported
  • Documented in T7 Release 14.0 FIX LF Manual Version 1
  • LF Gateway routing adds ~12 microseconds
  • Redundancy link >50 microseconds
  • No HF session access via FIX
  • PartyIDSource tag 447 (values D, P), TradingCapacity tag 1815 (value 3)
  • Software changes November 2019 prevent LF requests overtaking PS requests

Required source URL:

  • https://www.eurex.com/resource/blob/4597694/04238a237828a83c88541ca3e847bbae/data/T7_R.14.0_FIX_LF_Manual_Version_1.pdf

Target word count: 3,000-4,000 words

Chapter 5: Market Data Feeds (Parent + 4 Sub-pages)

File: chapters/05-market-data/README.md

Front matter:

---
layout: default
title: "5. Market Data"
nav_order: 5
parent: Chapters
has_children: true
---

Required content: Feed Comparison Matrix (EOBI, EMDI, MDI, RDI comparing protocol, transport, latency, depth, update granularity, network requirements, monthly pricing, primary use case), Feed Details for each, Distribution Architecture (10GbE dedicated network, UDP multicast, IGMPv2, EOBI/EMDI integrated in ME since Release 12.0), Recovery and Synchronization, Feed Selection Guide, Commercial Data Products (Xetra Core/Ultra, Eurex Core/Ultra, delayed data 15 minutes).

Key metrics:

  • EOBI: native binary, full unrestricted depth, ~4 us faster than EMDI, EUR 7,200/mo, CoLo only
  • EMDI: FIX/FAST, 15 levels (Eurex) / 10 levels (Xetra), EUR 5,200-6,000/mo
  • MDI: FIX/FAST, top-of-book, lower cost, UDP multicast or TCP
  • RDI: FIX/FAST, static reference, free (registration required)

Per-section content requirements:

  • Feed Comparison Matrix: 7-column table (Aspect, EOBI, EMDI, MDI, RDI) covering Protocol (Native Binary / FIX/FAST / FIX/FAST / FIX/FAST), Transport (UDP Multicast / UDP Multicast / UDP Multicast+TCP / UDP Multicast), Latency (Lowest ~4 us faster / Medium / Higher / N/A static), Order Book Depth (Full unrestricted / 15 levels Eurex, 10 Xetra / Top-of-book / N/A), Update Granularity (Every order/quote change / Snapshots+Incremental / Aggregated snapshots / Static reference), Network Requirements (10 GbE CoLo only / High bandwidth / Low bandwidth / High bandwidth), Monthly Pricing (EUR 7,200 / EUR 5,200-6,000 / Lower / Free with registration), Primary Use Case (HFT market making / Algorithmic trading / Retail monitoring / System configuration).
  • Distribution Architecture: Dedicated 10 GbE market data network physically separate from transaction network. UDP multicast with IGMPv2. Each instrument/group assigned specific multicast addresses. EOBI and EMDI integrated in ME process since Release 12.0. Live-live Side A/B: both sides independently generated, sequence numbers for gap detection, no failover delay.
  • Recovery and Synchronization: EOBI: dedicated snapshot channel at regular intervals, sequence number gap detection, Replay Service for historical recovery. EMDI: snapshot+incremental model, initial snapshot provides full state, incremental for changes, automatic resync via new snapshot when gap exceeds threshold. MDI/RDI: lower update frequency, snapshot-based, TCP option for MDI.
  • Feed Selection Guide: EOBI when latency-sensitive (HFT, market making, arbitrage), full depth needed, CoLo deployed, premium pricing justified. EMDI when moderate latency tolerance, FIX infrastructure preferred, 10-15 levels sufficient, remote connectivity acceptable. MDI when top-of-book sufficient, bandwidth/processing minimized, retail/surveillance, latency not critical. RDI always required.
  • Commercial Data Products: Xetra Core (netted pre-trade + un-netted trade, Level 1/2), Xetra Ultra (un-netted pre-trade + trade, 10 best bid/ask), Eurex Core (best bid/ask depth 15, last price, volumes), Eurex Ultra (un-netted pre-trade depth 15). Delayed data: MiFIR-compliant, 15-minute delay, free of charge.

Target word count: 2,000-2,500 words

File: chapters/05-market-data/eobi.md – EOBI Deep Dive

Front matter:

---
layout: default
title: "EOBI"
nav_order: 1
parent: "5. Market Data"
grand_parent: Chapters
---

Required content: Protocol Architecture (native binary, FIX 5.0 SP2 semantics but NOT FIX/FAST, integrated in ME process, UDP multicast. Clarify that “integrated in ME process” means the serialization code runs in the ME’s address space (eliminating IPC), not that EOBI and ETI share a network transmission path. EOBI exits via UDP multicast NIC queues; ETI exits via TCP NIC queues. The serialization happens first for EOBI, but the network transmission uses separate scheduling.), Data Content and Message Types (Order Add/Modify/Delete, Execution Messages, Trade Reports, Product State Changes, snapshot channels), Latency Characteristics (4 us faster than other feeds, 1.5 us before ETI responses), Redundancy and Reliability (Side A/B, sequence numbers), Recovery Mechanisms (snapshot channel, replay service), Network Requirements (10 Gbit/s CoLo 2.0 only, Equinix FR2, separate market data network, IGMPv2), Multicast Configuration, Pricing Structure, Use Cases, Implementation Considerations, Historical Evolution (introduced T7 Release 7.0 September 2018).

Key metrics:

  • ~4 us faster than EMDI
  • ~1.5 us before ETI execution reports
  • Xetra EOBI: EUR 7,200/mo
  • Eurex EOBI Futures: EUR 7,200/mo
  • Combined EMDI+EOBI: EUR 7,280/mo (Xetra), EUR 8,400+/mo (Eurex)
  • Dual connection rebate: EUR 750
  • 10 Gbit/s CoLo mandatory
  • Introduced T7 Release 7.0 September 2018

Target word count: 2,000-2,500 words

File: chapters/05-market-data/emdi.md – EMDI Deep Dive

Front matter:

---
layout: default
title: "EMDI"
nav_order: 2
parent: "5. Market Data"
grand_parent: Chapters
---

Required content: Protocol Architecture (FIX 5.0 SP2, FAST 1.1/1.2, consolidated into ME since Release 12.0), Data Content (15 levels Eurex, 10 levels Xetra, aggregated quantities), Snapshot and Incremental Update Model (MsgSeqNum, LastMsgSeqNumProcessed, 6-step recovery process), Latency Characteristics, Redundancy, Pricing (Xetra EMDI EUR 5,200/mo, Eurex EMDI EUR 6,000/mo, Combined EUR 7,280/mo, rebate EUR 750), EMDI vs EOBI Comparison, Use Cases, Implementation Considerations.

Target word count: 2,000-2,500 words

File: chapters/05-market-data/mdi.md – MDI Deep Dive

Front matter:

---
layout: default
title: "MDI"
nav_order: 3
parent: "5. Market Data"
grand_parent: Chapters
---

Required content: Protocol and Transport (FIX 5.0 SP2, FAST, UDP multicast or TCP), Data Content (best bid/ask only, trade data, market statistics, instrument status), MDI vs EMDI vs EOBI comparison table, Use Cases (retail, surveillance, risk, back-office, info vendors), Network Requirements, Pricing, Redundancy, Implementation.

Required source URL:

  • https://www.eurex.com/resource/blob/4332344/43e75aa168ed97fff40f8607002d560f/data/T7_R.13.1_%20EMDI_MDI_RDI_Manual_Version_2.pdf

Target word count: 2,000-2,500 words

File: chapters/05-market-data/rdi.md – RDI Deep Dive

Front matter:

---
layout: default
title: "RDI"
nav_order: 4
parent: "5. Market Data"
grand_parent: Chapters
---

Required content: Protocol and Transport (FIX 5.0 SP2, FAST, UDP multicast, free of charge), Data Content (instrument master data, product-to-partition assignments, trading calendar/schedule, technical config parameters including multicast addresses, trading parameters and risk limits), Publication Schedule, RDI vs RDF comparison, GraphQL Reference Data API (URL: https://console.developer.deutsche-boerse.com/apis, free anonymous access), Use Cases, Implementation.

Required source URLs:

  • https://www.eurex.com/resource/blob/4332344/43e75aa168ed97fff40f8607002d560f/data/T7_R.13.1_%20EMDI_MDI_RDI_Manual_Version_2.pdf
  • https://console.developer.deutsche-boerse.com/apis

Target word count: 2,000-2,500 words

Chapter 6: Order Types & Matching Engine

File: chapters/06-order-types-matching/README.md

Front matter:

---
layout: default
title: "6. Order Types & Matching"
nav_order: 6
parent: Chapters
---

Required H2/H3 headings and content: Introduction, Basic Order Types (Market, Limit, Stop – with table), Time-in-Force Options (GFD, GTC, GTD, IOC, FOK – with table including persistence behavior), Execution Restrictions (Book-or-Cancel, Market-to-Limit), Eurex Special Order Types (OCO, Trailing Stop, Auction-Only, Strategy Orders with table), Xetra Special Order Types (Midpoint Orders with 4-type table including Limit Midpoint/Market Midpoint/Limit Sweep/Market Sweep; midpoint execution formula; Iceberg Orders with 5% minimum peak; Pegged Orders; MAQ), Matching Algorithms (Price-Time Priority with modification rules table, Pro-Rata with allocation formula and example, Pro-Rata with Top-of-Book Priority with example, Auction Matching with price determination objectives), Self-Match Prevention (SMP Type A, tag 28744, 3 cancellation options CP/CAP/CA, default changed Dec 1 2025), Passive Liquidity Protection (PLP deferral times table: OESX 1ms Aug 2019, ODAX 1ms Aug 2020, OTUK 3ms Oct 2022; order type behavior table; matching timeline example; market impact: DAX options spread reduction 10-15%), Risk Controls at Order Level (MOV, Max Order Quantity with example limits table, Price Reasonability Checks), Volatility Interruptions (dynamic corridors, static corridors since Release 12.1, ACE for Xetra with expansion levels and interval requirements, VI process workflow), Order Book Management.

Key metrics:

  • Over 15 distinct order types
  • Lean orders: fastest submission path, memory-only
  • GTC auto-deleted after 1 year
  • Iceberg minimum peak: 5% of total (factor of 20)
  • Pro-rata allocation formula: allocated_qty = min(order_open_qty, floor((order_qty / total_best_price_qty) * incoming_qty))
  • PLP deferral: 1ms (OESX Aug 2019, ODAX Aug 2020), 3ms (OTUK Oct 2022)
  • SMP default changed from CAP to CP on December 1, 2025
  • SMP tag: 28744 (MatchInstCrossID)
  • ACE interval: 120 seconds (single-level), 120-300 seconds (multi-level)

Per-section content requirements:

  • Basic Order Types: 3-row table (Market/Limit/Stop) with description, key behavior, restrictions. Market: no price limit, not visible in book, prioritized over limit, may partially fill across price levels, flagged IOC for pro-rata products. Limit: price protection, book visible, supports all TIF, price changes create new order, quantity decreases maintain priority. Stop: inactive until trigger, configurable reference price (last traded, best bid/ask), converts to market or limit.
  • Time-in-Force: 5-row table (GFD/GTC/GTD/IOC/FOK) with code, behavior, persistence, use cases. Persistence behavior section with 3-row table (Standard Persistent/Standard Non-Persistent/Lean) comparing visibility, Market Reset survival, latency, HFT suitability. Lean orders: fastest path, memory-only, no replication, visible only to submitting session, not restated after Market Reset. GTC auto-deleted after 1 year.
  • Execution Restrictions: Book-or-Cancel (BOC): rejected if immediately executable, guarantees passive-only. Market-to-Limit: initial market execution, converts remainder to limit at last execution price.
  • Eurex Special: OCO (combined limit+stop, single order ID, cancellation of other on execution). Trailing Stop (variable stop limit, favorable adjustment only, configurable reference and distance). Auction-Only (opening/closing only, auto-cancelled if not executed). Strategy Orders table (4 types: Futures Combinations, Standard Options, Non-Standard Options up to 5 legs, Option Volatility Strategies).
  • Xetra Special: Midpoint Orders table with 4 types (Limit Midpoint, Market Midpoint, Limit Sweep, Market Sweep) showing execution and transparency. Midpoint formula: (best_bid + best_ask) / 2. Requires tight spread. No pre-trade transparency. Launched December 2024. Iceberg Orders: minimum 5% visible (factor 20 max), hidden auto-replenishes, new timestamp on refresh (loses priority). Example: 10,000 with 500 peak. Pegged Orders: automatic price adjustment relative to reference (best bid/ask/midpoint/last traded), configurable offset. MAQ: minimum fill size protection.
  • Matching Algorithms: Price-Time Priority (PTP): price first, then FIFO. Modification rules table (6 rows: quantity increase loses priority, decrease maintains, price change loses, other attributes maintain). Coverage: all Xetra equities/ETFs, most Eurex futures, options excluding equity options, complex instruments. Pro-Rata (PTR): price first, then proportional allocation by displayed size, residual by time. Allocation formula with example (3-order book, 500-share incoming). Coverage: all Eurex equity options. Pro-Rata with Top-of-Book Priority: hybrid – first order at best price fills completely, then pro-rata for rest. Example with 3-order book. Auction Matching: single-price execution maximizing volume. 4 auction types (opening, closing, intraday, volatility). Price determination: maximize volume, minimize surplus, market proximity. Process: call phase, price determination, book freeze, execution, publication.
  • Self-Match Prevention: SMP Type A on T7. Tag 28744 (MatchInstCrossID). Active during continuous trading only (not auctions). 3 cancellation options table (CP Cancel Passive, CAP Cancel Aggressive & Passive, CA Cancel Aggressive) with default since and use case. Default changed December 1, 2025 from CAP to CP. Configuration at Business Unit level. Example scenario with buy/sell at 50.00.
  • Passive Liquidity Protection: Purpose (protect market makers, prevent stale quote sniping, level playing field, encourage tighter spreads). Mechanism: aggressive orders deferred, passive immediate. PLP deferral times table by product (OESX 1ms Aug 2019, ODAX 1ms Aug 2020, OMSX 1ms, equity options 1ms, FI options 1ms, OTUK 3ms Oct 2022, FX varies). Order type behavior table (market/IOC/FOK = aggressive deferred, resting limit = passive immediate). Matching timeline example with 1ms PLP. Market impact: DAX options spread reduction 10-15%, increased depth, reduced adverse selection.
  • Risk Controls at Order Level: Maximum Order Value with calculation example (ODAX: 10,000 contracts x EUR 5 contract size x EUR 0.10 tick value). Maximum Order Quantity with example limits table (equity index options 50,000, FI futures 10,000, single stock options 25,000, commodity futures 5,000). Price Reasonability Checks: entry interval around reference price, no trading halt (unlike VI). Comparison table (price collar = reject, VI = halt).
  • Volatility Interruptions: Dynamic corridors: percentage deviation from rolling reference, auto-widen during fast market (e.g., 5% to 10%). Static corridors (Release 12.1+): fixed percentage from reference (10-20%), wider than dynamic, complementary. Comparison table (dynamic vs static). ACE for Xetra: 4 expansion levels (e.g., 5%, 8%, 12%, 20%) with minimum 120 seconds per level (single-level) or 120-300 seconds (multi-level). Extended VI if no valid price at Level 4. Full VI workflow: trigger event, immediate halt, instrument status broadcast, transition to auction, order management during call, indicative price publication, price determination, corridor validation, expansion or resolution, resumption.
  • Order Book Management: Priority after modification table (6 rows). Iceberg refresh behavior with examples. Market Reset synchronization with pre/post/required action state examples.

Target word count: 5,000-7,000 words

Chapter 7: Market Models & Microstructure

File: chapters/07-market-models/README.md

Front matter:

---
layout: default
title: "7. Market Models"
nav_order: 7
parent: Chapters
---

Required content: Xetra Trading Model (trading phases table with CET timings: Pre-Trading before 09:00, Opening Auction 09:00+, Continuous ~09:15-17:30, Intraday 13:00, Closing 17:30, Trade-at-Close ~17:35-17:45; market segments DAX/MDAX/TecDAX/SDAX/ETFs/Bonds; 2024 averages EUR 149.58B equity, EUR 36.72B ETF), Xetra Midpoint (launched December 2024, Reference Price Waiver, 0.3 bps per side, midpoint and sweep orders), Eurex Trading Model (extended hours table Asian 01:00-08:00, European 08:00-17:30, US 17:30-22:00; FDAX 01:10-22:00; product categories; complex instruments 4 strategy types), Auction Mechanics (price determination principle, indicative auction information, random end mechanism, order priority, single-price execution), Trade-at-Close (max 5 minutes 17:35-17:45), Market Microstructure (Xetra tick sizes RTS 11; Eurex tick size table: FDAX 1.0pt EUR 25, Mini-DAX 1.0pt EUR 5, FESX 1.0pt EUR 10, FGBL 0.01pt EUR 10, VSTOXX 0.05pt EUR 50), OTR (volume and transaction formulas, volatility factor since Dec 2023 with factors 1/1.5/2/4, TR100 reports daily + intraday every 30 minutes), Designated Sponsors (Xetra: 90% presence equities, 80% ETFs; 50% max buy/sell divergence), Eurex Market Maker Programs (PLP program, market maker rebates), Eurex Improve/CLIP (150ms price improvement window), Eurex EnLight (product coverage, access methods Bloomberg/TT/GUI/API, RFQ workflow), Protective Mechanisms (volatility interruptions, ACE for ETFs, circuit breakers, plausibility checks).

Required source URLs:

  • https://www.cashmarket.deutsche-boerse.com/cash-en/trading/Xetra/continuous-trading-with-auctions
  • https://www.eurex.com/ex-en/trade/trading-hours
  • https://www.eurex.com/ex-en/trade/market-models/eurex-plp
  • https://www.eurex.com/ex-en/trade/market-making-and-liquidity-provisioning

Per-section content requirements:

  • Xetra Trading Model: Hybrid continuous trading with auctions. Trading phases table with CET timings: Pre-Trading (before 09:00), Opening Auction Call (09:00+, minimum 15 minutes, random end), Continuous Trading (~09:15-17:30, price-time priority CLOB), Intraday Auction (13:00, minimum 2 minutes / 5 minutes for DAX), Closing Auction Call (17:30), Closing Price Determination (~17:35), Trade-at-Close (~17:35-17:45, max 5 minutes), Post-Trading (after 17:45). Market segments: DAX (40 blue-chip), MDAX (60 mid-cap), TecDAX (30 tech), SDAX (70 small-cap), ETFs, Bonds. 2024 averages: EUR 149.58B equity, EUR 36.72B ETF. Continuous trading mechanics: CLOB with price-time priority, aggressive orders cross spread, maker-taker pricing.
  • Xetra Midpoint: Launched December 2024. Dark pool with no pre-trade transparency. Reference Price Waiver under MiFID II. Midpoint execution = (best_bid + best_ask) / 2. Fee: 0.3 basis points per side. Eligible: all German equities and European ETFs. Two order types: Midpoint Orders (dark pool only) and Sweep Orders (dark pool first, then lit CLOB). HFT implications: price improvement (half-spread), reduced market impact, lower fees, integrated access. Risk: adverse selection.
  • Eurex Trading Model: Extended hours across 3 time zones. Asian 01:00-08:00, European 08:00-17:30, US 17:30-22:00. FDAX 01:10-22:00 CET. Product categories: equity index (DAX, EURO STOXX 50, MSCI), interest rate (Euro-Bund/Bobl/Schatz, ESTR), FI derivatives, FX, volatility (VSTOXX), dividend, credit (iTraxx), commodity, cryptocurrency (Bitcoin, Ethereum). Complex instruments: 4 strategy types (inter-product spreads, intra-product spreads, volatility strategies, synthetic positions). Synthetic matching.
  • Auction Mechanics: Price determination principle: maximize executable volume, minimize surplus, market proximity. Indicative auction info: indicative price, surplus side, surplus volume, executable volume. Random end mechanism (minimum duration + random extension to prevent manipulation). Order priority: market orders highest, then limit by price, then by time. Single-price execution (all at determined auction price).
  • Trade-at-Close: Immediately after closing price determination (~17:35 CET). Max 5 minutes to 17:45. Fixed closing price. Market and limit orders eligible. Strategic importance: fund valuation (NAV), index tracking, benchmark execution, corporate actions.
  • Tick Sizes: Xetra: RTS 11 regime, liquidity bands by ADNT, balance narrow spreads vs depth vs market maker profitability. Eurex tick size table: FDAX 1.0pt/EUR 25, Mini-DAX 1.0pt/EUR 5, Micro-DAX 1.0pt/EUR 1, FESX 1.0pt/EUR 10, FGBL 0.01pt/EUR 10, FGBM 0.01pt/EUR 10, VSTOXX 0.05pt/EUR 50. RDI TickRules field for automated systems.
  • OTR: Volume-based: (ordered vol / traded vol) - 1. Transaction-based: (orders / trades) - 1. Volatility factor since December 2023: 1.0/1.5/2.0/4.0 (auto-expand during turbulent markets). Product-specific limits with base and assigned factor. TR100 reports: daily + intraday every 30 minutes. Sanctions: warning, fee penalties, trading restrictions, membership review.
  • Designated Sponsors: Xetra program requirements table: equities 90% presence, ETFs 80%, max 50% buy/sell divergence, security-specific minimum quote size. Receive issuer compensation and preferential fees. 90% of 6-hour session = 5 hours 24 minutes.
  • Regulatory Market Making (MiFID II): RTS 8. Minimum 50% of trading hours on 50% of trading days per month. Simultaneous two-way quotes. Binding written agreements.
  • Eurex Market Maker Programs: Primary Liquidity Provider (PLP): automatic monthly rebates, no pre-registration, comprehensive coverage, performance criteria (spread quality, quote size, stress quotation, presence). Traditional market maker rebates: volume-based tiered, P/M-Position Account, performance tracking.
  • CLIP (Eurex Improve): Block-like treatment for below-block-size trades in equity options. Workflow: flow provider commits size at price, CLIP order submitted, public announcement broadcast, 150ms price improvement period, execution at improved or committed price. Central order book priority maintained. Product coverage: all equity options and equity index options.
  • Eurex EnLight (SRQS): Full RFQ system. Product coverage: equity options, index options, FI options, futures, FX derivatives. Access: Bloomberg Tradebook, Trading Technologies, Eurex GUI, T7 API. Workflow: request creation, quote submission, negotiation, strike. Information control: selective visibility, anonymity options. Operational: single T7 connectivity, instant validation, automated STP, audit trail.
  • Protective Mechanisms: Volatility interruptions (dynamic corridors 3-10% for liquid equities, static corridors 15-20%, ACE for ETFs with multi-level progressive expansion), circuit breakers (market-wide halt, EU coordination), plausibility checks (price range, size reasonableness, self-trade prevention, pre-trade risk limits).

Target word count: 4,000-5,500 words

Chapter 8: Latency & Performance

File: chapters/08-latency-performance/README.md

Front matter:

---
layout: default
title: "8. Latency & Performance"
nav_order: 8
parent: Chapters
---

Required content: Latency Metrics (order-to-response <55 us median, 56 us baseline 2019, options 54 us, futures 53 us; order-to-market-data ~40 us Xetra; EOBI vs ETI 1.5 us lead from Feb 13 2025 measurements; minimum reaction time 2,787 ns, ~10 participants below 2,830 ns; gateway latency differences: PS lowest, LF was 75 us now 12 us same-side and 1 us cross-side, redundancy link >50 us), Throughput and Capacity (peak 201K msg/sec June 2024: Eurex 118K March 13 2024, Xetra 92K April 16 2024; daily 1.25B requests April 7 2025 up from 857M 2023, Eurex 460M Xetra 759M; per-session TPS table; partition-level 20K msg/sec April 2025 up from 14K 2024), Timestamp Precision (measurement points table t_3a through t_9d with locations; nanosecond resolution; White Rabbit ~1 ns; HPT service; ETI fields RequestTime 5979, TrdRegTSPrevTimePriority, TrdRegTSTimePriority; MiFID II requires 100 us HFT), Latency Evolution (Tech Refresh 2024: InfiniBand to Ethernet, dual 12-core to 32-core, NUMA optimization, PTP improved to 4-5 ns RMS; key release milestones 6.0 partition-specific FIFO, 7.0 EOBI extended, H1 2021 PS/ME co-location, 14.0 Nov 2025, 14.1 May 2026; philosophy “low and deterministic latency”), Determinism and Fairness (CoLo 2.0, FIFO guarantees, no speed bumps, public data first, equal network access), Monitoring and Transparency (HPT file service, published latency statistics, time services GPS/PTP/White Rabbit), Optimization Strategies (co-location, PS vs LF selection, kernel bypass DPDK, EOBI processing, session management).

Required source URLs:

  • https://www.deutsche-boerse.com/resource/blob/3690194/fe6b01b1e14800eb40374a95516debf2/data/Open%20Day%202023%20-%20Presentation,%20T7-Latency%20Roadmap.pdf
  • https://www.eurex.com/resource/blob/48918/4f724c9415d2731cfb27295db6269c9c/data/presentation-insights-into-trading-system-dynamics.pdf
  • https://www.deutsche-boerse.com/resource/blob/1637232/da0ae611905acda0d7502260903a0835/data/Open-Day-2019_T7-Latency-Roadmap_Andreas-Lohr_final.pdf
  • https://www.deutsche-boerse.com/resource/blob/4126486/21cc046dd9eea5655f2b7ce17500f673/data/Tech%20Refreshes.pdf
  • https://www.cashmarket.deutsche-boerse.com/cash-en/Data-Tech/Technology/co-location-services
  • https://www.deutsche-boerse.com/dbg-en/markets-services/ps-technology/ps-7-market-technology/ps-n7/ps-connectivity-services-time-services

Per-section content requirements:

  • Order-to-Response Latency: Median <55 us via PS gateways. 2019 baseline: overall 56 us, options HF 54 us, futures HF 53 us. Cite T7 High-speed Trading Solution page.
  • Order-to-Market-Data Latency: ~40 us median on Xetra. Cite Open Day 2019 presentation.
  • EOBI vs ETI – Design Principle vs Measured Timing: Two distinct claims must be kept separate in the output: (a) Design principle (permanent): T7 always publishes market data (EOBI) before sending private execution reports (ETI). This is an architectural guarantee, not a measured artifact. State this without a specific microsecond figure. (b) Measured timing (dated observation): In median measurements from February 13, 2025, EOBI send times preceded ETI gateway send times by approximately 1.5 microseconds. This figure is load-dependent, hardware- dependent, and will change across releases. Always qualify with the measurement date. Do not state “1.5 us” as a permanent gap. Cite Insights into Trading System Dynamics March 2025 for (b) only.
  • Minimum Reaction Time: 2,787 ns (~2.8 us). ~10 participants below 2,830 ns. Encompasses receiving EOBI, processing, decision, order construction, transmission. Requires kernel bypass (DPDK), in-memory processing, co-location. Cite Trading System Dynamics.
  • PS Gateway Latency: Lowest path. Co-located with ME since H1 2021 on same physical server (same NUMA domain). Cite T7 Architecture Factsheet.
  • LF Gateway Latency: Was ~75 us. Now ~12 us same-side, ~1 us cross-side (as of January 2025, down from 45 us). Cite Open Day 2023.
  • Redundancy Link Latency: >50 us when active. Emergency backup only. Cite Open Day 2023.
  • Peak Message Rate: 201K msg/sec June 2024. Eurex 118K (March 13 2024), Xetra 92K (April 16 2024). Cite T7 Architecture Factsheet.
  • Daily Capacity: Over 320M transactions/day. April 7 2025: 1.25B daily requests (up from 857M 2023). Eurex 460M, Xetra 759M. Cite Factsheet.
  • Per-Session TPS: HF Full 150, HF Light 50, LF lower. Scale via multiple sessions.
  • Partition-Level: 20K msg/sec April 2025 (up from 14K 2024 = 43% YoY).
  • Timestamp Points Table: t_3a (network TAP inbound), t_3d (TAP outbound), t_3n (gateway entry), t_4 (ME receipt), t_5 (ME output), t_7 (market data generation), t_8 (market data send), t_9 (EOBI send), t_9d (EOBI TAP outbound). 3 passive TAPs at strategic locations.

CANONICAL Timestamp Reference (use this table VERBATIM in Chapter 8, Quick Reference Card 1, and any diagram annotations. Do not paraphrase or reorder):

Code Location Description
t_3a Passive network TAP Inbound packet capture at network boundary
t_3d Passive network TAP Outbound packet capture at network boundary
t_3n Gateway process Gateway processing entry point
t_4 Matching Engine ME receipt of order message
t_5 Matching Engine ME output after processing
t_7 Market Data process Market data serialization complete
t_8 Market Data NIC Market data packet sent to network
t_9 EOBI process EOBI message serialized
t_9d Passive network TAP EOBI packet capture at network boundary

Lock instruction: Reproduce this table identically wherever timestamp codes appear. Do not describe t_3a as “gateway entry” (that is t_3n). Do not describe t_3n as “TAP capture” (that is t_3a). The distinction matters: TAP captures are passive copies at the network boundary; gateway entry is the application-level processing point.

  • Nanosecond Resolution: Sub-nanosecond via White Rabbit ~1 ns quality. HPT service provides t_3a, t_3d, t_9d.
  • ETI Timestamp Fields: RequestTime field 5979, TrdRegTSPrevTimePriority, TrdRegTSTimePriority.
  • MiFID II: Requires 100 us for HFT. T7 exceeds by 5+ orders of magnitude.
  • Tech Refresh 2024: InfiniBand to Ethernet migration. Dual 12-core to dual 32-core processors. Single NUMA domain for GW+ME+MDP. PTP improved from ±50 ns to 4-5 ns RMS via hybrid PTP+SyncE.
  • Key Milestones: Release 6.0 (partition-specific FIFO), 7.0 (EOBI extended + PS as single entry point), H1 2021 (PS/ME co-location), 14.0 (Nov 2025 Sponsored Access), 14.1 (May 2026 new ETI requests).
  • Philosophy: “Low and deterministic latency means reduced risk.” Target constant low latency under high load.
  • Determinism: CoLo 2.0 10 Gbit/s latency-optimized network. FIFO guarantees. No speed bumps. Public data first. Equal network access (cable lengths, switch configs, routing standardized).
  • HPT File Service: Participants access t_3a, t_3d, t_9d files for latency measurement, bottleneck identification, regulatory compliance.
  • Optimization Strategies: Co-location at Equinix FR2 as most effective single optimization. PS vs LF selection criteria. Kernel bypass (DPDK, Solarflare OpenOnload). EOBI prioritized over EMDI. Multiple sessions for scaling. Dual-side connectivity.

Target word count: 4,000-5,500 words

Chapter 9: Risk Controls & Pre-Trade Checks

File: chapters/09-risk-controls/README.md

Front matter:

---
layout: default
title: "9. Risk Controls"
nav_order: 9
parent: Chapters
---

Required content: 12 numbered sections covering: Pre-Trade Risk Limits (MOQ, MOV, price range, reasonability), Transaction Size Limits (hierarchy, components, multipliers, clearing/trading member controls), Advanced Risk Protection (margin-based, C7 integration, automatic actions at 70/85/95/100% thresholds), Self-Match Prevention (CA/CP/CAP with configuration, MiFID II mandate, default change Dec 1 2025), Passive Liquidity Protection (mechanism, product-specific timings: ODAX 1ms, OESX 1ms, OSTK FR 3ms, OTUK 3ms, interaction with SMP), Volatility Interruptions (dynamic corridors, static corridors activated July 8 2024, ACE, random end), Market Maker Protection (volume/delta/vega/percent-based, auto-deactivation, futures MMP), OTR (formulas, volatility factor since Dec 2023 with levels 1/1.5/2/4, TR100 reports green/yellow/red thresholds 50/100), ESU Fees (formula, floor + volume components, Dec 2025 passive/aggressive split 0.5x/1.0x, volatility factor, TR102 reports), Kill Switch (4-eyes principle, emergency trading stop role, clearing member vs participant, recovery, emergency GUI at t7gui.emergency.eurex.com), Clearing-Level Controls (PRISMA 99/99.5%, 5000+ scenarios, default fund waterfall: margin, DF contribution, SITG EUR 143M, non-defaulted DF, SSITG EUR 57M, assessment = total EUR 200M; intraday margin calls), Regulatory Framework Summary (MiFID II Art 48, RTS 6/7/8, German HFT Act May 2013, algorithm testing, order flagging), Risk Controls Matrix summary table.

Required source URLs:

  • https://www.eurex.com/resource/blob/2448162/28033c3a73ea19078860573d526f8f33/data/presentation-trading-safeguards.pdf
  • https://www.eurex.com/resource/blob/245816/5ec9083e5a1966b0c64df116fb8d5c9e/data/order-to-trade-ratio-concept-paper.pdf
  • https://www.eurex.com/resource/blob/249916/ed46a4d5a4e6c67a25374fa8ee3426bb/data/excessive-system-usage-fee-concept-paper.pdf
  • https://www.eurex.com/resource/blob/2716266/f139149fe08ef13fbe787ea361089b20/data/Whitepaper-Eurex-Passive-Liquidity-Protection.pdf

Per-section content requirements:

  • PTRL Section: MOQ (minimum order quantity per product, typically 1 contract for equity derivatives), MOV (minimum order value = qty x reference price, typical EUR 500-5000), Price Range Validation (static ±20-30%, dynamic based on recent volatility, reference = last traded or theoretical), Price Reasonability (spread check, volume-weighted, cross-product, time-of-day).
  • TSL Section: 4-level hierarchy (clearing member, trading member, product group, individual product). Components: max order quantity (buy/sell separate), max open position (net + pending gross), daily volume limit (resets 00:00 CET). Multipliers: standard 1.0x, extended 1.5-3.0x, emergency 0.1-0.5x. Clearing member can override trading member. Enforcement: reject new orders increasing exposure, possible auto-cancel, real-time alerts, event logging, recovery via manual intervention or time-based/position-reduction reset.
  • ARP Section: Margin-based via PRISMA. C7 integration. 4 automatic action levels: Level 1 Warning 70% (alert only), Level 2 Risk 85% (prevent new orders increasing exposure), Level 3 Critical 95% (cancel all resting, prevent new), Level 4 Emergency 100% (automatic liquidation via market orders). Recovery: additional margin, position reduction, market movement, manual clearing member acknowledgment.
  • SMP Section: 3 types: CA (cancel aggressor), CP (cancel passive), CAP (cancel both). Configuration per trading member, user ID, product group. MiFID II Article 48(6) mandate. Default changed from CA to CP on December 1, 2025. Quarterly review required by clearing members.
  • PLP Section: Mechanism: aggressive order deferred, passive enters book immediately. Product-specific timings: ODAX 1 ms, OESX 1 ms, OSTK FR 3 ms, OTUK 3 ms, Fixed Income Options 1 ms. PLP executes before SMP check. Adds 1-3ms to latency for affected orders.
  • Volatility Interruptions: Dynamic corridors recalculated every 5 seconds. Static corridors activated July 8 2024 (fixed ±5-15% from reference). ACE: Auction Call Extension when auction price would still violate corridor. 30-60 second extensions, 2-3 max. Random end: base duration + 0-30 seconds random window.
  • MMP Section: 4 types: volume-based (cumulative contracts per rolling window), delta-based (net delta from executions), vega-based (cumulative vega), percent-based (% of 20-day average daily volume). Auto-deactivation: time-based cooldown, manual override, partial reactivation. Futures MMP: directional limits, rollover handling, inter-contract aggregation, spread exclusion option.
  • OTR Section: Volume-based formula: (ordered vol / traded vol) - 1. Transaction-based: (orders / trades) - 1. Volatility factor since December 2023: 1.0/1.5/2.0/4.0. TR100 reports: daily, per-product breakdown, peer comparison. Thresholds: green <50, yellow 50-100, red >100. Shared with BaFin.
  • ESU Section: Formula: (transaction count - limit) x per-transaction fee. Floor component: typically 500K messages/day baseline, adjusted for market maker. Volume component: executed volume x multiplier (0.5-5.0). December 2025 update: passive messages weighted 0.5x, aggressive 1.0x. Volatility factor same as OTR. TR102 reports daily, dispute within 5 business days, monthly fee collection.
  • Kill Switch: 4-eyes principle (operator + risk manager within 60 seconds). Emergency Trading Stop role: minimum 2 per clearing member, annual certification. Clearing member kill switch cancels all orders for all trading members, blocks new submissions, requires CM action to restore. Participant kill switch: own orders only, self-restore with CM approval. Recovery: root cause analysis, system verification, risk assessment, controlled restart (limit orders only first), 24-hour enhanced monitoring. Reported to BaFin within 24 hours. Emergency GUI at t7gui.emergency.eurex.com (cancel/view only, MFA with hardware tokens, 24/7).
  • Clearing-Level: PRISMA methodology: portfolio-based VaR, historical simulation, 5000+ scenarios since 1987, recalculated every 5 minutes intraday. Confidence 99% standard, 99.5% enhanced. Risk horizon: 2-day (liquid), 5-day (less liquid), extended (exotic). Default fund waterfall: Step 1 defaulter’s margin, Step 2 defaulter’s DF contribution, Step 3 CCP SITG EUR 143M, Step 4 non-defaulted members’ DF, Step 5 SSITG EUR 57M, Step 6 assessment powers. Total CCP SITG EUR 200M. Intraday margin calls: triggered at 70% decline vs initial margin, 1-hour settlement deadline, eligible collateral: cash EUR/USD/GBP, government bonds (haircut), gold, equities (large haircut).
  • Regulatory Summary: MiFID II Art 48 (pre/post-trade controls, kill switch, SMP, circuit breakers). RTS 6 (real-time monitoring, automated limits, audit trail, 7-year retention). RTS 7 (kill switch for algo firms). RTS 8 (algorithm testing). German HFT Act May 2013 (BaFin registration, algorithm registration, kill switch, OTR monitoring, HFT order flagging).
  • Risk Controls Matrix: Summary table with all 13 controls showing type, controller, key parameters, trigger condition.

Target word count: 5,000-7,000 words

Chapter 10: Regulatory Framework

File: chapters/10-regulatory-framework/README.md

Front matter:

---
layout: default
title: "10. Regulatory Framework"
nav_order: 10
parent: Chapters
---

Required content: MiFID II/MiFIR (effective Jan 3 2018, Article 17 firm requirements, Article 48 venue requirements), Key RTS (RTS 6 algo org requirements, RTS 7 venue requirements, RTS 8 market making, RTS 11 tick size regime with 20 tick sizes enforced April 1 2019 and ETF band 6, RTS 25 clock sync 1 us HFT / 1 ms others), German HFT Act (effective May 15 2013, BaFin registration, algorithm labeling from April 1 2014, OTR compliance, DEA notification from Jan 3 2018), Order Flagging (Algo flag, DEA flag, short selling indicator, SMP ID mandatory since April 1 2020, investment/execution decision codes, fields 22 and 24), Short Code Registration (ClientID structure, LEI ISO 17442, transaction reports TR160/161/167/168 generated 3x daily at 10:00/14:00/18:00 CET), Algorithm Testing (T7 Cloud Simulation 24/7, SSL/IPSEC, full interface support, mandatory consulting call with TMR, end-to-end test, certificate from DB CA), Clock Synchronization Compliance (PTP/White Rabbit/GPS/NTP, HPT product), Market Abuse Regulation (EU 596/2014 effective July 2016, prohibited practices, TSO, enforcement), OTR Enforcement and Penalties (penalties up to EUR 1,000,000, exclusion up to 30 days, suspension up to 6 months, revocation), Participant Admission Requirements, Compliance Summary Table.

Required source URLs:

  • https://www.deutsche-boerse.com/dbg-en/about-us/regulation/regulation-tcd/mifid-mifir
  • https://www.deutsche-boerse.com/dbg-en/about-us/regulation/regulation-tcd/reg-topic-hft
  • https://www.xetra.com/xetra-en/newsroom/current-regulatory-topics/high-frequency-trading
  • https://www.deutsche-boerse.com/dbg-en/about-us/regulation/regulation-hd/mad-mar
  • https://www.eurex.com/ex-en/support/technology/t7-cloud-simulation

Per-section content requirements:

  • MiFID II / MiFIR: Effective January 3, 2018. Article 17: testing, staffing, annual self-assessment, risk controls. Article 48: circuit breakers, tick size regimes, co-location on fair/reasonable/non-discriminatory terms, testing/simulation environments (Article 48(6)).
  • RTS 6: Organizational requirements for algo firms. Systems and controls, real-time monitoring, automatic submission limits, kill functionality, annual self-assessment, governance, business continuity.
  • RTS 7: Trading venue requirements. Circuit breaker parameters, tick sizes, co-location fairness, conformance testing environments.
  • RTS 8: Market making obligations. Binding written agreements, continuous quotation obligations, spread and volume parameters, incentive scheme transparency.
  • RTS 11: Harmonized tick size regime. Liquidity bands based on Average Daily Number of Transactions (ADNT). 20 tick size levels. Enforced on T7 from April 1, 2019. ETFs typically band 6. Price-dependent ticks.
  • RTS 25: Clock synchronization. HFT firms: within 1 microsecond of UTC. Others: within 1 millisecond. Traceability to UTC required. Documentation of sync arrangements.
  • German HFT Act: Effective May 15, 2013. BaFin registration mandatory. Algorithm labeling from April 1, 2014 (unique identifiers, change tracking). OTR compliance (volume and transaction-based). DEA notification from January 3, 2018.
  • Order Flagging: Algo flag, DEA flag, short selling indicator, SMP ID (mandatory since April 1, 2020 for algo proprietary trading), investment decision code, execution decision code. Fields 22 (algorithmic trading indicator) and 24 (human intervention indicator).
  • Short Code Registration: ClientID structure (short code mapping to long code). Natural persons: National ID. Legal persons: LEI (ISO 17442). GUI upload process. Transaction reports: TR160, TR161, TR167, TR168 generated 3x daily at 10:00, 14:00, 18:00 CET.
  • Algorithm Testing: T7 Cloud Simulation: 24/7, SSL/IPSEC, internet access, all interfaces (RDI, ETI, EMDI, MDI, EOBI). Custom orderbooks, trading phase simulation, failover testing, performance testing. Mandatory: consulting call with TMR, end-to-end test, connection test, certificate from DB CA.
  • Clock Synchronization Compliance: PTP IEEE 1588 ±50 ns. White Rabbit <1 ns (used internally). GPS antenna 10-100 ns. NTP for less stringent needs. HPT product for latency analysis.
  • MAR: EU 596/2014 effective July 2016. Prohibited: spoofing, layering, wash trading, benchmark manipulation. TSO: independent surveillance unit, sophisticated detection systems, cooperation with BaFin. Enforcement: fines, trading suspensions, exclusion, referral to criminal authorities.
  • OTR Penalties: Reprimand, fines up to EUR 1,000,000, exclusion up to 30 trading days, suspension up to 6 months, revocation. Progressive enforcement from monitoring through formal warning, penalties, exclusion, revocation.
  • Participant Admission: Mandatory steps: consulting call, end-to-end test, connection test, certificate creation, staff availability. Documentation: compliance policies, risk management framework, BCP, insurance, org structure. Ongoing: maintain compliance, notify of changes, periodic reviews, respond to audits, update testing on changes.
  • Compliance Summary Table: 13-row table mapping requirement to legal basis, key parameters, and effective date. Cover all RTS, German HFT Act, order flagging, short code, algorithm testing, MAR, OTR.

Target word count: 4,000-5,000 words

Chapter 11: Simulation & Testing Environments

File: chapters/11-simulation-testing/README.md

Front matter:

---
layout: default
title: "11. Simulation & Testing"
nav_order: 11
parent: Chapters
---

Required content: T7 Cloud Simulation (launched August 1 2025, 24/7, per-hour billing, cloudsim.deutsche-boerse.com, no post-trade or GUI), T7 Release Simulation (shared, mirrors production, mandatory participation, persists after go-live), Simulation Architecture (6 partitions: P1 Xetra German, P2/P3 Eurex equity/FI, P4 interest rate, P5 reserved, P55 Xetra non-German added Feb 16 2024, P6 Eurex FX FCUR/OCUR; NOT for performance testing, contact TKAM), Available Interfaces (ETI, FIX Gateway TLS mandatory since March 10 2023, EOBI/EMDI/MDI/RDI all with A/B multicast), Testing Capabilities (custom orderbooks, trading phase control, product state management, Liquidity Generator, Auto Matcher, Trade Reversal, Focus Day: 3 products 10 min + 1 hour exceptional), Release Simulation Schedule (T7 14.1 example timeline from Jan 2 2026 through dress rehearsal), Mandatory Testing Requirements (consulting call with TMR, end-to-end test, connection test, Readiness Statement via Member Section with Eurex PIN), Certificate Requirements (X.509v3 sha256RSA, DB CA only, separate per market/environment/access type, no limit on count), T7 GUI Testing (Eurex: t7gui.simulation.eurex.com/xeur/index.html, EEX: /xeee/index.html, Admin GUI, Controller GUI, T7 GUI Launcher with getdown), Market Data in Simulation, Performance and Stress Testing, T7 Market Replay Service (2+ replay cycles per day, MDReport bracket messages, part of EMDS), Disaster Recovery Testing, Member Section Portal.

Required source URLs:

  • https://www.eurex.com/ex-en/support/technology/t7-cloud-simulation
  • https://www.eurex.com/resource/blob/4629390/14655acd264bf07f5b8ef8ca2a6b47ba/data/T7_R.14.0_Participant_Simulation_Guide_Version_1.pdf
  • https://www.eurex.com/ex-en/support/initiatives/simulation-calendar

Per-section content requirements:

  • T7 Cloud Simulation: Launched August 1, 2025. On-demand dedicated 24/7 instances. SSL/IPSEC internet access. Per-hour billing with auto-termination. Login portal: cloudsim.deutsche-boerse.com. NO post-trade environment. NO GUI. Focused on core trading interfaces.
  • T7 Release Simulation: Shared environment mirroring production. Mandatory participation before each release. Simulation calendar published on eurex.com. Persists beyond production go-live.
  • Simulation Architecture: 6 partitions mirroring production topology. P1: Xetra German equities. P2/P3: Eurex equity and FI derivatives. P4: Eurex interest rate and FI. P5: Reserved/expansion. P55: Xetra non-German equities (added February 16, 2024). P6: Eurex FX (FCUR/OCUR). NOT for performance testing – infrastructure differs from production. Contact TKAM for performance testing.
  • Available Interfaces: ETI (full functional parity), FIX Gateway (FIX 4.2/4.4, TLS mandatory since March 10, 2023), EOBI (real-time Level 2, A/B multicast), EMDI (A/B multicast), MDI (A/B multicast), RDI (full reference data).
  • Testing Capabilities: Custom orderbooks (authorized users). Trading phase control (manual advancement). Product state management. Liquidity Generator (synthetic activity). Auto Matcher (rapid scenario progression). Trade Reversal (iterative testing). Focus Day: 3 designated products, 10 minutes intensive, then 1-hour exceptional market across entire market.
  • Release Simulation Schedule: T7 14.1 example: January 2, 2026 (14.0 enters production), March 23, 2026 (14.1 simulation starts), Weeks 1-2 (connectivity + basic functional), Weeks 3-4 (comprehensive functional), Week 5 (Focus Day), Week 6 (weekend sessions), Week 7 (dress rehearsal). Dedicated connectivity testing windows with TKAM.
  • Mandatory Testing: Consulting call with TMR staff. End-to-end test (full transaction flow through execution and clearing). Connection test (connectivity, auth, session management, heartbeat). Readiness Statement via Member Section portal with Eurex PIN credentials. Functional preparation mandatory before production access.
  • Certificate Requirements: X.509v3, sha256RSA. DB CA exclusive issuing authority. Separate per market (Eurex/Xetra/EEX), environment (production/simulation/cloud), access type (trading/market data/GUI). No limit on certificate count. Wrong/invalid = immediate access denial. Managed via Member Section portal.
  • T7 GUI Testing: Eurex Trader GUI: t7gui.simulation.eurex.com/xeur/index.html. EEX: t7gui.simulation.eurex.com/xeee/index.html. T7 Admin GUI. T7 Controller GUI (market control for authorized users). T7 GUI Launcher with getdown technology. Web-based, no local installation.
  • Market Data in Simulation: EMDI/MDI/EOBI with A/B multicast. Different IP ranges from production. Controlled failure scenarios. RDI with planned production configuration.
  • Performance Testing: NOT designed for production-scale. Contact TKAM. Focus Day provides stress testing within simulation limits.
  • T7 Market Replay Service: 2+ replay cycles per trading day. MDReport bracket messages for start/completion. Part of Extended Market Data Service (EMDS) subscription.
  • Disaster Recovery Testing: Simulates complete failover. Interface switching validation. DR concept document published annually on Member Section. Published schedule coordinated with simulation calendar.
  • Member Section Portal: Simulation calendar, certificate generation, credential management, TKAM consultation, Readiness Statements, technical documentation, system status monitoring.

Target word count: 3,500-4,500 words

Chapter 12: Developer Onboarding & Resources

File: chapters/12-developer-onboarding/README.md

Front matter:

---
layout: default
title: "12. Developer Onboarding"
nav_order: 12
parent: Chapters
---

Required content: Getting Started 5-phase (Phase 1: contact client.services@eurex.com, min equity EUR 50,000, eXAS portal; Phase 2: compliance; Phase 3: simulation; Phase 4: technical setup certificates/network/interfaces; Phase 5: production go-live with TKAM onboarding-team@deutsche-boerse.com), Essential Documentation (4-week prioritized reading: Week 1 Network Access Guide + Participant Maintenance + Incident Handling; Week 2 ETI/FIX Manual + Message Reference + Simulation Guide; Week 3 EMDI/MDI/RDI + EOBI manuals; Week 4 Emergency Playbook + Release Notes + Known Limitations), Developer Portal (developer.deutsche-boerse.com, docs.developer.deutsche-boerse.com, console.developer.deutsche-boerse.com/apis), Connectivity Setup 7 steps, SDK and Reference Implementations (NO comprehensive SDKs; STEP Python tool, XML FAST templates 1.1/1.2, FIXML schemas, XSD for ETI), ISV Program (vendors@deutsche-boerse.com, NO conformance testing/certification by Eurex), Training & Education (Capital Markets Academy academy.deutsche-boerse.com, NO developer bootcamp), Key Contact Points table (CTS +49-69-211-10888 cts@deutsche-boerse.com Mon 00:00-Fri 22:00; Client Services client.services@eurex.com; Member Section +49-69-211-17888 member.section@deutsche-boerse.com; TMR onboarding-team@deutsche-boerse.com; ISV vendors@deutsche-boerse.com), Staying Informed (circulars, production newsboard, readiness newsflashes, implementation news, release initiative pages, known limitations), Critical Upcoming Changes (TLS 1.2 decommissioning May 2026, new ETI order requests May 2026, ETI password encryption changes May 2025), Common Pitfalls (wrong certificates, deprecated FIX Gateway 4.4, RDI required for multicast, simulation not for performance testing), Events & Community (Open Day, Eurex Derivatives Forum, Focused Testing Days, NO public developer forum), T7 Ecosystem 9+ exchanges, System Availability Eurex 99.97% / FWB 99.98% over 20 years.

Required source URLs:

  • https://developer.deutsche-boerse.com
  • https://docs.developer.deutsche-boerse.com/
  • https://www.eurex.com/ex-en/trade/exchange-membership
  • https://www.eurex.com/ex-en/support/technology/isv-service-provider
  • https://academy.deutsche-boerse.com/

Per-section content requirements:

  • Getting Started Phase 1: Contact client.services@eurex.com. Admission requirements: minimum equity capital EUR 50,000 (unless bank or MiFID II regulated), trader registration, back office staff, clearing membership (direct or relationship). eXAS portal for formal admission.
  • Phase 2: Exchange rules review (Eurex Exchange Rules, Xetra Trading Rules), terms and conditions, fee regulations, KYC/AML due diligence. Parallel with technical preparation.
  • Phase 3: Simulation access. T7 GUI, ETI, FIX LF, Cloud Simulation. Synthetic market data. Separate network infrastructure.
  • Phase 4: Certificate management (DB CA mandatory, separate per market/env/access type, TLS 1.3 mandatory, TLS 1.2 decommissioned May 2026, approved cipher suites secp384r1/secp521r1/Ed25519/Ed448). Network connectivity (leased line or internet with SSL/IPSEC). IP address allocation (separate production/simulation). Interface selection (ETI vs FIX LF, EOBI vs EMDI, RDI mandatory for multicast).
  • Phase 5: TKAM coordination at onboarding-team@deutsche-boerse.com. Pre-production testing, capacity planning, production credentials, cutover execution, post-launch monitoring.
  • Essential Documentation: 4-week prioritized plan. Week 1: Network Access Guide, Participant Maintenance Manual, Incident Handling Guide. Week 2: ETI Manual (or FIX LF Manual), Message Reference, Participant Simulation Guide. Week 3: EMDI/MDI/RDI Manual, EOBI Manual. Week 4: Emergency Playbook, Release Notes, Known Limitations.
  • Developer Portal: developer.deutsche-boerse.com (main), docs.developer.deutsche-boerse.com (documentation), console.developer.deutsche-boerse.com/apis (API catalogue + Eurex Reference Data API with RESTful/GraphQL, JSON/XML).
  • Connectivity Setup: 7 steps (network access config, certificate management, firewall rules, IP allocation, interface selection, simulation testing, TKAM coordination).
  • SDK and Reference Implementations: NO comprehensive SDKs. STEP (Python ETI password encryption), XML FAST templates 1.1/1.2, FIXML schemas, XSD for ETI. Third-party vendor libraries available but not endorsed.
  • ISV Program: Register via vendors@deutsche-boerse.com. Must be registered participant or sponsored. Benefits: simulation access, CTS support, Eurex webpage listing, documentation distribution, focused testing days. NO conformance testing or certification by Eurex.
  • Training: Capital Markets Academy (academy.deutsche-boerse.com) with courses and certifications. Eurex Online System Training. Trader Examination Preparation. NO developer-specific bootcamp. Relies on self-study + simulation + CTS support.
  • Key Contact Points Table: CTS +49-69-211-10888 cts@deutsche-boerse.com Mon 00:00-Fri 22:00 CET; Client Services client.services@eurex.com Mon-Fri 09:00-18:00; Member Section +49-69-211-17888 member.section@deutsche-boerse.com Mon-Fri 09:00-18:00; TMR onboarding-team@deutsche-boerse.com Mon-Fri 09:00-18:00; ISV vendors@deutsche-boerse.com Mon-Fri 09:00-18:00.
  • Staying Informed: Subscribe to circulars (focus on Releases & Technology, Regulatory). Production Newsboard (real-time status). Readiness Newsflashes. Implementation News. Release Initiative Pages. Known Limitations Documents.
  • Critical Upcoming Changes: TLS 1.2 decommissioning May 2026 (Release 14.1). New ETI order entry requests mandatory May 2026. ETI password encryption changes May 2025.
  • Common Pitfalls: Wrong certificates (maintain inventory by market/env/access), deprecated FIX Gateway 4.4 (migrate to FIX LF), ETI password encryption outdated (use current STEP), RDI required for multicast (must implement before EOBI), simulation NOT for performance testing.
  • Events: Open Day (annual, exchange lab tours, technical presentations, networking). Eurex Derivatives Forum (annual, market structure, product innovation). Focused Testing Days (exchange-organized pre-release). NO public developer forum.
  • T7 Ecosystem: 9+ European exchanges use T7. System availability: Eurex 99.97%, FWB (Xetra) 99.98% over 20 years.

Target word count: 4,000-5,500 words

Section 6: APPENDIX SPECIFICATIONS

Glossary

File: chapters/appendix/glossary.md

Front matter:

---
layout: default
title: "Glossary"
nav_order: 1
parent: Appendices
---

Include ALL of the following terms with their definitions. Organized alphabetically by letter heading (## A, ## B, etc.). Each term is an H3 heading. Include cross-reference links to relevant chapters using *See: [Chapter N](path)* format.

A:

  • ACE (Automated Corridor Expansion) – Mechanism that automatically widens volatility interruption price corridors in specified time intervals.
  • Advanced Risk Protection (ARP) – Risk management feature in T7 that monitors trading activity in real-time to prevent breach of risk limits.
  • Algo ID – Unique identifier assigned to algorithmic trading strategies for regulatory flagging under MiFID II.
  • Auction – Trading phase where orders are collected without immediate execution, then matched at a single equilibrium price.

B:

  • BaFin – Bundesanstalt fur Finanzdienstleistungsaufsicht - German Federal Financial Supervisory Authority.
  • Binary Protocol – Wire-level encoding used by ETI and EOBI for minimal serialization overhead and lowest latency.
  • Book-or-Cancel (BOC) – Order type that must be fully added to the order book or be cancelled entirely.

C:

  • C7 – Deutsche Boerse’s clearing system for cash market transactions.
  • Central Counterparty (CCP) – Entity that interposes itself between counterparties to trades.
  • Clearstream – Deutsche Boerse’s post-trade services division.
  • CLIP (Central Limit Order Book Improvement Process) – Eurex Improve mechanism providing 150ms price improvement window for options.
  • Cloud Simulation – T7 on-demand testing environment providing 24/7 dedicated instance access. Launched August 2025.
  • CoLo 2.0 – Deutsche Boerse’s latest generation colocation facility.
  • Cross-Connect – Physical fiber connection (EUR 150/month).

D:

  • D7 – Market data distribution system.
  • DAX – Deutsche Boerse’s flagship equity index comprising the 40 largest German companies.
  • DEA (Direct Electronic Access) – Arrangement where trading member allows clients to use its trading identity.
  • Designated Sponsor – Market participant committed to providing continuous bid and ask quotes.
  • Deutsche Boerse AG – Germany’s leading exchange organization.
  • Drop Copy – ETI service providing real-time copy of order and trade activity.

E:

  • EEX – European Energy Exchange.
  • EMDI – Enhanced Market Data Interface.
  • EnLight (SRQS) – Eurex’s Selective Request for Quote Service.
  • EOBI – Enhanced Order Book Interface - ultra-low latency market data feed.
  • Equinix FR2 – Primary co-location data center in Frankfurt (Rebstocker Strasse 33, 60326).
  • ESU (Excessive System Usage) – Fee regime penalizing excessive message rates.
  • ETF – Exchange-Traded Fund.
  • ETI – Enhanced Trading Interface - native binary protocol.
  • Eurex – Europe’s largest derivatives exchange.
  • Eurex Clearing – Central counterparty within Deutsche Boerse Group.
  • ExecutionReport – ETI response message confirming order acceptance, modification, fill, or cancellation.

F:

  • FAST (FIX Adapted for Streaming) – Data compression protocol for EMDI and MDI feeds.
  • Fill-or-Kill (FOK) – Order type that must be executed immediately in its entirety or cancelled.
  • FIX – Financial Information eXchange protocol.
  • FIX LF – FIX Low-Frequency interface replacing legacy FIX Gateway. Supports FIX 4.2 and 4.4.
  • FWB – Frankfurter Wertpapierborse (Frankfurt Stock Exchange).

G:

  • Good-Till-Cancelled (GTC) – Order remains active until executed or explicitly cancelled.
  • Good-Till-Date (GTD) – Order remains active until a specified date.
  • GPS Antenna – Roof-mounted GPS receiver providing 10-100 ns accuracy at EUR 850/month.

H:

  • Heartbeat – Periodic keep-alive message exchanged between application and gateway.
  • High-Frequency Session (HF Session) – T7 session optimized for algorithmic trading with partition-specific access.
  • HPT (High Precision Timestamps) – Nanosecond-precision timestamps for latency analysis.

I:

  • IBIS – Integriertes Borsenhandels- und Informationssystem - predecessor to Xetra, launched 1991.
  • Immediate-or-Cancel (IOC) – Execute immediately for any available quantity, cancel unfilled.

K:

  • Kill Switch – Emergency mechanism to halt all trading. Requires 4-eyes principle.

L:

  • LEI (Legal Entity Identifier) – ISO 17442 standard identifier for MiFID II reporting.
  • Low-Frequency Gateway (LF Gateway) – Multi-partition access gateway.
  • Low-Frequency Session (LF Session) – Standard T7 trading session for traditional order flow.

M:

  • Market Data Interface (MDI) – Generic term for Deutsche Boerse’s market data systems.
  • Market Maker – Professional firm providing continuous two-sided quotes.
  • Market Reset – Emergency procedure where T7 halts trading and restarts.
  • Matching Engine – Core T7 component executing order matching logic.
  • MiFID II – Markets in Financial Instruments Directive II.
  • MMP (Market Maker Protection) – Automated protection monitoring volume/delta/vega/percent.
  • MOQ (Maximum Order Quantity) – Pre-trade risk limit.
  • MOV (Maximum Order Value) – Pre-trade risk limit.
  • Multicast – UDP network distribution for market data (EOBI, EMDI, MDI, RDI).

N:

  • N7 – Deutsche Boerse’s network infrastructure.

O:

  • Open Market (Freiverkehr) – German unregulated trading segment.
  • OTR (Order-to-Trade Ratio) – Volume-based: (ordered/traded)-1. Transaction-based: (orders/trades)-1.

P:

  • Partition – Logical subdivision of T7 matching engine.
  • Partition-Specific Gateway (PS Gateway) – Direct T7 access gateway to single partition.
  • Passive Liquidity Protection (PLP) – Risk control deferring aggressive orders.
  • Price-Time Priority (PTP) – Primary matching algorithm.
  • PRISMA – Portfolio Risk Integrated Assessment - Eurex Clearing’s margin methodology (99/99.5%).
  • Pro-Rata (PTR) – Alternative matching allocating fills proportionally by displayed quantity.

R:

  • RDI – Reference Data Interface.
  • Readiness Statement – Mandatory participant submission before each T7 release.
  • Regulated Market – Trading venue meeting EU MiFID II requirements.
  • RTS (Regulatory Technical Standards) – Key: RTS 6 (algo), RTS 7 (venue), RTS 11 (tick sizes), RTS 25 (clock sync).

S:

  • Self-Match Prevention (SMP) – Prevents trader’s orders from matching own opposite-side orders.
  • ServiceAvailabilityBroadcast – T7 message notifying of trading service status changes.
  • Side A / Side B – Live-live redundancy architecture.
  • SRQS – See EnLight.
  • STEP – Sample Tool for ETI Password Encryption (Python reference implementation).

T:

  • T7 – Deutsche Boerse’s flagship trading platform.
  • TES – Trade Entry Services for off-book trade reporting.
  • TKAM (Technical Key Account Manager) – Dedicated technical contact.
  • TLS 1.3 – Mandatory encryption protocol. TLS 1.2 decommissioned Release 14.1 (May 2026).
  • TMR (Technical Member Readiness) – Deutsche Boerse testing coordination team.
  • TPS – Transactions Per Second.
  • Trade-at-Close – Xetra phase (17:35-17:45 CET) at closing auction price.
  • TSL (Transaction Size Limits) – Risk limits configurable by clearing members.
  • TSO (Trading Surveillance Office) – Independent exchange monitoring body.

U:

  • UDP – User Datagram Protocol for multicast market data.

V:

  • Volatility Interruption – Automatic trading halt when prices exceed thresholds.
  • VSTOXX – EURO STOXX 50 Volatility Index.

W:

  • White Rabbit – Sub-nanosecond (<1 ns) precision time synchronization from CERN.

X:

  • Xetra – Exchange Electronic Trading - Deutsche Boerse’s cash equities platform.

Total: 89 terms

Quick Reference

File: chapters/appendix/quick-reference.md

Include 10 numbered reference cards as tables:

  1. Key Metrics at a Glance – 7-row table: minimum reaction time 2,787 ns, median order latency <55 us, LF gateway +12 us, EOBI lead 1.5 us, peak throughput 201K msg/sec, daily requests 1.25B (April 2025), availability 99.97-99.98%
  2. Session Types & Throttle Limits – HF Light 50 TPS EUR 125/250, HF Full 150 TPS EUR 250/500, HF Ultra 250 TPS, max 600 sessions. Add note below the session types table: “Session limits and pricing are set by Eurex circular and may change at any time. Verify current limits at the Eurex Circulars page. Last known update: June 2024 (limit increased from 400 to 600).”
  3. Market Data Feeds Comparison – EOBI/EMDI/MDI/RDI with protocol, depth, latency, CoLo fee
  4. Gateway Types – PS vs LF with latency, access, use case
  5. Co-Location Costs – CoLo 2.0 EOBI/EMDI/ETI fees, cross-connect EUR 150, PTP EUR 400, rack 5 kVA EUR 3,390
  6. Time Synchronization Options – PTP EUR 400 ±50ns, GPS EUR 850, White Rabbit <1 ns
  7. Risk Control Parameters – PLP deferral 1-3ms, OTR factors 1/1.5/2/4, OTR penalty max EUR 1M, SMP default CP since Dec 2025; PRISMA 99/99.5%, SITG EUR 143M, SSITG EUR 57M, total EUR 200M
  8. Key Regulatory Dates – German HFT Act May 15 2013, MiFID II Jan 3 2018, SMP mandatory April 1 2020, SMP default Dec 1 2025, T7 14.0 Nov 10 2025, T7 14.1 May 18 2026
  9. Key Contact Points – CTS, Client Services, Member Section, ISV, Clearing Support with emails and phones
  10. Essential URLs – T7 Cloud Simulation, Developer Portal, GitHub, API docs, Production Newsboard, Circulars, Member Section

Also include Quick Decision Trees (session type, gateway type, market data feed, time sync) and Abbreviations Reference table.

Release History

File: chapters/appendix/release-history.md

Front matter:

---
layout: default
title: "Release History"
nav_order: 3
parent: Appendices
---

Major Release Timeline Table (must include all entries):

Release Date Key Features for HFT
T7 1.0 Dec 2012 Initial T7 launch on Eurex, replacing legacy system. Modern microservice architecture. Baseline latency ~50-100 us.
T7 2.0 Jun 2013 Xetra migration to T7. Cash and derivatives on unified stack. Market data standardization.
T7 3.0 2014 EOBI introduction. UDP multicast market data. Improved granularity and lower latency.
T7 5.0 2015 SMP introduction. Parallel order book processing across CPU cores. Partitioning scheme. Latency ~20-30 us.
T7 6.0 Nov 2016 MiFID II preparation. Algorithmic order flagging. Enhanced order routing. Pre-trade risk controls.
T7 7.0 Jun 2017 Full MiFID II compliance. RTS 25 timestamp sync (100 us). OTR monitoring. Transaction reporting.
T7 8.0 Dec 2018 Post-MiFID II enhancements. Performance optimizations. Enhanced surveillance.
T7 9.0 Nov 2019 FIX LF introduction (replacing legacy FIX Gateway). FIX 5.0 SP2. Partition improvements. Market maker protection.
T7 10.0 Nov 2020 TSL enhancements. New partition structure. Latency ~10-15 us minimum.
T7 10.1 Jun 2021 PS Gateway consolidation with ME on same server. Eliminated inter-server hops. ~5-8 us reduction.
T7 11.0 Nov 2021 Performance optimizations. Capacity increases per partition. Memory architecture improvements.
T7 11.1 Jun 2022 ETI password encryption enhancements. Short Code solution 2.0. Order routing optimizations.
T7 12.0 Nov 2023 EOBI and EMDI publisher integration into ME process. ~4 us market data latency reduction. Unified order requests. MOV enhancements.
T7 12.1 Jun 2024 Static volatility interruptions (activated Jul 8, 2024). Partition expansion 5 to 6. Xetra Midpoint launch (Dec 2024).
T7 13.0 May 2024 Further ME performance optimizations. Improved order book update efficiency. Reduced reconnection latency.
T7 13.1 Nov 2024 Tech Refresh 2024: latest Intel Xeon processors. PTP improved to 4-5 ns RMS. 2x throughput capacity.
T7 14.0 Nov 2025 SMP CP mode default (Dec 1, 2025). New ETI order entry requests. ESU passive/aggressive split. Extended Retail Trading. T7 Clearer Web GUI.
T7 14.1 May 2026 (planned) TLS 1.2 decommissioning (TLS 1.3 only). Mandatory new ETI order requests. Synthetic matching for STIR packs/bundles. Optimized field layouts.

Key Architectural Milestones in 4 phases:

  • Phase 1: Platform Foundation (2012-2014) – T7 deployment, Xetra migration, EOBI introduction
  • Phase 2: Performance & Scalability (2015-2018) – SMP, partitioning, MiFID II compliance
  • Phase 3: Latency Optimization (2019-2023) – FIX LF, PS/ME co-location, EOBI/EMDI ME integration
  • Phase 4: Modern Platform (2024-2026) – Tech Refresh 2024, CoLo 2.0, SMP enhancements, TLS 1.3

Performance Evolution Table:

Period Typical Minimum Latency Key Enablers
2012-2014 50-100 us Initial architecture, single-core
2015-2016 20-30 us SMP introduction, partitioning
2017-2019 10-20 us Software optimizations, FIX LF
2020-2021 8-12 us PS Gateway consolidation
2022-2023 5-8 us EOBI integration, ME optimizations
2024-present 2.5-5 us Tech Refresh 2024, hardware + software

Release cadence: Biannual – major releases November, minor releases May/June. Backward compatibility maintained for at least two release cycles. Mandatory migrations communicated 12+ months in advance.

Looking Forward: Sub-microsecond targets, enhanced capacity, potential FPGA acceleration, market data compression, finer-grained risk controls.

Pricing Summary

File: chapters/appendix/pricing-summary.md

Include: Disclaimer noting prices approximate as of early 2026. Xetra CoLo 2.0 table (EMDI EUR 5,200, EOBI EUR 6,240, combined EUR 7,280, ETI EUR 6,000). Eurex CoLo 2.0 table (EMDI EUR 6,000, EOBI Futures EUR 7,200, rebate -EUR 750; ~15% increase Jan 1 2026). 1 Gbit/s Prime Order Entry EUR 5,600 (Nov 2025, max 6 connections). Session pricing tables for Eurex (HF Light EUR 125/250, HF Full EUR 250/500, HF Ultra see price list) and Xetra (HF Light EUR 250, HF Full EUR 500). Back-Office sessions EUR 100-104. Rack space table 3-6 kVA EUR 2,330-3,910. Cross-connect EUR 150. Time sync (PTP EUR 400, GPS EUR 850, White Rabbit contact). Remote connectivity table 7 Mbit/s EUR 520+ through 760 Mbit/s EUR 6,760+. MMSP EUR 4,000 basic (up from EUR 3,000 since April 2022). GUI EUR 310 standalone or free with other connectivity. Total Cost of Ownership example: dual-connected Eurex HFT ~EUR 30,790/month (~EUR 369,480/year). Cost optimization strategies. Price list reference URLs.

Required tables (must include all data points):

Xetra CoLo 2.0 (10 Gbit/s) Table:

Service Monthly Fee (EUR) Description
CoLo 2.0 EMDI 5,200 Enhanced Market Data Interface
CoLo 2.0 EOBI 6,240 Enhanced Order Book Interface
CoLo 2.0 EMDI + EOBI 7,280 Combined market data
CoLo 2.0 ETI (Transaction) 6,000 Order entry and management

Eurex CoLo 2.0 (10 Gbit/s) Table:

Service Monthly Fee (EUR) Description
CoLo 2.0 EMDI 6,000 Eurex derivatives market data
CoLo 2.0 EOBI Futures 7,200 Ultra-low latency futures data
Connection Rebate (dual) -750 per connection Discount for redundant connectivity

Notes: ~15% increase effective January 1, 2026. Dual connection rebate EUR 750 per connection (EUR 1,500 total monthly for redundant pair).

1 Gbit/s Prime Order Entry: EUR 5,600/month (introduced November 2025, max 6 connections, CoLo only).

Eurex ETI Session Pricing:

Session Type Max TPS Sessions 1-4 (EUR/mo) Session 5+ (EUR/mo)
HF Light 50 125 250
HF Full 150 250 500
HF Ultra 250 See Price List See Price List

Note on HF Ultra pricing: HF Ultra (250 TPS) pricing is not published in standard price lists. Participants must contact Deutsche Boerse directly. Do not state or estimate a specific EUR figure for HF Ultra sessions.

Xetra ETI Session Pricing:

Session Type Monthly Fee (EUR)
ETI HF Light 250
ETI HF Full 500

Back-Office Sessions: EUR 100-104/mo. FIX LF Back Office EUR 100/mo. Rebate up to EUR 1,000-1,040 per trading member.

Rack Space (Equinix FR2):

Power Monthly Fee (EUR)
3 kVA 2,330
4 kVA 2,870
5 kVA 3,390
6 kVA 3,910

Time Synchronization:

Service Monthly Fee (EUR) Accuracy
Standard PTP 400 ±50 ns (4-5 ns RMS typical)
GPS Antenna 850 10-100 ns
White Rabbit Contact DB <1 ns

Remote Connectivity (Leased Lines):

Bandwidth Monthly Fee (EUR)
7 Mbit/s 520+
14 Mbit/s 750+
80 Mbit/s 2,100+
200 Mbit/s 3,800+
260 Mbit/s 4,600+
760 Mbit/s 6,760+

MMSP: EUR 4,000/mo basic fee (up from EUR 3,000 since April 1, 2022).

GUI: EUR 310/mo standalone; free with other connectivity.

Cross-Connect: EUR 150/mo per connection.

Total Cost of Ownership Example (Dual-Connected Eurex HFT):

Component Qty Unit Cost (EUR) Total (EUR)
Eurex CoLo 2.0 EMDI 2 6,000 12,000
Eurex CoLo 2.0 EOBI Futures 2 7,200 14,400
Dual Connection Rebate 4 -750 -3,000
Eurex ETI HF Full Sessions 8 250-500 3,000
Physical Cross-Connects 4 150 600
Standard PTP 1 400 400
Equinix Rack Space (5 kVA) 1 3,390 3,390
Total Monthly     30,790

Annual: EUR 369,480.

Cost Optimization Strategies: Right-size connectivity (1 Gbit/s for moderate frequency), consolidate sessions (leverage sessions 1-4 pricing), selective market data (EMDI vs EOBI based on latency needs), shared infrastructure (MMSP), remote for non-critical systems.

Required source URLs (all 5 official price lists):

  • https://www.eurex.com/resource/blob/2567152/6c913fe00107e1cf1c2ffe3b506f9dfc/data/2025_01_01_efag_preisv_anv-e_en.pdf
  • https://www.cashmarket.deutsche-boerse.com/resource/blob/2954524/adc1ef0e9fbf67ade042dcd205a70917/data/20220223_Bandwidths-and-Connection-Fees.pdf
  • https://www.mds.deutsche-boerse.com/resource/blob/3347708/67fafc73c58441b867d1ce08ce720f3c/data/MDDA_Price_List_12_2.pdf
  • https://www.eurex.com/resource/blob/4821986/38ad2da44adee0c1f86b0ae7415e7d23/data/2025_11_11-connection-agreement-for-spa-pricelist_en.pdf
  • https://www.eurex.com/resource/blob/4803696/43359c9b6a32316ac0fd11501f6a88d7/data/Eurex_Circular_104_25_en_Attach1.pdf

Section 7: DIAGRAM SPECIFICATIONS

Diagram 1: T7 Architecture Overview

File: diagrams/t7-architecture-overview.md

Front matter:

---
layout: default
title: "T7 Architecture Overview"
nav_order: 1
parent: Diagrams
---

Mermaid code (VERBATIM):

flowchart TB
    subgraph Participants["Participant Layer"]
        HFS["High Frequency Session<br/>(Partition-Specific)<br/>Max 150 TPS"]
        LFS["Low Frequency Session<br/>(Multi-Partition)<br/>Single Connection"]
        FIXS["FIX Session<br/>(Industry Standard)<br/>Protocol Translation"]
        GUI["T7 GUI<br/>(Manual Trading)<br/>Web Interface"]
    end

    subgraph Gateways["Gateway Layer"]
        PSG1["PS Gateway 1<br/>(Partition 1)<br/>Co-located with ME"]
        PSG2["PS Gateway 2<br/>(Partition 2)<br/>Co-located with ME"]
        PSG3["PS Gateway N<br/>(Partition 11)<br/>Co-located with ME"]
        LFG["LF Gateways<br/>(All Partitions)<br/>+12us latency"]
        FIXG["FIX Gateways<br/>(Route via PS)<br/>Direct to partition"]
    end

    subgraph Core["Core Processing Layer"]
        subgraph Part1["Partition 1"]
            ME1["Matching Engine<br/>In-Memory State<br/>FIFO Processing"]
            RISK1["Risk Engine<br/>Pre-Trade Checks<br/>ARP / PTR Limits"]
        end
        subgraph Part2["Partition 2"]
            ME2["Matching Engine<br/>In-Memory State<br/>FIFO Processing"]
            RISK2["Risk Engine<br/>Pre-Trade Checks<br/>ARP / PTR Limits"]
        end
        subgraph PartN["Partition 11"]
            MEN["Matching Engine<br/>In-Memory State<br/>FIFO Processing"]
            RISKN["Risk Engine<br/>Pre-Trade Checks<br/>ARP / PTR Limits"]
        end
    end

    subgraph MarketData["Market Data Layer"]
        EOBI["EOBI<br/>Enhanced Order Book<br/>Full depth, all updates"]
        EMDI["EMDI<br/>Integrated in ME<br/>Lowest latency"]
        MDI["MDI<br/>Market Data Interface<br/>Aggregated data"]
        RDI["RDI<br/>Reference Data<br/>Static instrument data"]
    end

    subgraph Persistence["Persistence Layer"]
        PERS["Persistent Storage<br/>GTC/GTD Orders<br/>Survives failover"]
    end

    subgraph Redundancy["Redundancy Infrastructure"]
        RoomA["Room A<br/>Active System<br/>Primary Site"]
        RoomB["Room B<br/>Backup System<br/>Geographic Separation"]
        RedLink["Redundancy Link<br/>State Synchronization<br/>Emergency Backup"]
    end

    HFS --> PSG1
    HFS -.-> PSG2
    HFS -.-> PSG3
    LFS --> LFG
    FIXS --> FIXG
    GUI --> LFG

    PSG1 --> ME1
    PSG2 --> ME2
    PSG3 --> MEN
    LFG --> ME1
    LFG --> ME2
    LFG --> MEN
    FIXG --> PSG1
    FIXG -.-> PSG2
    FIXG -.-> PSG3

    ME1 --> RISK1
    ME2 --> RISK2
    MEN --> RISKN

    ME1 --> EOBI
    ME1 --> EMDI
    ME1 --> MDI
    ME2 --> EOBI
    ME2 --> EMDI
    ME2 --> MDI
    MEN --> EOBI
    MEN --> EMDI
    MEN --> MDI

    ME1 -.-> PERS
    ME2 -.-> PERS
    MEN -.-> PERS

    RDI -.-> Participants

    Part1 -.-> RoomA
    Part2 -.-> RoomA
    PartN -.-> RoomA
    RoomA <-.-> RedLink
    RedLink <-.-> RoomB

    classDef participantStyle fill:#e1f5ff,stroke:#0066b3,stroke-width:2px,color:#000
    classDef gatewayStyle fill:#cce7ff,stroke:#0052a3,stroke-width:2px,color:#000
    classDef coreStyle fill:#b3d9ff,stroke:#003d7a,stroke-width:2px,color:#000
    classDef dataStyle fill:#d4edda,stroke:#28a745,stroke-width:2px,color:#000
    classDef persistStyle fill:#fff3cd,stroke:#ffc107,stroke-width:2px,color:#000
    classDef redundancyStyle fill:#f8d7da,stroke:#dc3545,stroke-width:2px,color:#000

    class HFS,LFS,FIXS,GUI participantStyle
    class PSG1,PSG2,PSG3,LFG,FIXG gatewayStyle
    class ME1,ME2,MEN,RISK1,RISK2,RISKN coreStyle
    class EOBI,EMDI,MDI,RDI dataStyle
    class PERS persistStyle
    class RoomA,RoomB,RedLink redundancyStyle

Surround with descriptive text covering Architecture Layers (Participant, Gateway, Core Processing, Market Data, Persistence, Redundancy) and Key Architectural Characteristics (partition isolation, public data first, deterministic processing, CoLo 2.0 fairness, no batching, sub-55 us latency).

Diagram 2: Network Topology

File: diagrams/network-topology.md

Front matter:

---
layout: default
title: "Network Topology"
nav_order: 2
parent: Diagrams
---

Mermaid code (VERBATIM):

flowchart TB
    subgraph Remote["Remote Participants"]
        RLL["Leased Line<br/>Participants<br/>(7-200 Mbit/s)"]
        RVPN["iAccess VPN<br/>Participants<br/>(IPSec)"]
    end

    subgraph Equinix["Equinix FR2 Data Center - Frankfurt<br/>Rebstöcker Straße 33, 60326"]
        subgraph CoLo["Co-Located Participant Infrastructure"]
            CTS1["Trading Server 1"]
            CTS2["Trading Server 2"]
            CMDS["Market Data Server"]
            direction LR
        end

        subgraph Network["10 GbE Network Infrastructure"]
            subgraph TN["Transaction Network (ETI)"]
                PSG["PS Gateways<br/>(Partition-Specific)<br/>Side A & B"]
                LFG["LF Gateways<br/>(Low-Frequency)<br/>Side A & B"]
            end

            subgraph MDN["Market Data Network"]
                EOBI["EOBI<br/>(UDP Multicast)<br/>Side A & B"]
                EMDI["EMDI<br/>(UDP Multicast)<br/>Side A & B"]
                MDI["MDI<br/>(UDP Multicast)<br/>Side A & B"]
                RDI["RDI<br/>(UDP Multicast)<br/>Side A & B"]
            end

            subgraph GUIN["GUI Network"]
                GUI["Eurex Trader GUI<br/>T7 Web Apps<br/>(HTTPS)"]
            end

            subgraph BON["Back-Office Network"]
                BO["Account Management<br/>Trade Reporting<br/>Drop Copy<br/>Risk Config"]
            end
        end

        subgraph Time["Time Synchronization"]
            PTP["Standard PTP<br/>(±50 ns)<br/>EUR 400/mo"]
            WR["White Rabbit<br/>(<1 ns)<br/>Sub-nanosecond"]
            GPS["GPS Antenna<br/>(10-100 ns)<br/>EUR 850/mo"]
        end

        subgraph T7Room["T7 Matching Engine Infrastructure"]
            subgraph RoomA["Room A (Primary)"]
                MEA["Matching Engines<br/>Partitions 1-11<br/>Side A"]
            end

            subgraph RoomB["Room B (Backup)"]
                MEB["Matching Engines<br/>Partitions 1-11<br/>Side B"]
            end

            RL["Redundancy Link<br/>(Room A ↔ Room B)"]
        end
    end

    RLL -->|Dual Lines<br/>Different Providers| Network
    RVPN -->|Internet<br/>IPSec Tunnel| Network

    CTS1 -.->|10 GbE<br/>EUR 6,000/mo<br/>Cross-Connect| TN
    CTS2 -.->|10 GbE<br/>EUR 6,000/mo<br/>Cross-Connect| TN
    CMDS -.->|10 GbE<br/>EUR 6,000-8,400/mo<br/>Cross-Connect| MDN

    PSG -->|TCP/IP<br/>TLS 1.3<br/>Ultra-Low Latency| MEA
    PSG -->|TCP/IP<br/>TLS 1.3<br/>Ultra-Low Latency| MEB
    LFG -->|TCP/IP<br/>TLS 1.3<br/>Multi-Partition| MEA
    LFG -->|TCP/IP<br/>TLS 1.3<br/>Multi-Partition| MEB

    MEA -->|FIX 5.0 SP2<br/>FAST Encoding| EMDI
    MEA -->|Binary Protocol| EOBI
    MEA -->|FIX 5.0 SP2<br/>FAST Encoding| MDI
    MEA -->|FIX 5.0 SP2<br/>FAST Encoding| RDI

    MEB -->|FIX 5.0 SP2<br/>FAST Encoding| EMDI
    MEB -->|Binary Protocol| EOBI
    MEB -->|FIX 5.0 SP2<br/>FAST Encoding| MDI
    MEB -->|FIX 5.0 SP2<br/>FAST Encoding| RDI

    Time -.->|1 Gbps SMF<br/>Cross-Connect| CoLo

    MEA -.->|State<br/>Replication| RL
    RL -.->|State<br/>Replication| MEB

    classDef remote fill:#e1f5ff,stroke:#0277bd,stroke-width:2px
    classDef colo fill:#fff3e0,stroke:#ef6c00,stroke-width:2px
    classDef network fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    classDef matching fill:#e8f5e9,stroke:#388e3c,stroke-width:3px
    classDef time fill:#fff9c4,stroke:#f9a825,stroke-width:2px
    classDef gui fill:#fce4ec,stroke:#c2185b,stroke-width:2px

    class RLL,RVPN remote
    class CTS1,CTS2,CMDS colo
    class PSG,LFG,EOBI,EMDI,MDI,RDI,BO network
    class MEA,MEB,RL matching
    class PTP,WR,GPS time
    class GUI gui

Surround with descriptive text covering all network components, redundancy, latency optimization, and pricing summary.

Diagram 3: Order Lifecycle Flow

File: diagrams/order-flow.md

Front matter:

---
layout: default
title: "Order Lifecycle"
nav_order: 3
parent: Diagrams
---

Main state diagram Mermaid code (VERBATIM):

stateDiagram-v2
    [*] --> New: Order Submitted
    New --> PendingNew: Gateway Received

    PendingNew --> Acknowledged: Matching Engine Accepted
    PendingNew --> Rejected: Risk Check Failed/<br/>Invalid Parameters

    Acknowledged --> PartiallyFilled: Partial Execution
    Acknowledged --> Filled: Full Execution
    Acknowledged --> Cancelled: User/System Cancel
    Acknowledged --> Modified: Price/Qty Change
    Acknowledged --> Expired: TIF Expired<br/>(GFD/GTD)
    Acknowledged --> SMP_Cancelled: Self-Match Prevention
    Acknowledged --> Suspended: Volatility Interruption

    PartiallyFilled --> Filled: Remaining Qty Matched
    PartiallyFilled --> Cancelled: Cancel Remaining
    PartiallyFilled --> Modified: Modify Remaining
    PartiallyFilled --> SMP_Cancelled: Self-Match Prevention
    PartiallyFilled --> Suspended: Volatility Interruption

    Modified --> Acknowledged: Re-enters Book

    Suspended --> Acknowledged: VI Resolved,<br/>Trading Resumes

    Acknowledged --> Restated: Market Reset<br/>(GTC orders only)
    Restated --> Acknowledged: Book Rebuilt

    note right of Rejected
        Terminal State
        ExecType: Rejected (8)
        OrdStatus: Rejected (8)
    end note

    note right of Filled
        Terminal State
        ExecType: Trade (F)
        OrdStatus: Filled (2)
    end note

    note right of Cancelled
        Terminal State
        ExecType: Canceled (4)
        OrdStatus: Canceled (4)
    end note

    note right of Expired
        Terminal State
        ExecType: Expired (C)
        OrdStatus: Expired (C)
    end note

    note right of SMP_Cancelled
        Terminal State
        Protection Triggered
        OrdStatus: Canceled (4)
    end note

    note left of PendingNew
        <55 us via PS gateway
        ExecType: PendingNew (A)
        OrdStatus: PendingNew (A)
    end note

    note left of Acknowledged
        Active in Book
        ExecType: New (0)
        OrdStatus: New (0)
    end note

    note left of PartiallyFilled
        Active in Book
        ExecType: Trade (F)
        OrdStatus: PartiallyFilled (1)
    end note

    note left of Modified
        ExecType: Replace (5)
        Generates Cancel/New
    end note

    classDef activeState fill:#90EE90,stroke:#333,stroke-width:2px
    classDef terminalState fill:#FFB6C1,stroke:#333,stroke-width:2px
    classDef intermediateState fill:#87CEEB,stroke:#333,stroke-width:2px
    classDef protectionState fill:#FFA500,stroke:#333,stroke-width:2px

    class Acknowledged,PartiallyFilled,Restated activeState
    class Filled,Cancelled,Expired,Rejected terminalState
    class New,PendingNew,Modified intermediateState
    class SMP_Cancelled,Suspended protectionState

IOC (Immediate-or-Cancel) special path Mermaid code (VERBATIM):

stateDiagram-v2
    [*] --> New_IOC: IOC Order
    New_IOC --> PendingNew_IOC
    PendingNew_IOC --> Filled: Full Match
    PendingNew_IOC --> PartiallyFilled_IOC: Partial Match
    PartiallyFilled_IOC --> Cancelled: Remainder Auto-Cancelled
    PendingNew_IOC --> Cancelled: No Match

FOK (Fill-or-Kill) special path Mermaid code (VERBATIM):

stateDiagram-v2
    [*] --> New_FOK: FOK Order
    New_FOK --> PendingNew_FOK
    PendingNew_FOK --> Filled: Full Match Available
    PendingNew_FOK --> Rejected: Partial/No Match

BOC (Book-or-Cancel) special path Mermaid code (VERBATIM):

stateDiagram-v2
    [*] --> New_BOC: BOC Order
    New_BOC --> PendingNew_BOC
    PendingNew_BOC --> Acknowledged: No Match,<br/>Add to Book
    PendingNew_BOC --> Rejected: Would Execute

Stop Orders special path Mermaid code (VERBATIM):

stateDiagram-v2
    [*] --> Inactive: Stop Order<br/>Below Trigger
    Inactive --> Triggered: Market Price<br/>Reaches Trigger
    Triggered --> Acknowledged: Activated,<br/>Enters Book
    Acknowledged --> PartiallyFilled: Execution Begins
    PartiallyFilled --> Filled: Fully Executed

Surround all diagrams with descriptive text covering:

Order States and ExecType Mapping:

  • Active States (Green): Acknowledged (ExecType=New 0, OrdStatus=New 0), PartiallyFilled (ExecType=Trade F, OrdStatus=PartiallyFilled 1), Restated (ExecType=Restated D, OrdStatus=New 0)
  • Intermediate States (Blue): New, PendingNew (ExecType=PendingNew A, OrdStatus=PendingNew A), Modified (ExecType=Replace 5)
  • Terminal States (Red): Filled (ExecType=Trade F, OrdStatus=Filled 2), Cancelled (ExecType=Canceled 4, OrdStatus=Canceled 4), Expired (ExecType=Expired C, OrdStatus=Expired C), Rejected (ExecType=Rejected 8, OrdStatus=Rejected 8)
  • Protection States (Orange): SMP_Cancelled, Suspended

Timing and Performance:

  • PendingNew to Acknowledged: less than 55 microseconds via PS gateway
  • Execution: 100-200 microseconds typical
  • Modification: ~100 microseconds atomic operation

TIF Handling:

  • GFD: Expires at end of trading day (17:30 CET Xetra), does not persist through Market Reset
  • GTD: Expires at specified date, survives Market Reset if not reached
  • GTC: Survives Market Reset via Restated state, remains until cancelled or filled
  • IOC: Never enters Acknowledged state, unmatched quantity cancelled immediately
  • FOK: All-or-nothing, PendingNew to Filled or Rejected

Market Events:

  • Volatility Interruption: Active to Suspended, retains price/time priority, typical 2-5 minutes
  • Self-Match Prevention: Active to SMP_Cancelled, configurable cancel incoming/resting/both
  • Market Reset: Non-persistent orders deleted, persistent (GTC) restated then acknowledged

Modification Behavior: Cancel existing, submit new with updated parameters, new timestamp loses time priority, atomic operation, if new rejected original remains cancelled.

Diagram 4: Market Data Distribution

File: diagrams/market-data-distribution.md

Front matter:

---
layout: default
title: "Market Data Distribution"
nav_order: 4
parent: Diagrams
---

Mermaid code (VERBATIM):

flowchart TD
    ME[Matching Engine<br/>Data Generation] --> EOBI_PUB[EOBI Publisher<br/>Integrated in ME Process]
    ME --> EMDI_PUB[EMDI Publisher<br/>Integrated in ME Process]
    ME --> MDI_AGG[MDI Aggregator<br/>Separate Process]

    RDI_PUB[RDI Publisher<br/>Pre-Market Static Data] --> RDI_A[Side A Multicast<br/>RDI Channel]
    RDI_PUB --> RDI_B[Side B Multicast<br/>RDI Channel]

    EOBI_PUB --> EOBI_A[Side A Multicast<br/>EOBI Channel]
    EOBI_PUB --> EOBI_B[Side B Multicast<br/>EOBI Channel]
    EOBI_PUB --> SNAP_EOBI[Snapshot Channel<br/>EOBI Recovery]

    EMDI_PUB --> EMDI_A[Side A Multicast<br/>EMDI Channel]
    EMDI_PUB --> EMDI_B[Side B Multicast<br/>EMDI Channel]
    EMDI_PUB --> SNAP_EMDI[Snapshot Channel<br/>EMDI Recovery]

    MDI_AGG --> MDI_A[Side A Multicast<br/>MDI Channel]
    MDI_AGG --> MDI_B[Side B Multicast<br/>MDI Channel]

    EOBI_A --> COLO[Co-Located Participants<br/>10 GbE Dedicated Network]
    EOBI_B --> COLO
    EMDI_A --> COLO
    EMDI_B --> COLO

    MDI_A --> REMOTE[Remote Participants<br/>Leased Lines]
    MDI_B --> REMOTE

    RDI_A --> COLO
    RDI_B --> COLO
    RDI_A --> REMOTE
    RDI_B --> REMOTE

    SNAP_EOBI --> COLO
    SNAP_EMDI --> COLO

    style ME fill:#1e3a8a,color:#fff
    style EOBI_PUB fill:#10b981,color:#000
    style EOBI_A fill:#10b981,color:#000
    style EOBI_B fill:#10b981,color:#000
    style SNAP_EOBI fill:#10b981,color:#000
    style EMDI_PUB fill:#3b82f6,color:#fff
    style EMDI_A fill:#3b82f6,color:#fff
    style EMDI_B fill:#3b82f6,color:#fff
    style SNAP_EMDI fill:#3b82f6,color:#fff
    style MDI_AGG fill:#f97316,color:#fff
    style MDI_A fill:#f97316,color:#fff
    style MDI_B fill:#f97316,color:#fff
    style RDI_PUB fill:#fbbf24,color:#000
    style RDI_A fill:#fbbf24,color:#000
    style RDI_B fill:#fbbf24,color:#000
    style COLO fill:#e5e7eb,color:#000
    style REMOTE fill:#e5e7eb,color:#000

Surround with descriptive text covering:

Data Generation at the Matching Engine: All market data originates from the matching engine. Since Release 12.0, EOBI and EMDI publishers are integrated directly into the matching engine process, eliminating inter-process communication overhead and reducing latency by approximately 4 microseconds for EOBI.

Feed Types and Characteristics:

  • EOBI: full depth-of-book, proprietary binary, 20-30 us latency, HFT/market making
  • EMDI: 10-15 price levels, FIX/FAST, 30-40 us, integrated in ME, algorithmic trading
  • MDI: top-of-book aggregated, FIX/FAST, 100-200 us, separate aggregation process, retail/monitoring
  • RDI: static instrument data, pre-market, independent of ME

Redundancy Architecture: Live-live Side A and Side B on separate physical infrastructure. Both sides generated from same ME but transmitted on independent network paths with different multicast addresses. Participants consume both and use faster-arriving packet, discard duplicates via sequence numbers.

Recovery Mechanisms: EOBI and EMDI provide snapshot channels publishing full order book images at regular intervals. Snapshot frequency configurable per instrument class, typically 1-10 seconds.

Latency Hierarchy:

  1. EOBI (20-30 us) - integrated in ME, binary protocol
  2. EMDI (30-40 us) - integrated in ME, FIX/FAST encoding overhead
  3. MDI (100-200 us) - separate aggregation process

Public Data First Principle: No privileged early access. All feeds receive identical information simultaneously. EOBI published before ETI execution reports.

Pricing Summary Table: | Feed | Protocol | Depth | Latency | Monthly Fee Range | |——|———-|——-|———|——————-| | EOBI | Binary | Full | 20-30 us | EUR 5,000-25,000 | | EMDI | FIX/FAST | 10-15 levels | 30-40 us | EUR 3,000-15,000 | | MDI | FIX/FAST | Top-of-book | 100-200 us | EUR 1,000-5,000 | | RDI | FIX/FAST | Static | Pre-market | Included |

Diagram 5: ETI Session Lifecycle

File: diagrams/eti-session-lifecycle.md

Front matter:

---
layout: default
title: "ETI Session Lifecycle"
nav_order: 5
parent: Diagrams
---

Mermaid code (VERBATIM):

sequenceDiagram
    participant App as Trading Application
    participant GW as PS/LF Gateway
    participant ME as Matching Engine

    rect rgb(200, 220, 240)
        Note over App,GW: Phase 1: Connection Establishment
        App->>GW: TCP/IP Connection Request
        GW->>App: TCP/IP Connection Accepted
        App->>GW: TLS 1.3 Handshake
        GW->>App: TLS 1.3 Established
    end

    rect rgb(220, 240, 220)
        Note over App,GW: Phase 2: Session Login
        App->>GW: Session Logon Request<br/>(SessionID, Credentials, AppDetails)
        GW->>App: Session Logon Response<br/>(Throttle: 50/150/250 TPS)
    end

    rect rgb(240, 240, 200)
        Note over App,GW: Phase 3: Heartbeat Exchange
        loop Periodic Interval
            App->>GW: Heartbeat
            GW->>App: Heartbeat Notification
        end
    end

    rect rgb(200, 240, 200)
        Note over App,ME: Phase 4: Order Submission
        App->>GW: NewOrderSingle<br/>(OrderID, Instrument, Price, Qty)
        activate GW
        GW->>ME: Forward Order
        activate ME
        ME->>GW: ExecutionReport<br/>(ExecType=New, OrdStatus=New)
        deactivate ME
        GW->>App: ExecutionReport (Acknowledged)
        deactivate GW
        Note over App,GW: Median latency: less than 55 us via PS Gateway
    end

    rect rgb(220, 200, 240)
        Note over App,ME: Phase 5: Order Fill
        Note right of ME: Matching order arrives
        activate ME
        ME->>GW: ExecutionReport<br/>(ExecType=Fill, OrdStatus=Filled)
        deactivate ME
        activate GW
        GW->>App: ExecutionReport (Fill Notification)
        deactivate GW
        Note over GW,App: EOBI market data published<br/>~1.5 us BEFORE this ETI response
    end

    rect rgb(240, 220, 200)
        Note over App,ME: Phase 6: Order Modification
        App->>GW: ModifyOrder (NewPrice/NewQty)
        activate GW
        GW->>ME: Forward Modification
        activate ME
        ME->>GW: ExecutionReport (ExecType=Replaced)
        deactivate ME
        GW->>App: ExecutionReport (Modified)
        deactivate GW
    end

    rect rgb(240, 200, 200)
        Note over App,ME: Phase 7: Order Cancellation
        App->>GW: DeleteOrder (OrderID)
        activate GW
        GW->>ME: Forward Deletion
        activate ME
        ME->>GW: ExecutionReport (ExecType=Canceled)
        deactivate ME
        GW->>App: ExecutionReport (Canceled)
        deactivate GW
    end

    rect rgb(255, 220, 220)
        Note over App,GW: Phase 8: Error Handling
        alt Invalid Request
            App->>GW: Invalid Message
            GW->>App: BusinessMessageReject (ErrorCode)
        else Throttle Violation
            App->>GW: Order (exceeds TPS limit)
            GW->>App: Reject (ThrottleError)
        end
    end

    rect rgb(200, 200, 200)
        Note over App,GW: Phase 9: Session Logout
        App->>GW: Logout Request
        GW->>App: Logout Response
        Note over App,GW: TCP connection closed
    end

    rect rgb(220, 220, 240)
        Note over App,GW: Phase 10: Recovery (Disconnect)
        alt Connection Lost
            Note over App,GW: Network failure detected
            App->>GW: Reconnect TCP + TLS
            App->>GW: Session Logon (Recovery)
            GW->>App: Session Logon Response
            App->>GW: Retransmission Request
            GW->>App: Missed ExecutionReports
        end
    end

Surround with descriptive text covering all 10 phases and include key timing characteristics table:

Metric Value
Order-to-Acknowledgment (PS Gateway) < 55 microseconds median
LF Gateway Additional Latency ~12 microseconds
EOBI Publication Lead ~1.5 microseconds before ETI response
TLS 1.3 Overhead Single-digit microseconds per roundtrip
Maximum Sessions per Participant 600 (since June 2024)

Phase descriptions:

  • Phase 1: TCP connection followed by mandatory TLS 1.3 handshake. TLS 1.2 fully decommissioned Release 14.1 (May 2026).
  • Phase 2: Session Logon with SessionID (unique, assigned by DB), encrypted credentials (RSA public key), application version. Gateway returns throttle limits: HF Light 50 TPS, HF Full 150 TPS, HF Ultra 250 TPS, DR 30 TPS.
  • Phase 3: Bidirectional heartbeats at configurable intervals (typically 10-30 seconds). Stalled TCP detection requires application-level timeout.
  • Phase 4: NewOrderSingle with instrument, price, quantity, order type. Exactly one response per request. Median <55 us via PS.
  • Phase 5: Unsolicited ExecutionReport on match. EOBI market data published ~1.5 us before ETI response reaches originator.
  • Phase 6: ModifyOrder for price/quantity changes. Atomic operation. Queue priority rules apply.
  • Phase 7: DeleteOrder for individual or MassDeleteOrder for bulk cancellation by product/partition/session.
  • Phase 8: BusinessMessageReject for invalid messages. ThrottleError when exceeding TPS limit.
  • Phase 9: Graceful Logout Request/Response. Open orders remain active unless cancelled.
  • Phase 10: HF sessions reconnect to same PS gateway (or backup). LF sessions reconnect to any LF gateway. Retransmission of missed execution notifications.

Diagram 6: Matching Engine Flow

File: diagrams/matching-engine-flow.md

Front matter:

---
layout: default
title: "Matching Engine Flow"
nav_order: 6
parent: Diagrams
---

Mermaid code (VERBATIM):

flowchart TD
    Start([Order Arrives at Matching Engine]) --> PreTrade[Pre-Trade Risk Checks]

    PreTrade --> MOV{Maximum Order<br/>Value Check}
    MOV -->|Exceeded| Reject1[Reject: MOV Exceeded]
    MOV -->|Pass| MOQ{Maximum Order<br/>Quantity Check}

    MOQ -->|Exceeded| Reject2[Reject: MOQ Exceeded]
    MOQ -->|Pass| Price{Price Reasonability<br/>Check}

    Price -->|Outside Collars| Reject3[Reject: Price Collar Violation]
    Price -->|Pass| SMP{Self-Match<br/>Prevention Check}

    SMP -->|Same BU + SMP ID| SMPAction[Apply SMP Action<br/>CP/CAP/CA]
    SMP -->|No Conflict| OrderType{Order Type<br/>Processing}
    SMPAction --> OrderType

    OrderType -->|IOC/FOK| IOCCheck{Immediately<br/>Executable?}
    OrderType -->|BOC| BOCCheck{Would<br/>Match?}
    OrderType -->|Market/Limit| PLP

    IOCCheck -->|No| CancelIOC[Cancel: Not Executable]
    IOCCheck -->|Yes| PLP

    BOCCheck -->|Yes| Reject4[Reject: BOC Would Match]
    BOCCheck -->|No| PLP

    PLP{PLP Active<br/>on Product?}
    PLP -->|No| Matching
    PLP -->|Yes - Aggressive| Defer[Defer 1-3 ms<br/>Random Delay]
    PLP -->|Yes - Passive| ToBook1[Add to Book Immediately]

    Defer --> Matching[Matching Algorithm]

    Matching --> AlgoSelect{Algorithm<br/>Selection}
    AlgoSelect -->|Price-Time Priority| PTP[PTP Matching:<br/>Best Price, then FIFO]
    AlgoSelect -->|Pro-Rata| PTR[PTR Matching:<br/>Best Price, then Size-weighted]

    PTP --> MatchResult{Match<br/>Result}
    PTR --> MatchResult

    MatchResult -->|Full Fill| Fill[ExecutionReport: Fill]
    MatchResult -->|Partial Fill| Partial[ExecutionReport: PartialFill]
    MatchResult -->|No Match| NoMatch{Order<br/>Type?}

    Partial --> RemainderCheck{Remainder<br/>Action}
    RemainderCheck -->|IOC| CancelRemainder[Cancel Remainder]
    RemainderCheck -->|Other| ToBook2[Add Remainder to Book]

    NoMatch -->|IOC/FOK| CancelNoMatch[Cancel: No Match]
    NoMatch -->|Other| ToBook3[Add to Order Book]

    Fill --> PostMatch[Post-Match Processing]
    CancelRemainder --> PostMatch
    ToBook2 --> PostMatch
    CancelNoMatch --> PostMatch
    ToBook3 --> PostMatch

    PostMatch --> EOBI[Publish EOBI<br/>Market Data]
    EOBI --> ETI[Send ETI ExecutionReport<br/>~1.5 us after EOBI]
    ETI --> UpdateBook[Update Order Book]
    UpdateBook --> End([Complete])

    Reject1 --> RejectEnd([Rejected])
    Reject2 --> RejectEnd
    Reject3 --> RejectEnd
    Reject4 --> RejectEnd

    style PreTrade fill:#ff6b6b
    style MOV fill:#ff6b6b
    style MOQ fill:#ff6b6b
    style Price fill:#ff6b6b
    style SMP fill:#ffa500
    style SMPAction fill:#ffa500
    style Matching fill:#51cf66
    style AlgoSelect fill:#51cf66
    style PTP fill:#51cf66
    style PTR fill:#51cf66
    style EOBI fill:#339af0
    style ETI fill:#339af0
    style Reject1 fill:#8b0000
    style Reject2 fill:#8b0000
    style Reject3 fill:#8b0000
    style Reject4 fill:#8b0000
    style RejectEnd fill:#8b0000

Surround with descriptive text covering:

Pre-Trade Risk Checks (Red):

  1. Maximum Order Value (MOV): notional value (price x quantity) vs configured limits. Typical limit EUR 10 million per order.
  2. Maximum Order Quantity (MOQ): per-instrument quantity limits. Prevents fat-finger errors.
  3. Price Reasonability (Collars): limit price within static (typically +-10-20%) and dynamic corridors around current market price. Orders outside rejected immediately.

Self-Match Prevention (Orange):

  • Checks if incoming order would match against same business unit’s resting order (same MatchInstCrossID tag 28744)
  • Three cancellation modes: CP (Cancel Passive), CAP (Cancel Aggressive and Passive), CA (Cancel Aggressive)
  • Executes in <100 nanoseconds

Order Type Processing:

  • IOC: checked for immediate executability; unmatched portions cancelled
  • FOK: must execute completely or be rejected
  • BOC: rejected if it would match, accepted only if it adds liquidity
  • Market/Limit: proceeds to PLP check

PLP (Passive Liquidity Protection):

  • When enabled per product, applies random delay of 1-3 milliseconds to aggressive orders
  • Passive orders bypass delay and enter book immediately
  • Reduces latency arbitrage, protects displayed liquidity

Matching Algorithm Selection (Green):

  1. Price-Time Priority (PTP): standard FIFO at each price level. Used for most equity and index futures.
  2. Pro-Rata (PTR): size-weighted allocation at each price level. Used for equity options and selected products.
    • Matching engine executes in approximately 15-25 microseconds from arrival to match determination.

Matching Outcomes:

  • Full Fill: entire order matched, ExecutionReport with fill status
  • Partial Fill: portion matched; remainder added to book (limit) or cancelled (IOC)
  • No Match: order added to book or cancelled based on order type

Post-Match Processing (Blue):

  1. EOBI Publication first: market data to all consumers via multicast
  2. ETI ExecutionReport: ~1.5 microseconds after EOBI, private confirmation to participant
  3. Order Book Update: central book updated, triggers subsequent EOBI incremental updates

Timing Characteristics:

  • Pre-trade risk checks: <100 nanoseconds
  • SMP processing: <100 nanoseconds
  • PLP deferral: 1-3 milliseconds (when active, aggressive orders only)
  • Matching algorithm: 15-25 microseconds
  • EOBI to ETI delay: ~1.5 microseconds
  • Total latency (arrival to execution): typically 30-50 microseconds (excluding PLP)

Rejection Paths (Dark Red):

  • MOV exceeded, MOQ exceeded, price collar violation, BOC would match, IOC/FOK no executable contra-side
  • Each rejection includes specific reason code in ExecutionReport

Section 8: SUPPORTING FILES

README.md (Home Page)

File: README.md

Front matter:

---
layout: default
title: Home
nav_order: 0
permalink: /
---

Include: H1 title, description paragraph, “Who Is This For?” section (4 bullet points: quant traders, trading system developers, fintech professionals, students/researchers), Source Policy section listing 6 approved domains, “How to Use This Repository” section, “Note on HTP” section explaining there is no specific HTP protocol (the HFT stack is ETI + EOBI + EMDI), License (CC BY-SA 4.0), Contributing link.

TABLE_OF_CONTENTS.md

List all 12 chapters with sub-pages for chapters 4 and 5 (indented), 4 appendices, 6 diagrams. Use relative markdown links to all files.

SOURCES.md

Organize all URLs into these categories. Every URL listed below must appear in the generated SOURCES.md file:

Approved Source Domains:

  • deutsche-boerse.com
  • eurex.com / eurexchange.com
  • xetra.com
  • cashmarket.deutsche-boerse.com
  • developer.deutsche-boerse.com
  • mds.deutsche-boerse.com

Corporate & Exchange Overview:

T7 Architecture & Technology:

Trading Interfaces:

Market Data Feeds:

Latency & Performance:

Risk Controls:

Market Models:

Regulatory Framework:

Simulation & Testing:

Developer Resources:

Pricing:

Information Channels:

Events:

CONTRIBUTING.md

Front matter:

---
layout: default
title: "Contributing"
nav_order: 51
---

Required sections:

Source Requirements: All contributions must cite official Deutsche Boerse Group sources. List the 5 accepted domains: deutsche-boerse.com, eurex.com / eurexchange.com, xetra.com, cashmarket.deutsche-boerse.com, developer.deutsche-boerse.com.

What Is NOT Accepted (5 prohibitions):

  1. Proprietary or non-public information
  2. Content from third-party sources (blogs, forums, news articles, Wikipedia)
  3. Trading strategies or alpha-generating advice
  4. Comparisons with competing exchanges
  5. Speculation about undocumented internals

How to Contribute (4 steps):

  1. Fork this repository
  2. Create a branch for your change
  3. Make your edits, ensuring every factual claim has a source citation
  4. Submit a pull request with a clear description of what you changed and why

Style Guidelines:

  • Use Mermaid for diagrams (GitHub-native rendering)
  • Include source citations inline or as footnotes
  • Follow the existing chapter structure and formatting
  • Keep language technical but accessible

Index Pages

  • chapters/index.md: Title “Chapters”, nav_order 2, has_children true, brief description
  • chapters/appendix/index.md: Title “Appendices”, nav_order 3, has_children true, brief description
  • diagrams/index.md: Title “Diagrams”, nav_order 4, has_children true, brief description

Section 9: VERIFICATION PIPELINE

Functional Specification

The verification pipeline is a Python-based automated system that runs daily via GitHub Actions at 06:00 UTC. It validates the repository’s content integrity across four dimensions:

Module: run_all.py (Orchestrator)

  • Parses --checks argument (all, links, crossrefs, facts, circulars)
  • Determines repo root (2 levels up from script)
  • Loads config.yaml
  • Runs checks sequentially, collecting results and timing
  • Generates unified report via generate_report.py
  • Determines overall status: PASS (exit 0), WARNINGS (exit 1), ACTION REQUIRED (exit 2)
  • Prints summary to stdout

Module: check_links.py (URL Validation)

  • Scans all markdown files for URLs
  • Validates HTTP status codes, detects redirects, soft 404s, PDF changes
  • Rate-limited at 2 req/s per domain with exponential backoff
  • Checks 350+ URLs across 33 markdown files
  • Outputs: unique URLs count, failures list with status categories (NOT_FOUND, SERVER_ERROR, TIMEOUT, DOMAIN_ERROR, SOFT_404, REDIRECT, MOVED_PDF)

Module: check_crossrefs.py (Cross-Reference Validation)

  • Validates all internal markdown links between files
  • Checks anchor references (heading links)
  • Verifies TOC coverage (all chapters listed)
  • Validates back-links between chapters
  • Outputs: total internal links count, broken count, details

Module: check_facts.py (Fact Verification)

  • Reads fact_registry.yaml containing every verifiable fact
  • Each fact has: id, category (pricing/latency/session_limits/dates/contacts/regulatory), value, unit, file, line, context, source_url, source_document, effective_date, last_verified, verification_method (manual/automated/pdf_text_check)
  • For automated checks: fetches source URL, extracts text, compares against registered value
  • For PDF sources: uses a two-tier strategy:
    1. Content hash comparison (coarse): Downloads PDF and computes SHA-256 hash. If hash unchanged since last run, fact is presumed stable. If hash changed, the fact is flagged as NEEDS_REVIEW (not CHANGED – a hash change does not mean the specific fact changed).
    2. Text extraction (fine, when possible): For PDFs marked pdf_text_extractable: true in the fact registry, extracts text via pdfplumber or PyMuPDF and searches for the registered context string. If the context string is found, the fact is confirmed. If not found, the fact is flagged as POSSIBLE_CHANGE.
    3. Non-extractable PDFs: For PDFs marked pdf_text_extractable: false, only hash comparison is performed. A hash change produces a NEEDS_MANUAL_REVIEW status, not a failure. This prevents false positives from layout-only PDF changes.
      • Outputs: total facts, confirmed, needs_review, possible_change, needs_manual_review
  • Outputs: total facts, issues, failures with issue_type (changed/needs_update/stale)

Module: monitor_circulars.py (Circular Monitoring)

  • Monitors Eurex and Deutsche Boerse circular/announcement pages for new content
  • Filters by configurable keywords (e.g., “T7”, “Release”, “pricing”, “risk”)
  • Maintains state in .state/ directory to detect new-since-last-run circulars
  • Outputs: sources checked, new relevant circulars

Module: generate_report.py (Report Generation)

  • Combines results from all checks into reports/latest-report.md
  • Archives as reports/YYYY-MM-DD.json
  • Formats with status levels, summary statistics, and details

Module: build_registry.py (Registry Builder)

  • Semi-automated tool to discover verifiable facts in markdown files
  • Scans for patterns: EUR amounts, percentages, dates, latency figures
  • Outputs candidates to fact_registry.yaml with verification_method: unreviewed
  • Supports --merge to add new facts without overwriting existing

Module: utils/http_client.py (Rate-Limited HTTP Client)

  • Implements per-domain rate limiting (default 2 req/s)
  • Exponential backoff on failure (configurable retry count)
  • User-Agent header identifying the verification bot
  • Timeout handling (configurable per-request timeout)
  • Cookie and redirect following
  • SSL certificate verification

Module: utils/markdown_parser.py (Markdown Parsing Utilities)

  • Extracts all URLs from markdown files (inline links, reference links, bare URLs)
  • Extracts all internal cross-reference links between markdown files
  • Extracts heading anchors for anchor link validation
  • Parses front matter (YAML between — delimiters)
  • Identifies Mermaid code blocks

Module: utils/report_formatter.py (Report Formatting)

  • Formats check results into markdown report sections
  • Generates status badges (PASS/WARNINGS/ACTION REQUIRED)
  • Creates summary statistics tables
  • Formats failure details with file paths, line numbers, and error descriptions

Module: utils/github_issues.py (GitHub Issue Formatting)

  • Formats report content for GitHub Issue body (3000 char truncation)
  • Generates issue titles with date stamps
  • Manages verification-failure label

Configuration file: config.yaml

Must specify:

  • approved_domains: List of 7 approved Deutsche Boerse domains
  • rate_limits: Per-domain request rate (default: 2 req/s for all DB domains)
  • retry: Count (default 3), backoff multiplier (default 2.0), max wait (default 30s)
  • timeouts: Connect timeout (10s), read timeout (30s)
  • circular_sources: URLs for Eurex and Deutsche Boerse circular pages
  • circular_keywords: List including “T7”, “Release”, “pricing”, “risk”, “ETI”, “EOBI”, “simulation”, “certification”, “fee”, “session”, “session limit”, “throttle”, “TPS”, “partition”, “TLS”, “decommission”, “MiFID”, “EMIR”, “regulatory”, “price list”
  • notifications: GitHub Issue settings (label, auto-close on success), webhook URL (optional)
  • paths: Content directory (repo root), exclude patterns (scripts/, .omc/, node_modules/)

Fact Registry: fact_registry.yaml

Schema for each fact entry:

- id: "pricing-eurex-colo-emdi-monthly"
  category: pricing
  value: "6000"
  unit: "EUR/month"
  file: "chapters/appendix/pricing-summary.md"
  line: 50
  context: "CoLo 2.0 EMDI | 6,000"
  source_url: "https://www.eurex.com/resource/blob/..."
  source_document: "Eurex Circular 104/25"
  effective_date: "2026-01-01"
  last_verified: "2026-02-13"
  verification_method: "manual"
  pdf_text_extractable: null
  notes: ""

Categories: urls, pricing, latency, session_limits, dates, contacts, regulatory. Verification methods: manual, automated, pdf_text_check, unreviewed.

Seed Fact Registry

The generated fact_registry.yaml must include at minimum these seed entries. The build_registry.py tool can discover additional entries, but these represent the highest-priority verifiable facts:

# --- Pricing Facts (highest decay rate) ---
- id: pricing-eurex-colo-emdi
  category: pricing
  value: "6000"
  unit: "EUR/month"
  file: "chapters/appendix/pricing-summary.md"
  source_url: "https://www.eurex.com/resource/blob/2567152/..."
  source_document: "Eurex Connection Agreement Price List 2026"
  effective_date: "2026-01-01"
  verification_method: "manual"

- id: pricing-xetra-colo-eobi
  category: pricing
  value: "6240"
  unit: "EUR/month"
  file: "chapters/appendix/pricing-summary.md"
  source_url: "https://www.cashmarket.deutsche-boerse.com/resource/blob/..."
  verification_method: "manual"

# --- Session Limit Facts ---
- id: session-limit-max-per-participant
  category: session_limits
  value: "600"
  unit: "sessions"
  file: "chapters/04-trading-interfaces/README.md"
  source_url: "https://www.eurex.com/ex-en/find/circulars/..."
  effective_date: "2024-06-01"
  verification_method: "manual"

# --- Latency Facts ---
- id: latency-median-order-response
  category: latency
  value: "<55"
  unit: "microseconds"
  file: "chapters/08-latency-performance/README.md"
  source_url: "https://www.xetra.com/xetra-en/technology/t7"
  verification_method: "manual"

- id: latency-min-reaction-time
  category: latency
  value: "2787"
  unit: "nanoseconds"
  file: "chapters/08-latency-performance/README.md"
  source_url: "https://www.eurex.com/resource/blob/48918/..."
  effective_date: "2025-02-13"
  verification_method: "manual"

# --- Date Facts ---
- id: date-release-14-0-launch
  category: dates
  value: "2025-11-10"
  file: "chapters/02-t7-architecture/README.md"
  verification_method: "manual"

- id: date-release-14-1-planned
  category: dates
  value: "2026-05-18"
  file: "chapters/02-t7-architecture/README.md"
  verification_method: "manual"
  notes: "Planned, not yet launched. Check Eurex circulars."

Include at least 20 seed entries covering: 8 pricing, 4 latency, 3 session limits, 3 dates, 2 regulatory. Use verification_method: manual for all seeds. The build_registry.py tool adds additional entries with verification_method: unreviewed.

GitHub Actions Workflow

File: .github/workflows/daily-verification.yml

Trigger configuration:

  • Schedule: cron 0 6 * * * (daily at 06:00 UTC)
  • Manual: workflow_dispatch with optional checks input (default: ‘all’)

Concurrency: group verification-pipeline, cancel-in-progress: false

Job specification:

  • Runner: ubuntu-latest
  • Timeout: 20 minutes
  • Permissions: contents:write, issues:write

Steps (in order):

  1. Checkout repository (actions/checkout@v4)
  2. Set up Python 3.11 (actions/setup-python@v5)
  3. Install dependencies (pip install -r scripts/verification/requirements.txt)
  4. Restore state cache (actions/cache@v4, key: verification-state-$run_number)
  5. Create state directory (mkdir -p scripts/verification/.state)
  6. Run verification pipeline (python scripts/verification/run_all.py, continue-on-error: true)
  7. Upload report artifacts (actions/upload-artifact@v4, retention 90 days)
  8. Commit latest report (git add reports/latest-report.md, skip ci commit)
  9. Create or update GitHub Issue on failure (actions/github-script@v7, label: verification-failure, truncate body to 3000 chars)
  10. Close issue on success (auto-close with comment)
  11. Send webhook notification (optional, if NOTIFICATION_WEBHOOK secret set)

Exit code mapping: 0 = PASS, 1 = WARNINGS, 2 = ACTION REQUIRED

Pre-Commit Hook Specification

Generate a .github/hooks/pre-commit script (or equivalent instructions in CONTRIBUTING.md) that:

  1. Runs python scripts/verification/check_crossrefs.py on staged files only
  2. Rejects the commit if any broken internal links are found
  3. Prints the broken link and its target for easy fixing

Heading Stability Rule

Add to CONTRIBUTING.md:

Do not rename H2 or H3 headings without updating all cross-references that target them. The verification pipeline (check_crossrefs.py) will catch broken anchor links, but prevention is better than detection. If you must rename a heading, search the repository for the old anchor (#old-heading-slug) and update all references before committing.

PR-Level Verification Workflow

Add a second GitHub Actions workflow file to Batch 6: File: .github/workflows/pr-verification.yml

Trigger: pull_request on main branch. Steps: Checkout, Python setup, run check_crossrefs.py and check_links.py --internal-only (skip external URL checks for speed). Fail the PR check if any broken internal links are found.

Pricing Update Workflow

Add to CONTRIBUTING.md and the verification pipeline README:

Annual pricing update process (triggered by Q4 circulars):

  1. monitor_circulars.py detects a new Eurex or Xetra circular containing keyword “price list” or “fee” in Q4.
  2. The daily verification report flags this as ACTION REQUIRED with a link to the circular.
  3. A maintainer downloads the new price list PDF and compares against the current pricing-summary.md values.
  4. The maintainer updates these files (all pricing mentions must be consistent):
    • chapters/appendix/pricing-summary.md (primary)
    • chapters/appendix/quick-reference.md (Card 5: Co-Location Costs)
    • chapters/03-network-infrastructure/README.md (CoLo pricing section)
    • chapters/04-trading-interfaces/README.md (session pricing)
    • fact_registry.yaml (update values and effective_date)
  5. The maintainer creates a PR titled “Update pricing for [YEAR]” and the PR verification workflow validates cross-references.
  6. After merge, check_facts.py confirms the new values match the updated registry.

Estimated effort: 1-2 hours annually. Non-automatable because new price lists require human interpretation of PDF tables.

Living Document Monitoring

Some source documents change without version numbers or changelogs:

High-priority living documents:

  • T7 Architecture Factsheet (peak message rates, daily volumes, latency)
  • Eurex Trading Parameters (tick sizes, product lists)
  • Xetra Market Model documentation (trading hours, auction timing)

Monitoring strategy:

  1. check_facts.py maintains SHA-256 hashes for all source PDFs/pages in .state/document_hashes.json.
  2. When a hash changes, the report includes:
    • Which document changed
    • Which facts in fact_registry.yaml cite this document
    • A diff-friendly summary: “Document X changed. Facts citing it: [list]. Manual review required.”
  3. The report does NOT mark these as failures. It marks them as DOCUMENT_UPDATED -- REVIEW REQUIRED.

This prevents the “PDF_CHANGED = failure” false positive problem while still alerting maintainers to review.

Section 10: QUALITY REQUIREMENTS

Writing Style

  1. Professional and technical: Write as if authoring a system reference manual for experienced technologists. Avoid tutorial-style language (“let’s explore”, “you might wonder”).
  2. Precise terminology: Use exact product names (T7, ETI, EOBI, not “the trading system” or “the fast data feed”). Capitalize product names consistently.
  3. Active voice preferred: “T7 processes orders” not “Orders are processed by T7”.
  4. Concrete over abstract: “Median latency measures 55 microseconds” not “Latency is very low”.
  5. No marketing language: Do not use superlatives (“world’s best”, “unmatched performance”) unless quoting a source directly.
  6. Metric system: Use metric units. Latency in microseconds (us) or nanoseconds (ns). Currency in EUR. Time in CET.

Fabrication Guard: Numbers and Metrics

This prompt supplies every quantitative metric that should appear in the output. Follow these rules strictly:

  1. ONLY use numbers explicitly provided in this prompt. Do not infer, interpolate, extrapolate, or generate any quantitative figures (latency, pricing, percentages, counts, dates, throughput) that are not stated verbatim in the chapter specification above.

  2. If contextual prose requires a number not provided here, use a placeholder: Write [METRIC NOT IN SOURCE -- VERIFY] instead of generating a plausible figure. Example: if you need a 99th percentile latency but only the median is specified, write “the 99th percentile latency [METRIC NOT IN SOURCE – VERIFY]” rather than fabricating “120 microseconds.”

  3. Do not round, convert, or restate provided figures. If the prompt says “2,787 nanoseconds,” write “2,787 nanoseconds” – do not convert to “approximately 2.8 microseconds” unless the prompt itself provides both forms. When the prompt provides both (e.g., “2,787 ns (~2.8 us)”), use the exact dual form.

  4. Distinguish sourced facts from architectural descriptions. When writing prose that contextualizes a specific metric, do not embed additional unsourced metrics in the same paragraph. Keep sourced metrics in their own sentences with citations.

  5. Temporal qualifiers are mandatory for measurement-derived figures. If a figure is tied to a measurement date (e.g., “Feb 13 2025”), always include the date qualifier. Never state a measurement-dated figure as a permanent characteristic.

Temporal Qualifier Handling

Some facts in this prompt describe future events. Handle them as follows:

  1. “Planned” or “scheduled” events: Always include the qualifier. Write “Release 14.1, scheduled for May 18, 2026” – never “Release 14.1 launches May 18, 2026” (which asserts it has happened).

  2. Add a staleness marker for future events. After any “planned/scheduled” statement, add a parenthetical: (verify current status at [Eurex Release Initiative page](URL)). This tells the reader to check whether the event has occurred.

  3. The Release History table must distinguish launched from planned releases. Use a “Status” column: “Launched” for past releases, “Planned” for future ones.

  4. Add to CONTRIBUTING.md: “When a planned event occurs, update all references from ‘planned/scheduled’ to ‘launched on [DATE]’ and remove the staleness marker. Search the repository for the release number to find all references.”

  5. Do not use “upcoming” or “soon” – these have no verifiable meaning. Always use the specific date with “planned” or “scheduled.”

Cross-Reference Format

Use relative markdown links between files:

  • From chapter to chapter: [Chapter 2](../02-t7-architecture/README.md)
  • From sub-page to parent: [Back to Chapter 4 Overview](README.md)
  • From chapter to diagram: [T7 Architecture Diagram](../../diagrams/t7-architecture-overview.md)
  • From appendix to chapter: [Chapter 9 - Risk Controls](../09-risk-controls/README.md)

Include previous/next navigation at the bottom of each chapter:

[<< Previous: Chapter N-1](../NN-title/README.md) | [Next: Chapter N+1 >>](../NN+1-title/README.md)

Terminology Consistency

Maintain these exact terms throughout all files:

  • “Matching Engine” (not “match engine” or “matching system”)
  • “Partition-Specific Gateway” or “PS Gateway” (not “high-frequency gateway”)
  • “Low-Frequency Gateway” or “LF Gateway”
  • “Enhanced Trading Interface” or “ETI”
  • “Enhanced Order Book Interface” or “EOBI”
  • “Enhanced Market Data Interface” or “EMDI”
  • “Market Data Interface” or “MDI”
  • “Reference Data Interface” or “RDI”
  • “Equinix FR2” (not “the data center” or “co-location site”)
  • “Release 14.0” (not “version 14” or “v14”)
  • “TPS” for transactions per second (not “msgs/sec” when referring to session limits)
  • “Side A / Side B” (not “primary/secondary” for market data redundancy)
  • “Room A / Room B” (not “primary/backup” for geographic redundancy)

Glossary Authority Protocol

The glossary (Section 6) is the single source of truth for all term definitions. Follow these rules:

  1. Glossary definitions are canonical. If a chapter needs to describe a glossary term (e.g., PLP, SMP, EOBI), the chapter description must be consistent with the glossary definition. The chapter may provide MORE detail but must not CONTRADICT the glossary.

  2. Chapter descriptions add context; glossary provides the definition. The glossary entry for PLP should state what PLP IS (mechanism, purpose). Chapter 6 should explain HOW PLP works (deferral timing, order types affected). Chapter 9 should explain WHY PLP exists (market maker protection, latency arbitrage prevention). All three must be consistent.

  3. When writing a chapter that mentions a glossary term, mentally verify: Does my chapter description contradict the glossary definition? If yes, follow the glossary.

  4. Cross-reference from chapter to glossary: When a glossary term first appears in a chapter, link to it: [PLP](../appendix/glossary.md#passive- liquidity-protection-plp).

  5. Glossary PLP definition correction: The glossary definition of PLP in this prompt should read: “Risk control mechanism that defers aggressive orders by 1-3 milliseconds on enabled products, protecting passive (displayed) liquidity from latency arbitrage.” – NOT “preventing unintended passive order execution” which is the MMP definition.

Prohibited Content

  1. No competitor mentions: Do not compare Deutsche Boerse with CME, LSEG, Nasdaq, ICE, or any other exchange.
  2. No trading advice: Do not recommend specific trading strategies, alpha generation approaches, or position sizing.
  3. No proprietary information: Do not include non-public information or speculation about undocumented internals.
  4. No third-party tool recommendations: Do not recommend specific vendor products (e.g., specific FPGA vendors, specific trading libraries) unless they are explicitly mentioned in Deutsche Boerse documentation.
  5. No speculation about future features: Only mention confirmed future functionality from official sources (e.g., Release 14.1 confirmed features).

Known Limitations of LLM-Generated Documentation

This megaprompt produces documentation via large language model generation. The following limitations are inherent and cannot be fully mitigated by prompt design. The output should acknowledge these honestly.

1. URL Verification (R1-W2, R5-W3): The LLM cannot verify at generation time that cited URLs resolve, return HTTP 200, or contain the claimed facts. All citations in the output reflect URLs provided in this prompt as of early 2026. Deutsche Boerse regularly reorganizes its website and rotates PDF blob IDs. The verification pipeline (check_links.py) detects broken URLs post-generation, but 20-30% of URLs are expected to require remapping within 18 months.

Instruction to LLM: Add a note to SOURCES.md: “URLs were verified as of [generation date]. Deutsche Boerse periodically reorganizes its web presence. If a link is broken, search the relevant domain for the document title.”

2. Output Volume Constraint (R3-W2): The target word counts for all chapters, appendices, diagrams, and supporting files sum to approximately 71,000+ words. No current LLM can generate this volume with perfect cross-file consistency in a single session. Later batches may exhibit reduced detail or minor terminology drift.

Instruction to LLM: Prioritize accuracy and consistency over hitting the upper end of word count ranges. If you notice yourself becoming less precise in later batches, target the LOWER end of each chapter’s word count range. A 55,000-word accurate output is more valuable than a 71,000-word output with consistency errors.

3. Regulatory Decay (R5-W4): Chapter 10 (Regulatory Framework) documents MiFID II, the German HFT Act, and MAR as of early 2026. MiFID III and EMIR 3.0 are expected in 2026-2027 and will substantially change requirements. The verification pipeline’s circular monitor can detect regulatory announcements but cannot determine their impact on documentation content.

Instruction to LLM: Add a note to Chapter 10: “This chapter reflects the regulatory landscape as of early 2026. MiFID III/MiFIR II and EMIR 3.0 are under legislative development and may materially change the requirements described here. Check the Deutsche Boerse Regulation page for updates.”

PART 2: HOSTILE REVIEWS

Review 1: The Hallucination Auditor

Reviewer profile: LLM accuracy researcher specializing in factual grounding of generative AI outputs. Has published extensively on the “confident fabrication” problem in technical documentation generation.

Rating: 4/10

This megaprompt has a fundamental, irreconcilable design flaw: it asks a language model to produce thousands of precise technical figures – microsecond latencies, EUR pricing to the cent, nanosecond timestamps, protocol field numbers, session throughput limits – and then demands that each be “sourced” from specific URLs. The LLM cannot actually verify these URLs. It will simply parrot back whatever numbers the prompt feeds it, wrapping them in citation syntax that looks authoritative but provides zero verification.

Specific weakness 1: Latency figures will degrade into plausible fiction. The prompt specifies “Minimum reaction time: 2,787 nanoseconds” and “EOBI vs ETI: 1.5 us lead from Feb 13 2025 measurements.” These are extraordinarily precise figures tied to specific dates. An LLM generating Chapter 8 will faithfully reproduce these numbers – but it will also need to write surrounding prose that contextualizes them, and that contextual prose is where hallucination creeps in. For example, the model might state “the 99th percentile latency measures 120 microseconds” because that sounds reasonable, even though the prompt never specified a 99th percentile figure. The reader cannot distinguish prompt-sourced facts from model-confabulated “reasonable” facts because they all carry the same citation format.

Specific weakness 2: URL integrity is theater. The prompt demands citations like *(Source: [T7 Trading Architecture](https://www.xetra.com/xetra-en/technology/t7))*. The LLM has no way to verify that this URL currently resolves, that it contains the claimed fact, or that the page content matches the prompt’s claims. Deutsche Boerse regularly reorganizes their website – PDFs get new blob IDs, pages get restructured. The “source” citations create a false sense of verification. When the verification pipeline checks these URLs and finds them returning 404, the entire source policy collapses.

Specific weakness 3: The 89-term glossary is a memorization test the LLM will partially fail. The prompt lists “ACE” through “Xetra” and demands exact definitions. An LLM will get 80+ of these correct because the definitions are supplied in the prompt. But for the 5-10 terms where the prompt’s definition is ambiguous or the model’s training data suggests a slightly different definition (e.g., “N7” is described both as “news distribution service” in the glossary and as “Network infrastructure” in Chapter 1), the model will silently produce inconsistent definitions across files.

Additional weakness 4: Timestamp measurement point codes will be mixed up. The prompt specifies t_3a, t_3d, t_3n, t_4, t_5, t_7, t_8, t_9, t_9d – nine distinct measurement points with specific locations in the processing pipeline. The LLM must reproduce these codes accurately across Chapter 8 (Latency & Performance), the ETI Session Lifecycle diagram, and the Quick Reference appendix. In practice, the model will confuse t_3a (network TAP inbound) with t_3n (gateway processing entry) because both start with “t_3” and both relate to gateway-side measurement. If the model writes “t_3n represents the network TAP capture point” instead of “t_3a,” the resulting latency calculations described in the text become meaningless. These codes are arbitrary identifiers from Deutsche Boerse’s internal measurement infrastructure and are not intuitive enough for an LLM to keep straight across 4,000+ words of latency discussion.

Additional weakness 5: The “public data first” principle timing will be stated imprecisely. The prompt says “EOBI market data published approximately 1.5 microseconds BEFORE the ETI execution report reaches the order originator” based on “13 February 2025 measurements.” This is an extremely specific claim tied to a specific measurement date. The LLM will likely drop the date qualifier and state this as a permanent architectural guarantee, when in reality the 1.5 microsecond figure is an observed median from one measurement session. Under different load conditions or after architecture changes, this gap could widen or narrow. The prompt does not distinguish between “design principle” (public data always published first) and “measured timing” (the specific 1.5 us gap), and the LLM will conflate them.

Predicted failure mode: The output will contain 20-40 fabricated or subtly incorrect technical details embedded in otherwise correct prose, indistinguishable from accurate content without manual expert review. The citation format provides false confidence. The most dangerous errors will be in the latency chapter and ETI deep-dive, where microsecond-level precision is required and small errors compound into incorrect architectural understanding.

Review 2: The Deutsche Boerse Insider

Reviewer profile: Senior technologist at Deutsche Boerse Group with 15 years of experience in T7 platform development. Has worked on the matching engine, gateway consolidation project, and CoLo 2.0 rollout.

Rating: 5/10

The megaprompt demonstrates solid awareness of the publicly documented T7 architecture, but it contains several technical mischaracterizations that would immediately identify the output as written by someone who has never operated the system in production.

Specific weakness 1: The PS Gateway / Matching Engine co-location is oversimplified. The prompt states “PS gateways consolidated with matching engines on the same physical server” as though this is a simple architectural fact. In reality, the consolidation involved eliminating the inter-process communication layer between separate PS gateway and ME processes that previously ran on different servers. The prompt does not capture the nuance that the “same server” claim means the PS gateway and ME share a NUMA domain (correctly mentioned for the 2024 tech refresh but not connected to the original 2021 consolidation). An LLM will produce text suggesting the co-location simply “moved two boxes next to each other,” missing the IPC elimination that delivered the actual latency improvement.

Specific weakness 2: The LF gateway latency figures require careful temporal context. The prompt states LF gateways added “~75 microseconds” historically and now add “~12 microseconds same-side” and “~1 microsecond cross-side.” These figures are correct as of January 2025, but the prompt does not specify that “same-side” means the order enters from the same network side as the target partition’s primary PS gateway, while “cross-side” means the order must traverse the redundancy link. An LLM will likely conflate “cross-side” with “cross-partition,” which are different things entirely. Cross-partition means trading an instrument on a different partition through an LF gateway; cross-side means network path traversal. This conflation would produce subtly incorrect architectural descriptions.

Specific weakness 3: ETI session pricing is more complex than presented. The prompt lists flat per-session fees, but actual pricing involves volume-based tiers (sessions 1-4 vs 5+), market-specific pricing (Eurex vs Xetra), and negotiated rates for large participants. The prompt partially captures this (HF Light EUR 125 sessions 1-4, EUR 250 sessions 5+), but the LLM will likely produce a simplified flat-rate table that misrepresents the actual cost structure, particularly for HF Ultra where pricing is deliberately not published (“See Price List” / “Contact Deutsche Boerse”).

Additional weakness 4: The EOBI “integration into matching engine process” is described without nuance. The prompt states “EOBI and EMDI integrated into the Matching Engine process since Release 12.0.” This is architecturally correct but technically imprecise. The integration means that the EOBI serialization code runs within the same OS process as the matching engine, sharing the same address space and avoiding inter-process communication (IPC). Before Release 12.0, there was a separate Market Data Distributor (MDD) process that received matching events via shared memory or IPC and serialized them into EOBI/EMDI format. The elimination of the MDD process saved approximately 4 microseconds of IPC overhead. However, the LLM will likely describe this as “EOBI is now generated inside the matching engine” without distinguishing between the serialization step (which moved into the ME process) and the network transmission step (which still uses a separate kernel network stack path). This matters because participants sometimes ask whether EOBI messages are “generated before” execution reports – the answer is that EOBI serialization happens first within the ME process, but both EOBI multicast and ETI TCP responses exit through different NIC queues with different scheduling characteristics.

Additional weakness 5: The partition expansion timeline has a subtlety the prompt misses. The prompt says “Originally 10 partitions; expanded to 11 in February 2022; simulation expanded 5 to 6 in February 2024.” This is correct for Eurex, but Xetra has a different partition structure. Xetra operates with 2 partitions (German equities and non-German equities, the latter on partition 55 since February 2024). The prompt does not clearly distinguish Eurex partition counts from Xetra partition counts, and the LLM will likely generate text implying all 11 partitions serve both Eurex and Xetra equally, which is incorrect.

Predicted failure mode: The output will be 90% accurate to a casual reader but will contain 5-10 architectural mischaracterizations that an experienced T7 operator would immediately flag. These errors cluster around the boundary between “documented public behavior” and “operational implementation detail” – the exact boundary where an LLM trained on public documentation cannot distinguish what it knows from what it infers. The document’s claim to be “professional reference documentation” will be undermined by these errors, as professional users expect precision at exactly these architectural boundaries.

Review 3: The Prompt Engineer

Reviewer profile: LLM prompt design expert with experience designing long-form generation prompts for technical documentation. Has shipped production prompt systems generating 50K+ word outputs.

Rating: 6/10

This is a well-structured megaprompt with a clear organizational hierarchy, but it has fundamental scaling problems and several ambiguity traps that will degrade output quality.

Specific weakness 1: The 6-batch output model is under-specified. The prompt says “produce output in 6 batches” but does not specify how the LLM should handle cross-batch dependencies. Batch 2 (chapters 1-7) will contain cross-references to chapters in Batch 3 (chapters 8-12). Will the LLM produce broken relative links in Batch 2 because it hasn’t generated Batch 3 yet? The prompt says “Use relative markdown links” but does not instruct the LLM to pre-compute all link targets before generating any batch. In practice, the LLM will produce correct forward-references by convention (the paths are predictable), but any deviation from the specified directory structure will cascade into broken links across batches.

Specific weakness 2: The “target word count” ranges are contradictory with the total. Adding up the individual chapter targets: Ch1 2,500-3,500 + Ch2 4,000-5,500 + Ch3 4,000-5,500 + Ch4 parent 3,000-4,000 + ETI 5,000-7,000 + FIX 3,000-4,000 + Ch5 parent 2,000-2,500 + EOBI/EMDI/MDI/RDI 4x 2,000-2,500 + Ch6 5,000-7,000 + Ch7 4,000-5,500 + Ch8 4,000-5,500 + Ch9 5,000-7,000 + Ch10 4,000-5,000 + Ch11 3,500-4,500 + Ch12 4,000-5,500. The minimum total for chapters alone is approximately 61,000 words. Adding glossary, quick reference, release history, pricing summary, diagrams, and supporting files pushes the total well past 71,000 words. No current LLM can reliably generate 71,000 words of consistent, accurate, cross-referenced technical documentation from a single prompt, even with batching. The context window will overflow, and later batches will lose coherence with earlier ones.

Specific weakness 3: The source citation mandate is unenforceable. The prompt demands “every factual claim needs inline citation” but does not define what constitutes a “factual claim” vs. a “general architectural description.” The sentence “T7 processes orders in FIFO sequence” – is this a factual claim requiring citation, or general architecture? The prompt says general descriptions “may omit citations if self-evident from context,” but “self-evident” is subjective. In practice, the LLM will either over-cite (every sentence gets a source, making the text unreadable) or under-cite (omitting sources for specific numbers because the surrounding context feels “architectural”).

Additional weakness 4: The glossary specification is a consistency trap. The prompt demands 89 glossary terms with specific definitions, then demands those same concepts be described in 12+ chapters. The glossary defines “Passive Liquidity Protection (PLP)” as “Risk control mechanism preventing unintended passive order execution during periods of market stress by automatically pulling quotes when triggered.” But Chapter 6 describes PLP as a deferral mechanism for aggressive orders, and Chapter 9 describes it as a protection for market makers against latency arbitrage. These are different framings of the same mechanism, and the glossary definition is actually the least accurate of the three. The LLM must reconcile three different descriptions across three files. In practice, it will use whatever description appears last in its context window, creating inconsistency with files generated earlier.

Additional weakness 5: The verification pipeline specification creates a false dependency. Section 9 specifies a Python verification pipeline with modules like check_facts.py that reads a fact_registry.yaml. But the prompt does not include the fact_registry.yaml content. It describes the schema but does not populate it. This means the generated check_facts.py will reference a file that does not exist in the generated output. The LLM will either skip generating the registry (breaking the pipeline) or generate a partial registry with fabricated entries (introducing errors). Either way, the “verification pipeline” section of the output is non-functional upon generation.

Predicted failure mode: The LLM will produce excellent individual files but will struggle with cross-file consistency after approximately 40,000 words of output. Terminology will drift (“Matching Engine” becomes “matching engine” becomes “the matcher”), cross-references may break (especially forward-references to later batches), and the later chapters (9-12) will be noticeably thinner in technical detail as the model’s effective context degrades. The glossary will contain 3-5 definitions inconsistent with chapter content. The verification pipeline will be syntactically valid Python but non-functional due to missing dependencies and configuration files.

Review 4: The Open-Source Maintainer

Reviewer profile: Experienced open-source maintainer who has forked and maintained large documentation repositories. Focuses on practical maintainability, CI/CD integration, and contributor experience.

Rating: 5/10

This megaprompt produces a repository that looks impressively complete on day one but will become a maintenance nightmare within 6 months. The architectural choices prioritize initial generation over ongoing viability.

Specific weakness 1: The verification pipeline is specified but not implementable. The prompt describes check_facts.py as reading a fact_registry.yaml and validating facts against source URLs. But Deutsche Boerse’s fact sources are primarily PDFs behind CDN blob URLs (e.g., eurex.com/resource/blob/4305946/...). These PDFs are not text-extractable in many cases (image-based content). The prompt acknowledges this (“marked pdf_text_extractable: false”) but then says they “fall back to content hash comparison.” Content hash comparison only detects if the PDF file changed, not if the facts within it changed. If Deutsche Boerse updates a pricing PDF and the new PDF has different content but the same facts, the hash changes and triggers a false positive. If they update the facts but keep the same PDF structure, the hash might not catch it. The pipeline creates an illusion of automated verification that is actually fragile and high-maintenance.

Specific weakness 2: Cross-references will break on the first content edit. The prompt specifies relative markdown links between 38 files, including anchor links to specific headings. When a contributor edits a heading (e.g., changing “## CoLo 2.0 Connection Pricing” to “## Co-Location 2.0 Pricing”), every cross-reference targeting that heading’s auto-generated anchor will break silently. The check_crossrefs.py module should catch this, but only if it runs. Contributors editing locally without running the verification pipeline will unknowingly introduce broken links. The megaprompt does not specify any pre-commit hooks or editor integrations to catch this in real-time.

Specific weakness 3: The 89-term glossary creates a duplication problem. Every glossary term has a definition that must remain consistent with the corresponding chapter content. When Chapter 9 updates its description of “Passive Liquidity Protection,” the glossary entry must also be updated. With 89 terms spread across 33 content files, maintaining consistency requires either automated extraction (not specified) or manual coordination (error-prone). The megaprompt does not specify a single-source-of-truth mechanism for definitions.

Additional weakness 4: The Mermaid diagrams are maintenance land mines. The prompt specifies 6 Mermaid diagrams with precise node labels, edge labels, and styling. Mermaid syntax is version-sensitive – the _config.yml pins mermaid: version: "11", but the diagrams use features (subgraph nesting, classDef with multiple classes, style directives) that may behave differently across Mermaid 10 vs 11. When Mermaid 12 is released and just-the-docs updates its Mermaid dependency, these diagrams may break visually without any content change. The prompt does not specify a Mermaid version lock strategy or visual regression testing approach. A contributor who upgrades the just-the-docs theme will discover broken diagrams days later when someone reports rendering issues.

Additional weakness 5: The GitHub Actions workflow has no PR-level verification. The prompt specifies a daily cron job at 06:00 UTC for verification, but no pull request checks. Contributors will submit PRs that introduce broken links, incorrect cross-references, or stale facts, and these issues will not be caught until the next morning’s daily run. By then, the PR is merged. A proper CI/CD setup would run check_crossrefs.py and a subset of check_links.py on every PR. The prompt’s workflow design catches decay but not contributor-introduced errors, which is the wrong priority for an actively maintained repository.

Predicted failure mode: After 3 content updates, the repository will have 5-10 broken cross-references, 2-3 inconsistent glossary entries, and a verification pipeline that reports false positives on PDF checks, training maintainers to ignore its warnings. By update 10, the Mermaid diagrams will have diverged from the text descriptions because contributors update text without updating diagrams, and the verification pipeline does not validate diagram-text consistency. The repository will look professional but will have accumulated enough technical debt to require a full audit, which no one will perform because the verification pipeline’s daily “PASS” status provides false comfort.

Review 5: The Temporal Decay Auditor

Reviewer profile: Technology governance analyst specializing in documentation lifecycle management. Examines how technical documentation degrades over time as referenced systems, URLs, pricing, and regulations evolve.

Rating: 4/10

This megaprompt produces documentation with a half-life of approximately 6 months before it crosses the threshold from “slightly outdated” to “actively misleading.” The prompt embeds dozens of time-sensitive facts without adequate staleness detection or update workflows.

Specific weakness 1: Pricing figures will be wrong within 12 months. The prompt specifies exact EUR amounts: “CoLo 2.0 EMDI: EUR 6,000/mo,” “HF Light EUR 125 sessions 1-4 Eurex,” “MMSP EUR 4,000 basic fee.” Deutsche Boerse updates pricing annually (effective January 1 each year, announced via circulars in Q4). The 2026 prices in this prompt already reflect a “~15% increase” from 2025. By January 2027, these prices will be wrong. The verification pipeline monitors circulars but cannot automatically update pricing in markdown files – it can only flag that a new circular exists. A human must then read the circular, determine which prices changed, update 3+ files (pricing-summary.md, quick-reference.md, the relevant chapter), and ensure consistency across all mentions. The megaprompt does not specify a pricing update workflow.

Specific weakness 2: T7 Release 14.1 is “planned” – it will either ship or be delayed. The prompt references “T7 Release 14.1 scheduled May 18, 2026” and “TLS 1.2 decommissioning” as future events. If you generate this documentation in April 2026, these are upcoming changes. If Release 14.1 ships on schedule, the documentation must be updated to change “planned” to “launched” and update all affected technical details. If Release 14.1 is delayed (which has happened with previous releases), the documentation will contain incorrect dates. Either way, the “planned” qualifier creates a time bomb that requires manual intervention.

Specific weakness 3: URL rot will affect 20-30% of links within 18 months. Deutsche Boerse’s website URLs contain blob IDs (e.g., /resource/blob/4305946/dcadfeef8842b1a84b0e9afa439802e1/data/T7_R.13.1_...pdf). When a new version of a manual is published (e.g., ETI Manual R.14.1 replacing R.13.1), the old blob URL may return 404 or redirect. The prompt contains approximately 60 specific URLs, and based on historical patterns, 15-20 of these will become invalid within 18 months as new document versions are published. The circular monitor can detect new publications, but remapping old URLs to new ones requires manual investigation of each broken link.

Additional weakness 4: The regulatory landscape is the fastest-decaying layer. The prompt documents MiFID II (effective January 3, 2018), the German HFT Act (May 15, 2013), and MAR (July 2016). It mentions upcoming MiFID III/MiFIR II (expected Q4 2026) and EMIR 3.0 (expected Q2 2026) in the Quick Reference but does not provide specifications for these future regulations because they are not yet finalized. Within 12 months of generation, one or both of these regulations will be adopted, fundamentally changing requirements for algorithm testing, OTR monitoring, and clearing obligations. Chapter 10 (Regulatory Framework) will become not just outdated but actively misleading if readers follow its guidance without checking for the new regulations. The verification pipeline’s circular monitor can detect regulatory announcements but cannot determine whether a specific circular invalidates content in Chapter 10 – that requires human regulatory expertise.

Additional weakness 5: The session pricing and session limit figures have undocumented expiration dates. The prompt states “max 600 ETI sessions per participant (since June 2024)” and specific EUR pricing. These figures come from Eurex circulars that are valid “until further notice” – they can change with any circular, not just annual price list updates. In 2024, the session limit was increased from 400 to 600. If Eurex increases it again to 800 in 2027, the documentation will state a limit that is too low. Conversely, if Eurex introduces session tiering or per-session throttle changes, the documentation will miss entirely new categories. The prompt’s verification pipeline monitors circulars by keyword, but “session limit” is not listed as a keyword in the circular_keywords configuration, so this specific change type may not be detected.

Additional weakness 6: The T7 Architecture Factsheet is a living document that changes silently. Several key metrics in Chapter 8 cite the T7 Architecture Factsheet at deutsche-boerse.com/resource/blob/320052/.... This document is updated periodically without version numbering or change logs. The daily request volume figure of “1.25 billion (April 7, 2025)” will be updated to a new peak figure when one occurs. The verification pipeline can detect if the PDF hash changes, but it cannot determine which specific figure within the PDF changed or whether the change affects repository content. A maintainer receiving a “PDF_CHANGED” alert must manually download the PDF, compare it to the previous version, identify changed figures, and update the repository – a process that takes 30-60 minutes per alert and will be deprioritized when more urgent issues compete for attention.

Predicted failure mode: By April 2027 (12 months after generation), the documentation will contain: 5-8 incorrect pricing figures, 15-20 broken or redirected URLs, 2-3 incorrect “planned” references that should say “launched” or “delayed,” stale regulatory references if MiFID III or EMIR 3.0 timelines shift, and at least 2 performance metrics that have been superseded by new records. The verification pipeline will report these issues but cannot fix them, creating a growing backlog of ACTION REQUIRED reports that maintainers will eventually ignore. The repository’s stated goal of being a “comprehensive, up-to-date reference” will degrade to “a historical snapshot from early 2026 with a maintenance bot that complains daily.”

Appendix: Review Scoring Justification

Reviewer Score Primary Concern Secondary Concern
Hallucination Auditor 4/10 LLM cannot verify its own citations; fabricated details indistinguishable from correct ones Timestamp codes and latency figures will be confused in surrounding prose
Deutsche Boerse Insider 5/10 PS/ME co-location architectural nuance lost; LF gateway latency terms conflated ETI session pricing tiers oversimplified; partition counts Eurex vs Xetra not distinguished
Prompt Engineer 6/10 71K+ word total output exceeds reliable LLM generation capacity; cross-batch consistency degrades Glossary definitions inconsistent with chapter descriptions; verification pipeline non-functional without fact_registry.yaml
Open-Source Maintainer 5/10 PDF hash comparison creates false positives; cross-references break on first heading edit No PR-level CI checks; Mermaid version sensitivity unaddressed; glossary duplication problem
Temporal Decay Auditor 4/10 Pricing obsolete within 12 months; Release 14.1 “planned” status creates time bomb 20-30% URL rot within 18 months; regulatory landscape fastest-decaying layer; session limits change without warning

The average score of 4.8/10 reflects the fundamental tension in this megaprompt: it is an excellent specification for a human technical writer with access to Deutsche Boerse’s documentation, but it asks an LLM to perform tasks that require capabilities beyond text generation – URL verification, PDF content extraction, cross-file consistency over 70K+ words, and temporal awareness of when “planned” events become “launched.” The megaprompt’s greatest strength (exhaustive specification of every metric, URL, and structural detail) is simultaneously its greatest weakness (creating thousands of verification points that the LLM cannot actually verify, producing documentation that appears authoritative but contains undetectable errors).

End of Megaprompt

Back to top

This work is licensed under CC BY-SA 4.0. All content sourced exclusively from official Deutsche Boerse Group publications.