C7 Releases

The original trade type will be reported, as opposed to what occurs now with the classical average price, where we override with trade type 51. With Value Based Average Price the original trade type will remain for on-exchange and EnLight trades and will also remain for TES trade if only one TES type is included. In the case of multiple TES trades, then a new dedicated trade type will be used. 

Likewise, in the case of fee calculation, the right differentiation will be made based on quantities in case of mixing different trade types. 

Yes, the functionality will also be fully supported in FIXML.

Cash residual is the difference between the mathematical average price of the group and the price which is used for the average price allocation. It will be attached on transaction level and will be shown in report CB716 average pricing report.

It will not, as C7 will send back the original number of contracts per each trade type to the allocated trades and that should match exactly what has gone into the group. It will be ensured that the quantity of original trades at a certain fee-level (trade type + trade publish information) equals the quantity of the resulting average prices at this fee level either with a pro-rata allocation, or via validations (requested allocation quantity checked versus the remaining quantity in the group).

Yes, for the time being, at least for the next couple of months. We will then monitor the usage of both functionalities. 

If this is referring to split during the allocation the answer is no, a Clearing Member will have to allocate to each position account separately and individual average price transactions. 

Files are already available in C7 Release 9.1 > system documentation > reports> Eurex Clearing XML Reports – XML Schema Files v.9.1 (C7 Release 9.1). CB002 test sample available upon request.

• Easier operational handling > average pricing can be prepared by grouping during the day and is simply completed once the last trades are executed. 
• More flexible, since prices deviating from the calculated average price can be used and different trade types can be complied with. 

Members can either request a certain fee level when submitting the allocation or use the system pro rata allocation mechanism by not defining a certain fee level with the allocation. 

Obviously, the average price must be within the high-low price range of the original transactions. The total group value cannot be exceeded. System checks are in place to ensure that the price used for the current allocation allows that the price for the next allocation still can be within the high-low range. 

• End client might not be able to handle the full 7 decimal places. 
• Two large orders of the same client comingled into one large group will lead to a more efficient allocation as no longer need to create two average prices for the two orders. 

Auto VBAP (Value Based Average Pricing) transaction will be created at system calculated average price. The transaction can be further processed on t+1. 

Allocations/groups can be cancelled, re-opened, and adjusted. 

No, only trades for the same trade date can be average priced. 

Yes up until t+5. 

No special restrictions other than the usual GUI restriction of 5000 records applies. 

Offset-transactions (at average price) are booked to balance the original transactions. The “residual” arises as a Variation Margin/Premium deviation between the original and the offset-transactions (based on the price difference between the Initial Mathematical Average Price und the booked average price). 

Yes, with the required entitlement setting (give-ups must be enabled in C7). 

Not by default. The user needs to activate with the correct entitlement settings. C7 privileges D010ADD, D010MAI and D011ADD must be increased to level 3. 

No, there is a one-to-one relationship between request and allocation. In the case of mixing different trade types, one request might return multiple allocations if the pro rata mechanism is used. 

Residuals are shown in FIXML, GUI and reports. They will remain with and will be handled by the average price transaction initiating member.  

Eurex transactions fees are calculated at the end of each business day outside of the main trading (T7) and clearing (C7) system. Therefore it is not possible to publish real-time fee information with the Trade Capture Report.

Optional for the time being. It would become required though if a CM decides to go for the buy side disclosure. And it will become mandatory for everyone when Eurex decommissions the current billing infrastructure (along with report CB001) in the future, ETA second half of 2024 (probably with C7 Release 11.0 in Nov 2024).

Despite the fact that this functionality is optional for the time being, we encourage Clearing Members who don't want to use it for now to check their FIXML implementation and ensure that the new Fee Code can be ignored by their systems.

No, there will be no differentiation in fees.

For the time being just Eurex, no plans to extend to ECC.

The reports are available in simulation, including billing report CB165.

Yes, the correct value will be sent also for historical transactions after 5 June 2023 when the new fee report CB002 kicks in.

With C7 Release 9.1 CB002 will be provided in the usual report format.  There are currently no plans to publish CB002 via API. RestAPI will not be supported by Eurex, instead any API development will be based on GraphQL API.

The entity that we expect to register is the one who does the trading and is operationally involved with trading and dealing activities and that speaks directly with the execution broker. Only investment manager level needs registering, not the individual funds underneath. 

No. The end client is invited to register themselves via Member section. A registration functionality will be available by the end of 2023. During registration, you will have to select one or more participating Brokers (Eurex Members) who will ID-tag your orders towards Eurex.

Yes. On the Execution Broker level, the globally unique Client ID (LEI) ensure that the Eurex Buy-Side Client is identifiable to Eurex, regardless  which Broker the order arrives through.

On the Clearing Broker level, the fees will be charged based on the Fee Code. Therefore, regardless of the Execution Broker and the Clearing Broker, if the transaction is disclosed, finally settled on the A-Account (and if the other requirements apply), the disclosed fee will be charged. 

It is the Executing Broker's responsibility to flag the trade correctly ex-ante. If the trade is not correctly flagged, Eurex will take it as a non-disclosed trade and charge as such.

With the introduction of the fee differentiation, disclosed trades will pay a lower fee than today, and non-disclosed trades will pay a higher fee.