Question 2.1.6 Data Field (4)

Identifier to represent a “sleeve” action taken by a broker

This requirement is dependent on other interpretations which may require that matched orders get reported.

The question is to how a matched order when a “non Market Participant” is on one side or the other is to be reported.

Brokers often aggress orders placed on screen as a result of a voice instruction from another client. The resulting “trade” is not really a trade as one of the parties to it is a broker who is not a market participant.

The “trade” is in reality an internal broker placeholder for further work to be done by the broker in order to generate a binding trade. These internal trades will always get deleted as the broker cannot contractually deliver or receive any commodity.

The problem is that the broker does not have an ACER code, so if he needs to report any actions then it gets messy.

The suggestion is that ACER allocates a generic ACER code for Broker’s internal processes, so allowing brokers to report these processes if required in a consistent fashion.

Suggestion would be an ACER code something like this as a generic code:

SLEEVE000.EU

Or it may be preferred to have one code per broker such as this:

SPECSLEEV.EU

GRIFSLEEV.EU

ICAPSLEEV.EU

This way, anything reported with a code like this can be identified as being acted upon by the broker.

Answer

Brokers (that are Organised Market Places rather than Executing Brokers) are not market participants and therefore should not appear as counterparty. For sleeve trades with orders on screen, please see example (3.19) in Annex II to the TRUM.