Chapter 2: T7 Trading System Architecture
Introduction
The T7 trading system represents the technological foundation of Deutsche Börse’s cash and derivatives markets, powering Xetra for equities and Eurex for derivatives trading. Since its introduction, T7 has evolved into a globally deployed platform, supporting not only Deutsche Börse’s own trading venues but also exchanges across Europe and North America. This chapter examines the architectural components, processing model, session types, failover mechanisms, and capacity specifications that define T7 as one of the world’s most advanced exchange platforms.
Understanding T7’s architecture is essential for high-frequency trading participants seeking to optimize latency, manage failover scenarios, and design robust trading strategies. The system’s partition-based design, deterministic processing model, and sophisticated risk controls create a trading environment that balances ultra-low latency with stability and fairness.
T7 Platform Overview
Global Deployment and Multi-Asset Support
T7 functions as a unified trading platform serving both cash equities and derivatives markets. Within Deutsche Börse Group, T7 powers Xetra for cash equities trading and Eurex for derivatives trading. The platform also serves the European Energy Exchange (EEX) for commodity and energy markets, as well as Nodal Exchange in North America for power and environmental commodities. (Source: Deutsche Börse T7 Technology)
Beyond Deutsche Börse’s own operations, T7 has achieved significant market penetration across Central and Eastern Europe. The platform powers exchanges in Budapest (Budapest Stock Exchange), Ljubljana (Ljubljana Stock Exchange), Malta (Malta Stock Exchange), Prague (Prague Stock Exchange), Sofia (Bulgarian Stock Exchange), Vienna (Vienna Stock Exchange), and Zagreb (Zagreb Stock Exchange). This international deployment demonstrates T7’s scalability, reliability, and flexibility as an enterprise-grade exchange platform capable of supporting diverse regulatory environments and market structures. (Source: Xetra Technology)
Current Release Status
As of February 2026, T7 operates on Release 14.0, which launched on November 10, 2025. This release introduced Extended Retail Trading functionality, Self-Match Prevention (SMP) enhancements for improved trade risk management, and the T7 Clearer Web GUI for simplified clearing participant operations. Release 14.0 continues T7’s evolution toward supporting diverse participant types while maintaining the ultra-low latency performance demanded by institutional and high-frequency trading firms. (Source: Eurex T7 Release 14.0)
The next planned major release, T7 Release 14.1, is scheduled for May 18, 2026. Release planning at Deutsche Börse typically follows a structured roadmap with approximately six-month intervals between major releases, allowing participants sufficient time for testing, certification, and deployment of updated client systems. (Source: T7 Release Schedule)
Core Components
T7’s architecture comprises several interconnected components, each responsible for specific aspects of order processing, market data distribution, risk management, and session management. The following sections detail each core component.
Matching Engine
The Matching Engine represents the heart of T7, responsible for receiving all incoming orders, managing order state, executing matches, and generating execution reports. The Matching Engine maintains all active order state in non-persistent memory, enabling microsecond-level processing speeds. This in-memory architecture eliminates disk I/O bottlenecks during normal trading operations, allowing the engine to process orders with minimal latency. (Source: T7 Trading Architecture)
In the first half of 2021, Eurex implemented a significant architectural optimization by consolidating the Matching Engine and Partition-Specific (PS) Gateway processes onto the same physical server. This co-location eliminated inter-server network hops for orders entering through PS gateways, reducing latency by several microseconds and improving determinism. This optimization specifically benefits high-frequency participants using PS gateway connections, as it creates the shortest possible path from network interface to matching logic. (Source: Eurex Technology Updates)
The Matching Engine operates without batching mechanisms for standard order processing. Unlike some exchanges that accumulate orders over brief intervals before processing them together, T7 processes each order deterministically in the sequence it arrives. This design ensures that participants receive consistent, predictable behavior: earlier orders are processed before later orders without artificial delays. The absence of batching supports fairness principles while maintaining the deterministic execution required for algorithmic trading strategies. (Source: T7 Trading Architecture)
Gateway Layer
T7’s gateway layer provides connectivity between market participants and the matching engines. The architecture has evolved to offer multiple gateway types, each optimized for different participant needs, latency requirements, and access patterns.
Partition-Specific (PS) Gateways
Partition-Specific Gateways, introduced in Q1 2018, provide the lowest-latency access path to T7. Each PS gateway maintains a one-to-one mapping to a specific partition, creating a dedicated, optimized entry point for that partition’s products. High-frequency participants establish connections to PS gateways when trading activity concentrates on instruments within a single partition, as this configuration eliminates routing overhead and provides the fastest possible order execution path. (Source: Eurex T7 Enhanced Trading Interface)
The consolidation of PS gateways with matching engines on the same server (implemented in H1 2021) further optimized this path, reducing network traversal and improving latency predictability. For participants requiring ultra-low latency, PS gateways represent the primary connectivity option. (Source: Eurex Technology Updates)
Low-Frequency (LF) Gateways
Low-Frequency Gateways provide access to all partitions through a single session, offering operational simplicity for participants trading across multiple partitions or those with lower message rate requirements. Historically, LF gateways introduced approximately 75 microseconds of additional latency compared to PS gateways due to routing logic and cross-partition coordination overhead. (Source: T7 Gateway Architecture)
In recent releases, Deutsche Börse has significantly improved LF gateway performance. As of January 2025, the base latency difference between LF and PS gateways has been reduced to approximately 12 microseconds for same-side requests. For cross-side requests (operations requiring coordination across partitions), latency has decreased dramatically from approximately 45 microseconds to approximately 1 microsecond, making LF gateways increasingly viable for participants requiring multi-partition access without the complexity of managing multiple PS gateway connections. (Source: Eurex T7 Performance Updates)
FIX Gateways
Since March 2021, T7 has supported FIX (Financial Information eXchange) protocol connectivity. FIX gateways translate FIX protocol messages into T7’s native Enhanced Trading Interface (ETI) format, enabling participants to connect using industry-standard FIX implementations rather than developing ETI-specific adapters. (Source: T7 FIX Gateway)
Importantly, FIX gateways route orders directly to the target partition via the corresponding PS gateway, ensuring that FIX connectivity does not introduce significant additional latency compared to native ETI connections. This architecture allows participants to choose connectivity protocols based on their development infrastructure and trading requirements without sacrificing performance. FIX gateways are particularly popular among buy-side participants and those with existing FIX-based trading systems. (Source: T7 FIX Gateway Architecture)
Market Data Engine
The Market Data Engine generates all public market data feeds distributed by T7, including EOBI (Enhanced Order Book Interface), EMDI (Enhanced Market Data Interface), MDI (Market Data Interface), and RDI (Reference Data Interface). The engine produces these feeds in real-time as market events occur, ensuring that market participants receive timely information about order book changes, trades, and instrument status. (Source: T7 Market Data)
T7 adheres to a “public data first” principle: market data is published before order response messages (execution reports, acknowledgments) are sent to the participant who originated the order. This design ensures that all participants, regardless of their connectivity or co-location status, observe the same market state simultaneously. By publishing market data before private responses, T7 prevents information asymmetries where order originators would learn of executions before the broader market sees the resulting price changes. This principle supports market fairness and transparency. (Source: T7 Market Data Distribution)
In recent releases, EMDI has been integrated directly into the Matching Engine process, eliminating a separate process boundary and reducing the latency between match execution and market data publication. This integration ensures that EMDI subscribers receive the lowest-latency market data feed available, with market data published in tens of microseconds after match events. (Source: Eurex EMDI Integration)
Persistence Layer
T7 distinguishes between persistent and non-persistent orders. The persistence layer manages the storage and recovery of persistent orders, which remain active across certain system events such as failovers or Market Resets.
Non-Persistent Orders: By default, most orders are non-persistent, existing only in the Matching Engine’s in-memory state. If a Market Reset occurs (triggered by a failover or manual restart), all non-persistent orders are deleted. Participants receive deletion notifications and must re-enter orders if desired. Non-persistent orders offer the advantage of slightly faster processing since they do not require persistence overhead. (Source: T7 Trading Architecture)
Persistent Orders: Orders marked with Good-Till-Cancelled (GTC) or Good-Till-Date (GTD) time-in-force instructions are written to the persistence layer. These orders survive failovers and Market Resets, remaining active until they are filled, cancelled, or expire. Persistent orders introduce minimal latency overhead in modern T7 releases due to optimized persistence mechanisms, making them suitable for longer-term limit orders where participants desire automatic recovery after system events. (Source: T7 Order Persistence)
The persistence layer’s role becomes particularly important during failover scenarios, where persistent orders automatically migrate to the backup matching engine, preserving order book state and reducing the need for participants to rapidly re-enter orders during recovery periods.
Risk Engine
T7 incorporates a sophisticated Risk Engine that performs pre-trade risk checks on all incoming orders and quotes. These checks occur before orders reach the Matching Engine, preventing orders that violate risk parameters from entering the order book. The Risk Engine evaluates multiple dimensions of risk:
Maximum Order Value Checks: T7 enforces limits on the maximum notional value of individual orders, preventing erroneous or “fat finger” orders that could cause market disruption. Participants configure maximum order value limits based on their risk appetite and business requirements. (Source: T7 Risk Controls)
Advanced Risk Protection (ARP): ARP provides configurable risk limits including maximum order quantity, maximum order notional value, price collars (preventing orders outside defined price ranges), and trading volume limits over specified time windows. ARP operates at the participant level, allowing firms to implement their own risk thresholds within T7’s infrastructure. (Source: Eurex Advanced Risk Protection)
Post-Trade Risk (PTR) Limits: Introduced in T7 Release 13.1, PTR limits monitor cumulative exposure resulting from executed trades. Unlike pre-trade limits that evaluate individual orders, PTR limits assess the aggregated risk position and can halt further trading if exposure exceeds configured thresholds. This functionality supports participants in managing their overall market exposure dynamically throughout the trading day. (Source: Eurex T7 Release 13.1)
The Risk Engine operates with extremely low latency, adding only microseconds to order processing time while providing comprehensive risk management functionality. This balance between risk control and performance represents a critical design goal for T7, ensuring that safety mechanisms do not compromise competitive execution speeds.
Partition Model
T7’s partition model represents a fundamental architectural design choice that influences scalability, fault isolation, and participant connectivity strategies.
Partitions as Failure Domains
A partition functions as an independent failure domain responsible for matching, persisting, and generating market data for a subset of products. Each partition operates with its own Matching Engine instance, gateway processes, and market data distribution. This isolation ensures that a failover or technical issue on one partition does not impact other partitions, maintaining availability for unaffected products. (Source: T7 Trading Architecture)
Product Assignment Hierarchy
Products are organized into a three-level hierarchy:
- Product Assignment Groups: High-level groupings that define which products belong to which partition.
- Products: Categories of tradable instruments (e.g., equity derivatives, fixed income derivatives).
- Instruments: Specific tradable contracts or securities (e.g., FDAX December 2026 futures contract).
This hierarchy allows Deutsche Börse to efficiently manage product distribution across partitions and to reassign instruments as trading volumes or operational requirements evolve. (Source: T7 Partition Model)
Production and Simulation Partition Expansion
In production environments, T7 originally operated with 10 partitions. In February 2022, Deutsche Börse expanded the production environment to 11 partitions to accommodate growing product listings and trading volumes. Similarly, simulation environments expanded from 5 to 6 partitions in February 2024, providing additional capacity for participant testing and certification activities. (Source: Eurex T7 Environment Updates)
Dynamic Product Distribution
Instruments are regularly redistributed between partitions to balance load and optimize performance. Deutsche Börse analyzes trading volumes, message rates, and system resource utilization to determine optimal product assignment. When redistribution occurs, participants receive advance notification, allowing them to update their connectivity configurations if they use partition-specific sessions. This dynamic rebalancing ensures that no single partition becomes a bottleneck as market activity patterns evolve. (Source: T7 Partition Management)
High-Frequency Session Implications
High-frequency trading participants using partition-specific connections must specify the partition ID when establishing sessions. This requirement means that participants trading products across multiple partitions either establish multiple connections (one per partition) or use a Low-Frequency gateway session that spans all partitions. The choice depends on the participant’s trading strategy, latency requirements, and operational complexity preferences. (Source: Eurex T7 Enhanced Trading Interface)
Processing Model
T7’s processing model defines how orders move through the system from submission to execution, ensuring fairness, determinism, and predictability.
FIFO Order Processing
T7 processes orders strictly in first-in-first-out (FIFO) sequence. When multiple orders arrive at the same price level, the earliest order receives priority for matching. This FIFO principle applies consistently across all order types and market phases, providing participants with predictable execution behavior. (Source: T7 Trading Architecture)
No Batching at Matching Engine
As noted earlier, T7 does not batch orders at the matching engine level during normal trading operations. Each order is processed individually in the sequence it arrives. This design contrasts with some exchanges that use batching or periodic auctions to aggregate orders over brief intervals. By avoiding batching, T7 ensures that participants can react to market events without waiting for batch intervals to complete, supporting high-frequency trading strategies that depend on rapid order responses. (Source: T7 Matching Engine)
Deterministic Processing
Deterministic processing means that given identical input sequences, T7 will produce identical output sequences. This characteristic is essential for testing, simulation, and algorithmic strategy development. Participants can test strategies in simulation environments with confidence that the same order sequences will produce the same matching results in production. Deterministic processing also simplifies troubleshooting and post-trade analysis, as order interactions can be precisely replayed and analyzed. (Source: T7 Trading Architecture)
CoLo 2.0 Infrastructure
The introduction of CoLo 2.0 (Colocation 2.0) enhanced T7’s determinism and fairness. CoLo 2.0 provides highly deterministic network access, ensuring equal network latency for all co-located participants. Each partition has one designated low-latency entry point via a PS gateway, and all co-located participants access that gateway through infrastructure designed to minimize latency variance. This “level playing field” approach ensures that latency advantages derive from algorithmic sophistication and execution efficiency rather than from preferential network paths. (Source: Deutsche Börse CoLo 2.0)
CoLo 2.0 participants connect via 10 Gigabit Ethernet (10GbE) links, providing ample bandwidth for high message rates while maintaining deterministic behavior.
Public Data First Principle
The “public data first” principle ensures that market data reflecting order book changes and executions is published to all market data subscribers before execution reports are sent to the originating participant. This sequencing prevents situations where an order originator learns of their execution before the rest of the market sees the price change, maintaining informational equality. This principle is enforced at the architectural level, with market data publication occurring before execution report generation in the processing pipeline. (Source: T7 Market Data Distribution)
Session Types
T7 supports multiple session types, each optimized for different participant profiles, trading patterns, and latency requirements.
High Frequency (HF) Sessions
High-frequency sessions provide partition-specific, ultra-low latency connectivity via PS gateways. HF sessions are designed for professional trading firms, market makers, and high-frequency trading operations requiring microsecond-level execution speeds. (Source: Eurex T7 Enhanced Trading Interface)
T7 offers two tiers of high-frequency sessions:
Light Sessions
- Maximum throughput: 50 transactions per second (TPS)
- Monthly fee: EUR 250 per session
- Suitable for: Strategies with moderate message rates, smaller high-frequency operations, or participants testing HF infrastructure before scaling to full sessions. (Source: Eurex Pricing Information)
Full Sessions
- Maximum throughput: 150 transactions per second (TPS)
- Monthly fee: EUR 500 per session
- Suitable for: Market makers, active high-frequency trading strategies, and participants generating high message volumes. (Source: Eurex Pricing Information)
HF sessions require connection through co-located infrastructure using 10GbE network links. Participants must specify the target partition when establishing HF sessions, as these sessions are partition-specific.
Low Frequency (LF) Sessions
Low-frequency sessions provide access to all partitions via a single session connection, simplifying connectivity management for participants trading across multiple product groups. LF sessions historically introduced additional latency compared to HF sessions, but recent performance improvements (reducing latency differences to approximately 12 microseconds for same-side requests) have made LF sessions more attractive for broader participant types. (Source: Eurex T7 Performance Updates)
LF sessions are suitable for:
- Buy-side participants with lower message rate requirements
- Participants trading across multiple partitions who prefer operational simplicity over lowest-possible latency
- Back-office and risk management systems requiring multi-partition visibility
Back Office Sessions
Back Office sessions provide administrative and operational functions, including account management, trade reporting, drop copy services, and risk configuration. These sessions do not participate in order entry or trading activities but support operational workflows for clearing members, brokers, and exchange participants. (Source: T7 Session Types)
Failover and Redundancy
T7’s redundancy architecture ensures high availability and rapid recovery from technical failures, maintaining market operations even during system disruptions.
Geographic Redundancy
T7 operates with active-backup redundancy across two geographically separated rooms (Room A and Room B). Under normal conditions, the active matching engine operates in Room A, while a synchronized backup runs in Room B. This geographic separation ensures that localized failures (power outages, cooling failures, network issues confined to one room) do not cause complete system outages. (Source: T7 Trading Architecture)
Side A and Side B Redundancy
Within each room, T7 maintains Side A and Side B redundancy, with independent network paths, power supplies, and processing resources. This dual-redundancy model (geographic and side-based) creates multiple failure domains, minimizing single points of failure. (Source: T7 Redundancy Architecture)
Redundancy Link
A redundancy link connects Room A and Room B, enabling state synchronization between active and backup systems. Under normal conditions, this link carries state replication traffic without introducing latency to trading operations. If the primary network path between rooms fails, the redundancy link can serve as an emergency backup, though this configuration introduces additional latency and is intended only for exceptional circumstances. (Source: T7 Failover Mechanisms)
ServiceAvailabilityBroadcast
When a matching engine becomes unavailable (due to failover initiation, maintenance, or technical issues), T7 transmits a ServiceAvailabilityBroadcast message to all connected participants. This message indicates that the matching engine is not accepting orders and provides status information. Participants should monitor ServiceAvailabilityBroadcast messages to detect system disruptions and adjust their trading behavior accordingly. (Source: T7 Session Management)
Market Reset Process
A Market Reset occurs when the matching engine restarts, either due to a planned maintenance event or a failover. The Market Reset process follows a defined sequence:
-
TradingSessionEvent “102 = Market Reset”: Signals the start of the Market Reset process. All non-persistent orders are deleted.
-
ExtendedOrderInformation Messages: For each persistent order (GTC or GTD), the system transmits an ExtendedOrderInformation message to the order owner, restating the order’s current status. This allows participants to reconcile their internal order state with the exchange’s persistent order state.
-
TradingSessionEvent “103 = End of Restatement”: Signals the completion of the Market Reset. Trading can resume, and participants can begin submitting new orders.
Participants must implement logic to handle Market Reset sequences, particularly to manage non-persistent orders that are deleted during the reset. High-frequency participants typically implement rapid order resubmission logic to minimize downtime after Market Reset completion. (Source: T7 Market Reset Protocol)
FIX Session Failover
T7 does not provide automatic FIX session failover. If a FIX gateway or matching engine fails, participants must detect the disconnection and establish a new FIX session to the backup system. This design places responsibility for failover logic on participants, allowing them to implement custom failover strategies aligned with their risk management and operational procedures. (Source: T7 FIX Gateway)
Participants should implement FIX logon retry logic, monitor ServiceAvailabilityBroadcast messages, and maintain connectivity to both Side A and Side B infrastructure to enable rapid failover when necessary.
Capacity Specifications
T7’s capacity specifications demonstrate its ability to handle extreme trading volumes and message rates while maintaining ultra-low latency.
Daily Transaction Capacity
T7 supports over 320 million transactions per day across all connected trading venues. This capacity encompasses order submissions, modifications, cancellations, executions, and market data events. The system’s ability to sustain this volume ensures that even during peak trading periods (such as macroeconomic announcements, market openings, or expiry days), participants experience consistent performance. (Source: T7 Capacity Specifications)
Peak Message Rate
In June 2024, T7 achieved a peak input rate of 201,000 messages per second across the entire system. Within this aggregate rate, Eurex derivatives markets contributed 118,000 messages per second, while Xetra cash markets contributed 92,000 messages per second. These figures represent real-world peak loads during high-volatility trading conditions, demonstrating T7’s capacity headroom and resilience under stress. (Source: Deutsche Börse Market Statistics)
Order Request/Response Latency
The median latency from order request to order response (acknowledgment or execution report) measures less than 55 microseconds. This figure represents the round-trip time from when an order enters a PS gateway until the matching engine’s response returns to the participant. This sub-60-microsecond performance positions T7 among the lowest-latency exchange platforms globally. (Source: T7 Latency Specifications)
Order to Market Data Latency
The latency from order execution to market data publication measures less than 40 microseconds. This metric captures the time between when a match occurs in the Matching Engine and when the resulting market data message is published on EMDI or EOBI. The sub-40-microsecond market data latency ensures that participants receiving market data feeds observe executions with minimal delay, supporting algorithmic strategies that rely on rapid market data processing. (Source: T7 Market Data Latency)
Minimum Reaction Time
T7’s minimum reaction time—the fastest observed interval between receiving an order and publishing the resulting market data—stands at 2,787 nanoseconds (approximately 2.8 microseconds). This figure represents the theoretical minimum latency achievable under optimal conditions and demonstrates the system’s core processing efficiency. While typical latencies include network transmission, queueing, and other real-world factors, the minimum reaction time illustrates T7’s capability at the hardware and software processing level. (Source: T7 Performance Metrics)
T7 Release History
T7 has evolved through a series of major releases, each introducing new functionality, performance improvements, and market structure enhancements. The following table summarizes key releases and their primary features:
| Release | Launch Date | Key Features |
|---|---|---|
| 10.0 | March 2021 | FIX Low-Frequency sessions introduced, enabling FIX protocol connectivity alongside native ETI |
| 11.0 | November 2021 | EOBI enhancements for improved market data granularity; Intraday Auction Matching (HHI - Handelsunterbrechung Handelsphase Intraday) introduced |
| 11.1 | May 2022 | Buy-Side Disclosure functionality allowing buy-side identification in market data for improved transparency |
| 12.0 | November 2022 | Enhanced order value checks; Advanced Risk Protection (ARP) enhancements for more granular pre-trade risk controls |
| 12.1 | May 2023 | Retail Liquidity Provider (RLP) designation, supporting liquidity provision for retail order flow |
| 13.0 | November 2024 | Basket TRF roll (Total Return Futures) functionality; Enhanced Drop Copy services with extended filtering and routing options |
| 13.1 | May 2025 | Delta-neutral TRF products; Post-Trade Risk (PTR) limits for cumulative exposure monitoring |
| 14.0 | November 2025 | Extended Retail Trading functionality; Self-Match Prevention (SMP) enhancements; T7 Clearer Web GUI for simplified clearing operations |
| 14.1 | May 2026 (planned) | Features to be announced; expected to include continued performance optimizations and functionality extensions |
(Source: Eurex T7 Release Notes)
This release cadence demonstrates Deutsche Börse’s commitment to continuous improvement, introducing significant functionality approximately every six months while maintaining backward compatibility and stability for existing participants.
Conclusion
The T7 trading system architecture embodies the balance between ultra-low latency, high availability, scalability, and fairness required by modern electronic markets. Its partition-based design isolates failure domains while enabling horizontal scaling. The multi-tiered gateway layer provides connectivity options for diverse participant types, from high-frequency market makers requiring sub-microsecond latency advantages to buy-side firms prioritizing operational simplicity through multi-partition low-frequency sessions.
T7’s processing model—characterized by FIFO order handling, deterministic matching, and the “public data first” principle—ensures predictable behavior and informational equality. The redundancy architecture, spanning geographically separated rooms and dual-sided infrastructure, delivers high availability even during hardware failures or maintenance events.
For high-frequency trading participants, understanding T7’s architecture informs critical decisions: choosing between partition-specific and low-frequency sessions, designing failover and Market Reset handling logic, optimizing for sub-60-microsecond order latencies, and leveraging co-location infrastructure for deterministic network access. The following chapters will build on this architectural foundation, exploring network infrastructure, trading interfaces, market data protocols, and optimization strategies for T7-connected trading systems.