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