Please insert at least 3 characters

FAQs on transaction reporting – Question II.2.1.1

Data Field (1) and (8)

Some market participants place orders on screen on behalf of more than one legal entity.

For example, a trading house may has a US head office and a European subsidiary and they enter into master agreements with various trading counterparties with either the US head office or the European registered entity, depending upon the preference of the counterparty. US entities would for example contract with the US parent for example to be governed by US law whereas European entities would typically contract with the European based subsidiary.

A trader at one of these “double headed” companies places a single order onto the market. For every counterparty that has good credit with them the number appears tradable, but the resulting trade can end up as being between one of several entities. So a single order can result in a trade with a different “principal” depending on who the counterparty name is. The order is in effect placed on behalf of two (or more) legal entities. I can’t see a way in the schema of representing this.

Example – trader at DoubleCo that has 2 entities – Usco and EUco.

With counterparty A they have a master agreement between A and USco.

With counterparty B they have a master agreement between A and EUco.

DoubleCo initiates an order onto the market, and depending on whether it is aggressed by A or B determines whether there is a trade between USCo and A, or EUCo and B.

The difficulty is how to represent the single order that is on behalf of more than one entity.

USCo is not acting as an agent for EUCo, both USCo and EUCo would be principals to the trade. Company A would report a trade with USCo and company B would report a trade with EUco.

The suggestion would be that ACER accepts that for certain participants, that the idOfMarketParticipant reported for the order may not match the idOfMarketParticipant reported on the linked trade.

An alternative would be to update the schema to allow more than one participant ID on an order (but not on a trade, since we know the correct legal entity at this point).


Answer:

When market participants place orders to trade on broker platforms on behalf of more than one legal entity the Organised Market Place should decide or/and agree with their clients which market participant is placing the order for the reporting purpose. By placing an order the legal entity is a market participant even if it will not be a counterparty to the trade.

Data Field (1) ID of the market participant or counterparty, requires that the ID of the market participant or counterparty on whose behalf the record of transaction is reported shall be identified by a unique code.

In the Agency’s view, this means that market participants that place orders on the screen of the brokers or exchanges have to be identified in the trade report as responsible for the reporting of the report. This does not imply that they are counterparty to the contract, but that they are responsible for the reporting of the order or the trade.

When a single order can result in a trade with a different “principal” depending on who the counterparty name is and the order is still placed on behalf of two (or more) legal entities, there is no need to indicate in the order report who is the beneficiary if and only if the beneficiary may be either the USco and EUco (as for the example above).

With regard to the trade, once it is clear to the Organised Market Place (and the market participant who placed the order) who is the beneficiary of the trade, this can be added in field (8) “Beneficiary ID” if this is different than the market participant reported in Field (1) “ID of the market participant or counterparty” in the order report. Please see the example below.

Firms Placing the order

(any of the three legal entities e.g. EUCo)

Matched orders Other side of the trade
EUCo EUCo and MP 1 MP 1
USCo EUco USCo and MP 2 MP 2
JPCo JPCo and MP 3 MP 3

 

The trade report should look like:

 Field # Case 1

EUCo and MP1

Case 2

EUCo and MP1

(alternative to case 1)

Case 3

USCo and MP2

Case 4

JPCo and MP3

#1 (ID MP) EUCo EUCo EUCo EUCo
# 4 (ID Other MP) MP 1 MP 1 MP 2 MP 3
# 8 (Beneficiary ID) EUCo USCo JPCo
#10 (Capacity) P A A A

 

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.2

Data Field (2)

Allowable format of BIC Codes.

The TRUM and XSD schema both show the BIC as being an 11 character field.

However, in the marketplace the BIC code is actually an 8 character reference, with an optional 3. And in ACER’s list of Participant’s

We suggest that the XSD be modified to allow BIC submission with a minLength of 8.

<xs:simpleTypename=”bic“>

<xs:restriction base=”xs:string“>

<xs:maxLength value=”11“/>

<xs:minLength value=”118“/>

<xs:pattern value=[A-Za-z0-9_]+“/>

</xs:restriction>

As background, the BIC is made up by;

  • Business Party Prefix (4 Characters)
  • Country Code (2 Characters)
  • Business Party Suffix (2 Characters)
  • Optional Branch Identifier (3 Characters)

Numerous instances of 8 character BIC codes in the marketplace.  A small selection below for reference:

KRONDK22

NDEAFIHH

DABAFIHH

RABONL2U

OKOYFIHH

BREXPLPW

TATRSKBX

BAWAATW

Suggestion is that in order to successfully use BIC within the ACER XML schema, the validation on BIC should allow for a minimum of 8 characters (currently 11) and a maximum of 11.


Answer:

Our understanding is that the SWIFT code is 8 or 11 characters long. According to ISO 9362:2009 (dated 2009-10-01).

The SWIFT code is 8 or 11 characters long, made up of:

  • 4 letters: Institution Code or bank code.
  • 2 letters: ISO 3166-1 alpha-2 country code
  • 2 letters or digits: location code

If the second character is “0”, then it is typically a test BIC as opposed to a BIC used on the live network.

If the second character is “1”, then it denotes a passive participant in the SWIFT network

If the second character is “2”, then it typically indicates a reverse billing BIC, where the recipient pays for the message as opposed to the more usual mode whereby the sender pays for the message.

3 letters or digits: branch code, optional (‘XXX’ for primary office)

Where an 8-digit code is given, it may be assumed that it refers to the primary office and therefore should be reported as:

<bic>12345678XXX</bic>

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.3

Data Field (3)

If an OMP produces an ACER XML file, but instead of loading the data through an RRM, the ACER XML file is provided to the market participant to load into their RRM of choice – will the validation of the Field 3 (Trader ID) data be based upon the OMP Trader Id (3a) or the Participant Trader Id (3b)?

OR

If an OMP produces an ACER XML file, but instead of loading the data through an RRM, the ACER XML file is provided to the market participant to load into their ETRM system and then report the trade to their RRM of choice – will the validation of the Field 3 (Trader ID) data be based upon the OMP Trader Id (3a) or the Participant Trader Id (3b)?

“traderIdForOrganisedMarket” (Field No. 3a)
“traderIdForMarketParticipant” (Field No. 3b)

  • MP A trades on OMP 1.
  • OMP 1 uses RRM 1.
  • MP A opts out of OMP 1 reporting, and requests the ACER XL data to lodge with their RRM of choice (RRM 2).
  • OMP 1 generates a daily ACER XML file for MP A.
  • MP A takes the file and loads it to RRM 2.

In this instance, does the ACER check on Field 3 (Trader Id) look at the OMP value (3a) as the data was sourced from an OMP or the participant value (3b as the data was loaded via a participant?
Suggest that in this instance, either value be allowed for reporting.


Answer:

Because the trade is executed at the Organised Market Place, the market participant should report the trade/order report with the same information of the Organised Market Place and therefore “traderIdForOrganisedMarket” (Field No. 3a) should be reported.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.4

Data Field (3)

Reference to documents: Annex IV to Transaction Reporting User Manual

Is it mandatory for OTC contracts, to fill Table 1, Field 3? In the examples provided by ACER, such fields are filled only for standard contracts and examples 15.2-18.2. What features of examples 15.2-18.2 are triggers for reporting this field? What is the understanding of the person concluding the contract in case of OTC market? Is it a person whose signature appears on the contract?

In our opinion, this field should not be required for contracts concluded OTC.


Answer:

Data Field (3) ID of Trader is required to be populated for any contract executed at organised market places and bilaterally as already indicated in the TRUM. For executions executed under the framework of non-standard contracts, examples are available in Section (2) of Annex II to the TRUM. The Agency would not expect this filed to be reported in line with the examples provided in Annex II to the TRUM.

RSS_Icon Last update: 26/09/2016  

FAQs on transaction reporting – Question II.2.1.5

Data Field (4)

This question pertains to exchange contracts traded on a broker. These contracts are typically traded anonymously, so that neither party to the trade knows who the other party is. The question is what value should be supplied for TRUM field 4 for trades on such contracts. An example would be a XXX Germany Baseload contract traded on broker platform.

We believe the counterparty should be omitted. This would be consistent with the rule that exchange-traded contracts do not require a counterparty.


Answer:

If the trade takes place on an exchange with orders to trade placed on the broker’s screen or voice brokered, this trade should be reported as any other trade that takes place on exchange.

If traded on the broker’s screen, the orders should be reported as orders placed on the exchange’s contract. There is no expectation that the order report and the trade report are linked together as they were placed first and executed after on two different Organised Market Places.

When orders on futures traded on exchanges are placed on the broker platforms, e.g. Indication of Interest (IOI), Field (4) “ID of the of the market participant” should include the ID of the Exchange.

This can be reported in the form of the LEI, BIC, EIC, or ACER code. When only the Exchange’s MIC code is available to the reporting party, this can be reported (as a last resource) in the format XMIC0000.EU – where the 4 first digits represent the Exchange’s MIC code, followed by 5 zeros, followed by “.EU” to replicate an ACER code.

For the reporting of the trades and for the reporting of the orders, please see examples (2.17) and (3.21) respectively included in the Annex II to the TRUM.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.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 and at the end of this document.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.7

Data Field (8)

If the beneficiary of the contract as referred in Article 8(1) of Regulation (EU) No 1227/2011 is counterparty to this contract the field is to be left blank. If the beneficiary of the contract is not counterparty to this contract the reporting counterparty has to identify the beneficiary by a unique code.

If an order is placed by an agent we don’t know the ID/name of the beneficiary.

Has the beneficiary information to be reported as OTC deal by the trading participant (between trading participant/agent and beneficiary)?

We will leave the field “Beneficiary ID” blank because we do not know the beneficiary if the beneficiary is not identical to the trading participant.


Answer:

Please see guidance on field (8) Beneficiary ID available in the TRUM at https://www.acer-remit.eu/portal/data-submission

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.8

Data Field (8)

Article 4 (1)(a) of the Regulation 1348/2014 – Reporting of intragroup transactions and beneficiary identification.

A broker concludes a back-to-back transaction in an organised market place. It acts as a Principal, however the Beneficiary of the transaction will ultimately be a market participant belonging to the same capital group as the broker.

Can ACER confirm that:

1) the transaction concluded by the broker in the organised market place should be reported without indicating the Beneficiary in the Field 8 (as it is a back-to-back transaction);

2) the transaction between the broker and the market participant should not be normally reported at all (as it is an intragroup transaction and takes place OTC).

Hence, ACER will not have information about the beneficiary of the transaction?


Answer:

A back-to-back transaction is a bilateral transaction not executed on the exchange. The transaction concluded by the executing broker at the Organised Market Place should be reported by the exchange indicating the Beneficiary in the Field 8 if this information is available to the exchange. Please see the TRUM, guidance on Field 8.

The transaction between the broker and the market participant may not be reported if this is an intragroup transaction and takes place OTC. However, nothing prevents the market participant from reporting the back-to-back transaction to ACER.

Based on the above, the Beneficiary will be the executing broker who is also a market participant if the back-to-back transaction is an intragroup transaction. It is worth noting that if no beneficiary is provided, then the market participant indicated in Filed (1) will be assumed to be the beneficiary.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.9

Data Field (8)

The TRUM is not explicit about whether beneficiary information should be included as a lifecycle event for order data both on unexecuted orders and orders which result in a trade. It is clear that Participants will have to report the beneficiary information on trades, but it is not clear if they should have to for orders. Please could ACER clarify?

Example: Where a transaction needs to be updated with the beneficiary information as a lifecycle event; does ACER expect market participants to also update the related orders that led to the transaction with the beneficiary information?

The beneficiary information should only be required to be reported on executed trades


Answer:

When a trade report is updated with the beneficiary information as a lifecycle event there is no expectation that market participants also update the related orders that led to the transaction with the beneficiary information.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.10

Data Field No (9)

With regard to the Trading Capacity and the connected information final beneficiary we have a question: Our understanding is that a Trading Capacity setting of Agent only adds value in the context of also providing a final beneficiary that is then the actual owner of the transaction. A setting of Agent without the indication of the final beneficiary will need to be considered as if it were for the member (acting as an agent) until the actual beneficiary is acknowledged.

The current assumption is that the final beneficiary information for exchange trades will be provided starting April 2016 based on a back-to-back Non-Standard ACER Transaction between the member and the final beneficiary.

(The direct information for the final beneficiary is not an information that is available on the exchange platforms).

Based on these facts, our best effort suggestion is that all exchange trades should be reported as P – Principal until in April 2016 the complete set including the final beneficiaries (with their related Non-standard transaction between member and final beneficiary) can and needs to be reported.


Answer:

The definition of Trading Capacity is available in the TRUM. If the Organised Market Place knows that the trading capacity of the market participant is “Agent” then “A” should be reported irrespective or the availability of the Beneficiary ID. This always adds value to the transaction report.

RSS_Icon Last update: 08/09/2015  

RSS_Icon Subscribe to this Category’s RSS