HFT Exchange Knowledge Base – Work Plan

Produced: 2026-04-08. Target: Deutsche Boerse Group. Exchange-specific decisions are marked with [DB-SPECIFIC] throughout. Replace these for CME/LSE/SGX adaptation.

---

Phase 1: Research (Source Gathering)

Entry criterion: Project kickoff. Exit criterion: Every chapter has a populated source list; gap analysis complete; temporal snapshot recorded for all documents. Estimated effort: 5-7 days.

Task 1.1: Domain Crawl – Eurex

Description: Systematically harvest technical manuals, circulars, concept papers, and price lists from eurex.com. Dependencies: None. Effort: 1 day.

Documents to collect:

Document	URL Path	Chapters Served
ETI Manual (current release)	/resource/blob/…Enhanced_Trading_Interface	Ch 4, 8, 9
FIX LF Manual (current release)	/resource/blob/…FIX_LF_Manual	Ch 4
EMDI/MDI/RDI Manual	/resource/blob/…EMDI_MDI_RDI	Ch 5
EOBI Manual	/resource/blob/…EOBI_Manual	Ch 5, 8
Participant Simulation Guide	/resource/blob/…Simulation_Guide	Ch 11
T7 Disaster Recovery Concept	/resource/blob/…Disaster_Recovery	Ch 11
Connection Agreement Price List	/resource/blob/…preisv_anv	Ch 4, 8, 10
Trading Safeguards presentation	/resource/blob/…trading-safeguards	Ch 9
OTR Concept Paper	/resource/blob/…order-to-trade-ratio	Ch 9
Excessive System Usage Fee Paper	/resource/blob/…excessive-system-usage	Ch 9
PLP Whitepaper	/resource/blob/…Passive-Liquidity-Protection	Ch 6, 7
Circular archive (latest 50)	/ex-en/find/circulars	Ch 12, maintenance
T7 Cloud Simulation page	/ex-en/support/technology/t7-cloud-simulation	Ch 11
Market Making & Liquidity page	/ex-en/trade/market-making	Ch 10
Exchange Membership pages	/ex-en/trade/exchange-membership	Ch 12
T7 Release initiative pages	/ex-en/support/initiatives/T7-Release-*	Ch 12

Acceptance criteria: All listed PDFs downloaded locally; HTML pages archived as PDF snapshots; retrieval dates recorded.

Task 1.2: Domain Crawl – Xetra / Cash Market

Description: Harvest trading parameters, connection fee schedules, and regulatory factsheets from xetra.com and cashmarket.deutsche-boerse.com. Dependencies: None. Effort: 0.5 day.

Documents to collect:

Document	Chapters Served
Continuous Trading with Auctions page	Ch 3, 6, 7
Trading Parameter / Tick Size pages	Ch 3, 6
Co-Location Services page	Ch 1, 3, 8
Bandwidths and Connection Fees PDF	Ch 8
MiFID II Flagging Requirements factsheet	Ch 2
Reporting Handbook RTS24	Ch 2
Deutsche Boerse Circulars archive	Ch 12, maintenance
N7 Network Access Guide PDF	Ch 3, 8

Acceptance criteria: Same as 1.1.

Task 1.3: Domain Crawl – Deutsche Boerse Group

Description: Harvest corporate/group-level documents: architecture overviews, regulatory pages, Open Day presentations. Dependencies: None. Effort: 0.5 day.

Documents to collect:

Document	Chapters Served
T7 Trading Architecture overview	Ch 1, 2
MiFID II/MiFIR regulation page	Ch 2
HFT Regulation page	Ch 2
MAD/MAR regulation page	Ch 2
Open Day 2023 – Latency Roadmap	Ch 8
Open Day 2023 – Risk Controls	Ch 9
Open Day 2019 – T7 Latency Roadmap	Ch 8
T7 Network Access Guide PDF	Ch 3, 8
FIX Gateway Introduction PDF	Ch 4
Group events page (upcoming Open Days)	Ch 12

Acceptance criteria: Same as 1.1.

Task 1.4: Domain Crawl – Specialized Domains

Description: Harvest from eurex-clearing.com, mdi.deutsche-boerse.com (Market Data Services), eex.com, and developer.deutsche-boerse.com. Dependencies: None. Effort: 0.5 day.

Documents to collect:

Domain	Documents	Chapters Served
eurex-clearing.com	PRISMA margining overview, Default Management Process, Default Waterfall, CCP service descriptions	Ch 7, 9
mds.deutsche-boerse.com	High Precision Timestamps page, MDDA Price List PDF	Ch 5, 8
eex.com [DB-SPECIFIC]	Trading rules overview, connectivity pages (for EEX venue coverage)	Ch 3
developer.deutsche-boerse.com	API documentation portal, onboarding guides	Ch 12

Acceptance criteria: Same as 1.1.

Task 1.5: Temporal Snapshot Registry

Description: For every document collected in 1.1-1.4, record metadata into a machine-readable registry. Dependencies: 1.1-1.4 complete. Effort: 0.5 day.

Metadata schema per entry:

- id: "SRC-001"
  title: "ETI Manual R.14.0"
  domain: "eurex.com"
  url: "https://..."
  document_type: "technical_manual"  # technical_manual | circular | concept_paper | presentation | price_list | release_notes | regulatory_filing | web_page
  publication_date: "2025-11-01"     # from document header or best estimate
  retrieval_date: "2026-04-10"
  version: "R.14.0 v1"
  sha256_hash: "abc123..."          # for PDFs only
  living_document: false             # true if URL is known to be updated in-place
  chapters_served: [4, 8, 9]
  decay_category: "architecture"     # pricing | url | regulatory | architecture
  notes: ""

Acceptance criteria: Registry file (YAML or JSON) exists with an entry for every collected document. No chapter has zero source entries.

Task 1.6: Gap Analysis

Description: For each chapter, compare the topic outline (from Phase 3 specs) against available sources. Identify topics with no approved-domain coverage. Dependencies: 1.5 complete. Effort: 0.5 day.

Decision rules for gaps:

Gap Type	Action
DB-specific fact with no DB source	Omit or flag as “not publicly documented”
Industry-standard concept (e.g., FIX protocol basics)	Include as general knowledge; no citation required
Cross-exchange concept with DB nuance	State the general concept, note DB-specific aspects only if sourced
Latency/performance number without document	NEVER fabricate; omit or state “consult current documentation”

Acceptance criteria: Gap analysis document produced. Every gap has a disposition (omit / general knowledge / flagged). Zero unresolved gaps.

Risk notes: Pricing data and session limits change frequently; documents retrieved now may be outdated by content generation time. Mitigate by recording retrieval dates and planning a pre-publication freshness check.

---

Phase 2: Content Architecture

Entry criterion: Phase 1 complete (all source lists populated, gap analysis done). Exit criterion: Architecture decision document approved; directory structure committed; navigation hierarchy defined. Estimated effort: 2-3 days.

Task 2.1: Directory Structure Decision

Description: Finalize file organization. The existing project uses a nested structure: chapters/NN-slug/README.md with sub-pages as siblings. Validate or revise. Dependencies: Phase 1 complete. Effort: 0.5 day.

Current structure (already in repo):

chapters/
  01-exchange-overview/README.md
  02-t7-architecture/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
  appendix/
    glossary.md
    quick-reference.md
    release-history.md
    pricing-summary.md
diagrams/
  t7-architecture-overview.md
  ...

Decision criteria: When does a topic get its own sub-page? Rule: if it exceeds 3,000 words AND has a distinct source document set, split it out. Otherwise, keep it as an H2 section.

Acceptance criteria: Directory structure documented; matches existing repo structure or migration plan produced if changes needed.

Task 2.2: Chapter Dependency Graph

Description: Map which chapters reference concepts from other chapters. Determine optimal writing order. Dependencies: None. Effort: 0.5 day.

Dependency map:

Ch 1 (Exchange Overview)     --> foundation for all
Ch 2 (T7 Architecture)       --> depends on Ch 1; needed by Ch 4, 5, 8
Ch 3 (Network/Co-Lo)         --> depends on Ch 1, 2; needed by Ch 8
Ch 4 (Trading Interfaces)    --> depends on Ch 2, 3; needed by Ch 6, 8, 9
Ch 5 (Market Data)           --> depends on Ch 2, 3; needed by Ch 8
Ch 6 (Order Types/Matching)  --> depends on Ch 4; needed by Ch 7, 9
Ch 7 (Market Models)         --> depends on Ch 3, 6; needed by Ch 10
Ch 8 (Latency/Performance)   --> depends on Ch 2, 3, 4, 5 (most dependencies)
Ch 9 (Risk Controls)         --> depends on Ch 4, 6
Ch 10 (Regulatory)           --> depends on Ch 7; cross-cuts all
Ch 11 (Testing/Cert)         --> depends on Ch 4, 5
Ch 12 (Roadmap/Changes)      --> depends on all (references planned changes to each area)

Recommended writing order: 1, 2, 3, 4, 5, 6, 7, 9, 10, 11, 8, 12. Rationale: Ch 8 (latency) has the most inbound dependencies, so write it late. Ch 12 (roadmap) must be last since it references all other chapters.

Acceptance criteria: Dependency graph committed to planning docs; writing order justified.

Task 2.3: Navigation Hierarchy (Front Matter)

Description: Define the just-the-docs front matter schema for sidebar navigation. Dependencies: 2.1 complete. Effort: 0.5 day.

Front matter schema (already partially implemented):

---
layout: default
title: "Chapter Title"
nav_order: N          # 1-based; chapters 10-120 (by 10s), appendices 200+, diagrams 300+
parent: "Parent Title" # for sub-pages only
has_children: true     # for chapter index pages with sub-pages
---

Acceptance criteria: Every .md file has correct front matter; sidebar renders the full TOC in correct order.

Task 2.4: Cross-Reference Strategy

Description: Define how internal links work across pages and how to prevent breakage. Dependencies: 2.1, 2.3 complete. Effort: 0.5 day.

Rules:

1. Link format: Use relative markdown links: [ETI](../04-trading-interfaces/eti.md). The jekyll-relative-links plugin converts .md to .html at build time.
2. Anchor links: Use explicit heading anchors where auto-generated anchors are fragile. For critical targets (frequently linked headings), add {: #stable-anchor} kramdown attributes.
3. Cross-reference registry: Maintain a JSON file (crossrefs_result.json) listing all link targets. The verification pipeline checks all links against this registry on every PR.
4. Heading rename protocol: Before renaming any heading, search for all inbound links. The CI cross-reference check catches renames post-commit, but authors should grep before editing.

Acceptance criteria: Cross-reference validation script exists and runs in CI. Zero broken links at initial deployment.

Task 2.5: Glossary Authority Protocol

Description: Define the single-source-of-truth mechanism for glossary terms. Dependencies: None. Effort: 0.5 day.

Rules:

1. chapters/appendix/glossary.md is the authoritative definition source for all ~90 terms.
2. Chapters MUST NOT redefine glossary terms inline. On first use in a chapter, link to the glossary entry: [ETI](../appendix/glossary.md#eti).
3. Chapters MAY provide additional context about a term (e.g., “ETI is the primary low-latency interface; see the ETI deep-dive for session management details”) but MUST NOT contradict the glossary definition.
4. The verification pipeline includes a glossary consistency checker that flags: (a) terms used without linking to glossary, (b) inline definitions that diverge from glossary text.
5. New terms are added to the glossary FIRST, then referenced in chapters. Never the reverse.

Citation boundary rule: Facts requiring citation vs. general knowledge:

• Requires citation: any number (price, latency, session limit, threshold), any protocol-specific behavior, any Deutsche Boerse-specific policy.
• General knowledge (no citation): what an order book is, what TCP means, what MiFID II is (in broad terms).

Acceptance criteria: Glossary protocol documented; verification module spec’d for consistency checking.

---

Phase 3: Per-Chapter Writing Specifications

Entry criterion: Phase 2 complete. Exit criterion: All 12 chapter specs and 4 appendix specs finalized. Estimated effort: 3-4 days.

Note on existing chapter numbering. The planning prompt uses a different chapter ordering than the existing repo. The repo structure (established and deployed) is authoritative. The specs below follow the repo’s numbering. The planning prompt’s chapter titles map as follows:

Planning Prompt	Repo Chapter
Ch 1 Exchange Architecture Overview	Ch 1 Exchange Overview + Ch 2 T7 Architecture
Ch 2 Regulatory Framework	Ch 10 Regulatory Framework
Ch 3 Trading Venues & Microstructure	Ch 7 Market Models + Ch 3 Network Infrastructure
Ch 4 Trading Interfaces	Ch 4 Trading Interfaces
Ch 5 Market Data	Ch 5 Market Data
Ch 6 Order Types	Ch 6 Order Types & Matching
Ch 7 Clearing & Settlement	Partially in Ch 9 Risk Controls (clearing/CCP)
Ch 8 Latency & Performance	Ch 8 Latency & Performance
Ch 9 Risk Management	Ch 9 Risk Controls
Ch 10 Market Making	Partially in Ch 7 Market Models
Ch 11 Testing & Certification	Ch 11 Simulation & Testing
Ch 12 Upcoming Changes	Ch 12 Developer Onboarding + release-history appendix

Chapter 1: Deutsche Boerse Group Overview

• Scope: Corporate structure, trading venues (Xetra, Eurex, EEX, 360T), value chain from trading through clearing to settlement. Excludes: technical architecture details (deferred to Ch 2).
• Required sources: deutsche-boerse.com group overview, Eurex Exchange overview, Xetra overview, EEX overview pages.
• Topic outline:
  • H2: Corporate Structure and Business Segments
  • H2: Trading Venues at a Glance
    • H3: Xetra (Cash Market)
    • H3: Eurex (Derivatives)
    • H3: EEX (Energy) [DB-SPECIFIC]
    • H3: 360T (FX) [DB-SPECIFIC]
  • H2: The Value Chain (Trading -> Clearing -> Settlement -> Custody)
  • H2: Key Subsidiaries and Their Roles
• Depth: Surface overview. Establishes context; details live in later chapters.
• Word count target: 2,500-3,500 words.
• Cross-ref dependencies: Linked FROM all subsequent chapters. Links TO Ch 2 (architecture), Ch 7 (market models).
• Known pitfalls: Risk of being too superficial on venue differences. Must clearly distinguish Xetra vs. Eurex matching engine architecture even at overview level. Avoid conflating “Deutsche Boerse” (the group) with “Deutsche Boerse AG” (the specific entity).

Chapter 2: T7 Trading System Architecture

• Scope: T7 platform architecture: partition structure, matching engine design (PS/ME topology), gateway layers, high-availability model. Excludes: network-level details (Ch 3), specific interface protocols (Ch 4).
• Required sources: T7 Trading Architecture page, Open Day presentations, T7 Network Access Guide (architecture sections only).
• Topic outline:
  • H2: T7 Platform Overview
  • H2: Partition Model (Products to Partitions)
    • H3: Xetra Partitions vs. Eurex Partitions
  • H2: Matching Engine Architecture
    • H3: PS/ME Co-Location Topology
    • H3: Failover and High Availability
  • H2: Gateway Architecture
    • H3: Trading Gateways
    • H3: Market Data Gateways
  • H2: Release Cycle and Versioning
• Depth: Moderate-to-deep. This is a core reference chapter.
• Word count target: 4,000-5,500 words.
• Cross-ref dependencies: Depends on Ch 1. Linked from Ch 3, 4, 5, 8.
• Known pitfalls: PS/ME co-location topology differences between Eurex and Xetra partitions are frequently oversimplified. Must not present a single topology as universal. Gateway terminology (LF gateway vs. HF gateway) must be precise – conflation is a known LLM failure mode.

Chapter 3: Network & Co-Location Infrastructure

• Scope: Physical and logical network topology, co-location/proximity hosting, connectivity options (leased lines, internet), bandwidth tiers. Excludes: protocol-level details (Ch 4), latency measurement methodology (Ch 8).
• Required sources: T7 Network Access Guide, N7 Network Access Guide, Co-Location Services pages, Bandwidths and Connection Fees PDF.
• Topic outline:
  • H2: Data Center Topology [DB-SPECIFIC]
  • H2: Co-Location Services
    • H3: Proximity Hosting vs. Full Co-Location
  • H2: Connectivity Options
    • H3: Leased Lines
    • H3: Internet Access
    • H3: Bandwidth Tiers and Pricing
  • H2: Network Architecture (10GbE, Multicast)
  • H2: Redundancy and Failover
• Depth: Moderate. Mix of conceptual and specific (pricing tiers need citation).
• Word count target: 3,500-5,000 words.
• Cross-ref dependencies: Depends on Ch 1, 2. Linked from Ch 4, 5, 8.
• Known pitfalls: Pricing data decays fastest. All bandwidth/connection fee figures must carry source date and “verify current pricing” disclaimer. Co-location terminology differs across Xetra and Eurex documentation.

Chapter 4: Trading Interfaces (ETI & FIX Gateway)

• Scope: ETI protocol (session management, message types, throttling, session pricing), FIX LF interface, FIXML. Excludes: market data interfaces (Ch 5).
• Required sources: ETI Manual, FIX LF Manual, FIX Gateway Introduction PDF, Connection Agreement Price List.
• Sub-pages: eti.md (ETI deep-dive), fix-gateway.md (FIX deep-dive).
• Topic outline (README.md index):
  • H2: Interface Landscape Overview
  • H2: ETI (Enhanced Trading Interface)
    • H3: Session Types and Lifecycle
    • H3: Message Types (Request/Response, Broadcast)
    • H3: Throttling and Back-Pressure
  • H2: FIX LF Interface
    • H3: FIX Session Management
    • H3: Supported Message Types
  • H2: Choosing Between ETI and FIX
  • H2: Session Pricing [DB-SPECIFIC]
• Topic outline (eti.md deep-dive):
  • H2: ETI Session Lifecycle (detailed)
  • H2: Application Messages
  • H2: Heartbeat and Session Maintenance
  • H2: Error Handling and Recovery
  • H2: Bandwidth and Throttle Parameters
• Depth: Deep technical specification. This is a primary reference chapter for implementers.
• Word count target: 5,000-7,000 words (across README + 2 sub-pages).
• Cross-ref dependencies: Depends on Ch 2, 3. Linked from Ch 6, 8, 9, 11.
• Known pitfalls: ETI session pricing has volume tiers and instrument-group variations that resist simple summarization. Do NOT flatten pricing into a single table without noting that tiers exist. Timestamp measurement codes (T1-T7 series for ETI) must be clearly distinguished from EOBI codes. Session limit numbers change via circulars – always cite the specific circular/document version.

Chapter 5: Market Data Interfaces

• Scope: EOBI, EMDI, MDI, RDI, EMDS. Feed architecture, entitlements, integration patterns, data quality. Excludes: trading interfaces (Ch 4), latency benchmarking (Ch 8).
• Required sources: EOBI Manual, EMDI/MDI/RDI Manual, High Precision Timestamps page, EMDS Manual, MDDA Price List.
• Sub-pages: eobi.md, emdi.md, mdi.md, rdi.md.
• Topic outline (README.md index):
  • H2: Market Data Architecture Overview
  • H2: Feed Comparison Matrix (EOBI vs EMDI vs MDI vs RDI)
  • H2: Data Entitlements and Licensing [DB-SPECIFIC]
  • H2: Integration Patterns
• Depth: Deep. Each sub-page covers a single feed in full technical detail.
• Word count target: 5,000-7,000 words (across README + 4 sub-pages).
• Cross-ref dependencies: Depends on Ch 2, 3. Linked from Ch 8.
• Known pitfalls: EOBI is NOT a simple drop-in feed – its operational complexity (sequence management, recovery, snapshot handling) must be covered honestly. Do not present it as “just another market data feed.” Timestamp measurement code series (Tnn for EOBI) must not be conflated with ETI T1-T7 series. MDDA pricing is a known decay risk.

Chapter 6: Order Types & Matching Engine

• Scope: Order type taxonomy (market, limit, stop, iceberg, etc.), matching logic, self-match prevention, order routing. Excludes: market model phases (Ch 7), risk controls applied to orders (Ch 9).
• Required sources: ETI Manual (order types section), PLP Whitepaper, Self-Match Prevention page, Xetra continuous trading page.
• Topic outline:
  • H2: Order Type Taxonomy
    • H3: Market Orders
    • H3: Limit Orders
    • H3: Stop Orders
    • H3: Iceberg/Reserve Orders
    • H3: Persistence Types (GTC, GTD, IOC, FOK)
  • H2: Matching Engine Logic
    • H3: Price-Time Priority
    • H3: Auction Matching
  • H2: Self-Match Prevention
  • H2: Order Routing Across Venues [DB-SPECIFIC]
• Depth: Moderate-to-deep. Order types need precise definitions; matching logic needs worked examples.
• Word count target: 4,000-5,500 words.
• Cross-ref dependencies: Depends on Ch 4. Linked from Ch 7, 9.
• Known pitfalls: Order type availability differs between Xetra and Eurex. Must not present a unified order type list without noting venue-specific restrictions. PLP interaction with matching priority is subtle.

Chapter 7: Market Models & Microstructure

• Scope: Trading phases (pre-trading, opening auction, continuous, closing auction, post-trading), market models (continuous with auctions, Eurex PLP), tick sizes, trading hours. Excludes: order type definitions (Ch 6), regulatory requirements for market models (Ch 10).
• Required sources: Xetra Continuous Trading page, Eurex Trading Hours/Phases pages, Eurex PLP Market Model page, Trading Parameters/Tick Sizes pages, Market Making and Liquidity Provisioning page.
• Topic outline:
  • H2: Trading Phases
    • H3: Pre-Trading
    • H3: Opening Auction
    • H3: Continuous Trading
    • H3: Closing Auction
    • H3: Post-Trading
  • H2: Xetra Market Model
  • H2: Eurex Market Model
    • H3: Passive Liquidity Protection (PLP)
  • H2: Tick Size Regimes
  • H2: Trading Hours [DB-SPECIFIC]
  • H2: Market Making and Designated Sponsors
    • H3: Quoting Obligations
    • H3: Rebate Structures [DB-SPECIFIC]
• Depth: Moderate. Phase descriptions must be precise but concise.
• Word count target: 4,000-5,500 words.
• Cross-ref dependencies: Depends on Ch 3, 6. Linked from Ch 10.
• Known pitfalls: Eurex and Xetra market models differ significantly; must not generalize. Tick size regimes are set by regulation (MiFID II) but implemented per-venue – clarify the distinction. Market maker rebate tiers are pricing data with high decay risk.

Chapter 8: Latency & Performance

• Scope: End-to-end latency measurement, timestamp methodology, co-location latency characteristics, gateway latency, performance optimization strategies. Excludes: network topology details (Ch 3), co-location pricing (Ch 3).
• Required sources: Open Day 2023 Latency Roadmap, Open Day 2019 Latency Roadmap, Trading System Dynamics presentation, High Precision Timestamps page, T7 Network Access Guide (latency sections).
• Topic outline:
  • H2: Latency Measurement Methodology
    • H3: Timestamp Codes (ETI: T1-T7)
    • H3: Timestamp Codes (EOBI: Tnn series)
    • H3: High Precision Timestamps
  • H2: Gateway Latency
    • H3: LF Gateway vs. HF Path
    • H3: Measuring Round-Trip Time
  • H2: Co-Location Performance Characteristics
  • H2: Performance Optimization Strategies
  • H2: Historical Latency Improvements
• Depth: Deep technical specification. This chapter targets HFT practitioners directly.
• Word count target: 4,000-6,000 words.
• Cross-ref dependencies: Depends on Ch 2, 3, 4, 5. Linked from Ch 9. (Most inbound dependencies of any chapter.)
• Known pitfalls: HIGHEST RISK CHAPTER. Latency figures degrade into plausible fiction when sourced from memory. Every number must have a document citation with date. LF gateway terminology is frequently conflated across documents. Timestamp measurement codes (T1-T7 vs. Tnn) are easily confused across ETI and EOBI contexts – use separate subsections, never interleave. Gateway latency terminology (“order-entry gateway” vs. “trading gateway” vs. “LF gateway”) must map precisely to official documentation terms. NEVER state a latency number without citing the specific source document, page, and date.

Chapter 9: Risk Controls & Pre-Trade Checks

• Scope: Pre-trade risk controls, circuit breakers/volatility interruptions, kill switches, position limits, order-to-trade ratios, excessive system usage fees, CCP/clearing model overview. Excludes: detailed margin methodology (would need a dedicated chapter), regulatory mandate for controls (Ch 10).
• Required sources: Trading Safeguards presentation, Risk Controls Open Day 2023 presentation, OTR Concept Paper, Excessive System Usage Fee Paper, Volatility Interruption page, Eurex Clearing PRISMA overview, Default Management/Waterfall pages.
• Topic outline:
  • H2: Pre-Trade Risk Controls
    • H3: Price Validations
    • H3: Quantity Limits
    • H3: Kill Switch Functionality
  • H2: Market-Level Safeguards
    • H3: Volatility Interruptions (Circuit Breakers)
    • H3: Extended Volatility Interruptions
  • H2: Order-to-Trade Ratios
  • H2: Excessive System Usage Fees
  • H2: Clearing and CCP Model Overview
    • H3: Eurex Clearing Role
    • H3: PRISMA Margin Methodology (overview only)
    • H3: Default Waterfall
  • H2: Position Limits
• Depth: Moderate-to-deep. Risk thresholds need citations; clearing is overview-level.
• Word count target: 4,500-6,000 words.
• Cross-ref dependencies: Depends on Ch 4, 6. Linked from Ch 10.
• Known pitfalls: Risk thresholds (OTR limits, volatility interruption bands) change via circulars. All thresholds must cite circular number and date. PRISMA margin methodology is complex – keep it at overview level and link to Eurex Clearing documentation for details.

Chapter 10: Regulatory Framework

• Scope: MiFID II/MiFIR requirements for algorithmic and HFT firms, BaFin oversight, algo flagging, transaction reporting, market abuse regulation. Excludes: specific venue trading rules (Ch 7), specific risk control implementations (Ch 9).
• Required sources: MiFID II/MiFIR DB page, HFT Regulation page, MiFID II Flagging Requirements factsheet, Reporting Handbook RTS24, MAD/MAR regulation page.
• Topic outline:
  • H2: MiFID II/MiFIR Overview
    • H3: Algorithmic Trading Definition
    • H3: HFT Definition and Thresholds
  • H2: Algo Flagging Requirements
  • H2: Transaction Reporting (RTS 24/25)
  • H2: Market Abuse Regulation (MAR)
  • H2: BaFin Oversight [DB-SPECIFIC]
  • H2: Upcoming Regulatory Changes (MiFID III/MiFIR II)
• Depth: Moderate. Regulatory text must be accurate but accessible to technologists, not lawyers.
• Word count target: 3,500-5,000 words.
• Cross-ref dependencies: Depends on Ch 7. Cross-cuts all chapters (regulatory underpins everything).
• Known pitfalls: Regulatory content has medium-term decay (MiFID III expected 2026-2027). All regulatory statements must carry temporal qualifiers (“as of [date]”). Must distinguish between EU-level regulation and DB-specific implementation. BaFin-specific requirements are exchange-specific.

Chapter 11: Simulation & Testing Environments

• Scope: T7 Cloud Simulation, participant simulation, conformance testing, production readiness, disaster recovery testing. Excludes: production risk controls (Ch 9), connectivity setup (Ch 3).
• Required sources: T7 Cloud Simulation page, Participant Simulation Guide, Simulation Calendar page, T7 Disaster Recovery Concept, Incident Handling Guide.
• Topic outline:
  • H2: T7 Cloud Simulation Environment
  • H2: Participant Simulation
    • H3: Instrument Availability
    • H3: Simulation Calendar and Scheduling
  • H2: Conformance Testing
  • H2: Production Readiness Checklist
  • H2: Disaster Recovery Testing
  • H2: Emergency Playbook Overview
• Depth: Moderate. Practical focus for firms onboarding to the exchange.
• Word count target: 3,000-4,500 words.
• Cross-ref dependencies: Depends on Ch 4, 5.
• Known pitfalls: Simulation calendar dates are ephemeral. Do not embed specific dates; link to the live calendar page. Conformance testing requirements can change with T7 releases.

Chapter 12: Developer Onboarding & Resources

• Scope: Getting started guide, developer portal, API access, membership/admission process, ISV program, upcoming T7 releases and roadmap. Excludes: detailed interface specifications (Ch 4, 5).
• Required sources: Developer Portal, API Documentation, Exchange Membership pages, Trader Admission, ISV Program page, T7 Release pages, Implementation News, Production Newsboard.
• Topic outline:
  • H2: Getting Started
    • H3: Membership and Admission Process
    • H3: Technical Onboarding Steps
  • H2: Developer Portal and APIs
  • H2: ISV and Service Provider Program
  • H2: Information Channels
    • H3: Circulars and Newsflashes
    • H3: Implementation News
    • H3: Production Newsboard
  • H2: T7 Release Roadmap
    • H3: Current Release (R.14.0)
    • H3: Planned Releases
  • H2: Community and Events
    • H3: Capital Markets Academy
    • H3: Open Day, Derivatives Forum
• Depth: Surface-to-moderate. This is a guide, not a specification.
• Word count target: 2,500-4,000 words.
• Cross-ref dependencies: References all chapters (serves as a navigation entry point). Must be written last.
• Known pitfalls: “Planned” vs. “launched” status is the primary risk. Every item tagged as “upcoming” or “planned” must include the source date and a status field. The release roadmap section will decay fastest – plan quarterly review.

Appendix Specs

A. Glossary (~90 terms): Authoritative term definitions. Each entry: term, acronym (if applicable), definition (1-3 sentences), cross-ref to chapter where discussed. Source: technical manuals. Word count: 4,000-5,000 words.

B. Quick Reference / Acronym Reference: Alphabetical acronym list with expansions. One-line entries only. Derived mechanically from glossary. Word count: 1,000-1,500 words.

C. Release History: T7 release timeline with major features per release. Source: T7 Release pages, circulars. Decays on every release. Word count: 1,500-2,500 words.

D. Pricing Summary: Consolidated pricing reference (connection fees, session fees, market data fees). HIGHEST DECAY RISK. Every figure must cite source PDF and date. Include “verify current pricing at [URL]” disclaimer. Word count: 1,500-2,500 words.

Total word count target: 53,000-72,000 words (within the ~70,000-word LLM generation bound).

---

Phase 4: Diagrams

Entry criterion: Phase 3 chapter specs approved. Exit criterion: All 6 diagrams specified; Mermaid syntax validated; diagram-text terminology verified. Estimated effort: 2 days.

Diagram Inventory

#	Diagram	File	Visualizes	Technology
1	T7 Architecture Overview	diagrams/t7-architecture-overview.md	PS/ME topology, gateway layers, partition structure	Mermaid flowchart
2	Network Topology	diagrams/network-topology.md	Data center layout, co-lo zones, connectivity paths	Mermaid flowchart
3	Order Flow Lifecycle	diagrams/order-flow.md	Order entry through matching to execution report	Mermaid sequence diagram
4	Market Data Distribution	diagrams/market-data-distribution.md	Feed hierarchy (EOBI/EMDI/MDI/RDI), multicast groups	Mermaid flowchart
5	ETI Session Lifecycle	diagrams/eti-session-lifecycle.md	Session states, heartbeat, recovery	Mermaid state diagram
6	Matching Engine Flow	diagrams/matching-engine-flow.md	Order book operations, price-time priority, auction matching	Mermaid flowchart

Per-Diagram Specs

Diagram 1 – T7 Architecture Overview:

• Show: Partition Server (PS), Matching Engine (ME), Trading Gateways, Market Data Gateways, Clearing link.
• Exclude: individual network cables, IP addresses, specific product assignments to partitions.
• Must clearly show PS/ME co-location differences between Xetra and Eurex.

Diagram 2 – Network Topology:

• Show: Primary/secondary data centers, co-location zones, proximity hosting, leased line paths, internet paths.
• Exclude: internal switch-level topology, specific vendor equipment.

Diagram 3 – Order Flow Lifecycle:

• Show: Client -> Gateway -> PS -> ME -> Execution Report -> Client. Include throttling decision point.
• Exclude: error flows (keep to happy path + one rejection path).

Diagram 4 – Market Data Distribution:

• Show: Matching Engine -> EOBI (direct), ME -> EMDI (enriched), ME -> MDI (aggregated), RDI (reference data). Show multicast distribution.
• Exclude: entitlement logic, commercial licensing.

Diagram 5 – ETI Session Lifecycle:

• Show: States (Disconnected, Connected, Logged In, Active, Recovery). Transitions (Connect, Logon, Subscribe, Heartbeat Timeout, Reconnect).
• Exclude: individual message field layouts.

Diagram 6 – Matching Engine Flow:

• Show: Incoming order -> Price validation -> Book insertion -> Match attempt -> Trade generation.
• Exclude: self-match prevention details (covered in Ch 6 text).

Mermaid Version Lock Strategy

• Lock Mermaid version in _config.yml: mermaid: version: "11" (already configured).
• Pin to major version only; minor updates within v11 are backward-compatible.
• If GitHub Pages updates Mermaid, test all 6 diagrams. Add a CI check that renders each diagram and screenshots for visual diff (stretch goal).
• Maintain a diagrams/README.md noting the Mermaid version and syntax conventions used.

Diagram-Text Consistency Protocol

• Every label in a diagram must use the exact term from the glossary. Before finalizing a diagram, cross-check all labels against glossary.md.
• Diagrams are reviewed in Phase 6 as part of glossary consistency verification.

---

Phase 5: Infrastructure

Entry criterion: Phase 2 architecture decisions approved. (Can run in parallel with Phase 3.) Exit criterion: Site deploys to GH Pages; CI pipeline runs on PRs; verification scripts execute. Estimated effort: 2-3 days.

Task 5.1: Jekyll + just-the-docs Setup

Description: Already configured. Validate: theme renders, sidebar navigation works, Mermaid diagrams render, search functions. Dependencies: Phase 2 (front matter schema). Effort: 0.5 day. Acceptance criteria: bundle exec jekyll serve renders all pages locally; sidebar shows full chapter hierarchy.

Task 5.2: GitHub Pages Deployment

Description: Already configured via remote_theme. Validate deployment pipeline. Dependencies: 5.1. Effort: 0.5 day. Acceptance criteria: Push to master triggers GH Pages build; site accessible at josterri.github.io/hft-exchange-knowledge.

Task 5.3: CI/CD Pipeline (GitHub Actions)

Description: Create .github/workflows/verify.yml with PR checks and merge checks. Dependencies: 5.1, 5.2. Effort: 1 day.

PR-level checks (fast, <2 min):

Check	Tool	Blocking?
Markdown lint	markdownlint-cli	Yes
Internal link validation	custom script or markdown-link-check	Yes
Cross-reference integrity	scripts/verification/verify_crossrefs.py	Yes
Glossary consistency	scripts/verification/verify_glossary.py	Yes
Heading anchor stability	custom script	Yes
Front matter schema validation	custom script	Warning

Scheduled checks (daily or weekly):

Check	Tool	Blocking?
External URL reachability	custom script	Warning
Fact registry staleness	scripts/verification/check_staleness.py	Warning
Circular archive freshness	custom script	Warning

Acceptance criteria: PR to master triggers all PR-level checks; merge blocked on check failure; scheduled checks produce reports.

Task 5.4: Pre-Commit Hooks

Description: Install pre-commit hooks for local developer checks. Dependencies: 5.3. Effort: 0.5 day.

Hooks:

• Markdown formatting (trailing whitespace, consistent heading style).
• Heading anchor check (warn if a heading that is a cross-ref target is modified).
• Glossary term usage lint (first use of a glossary term in a chapter should link to glossary).

Acceptance criteria: pre-commit run --all-files passes on clean repo.

Task 5.5: Repository Metadata

Description: Validate LICENSE (CC BY-SA 4.0), README, CONTRIBUTING guide, .gitignore. Dependencies: None. Effort: 0.5 day. Acceptance criteria: All files present and accurate. LICENSE matches CC BY-SA 4.0 text. CONTRIBUTING describes the source policy.

---

Phase 6: QA & Verification

Entry criterion: Content generation complete (all chapters, appendices, diagrams written). Exit criterion: All blocking findings resolved; advisory notes logged; verification pipeline passes clean. Estimated effort: 5-7 days.

Task 6.1: Verification Pipeline Architecture

Description: Design and implement the multi-module verification system. Dependencies: Phase 5 CI/CD in place. Effort: 2 days.

Modules:

Module	Input	Output	Automated?
Link Validator	All .md files	Broken link report	Yes
Cross-Ref Checker	crossrefs_result.json + all .md files	Orphan/broken ref report	Yes
Glossary Consistency	glossary.md + all chapter files	Inconsistency report (divergent definitions, unlinked terms)	Yes
Fact Registry Verifier	fact_registry.yaml + chapter text	Unregistered fact claims, stale facts	Partial (flags for human review)
Circular Freshness	circular list + eurex.com/circulars	New circulars affecting content	Partial (needs HTTP access)
Staleness Detector	source registry + current date	Pages exceeding staleness threshold	Yes
Word Count Auditor	all .md files	Per-chapter word counts vs. targets	Yes

Task 6.2: Fact Registry Population

Description: Populate fact_registry.yaml from Phase 1 source documents. Every cited number (price, latency, session limit, threshold, version) gets a registry entry. Dependencies: Phase 1 source registry, content generation complete. Effort: 1 day.

Schema per fact:

- id: "FACT-001"
  claim: "ETI supports up to 200 sessions per participant"
  value: 200
  unit: "sessions"
  source_id: "SRC-001"  # links to source registry
  source_page: "p. 42"
  verified_date: "2026-04-10"
  verification_status: "verified"  # verified | unverified | stale | disputed
  chapters_used: [4]
  decay_category: "architecture"
  notes: "May change with T7 releases; check circulars"

Acceptance criteria: Every numerical claim in the knowledge base has a corresponding fact registry entry. Zero unverified entries at launch.

Task 6.3: Hostile Review Execution

Description: Execute the five-archetype hostile review process. Dependencies: Content generation complete. Effort: 2-3 days.

Archetype execution plan:

Archetype	Focus Areas	Blocking Criteria
Hallucination Auditor	Every latency figure, price, session limit, protocol spec. Every timestamp code.	Any unsourced numerical claim.
Domain Insider	PS/ME topology accuracy, EOBI complexity, PLP mechanics, gateway terminology.	Technically incorrect statement about T7 internals.
Prompt Engineer	Glossary consistency across chapters, cross-ref integrity, word count compliance.	Glossary contradiction. Broken cross-ref.
Open-Source Maintainer	Dead links, undocumented dependencies, missing CI checks, contributor friction.	Broken link. CI gap for a verifiable check.
Temporal Decay Auditor	Pricing currency, “planned” labels without dates, regulatory horizon accuracy.	Stale pricing without disclaimer. Undated “planned” label.

Acceptance criteria: All blocking findings resolved. Advisory notes cataloged in an issues file for future maintenance.

Task 6.4: Post-Generation Consistency Pass

Description: Normalize terminology, acronym usage, cross-reference format, and front matter schema across all generated content. Dependencies: Content generation complete. Effort: 1 day.

Checks:

• Every glossary term used consistently (exact match with glossary definition).
• Every acronym defined on first use per chapter.
• All cross-references use relative .md paths.
• All front matter follows the schema from Task 2.3.
• No duplicate heading anchors within any page.

Acceptance criteria: Verification pipeline runs clean. Zero warnings on glossary and cross-ref checks.

---

Phase 7: Maintenance

Entry criterion: Site deployed to production. Exit criterion: N/A (continuous).

Task 7.1: Content Decay Monitoring

Description: Implement differential monitoring based on decay category.

Decay Category	Monitoring Frequency	Action on Change
Pricing (fees, rebates)	Quarterly (minimum annually)	Update figures, update fact registry, update source date
URLs	Monthly (automated)	Fix or remove dead links; update source registry
Regulatory (MiFID III, EMIR 3.0)	When announced + semiannually	Update Ch 10; review cross-references to regulatory content
Architecture (T7 platform)	On major T7 release	Review Ch 2, 8; update diagrams if topology changes

Acceptance criteria: Monitoring schedule documented; automated URL checks running; responsible party assigned.

Task 7.2: Pricing Update Workflow

Description: Annual (at minimum) review of all pricing data. Process:

1. Download current price lists from eurex.com and cashmarket sites.
2. Compare against fact registry entries with decay_category: pricing.
3. Update all affected pages (Ch 3, 4, 5, 8, Appendix D).
4. Update fact registry with new values, sources, and verification dates.
5. Update “last verified” date on affected pages.

Acceptance criteria: No pricing fact in the knowledge base is older than 12 months from its source document date.

Task 7.3: Circular and Newsflash Monitoring

Description: Monitor eurex.com/circulars and cashmarket circulars for changes affecting knowledge base content. Keywords to monitor: “session limit”, “throttle”, “fee schedule”, “T7 Release”, “price list”, “matching engine”, “co-location”, “market model”, “tick size”, “risk control”, “circuit breaker”. Process: Monthly review of new circulars. For each relevant circular, assess impact on affected chapters and update accordingly.

Acceptance criteria: Circular monitoring log maintained. No unprocessed relevant circular older than 30 days.

Task 7.4: “Planned” vs. “Launched” Status Tracking

Description: Maintain a tracking file for all items tagged as “planned” or “upcoming” in the knowledge base. Fields: item description, chapter, status (planned/launched/delayed/cancelled), source, date tagged, last checked. Process: Check status monthly. Update chapter text when status changes.

Acceptance criteria: No “planned” item in the knowledge base remains unchecked for more than 60 days.

Task 7.5: Living Document Tracking

Description: For source documents flagged as living_document: true in the source registry, implement periodic re-download and comparison. Process: Quarterly re-download. Compare SHA-256 hash (for PDFs) or text content (for HTML pages). Flag changes for human review.

Acceptance criteria: Living document check log maintained. Changes detected within one quarter.

Task 7.6: Staleness Markers on Pages

Description: Each content page displays a “last verified” date in its front matter or footer. Thresholds:

• Pricing content: stale after 6 months.
• URL-dependent content: stale after 12 months.
• Regulatory content: stale after 12 months.
• Architecture content: stale after 18 months.

When a page exceeds its staleness threshold, the verification pipeline flags it.

Acceptance criteria: Staleness dates present on all pages. Automated staleness check in CI.

---

Risk Register

Derived from the five hostile reviewer archetypes. Each risk maps to the phase that mitigates it.

ID	Risk	Likelihood	Impact	Mitigation	Phase
R01	Fabricated latency figures	High	Critical	Fact registry + mandatory citation for every number; hallucination auditor review	1, 6
R02	Conflated timestamp codes (ETI T1-T7 vs EOBI Tnn)	High	High	Separate subsections in Ch 8; explicit differentiation in writing spec; auditor review	3, 6
R03	LF gateway terminology conflation	Medium	High	Glossary authority protocol; domain insider review	2, 6
R04	ETI session pricing oversimplification	Medium	Medium	Writing spec mandates tier acknowledgment; price list citation required	3, 6
R05	EOBI presented as simple drop-in feed	Medium	High	Writing spec mandates operational complexity coverage	3, 6
R06	PS/ME topology oversimplified	Medium	High	Writing spec requires Xetra vs. Eurex distinction; domain insider review	3, 6
R07	Glossary definition drift	High	Medium	Single-source-of-truth protocol; automated consistency check	2, 5
R08	Broken cross-references on heading rename	High	Medium	CI cross-ref check; stable anchor attributes on critical headings	2, 5
R09	URL rot (20-30% within 18 months)	High	Medium	Monthly automated URL check; source registry with alternatives	5, 7
R10	Pricing data staleness	High	High	Quarterly monitoring; fact registry; staleness markers	1, 7
R11	Stale “planned” labels	High	Medium	Status tracking file; monthly review	7
R12	Regulatory content decay (MiFID III)	Medium	High	Temporal qualifiers; semiannual regulatory review	3, 7
R13	Living document silent updates	Medium	Medium	Quarterly re-download and hash comparison	7
R14	Cross-batch consistency degradation (LLM)	High	Medium	Post-generation consistency pass; glossary enforcement	6
R15	Word count exceeds LLM generation bound	Medium	High	Per-chapter targets summing to <70K; batched generation plan	3
R16	Circular/newsflash changes undetected	Medium	Medium	Monthly circular monitoring; keyword watch list	7
R17	Order type venue-specific differences omitted	Medium	Medium	Writing spec requires venue distinction; domain insider review	3, 6
R18	Diagram-text terminology mismatch	Medium	Low	Diagram-text consistency protocol; glossary label cross-check	4, 6
R19	Mermaid rendering breakage on version update	Low	Medium	Version lock in _config.yml; CI diagram render test	4, 5
R20	Session limit numbers stale (changed via circular)	Medium	High	Fact registry; circular monitoring; temporal qualifiers	1, 7
R21	General vs. DB-specific knowledge boundary unclear	Medium	Medium	Citation boundary rule in glossary protocol	2
R22	PDF re-rendered without content change (false positive)	Low	Low	Supplement hash check with text extraction diff	7
R23	Acronym inconsistency across chapters	Medium	Low	Post-generation consistency pass; automated acronym check	6
R24	Contributor friction (unclear source policy)	Low	Medium	CONTRIBUTING guide documents source policy; PR template	5
R25	Simulation calendar dates embedded and stale	Medium	Low	Writing spec forbids embedding dates; link to live calendar	3
R26	Market maker rebate data decay	High	Medium	Pricing update workflow; staleness marker	7

---

Decision Log Template

ID	Date	Decision	Rationale	Alternatives Considered	Reviewer
D-001
D-002
D-003

---

Success Criteria

The project is complete when ALL of the following are true:

1. Content complete. All 12 chapters, 4 appendices, and 6 diagrams published on GitHub Pages.
2. Source-backed. Every factual claim (numbers, protocol behaviors, pricing, thresholds) traces to a document on an approved domain, recorded in the fact registry.
3. Cross-references intact. Zero broken internal links. Verified by CI pipeline on every merge.
4. Glossary consistent. Every glossary term used identically across all chapters. Verified by automated consistency check.
5. Verification pipeline operational. All PR-level checks run automatically. Scheduled checks produce reports.
6. Hostile review clean. All blocking findings from 5-archetype review resolved. Advisory notes logged.
7. Temporal markers present. Every time-sensitive fact carries a source date. Every page has a “last verified” date.
8. Staleness monitoring active. Automated URL checking, circular monitoring, and pricing review workflows are documented and scheduled.
9. Maintenance plan documented. Decay categories, monitoring frequencies, and responsible parties defined.
10. No fabricated content. Zero numerical claims without document citations. Hallucination auditor found no unsourced claims.