Service Navigation

Matching principles

Matching principles

For the matching process, T7 treats orders and quotes identically. Therefore, in the following, the term “order” is generally applied to both orders and quotes.

Matching is the procedure of finding pairs or groups of orders that are executed against each other. In its simplest form, there is one buy order and one sell order that are both executed at the same execution price and with the same quantity. However in general, several orders on the buy side can be executed against several orders on the sell side. The execution price is the same for all involved orders and the accumulated executed quantity on the buy side must equal the accumulated executed quantity on the sell side. T7 informs the owners of the orders with an execution confirmation, and then creates a trade and forwards this trade to the clearing system.

The matching of orders that all belong to the same instrument is called Direct Matching. In Synthetic Matching, orders of different simple and complex instruments are executed against each other. T7 supports synthetic matching for futures spreads and for inter-product spreads. For further information on synthetic matching we refer to the Eurex Functional Reference Guide, Chapter 11.3.

The matching procedure makes a difference between incoming orders and book orders. Strictly speaking, an incoming order is an order that is in the process of being entered, and a book order is an order that is in the order book already. 

In the context of matching however, book orders are sometimes treated as incoming orders. These cases are 

  • Orders that are being modified such that the price is improved,
  • Quotes that are reactivated,
  • Market orders that are triggered,
  • Stop orders and OCO orders that are triggered,
  • Futures spread orders and inter-product spread orders that are fed into the market after an uncrossing.

In the following therefore, the term “incoming order” is applied not only to actual incoming orders, but extended also to book orders given in the above list.

An order will match fully if its entire open quantity is executed. Since there is nothing left to match, a fully matched book order is removed from the order book, and a fully matched order that is in the process of being entered, is not written to the book.

Or an order matches partially, if not all its open quantity is executed. In this case an order that was already on the order book remains on the order book, and an order that is in the process of being entered and is not an IOC order, is written to the order book. The quantity that was executed is removed from the open quantity and added to the accumulated executed quantity.

It is possible for a single order to get involved in multiple executions at different points in time. For example, an order may be partially executed upon entry, while the remaining open order remains in the order book. The open portion may then be executed a minute later, an hour later, or even days later.

When orders and quotes are entered into the central order book, they are sorted by type, price and depending on the order allocation method entry time and/or size. Market orders are always given the highest priority for matching purposes. Limit orders and quotes are sorted together; there is no special consideration given to Market Maker quotes.

Orders and quotes in the central order book are anonymous: A trader never knows the opposite side on a trade executed through the exchange. Eurex Clearing AG is always the counterparty. Participants only see the specific details of their own orders.


Price/time priority

The time allocation method first sorts the eligible orders by their priority time stamp, orders with an older priority time stamp coming first. 

It then determines the allocation for one eligible order after the other in the sequence that they have just been sorted. 

Each order receives an allocated quantity that is equal to its open quantity, provided that the quantity left to be allocated after the previous orders in the list got their share, is sufficient. If that quantity is not sufficient, then the order is allocated whatever remaining quantity was left to be allocated. 

In this way, it is possible that orders, which are last in the list, receive nothing.

Note that the term “Time Allocation” is a synonym of the term “Price-Time Allocation”. The term “Time Allocation” is applied here, because price priority is something that is a common feature of all matching procedures in T7, independent of the order allocation method. What distinguishes the time allocation method from other order allocation methods is the priority time being the only criteria for the allocation among orders of the same price level.

Pro-rata matching

Pro-rata allocation
The allocated quantity of the incoming order is shared amongst all book orders at the best price. The allocation is proportional to the size of each book order. All book orders at the best price are considered in the allocation. The allocation method first sorts the eligible orders by their open quantity, orders with larger open quantity coming first. If there are orders with the same open quantity, these are then sorted between them by their time priority, orders with an older time priority stamp preceding those with a newer priority time stamp.

Time-pro-rata allocation
The price best orders are sequenced by their time priority. Orders with a higher time priority receive a higher matched quantity compared to the pro-rata allocation at the expense of orders with a lower time priority. Compared to the time allocation, orders with a high time priority receive a lower matched quantity. Depending on the specific order book situation, it may be possible that not all price best orders are considered for execution and, consequently, the number of orders considered by the time-pro-rata allocation is smaller compared to the pro-rata allocation.

Auction principle

All orders that are executed in a specific uncrossing procedure, are executed at the same execution price, irrespective of their limit price. This execution price is the auction price of the specific uncrossing procedure.

T7 determines the auction price so that the following two main objectives are reached:

  • Uncrossing: After the auction trade, there will be no two orders left in the order book that are executable against each other. As a consequence, the best sell price that is available after the execution of the auction trade is always higher than the corresponding best buy price. Market orders are considered as being executable against any limit order.
  • Price continuity: The auction trade price will not be lower than the best buy price that is available after the execution of the auction trade, and it will not be higher than the best sell price that is available after the execution of the auction trade.

As a by-product of fulfilling these two objectives, the principle of maximizing executions is fulfilled as well, i.e. the auction price is a price for which the executed volume is maximized.

There are situations where no auction price can be determined and therefore no auction trade is done:

  • The order book is not crossed; there are no two orders that can be matched against each other.
  • There are only market orders on both sides of the order book. In this case there is no limit price that could serve as a reference for the determination of the auction price. Therefore, no auction trade is done, and the uncrossing condition mentioned above is considered as fulfilled anyway.

Self-match prevention

Self-match prevention is an optional functionality which allows a business unit to prevent that certain own orders of the same instrument match against each other. Self-match prevention is supported during continuous trading, but not in any matches in an auction or order book uncrossing. Self-match prevention is not supported for synthetic matching, i.e. it does not prevent matches between orders of different instruments.

When an incoming order (in the extended sense as defined in chapter 7.1 of the Eurex Functional Reference Guide) and a book order would match against each other, T7 checks whether they are owned by the same business unit and whether they carry the same user supplied cross ID. If that is the case, the match between the two orders is prevented and the quantity which would have matched is removed from the order quantity, for both the incoming order and the book order. For a book order that would have partially matched, the total order quantity is reduced by the quantity that would have matched, and the remainder remains on the book. A book order that would have fully matched is deleted.

For the incoming order, if there is still a remaining open quantity left after its quantity is reduced by the prevented match quantity, then this remainder of the incoming order is allowed to match further but only on the same price level. It is also possible that further matches on that price level are again prevented due to self-match prevention. After matching completed on that price level, any remaining open quantity left for the incoming order is cancelled, effectively preventing the incoming order to match on further price levels.

Cross & pre-arranged trades

A cross trade is a trade where a member trades against an own order in the order book. In a pre-arranged trade, orders from at least two members are executed against each other as previously negotiated. Cross and pre-arranged trades may not knowingly be entered into the T7 system by a member, unless the member precedes the cross or pre-arranged trade with a cross request. A market member is required to enter a cross request to inform the market of his intention to execute a cross or pre-arranged trade. As soon as a cross request is entered into the T7 system, all market participants have the opportunity to enter corresponding orders (or quotes, depending on the product and the status of the market participant).

After entering a cross request, the initiating market member must enter the matching orders (or quotes, depending on the product and the status of the market member). Orders must be entered within a certain time frame: there is a minimum amount of time the market member has to wait before entering matching orders/quotes, and there is also a maximum amount of time the market member can wait before the cross request expires. Both of these time periods are specified by the exchange.

The exchange may also stipulate at any time a maximum size for a cross trade. Cross requests are possible for both options and futures; combination cross requests can only be entered for futures. For option combinations, cross requests must be entered in the respective legs. Cross requests for strategies are supported.


A mistrade is a trade which deviates considerably from the market price, defined as the reference price. The procedures for determining the reference price for each product can be found in paragraph 2.8 in the Conditions for trading at Eurex Deutschland and Eurex Zurich.

For futures and options, product-specific ranges are defined by the exchange. Mistrade parameters will be published periodically by circular.

In the event of a mistrade, a trader should immediately contact the trading helpdesk (Eurex Market Supervision) and identify the mistrade.

Any objection to the contents of a transaction confirmation must be delivered to Eurex Market Supervision, in writing by fax or by email or by phone , not later than 30 minutes after the trade.

The final determination of a mistrade is made by the Boards of Management of Eurex.


Related topics


Market Status




Trading System experiencing issues

Trading System experiencing serious issues

Production newsboard

The Market Status Indicator displays the current technical availability of the trading system.

It indicates whether Production Newsboard messages regarding current technical issues of the trading system have been published or will be published shortly.

We strongly recommend not to take any decisions based on the Market Status Indicator. Please, always check the Production Newsboard for comprehensive information.

An instant update of the Market Status requires an enabled up-to date Java™ version within the browser.