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).


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

# 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.1.1.1

Reference to documents: Section 3.4.2 of the REMIT TRUM on Page 31

“Details of standard contracts, including orders to trade, shall be reported no later than on the working day following the conclusion of the contract or the placement of the order. Any modification or the termination of the concluded contract or the order placed shall be reported no later than the working day following the modification or termination”.

OMPs, Market Participants and RRMs need further clarification regarding the definition of a “Working Day” for management of their internal systems.

Further clarification is also needed for ACER in relation to their expectations of, “the next working day”

OMPs such as XXX Futures EU and XXX Spot (collectively “the Exchanges”) operate in multi-time-zone markets and their established support systems and processes are configured accordingly. The Exchanges use trading days with each trading day corresponding to an underlying processing day. The Exchanges appreciates that a trading day may not have the same definition as a “Working Day”.

The Exchanges request that ACER confirm that it is happy to accept that the below as being in conformance with the definition of a “Working Day”.

XXX has identified the following “processing window” times;


These times correspond with the XXX’s internal systems. XXX believes that these processing day times should be compatible with ACER’s definition of a “working day”.

Furthermore, taking into consideration that REMIT reportable data should be reported on the next working day, please could ACER clarify whether it is happy to receive REMIT data on the following basis.


These times take into account the various necessary maintenance windows for the Exchanges markets.


Working days should be understood as business days rather than the exchange trading days. This implies that bank holidays are not working days.

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:restriction base=”xs:string“>

<xs:maxLength value=”11“/>

<xs:minLength value=”118“/>

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


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:









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.


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:


RSS_Icon Last update: 08/09/2015  

RSS_Icon Subscribe to this Category’s RSS