Disclaimer

©2024 Deutsche Boerse AG - All rights reserved. The information contained in this document is confidential or protected by law. Any unauthorized copying of this document or part of it or unauthorized distribution of the information contained herein is prohibited. All materials provided by DB in this context are and remain the intellectual property of DB and all rights therein are reserved.

1 Abstract

This document contains a functional description of the XML reports generated by the Reporting Engine and Reporter modules of the M7 Trading. This includes report subscription, report generation, report structure, available report types and their contents. It requires a familiarity with the XML standard, as defined by the World Wide Web Consortium (W3C, see https://www.w3.org/XML for more information).

Note: Data contained in graphics and examples are for illustrative purposes only.

2 Introduction

2.1 General

The M7 Trading Module enables the trading of energy products and commodity derivatives between different market areas.

All trading related activities, like order entry, order modification or the generation of trades, are documented in XML reports which are generated based on data from the M7 Trading Module and can be downloaded via the WebGUI.

The reports generated by the Reporting Engine module are available to both report users who can belong to a non-Admin member and to market operations (Admin members).

The reports generated by the Reporter module are designed for market operations only (Admin members).

2.2 System Login

Access to the M7 Service Market Operation WebGUI is protected by SSL connection encryption and implements two-factor authentication (2FA).

On the log-in screen, the User is asked to provide following information:

• User Name
• User Password (static)
• Time Based One-Time Password (TOTP)

After successful authentication through the entry of a valid market operation Username and passwords, the system’s “Report Subscription and Download” page opens (see Report Subscription and Download). If an invalid Username or any of the passwords is entered, the user receives an error message and access to the M7 Service is denied.

2.2.1 Two-Factor Authentication

M7T implements an industry standard form of 2FA. For logging in, the User is configured with a static password complemented by a Time-based one-time password (TOTP) generated by an Authenticator with each login based on a known algorithm. The User is allowed to log in to the M7T WebGUI only if both passwords provided on login - the static password and the TOTP - are correct.

In order to generate the TOTP code, TOTP key needs to be provided to User’s Authenticator. This key is generated when a new user is created (For details please refer to MFG130 Admin Manual for Market Operations WebGUI, the chapter First Time User Setup. To generate the code for login either an Authenticator application or custom implementation of the TOTP algorithm can be used.

Change of TOTP key can be done via Change password Screen and clicking to the Regenerate Key button. Newly generated key needs to be provided to the Authenticator, is then shown in the TOTP Key field. Once generated, the new TOTP key is displayed until the User navigates away form the Change Password Screen or logs out.

A QR Code with the TOTP Key can be downloaded by clicking the QR Code button. It can be scanned and used to configure the Authenticator conveniently if the application supports such functionality.

2.2.2 Cipher Suites Supported for Connection to WebGUI

The M7 Trading application currently supports the following cipher suites for the connection to the M7 Service Market Operation WebGUI:

• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Disclaimer: The above-mentioned list is based on the last penetration test performed by DBAG in November 2020 and may be subject to change. Any modifications to the list triggered by DBAG will be announced with sufficient lead time, whenever the situation allows it (an example of an exception would be the installation of a security patch).

Nevertheless, it is important to note that also upgrades of the OS and the SSL library may result in some (but not all) of the above listed ciphers not being supported for establishing the communication with the M7 Service Market Operation WebGUI. As DBAG cannot influence the project lifecycle of the third parties’ software, it strongly recommends the M7 Service Market Operation users to perform a simple login test to verify that it is possible to log in into the M7 Service Market Operation WebGUI using the selected browser. Such test should be executed at least once for each major release (6.11, 6.12 etc.) during the release UAT phase, to prevent later connectivity issues in a Production environment.

3 XML Report Layout

3.1 General

The XML report layout consists of the basic elements: structures and data fields, whilst each XML element occurs in a sequence defined by the main report structure.

3.2 Structure Elements

Structures are ordered collections of structure members (see Structure Members) and may contain data fields and/or other structure elements (substructures).

3.3 Structure Members

A structure member is either a data field or another structure element. A structure member may be enriched by attributes to define report specific properties.

Data fields are elements which contain data as defined by their data type (see Data Types).

Substructures may occur zero, once or multiple times inside a structure (see Structure Cardinality).

All elements may be mandatory or optional (see Usage Code). Optional elements may be omitted in the XML report.

3.4 Data Types

The following data types are used in the description of each report generated by

• the Reporting Engine module:

• the Reporter module:

For further details on the data types used by the Reporter module please see https://www.w3.org/TR/xmlschema-2/.

3.5 Structure Cardinality

Any substructure may occur zero, one or multiple times in a structure.

The XML report structure descriptions in this document contain the cardinality information in the column “No.”, which can contain the following values:

3.6 Usage Code

The XML report descriptions contain usage codes for each tag. These codes provide information on whether a tag is mandatory or optional. The table below lists all applicable usage codes and provides a description.

3.7 Basic Structure

3.7.1 Structure of Reports Generated by the Reporting Engine

The basic structure of each report is:

1. All content is enclosed by a tag with the report name code

<rptName>

2. Each report contains a header enclosed in the header tag

<rptHeader>

3. After the header, the main report data is enclosed by the tag

<rptNameGrp>

4. The report structure then looks as follows

<rptName>
    <rptHeader>
        <!-- header content -->
    </rptHeader>
    <rptNameGrp>
        <!-- data content -->
    </rptNameGrp>
</rptName>

3.7.2 Structure of Reports Generated by the Reporter

The basic structure of each report is:

1. All content is enclosed by a tag with the report name code

<name>

2. Each report contains a header enclosed in the header tag

<header>

3. After the header, the main report data is enclosed by the tag

<body>

4. The report structure then looks as follows

<name>
    <header>
        <!-- header content -->
    </header>
    <body>
        <!-- data content -->
    </body>
</name>

4 Report Subscription and Download

In the WebGUI of the M7 Trading Module, a report user can manage the subscriptions to the XML reports and download the generated subscribed reports.

After logging into the WebGUI, a window with the following sections is displayed:

• Subscribe Reports. The window refers to the reports generated by the Reporting Engine,

• Reporter Admin Reports. The window refers to the reports generated by the Reporter module (only visible for ADMIN report users),

• Download Reports.

4.1 Subscription

In the “Subscribe Reports” section, a report user can subscribe to one or more daily reports.

The subscription area of the report page contains a table with the following columns:

• ID An identification code for each report type.

• Freq Indicates the generation frequency of each report. All reports are generated daily which is indicated by the value "D".

• Name The report name.

• Subscribe The checkbox to subscribe/unsubscribe a report.

The report user can subscribe and unsubscribe to report types by selecting/deselecting the respective report type checkbox (/) and by confirming the settings by clicking the button labelled "Save subscriptions". With the button “Reload” it is possible to retrieve the current state of subscriptions in the database without necessity of logging out and in the WebGUI.

For each exchange, the system operator can configure that the same or a different set of report types will be available for subscription by the market operations report users and non-Admin report users. A later change to the configured set would require a downtime.

The changes in the subscriptions made by the report user come into effect with the next report generation run and apply to the whole member. In case of a Broker report user, one report is generated for each selected report type which contain both broker’s own trading actions as well as actions performed on behalf of other traders.

4.2 Reporter Admin Reports

In the “Reporter Admin Reports” section, a reporting user that belongs to an ADMIN member can view the list of the reports produced by the Reporter module.

The section contains a table with the following columns:

• ID An identification code for each report type.

• Freq Indicates the generation frequency of the report. For the reports generated by the Reporter module, the following frequency is available and can be displayed:

• Name The report name.

The generation of the reports in this section cannot be turned off/on manually on the WebGUI but the configuration can be amended upon customer’s request during a deployment of the Reporter module.

With the button “Reload” it is possible to retrieve the list of the currently supported reports.

The section is not available for non ADMIN reporting users.

4.3 Download

Already generated reports that are ready for download are listed in the bottom section in a table labelled “Download Reports”. Each report remains in the download area for 6 trading days after its generation, meaning the report user is able to download the reports for the last 6 trading days.

The number of days available in the “Download Reports” is configurable by the system operator. The change would require a downtime of the Reporting Engine module. The request would also need to be first assessed by DBAG, because the number of days may be limited by the file system where the reports are stored.

With the button “Reload” it is possible to refresh the list of all generated reports available for download.

The “Download Reports” table contains the following columns:

• ID An identification code for each report type.

• Size Size of the report file.

• Date Creation date of the report.

• Filename Filename of the report.

5 Report Generation

5.1 Trading Day

While contracts in M7 are traded based on the product time zone, reports generated by the Reporting Engine module use the market time zone (i.e. CET/CEST) and the market trading day configuration (00:00:00 CET/CEST - 23:59:59 CET/CEST on the same calendar day).

The M7 system supports 24/7 trading, i.e. trading around the clock and on each day of the week.

5.2 Report Generation by the Reporting Engine

The reports generated by the Reporting Engine module are used to display data for the generated trades and bids, or order maintenance during the last (full) trading day. They are automatically generated once a day at the preconfigured time. The time is configured by DBAG at the exchange level and applies to all report types generated by this module.

Since the report generation timer is based on UTC (Coordinated Universal Time), the actual time of report generation will differ in Central European Summer Time (CEST) and during Central European Time (CET). During CEST, the reports will be generated one hour later in comparison to CET. In other words, the reports with the generation time configured to hh:mm:ss (UTC) will be generated at (hh+1):mm:ss during CET and at (hh+2):mm:ss during CEST.

Example: Assuming the configured report generation time is 3:00 am UTC, in May the reports will be generated at 5:00 am whereas in November at 4:00 am.

For market operations report users, the reports are generated regardless of the user status. The appropriate <Login ID> will appear in the file name when an ADMIN report user is available; in case of multiple report users, the reports will be named based on the first active user found by the system. If there is no report user at the time of the report generation, the file name will contain the string “UNKNOWN” instead of <Login ID>. The existing reports will not be renamed after an ADMIN report user is available.

For a non-Admin report user, the reports for the trading day t are only generated if both the report member and the appropriate report user were active at the time of the generation on t-1.

Note: The reports can be generated the second time for the same trading day or retrospectively only with the assistance of DBAG and upon request of the customer. In case a report for the same trading days is generated again, the first one will be renamed to ~.bak and will not be available for direct download.

5.3 Report Generation by the Reporter

5.3.1 M7 is connected to XBID

The Reporter module generates reports for market operations report users on a regular basis based on the order and trade data available to M7 at the time of the report generation or after the re-synchronisation with XBID.

The frequency of the report generation depends on the configured duration of the trading period to be covered by one report. For example, with the configured trading period duration of 1 hour, the Reporter module will generate 24 reports. Each report will be generated at latest X minutes after the end of the trading period, where X = 15 + 'configured trading period duration in minutes' / 6.

The default trading period duration of 1 hour can be amended by a DBAG system operator during a maintenance window. The new configuration changed on the day d will come into effect at midnight (UTC) on the day d+1. For the list of the allowed trading periods, see Reporter Admin Reports.

The generation of the reports by the Reporter module is managed in the UTC time and the trading period covered by each report is fixed throughout the year to the configured duration. Therefore, DST switches do not have any impact on the timings of the reports generation nor on the duration of the trading period covered by the reports.

5.3.2 M7 is disconnected from XBID

The Reporter module reacts upon M7 disconnection events from and re-connection events to XBID. Upon an automatic detection of an M7 disconnection event from XBID, the Reporter stops generating the reports.

5.3.3 M7 re-connection to XBID

As soon as the Reporter module recognises that the connection between M7 and XBID has been re-established and the synchronisation with M7 has been completed, it automatically starts generating the missing reports, from the report with the oldest trading period towards the newest. Once all missing reports have been generated, the usual report generation is resumed. The missing reports are generated at most 6 trading days back.

6 XML Report Descriptions

The following chapter describes the content of reports and their structure including information contained in the individual attributes.

6.1 TC540 Daily Order Maintenance

6.1.1 TC540 Selection Criteria and Target Group

The report is generated as member-specific as well as for market operations. The latter receives the report as an aggregation of all generated member reports.

6.1.2 TC540 Structural Logic

For each member, a <tc540Grp> contains the orders that have been modified by the member’s users. Inside this group tag, the orders are sorted by a combination of the user code and contract. Each such combination is defined by a <tc540Grp1>. Finally, within this group tag, each maintenance action is listed individually inside a <tc540Rec> tag (please see guidance on the reported maintenance actions in TC540 Daily Order Maintenance). All <tc540Rec> inside a <tc540Grp1> appear in chronological order (earliest first). To ensure such ordering, the actions are ordered by their revision.

One report does not necessarily contain the complete lifecycle of an order, as it lists only the maintenance actions for one trading day, which is displayed in the tag <rptPrntEffDat>.

In the report for the market operations, a member will appear if and only if at least one of its users performed an order maintenance action (or the action was performed on behalf) during the last (full) trading day. In this regard, the status in which the (trading) member or its user is at the time of the report generation is irrelevant.

6.1.3 TC540 Example

Member A has two traders called Trader I and Trader II. Trader I performed two maintenance actions on an order for contract X and trader II performed one maintenance action on an order for the same contract X and two maintenance actions on an order for contract Y. Some of the orders have been entered the day before. However, the TC540 only contains the actions that were performed on the orders on the trading day stated in the “rptPrntEffDat” field. The resulting report structure is:

<tc540Grp>              <!-- contains all actions for Member A -->                                                    
    <tc540Grp1>         <!-- contains the actions of Trader I for contract X -->
        <tc540Rec>      <!-- the first action of Trader I on contract X -->
        <tc540Rec>      <!-- the second action of Trader I on contract X -->
    <tc540Grp1>         <!-- contains the actions of Trader II for contract X -->
        <tc540Rec>      <!-- an action of Trader II on contract X -->
    <tc540Grp1>         <!-- contains the actions of Trader II for contract Y -->
        <tc540Rec>      <!-- the first action of Trader II on contract Y -->
        <tc540Rec>      <!-- the second action of Trader II on contract Y -->

6.1.4 TC540 Structure

6.2 TC550 Admin Order Data Report

6.2.1 Selection Criteria and Target group

The report is an aggregation of order maintenance actions of all members during the configured trading period.

6.2.2 TC550 Structural Logic

Each TC550 report covers the trading period specified by the <startTime> and <endTime> elements, which can be found inside the <header> tag. The order maintenance actions performed during the configured trading period are listed in the <body> tag of the report, each order being embedded in the <order> tag.

Inside the <order> tag, all order maintenance actions are sorted by the orderNo ascending and then by the revisionNo ascending. The report attributes are listed in two groups, first <orderAttributes>, which contains immutable order characteristicts, and then <revisionChange>, which is the wrapper for mutable order attributes.

If the order is included in two or more TC550 reports, the immutable order characteristics in <orderAttributes> are present in all of them. The group <revisionChange> will contain the mutable order attributes for all new revisions that have emerged during the TC550 trading period.

6.2.3 TC550 Example

The part of the report body that follows represents two order management actions performed on one order, first of them represents the order entry, the second one represents the full execution of the order.

<order>
 <orderAttributes>
  <orderId>3015</orderId>
  <initialOrderId>3015</initialOrderId>
  <remoteOrderId>581784539</remoteOrderId>
  <memberId>TEST1</memberId>
  <balancingGroup>TEST1-BG1------X</balancingGroup>
  <userCode>TRD001</userCode>
  <productLongName>Intraday_Power_D</productLongName>
  <contractLongName>20210205 14:00-20210205 15:00</contractLongName>
  <contractDeliveryStartTime>2021-02-05T13:00:00Z</contractDeliveryStartTime>
  <contractDeliveryEndTime>2021-02-05T14:00:00Z</contractDeliveryEndTime>
  <marketAreaEic>DEMO1-----------</marketAreaEic>
  <deliveryAreaEic>DEMO2-----------</deliveryAreaEic>
  <side>BUY</side>
  <type>O</type>
  <clearingAccountType>P</clearingAccountType>
  <currency>EUR</currency>
  <listExecutionInstruction>NONE</listExecutionInstruction>
  </orderAttributes>
 <revisionChange>
  <revisionNo>5</revisionNo>
  <qty>1.000</qty>
  <px>2.00</px>
  <state>IACT</state>
  <action>UDEL</action>
  <tranTime>2021-02-05T10:00:11.6Z</tranTime>
  <matchPrioTime>2021-02-05T09:36:06.785Z</matchPrioTime>
  <validityRestriction>GFS</validityRestriction>
  <aot>false</aot>
  <applicationId>ComTrader</applicationId>
  <applicationVersion>6.11.52</applicationVersion>
  <validityDateTime>2021-02-05T12:00:00Z</validityDateTime>
  <orderExeRestriction>NON</orderExeRestriction>
  <remoteRevisionNo>4</remoteRevisionNo>
 </revisionChange>
</order>

6.2.4 TC550 Structure

6.3 TC810 Daily Trade Confirmation

6.3.1 TC810 Selection Criteria and Target Group

This report can be generated as member-specific as well as for market operations. The latter receives the report with the trades of all members.

This report shows the trades of the last closed trading period (day).

6.3.2 TC810 Structural Logic

Each <tc810Grp> contains all trades for a member/contract combination. Inside this group tag, the trades are organized by traders into different <tc810Grp1>. Inside this structure, the trades themselves are listed in the last hierarchy level, each in a separate <tc810Rec>.

In general, all trades identified by their “tranIdNo”, are only present once. The exception are trades for which a trade recall has been requested (identified by the value “Q” in the field <tranTypCod>), recalled trades (identified by the value “R” in the field <tranTypCod>), trades with the recall rejected (identified by the value “J” in the field <tranTypCod>) and cancelled trades (identified by the value “C” in the field <tranTypCod>).

6.3.3 TC810 Examples

6.3.3.1 Report Structure

Member A has two traders, Trader 1 and 2. For contract X, Trader 1 has two trades; for contract Y, Trader 1 and Trader 2 have one trade each.

The resulting report structure is (key groups are not displayed here):

<tc810>                                                                                                                                         
    <tc810Grp>               <!-- contains all trades for Member A and contract X -->                                                   
        <tc810Grp1>          <!-- contains all trades of Trader 1 for contract X -->  
            <tc810Rec>       <!-- the first trade of Trader 1 for contract X -->
            <tc810Rec>       <!-- the second trade of Trader 1 for contract X -->
    <tc810Grp>               <!-- contains all trades for Member A and contract Y -->                                                   
        <tc810Grp1>          <!-- contains all trades of Trader 1 for contract Y -->
            <tc810Rec>       <!-- a trade of Trader 1 for contract Y -->
        <tc810Grp1>          <!-- contains all trades of Trader 2 for contract Y -->
            <tc810Rec>       <!-- a trade of Trader 2 for contract Y -->

6.3.3.2 Cross-Product Matching and Trade Decomposition

Cross-product matching between an hourly product and a quarterly product is enabled. Member A has one trader, Trader A, who placed an hourly buy order for the contract 12-13. Member B has one trader, Trader B who placed three quarterly (3x15 minutes) sell orders for the contracts 12Q1, 12Q2 and 12Q3. Member C has one trader, Trader C who placed one quarterly (1x15 minutes) sell order for the contract 12Q4. The buy order and the four sell orders were matched into a trade. As a result of the cross-product matching process, the hourly buy trade was decomposed into four quarterly trades. The report contains only the trades for the quarterly contracts.

The resulting report (for market operations) contains the following trades:

<tc810>                                                                                                                                               
    <tc810Grp>              <!-- contains all trades for Member A and contract 12Q1 -->                                                    
        <tc810Grp1>         <!-- contains all trades of Trader A for contract 12Q1 -->
            <tc810Rec>      <!-- (buy side of) trade of Trader A for contract 12Q1 -->
    <tc810Grp>              <!-- contains all trades for Member A and contract 12Q2 -->                                                     
        <tc810Grp1>         <!-- contains all trades of Trader A for contract 12Q2 -->
            <tc810Rec>      <!-- (buy side of) trade of Trader A for contract 12Q2 -->
    <tc810Grp>              <!-- contains all trades for Member A and contract 12Q3 -->                                                     
        <tc810Grp1>         <!-- contains all trades of Trader A for contract 12Q3 -->
            <tc810Rec>      <!-- (buy side of) trade of Trader A for contract 12Q3 -->
    <tc810Grp>              <!-- contains all trades for Member A and contract 12Q4 -->                                                     
        <tc810Grp1>         <!-- contains all trades of Trader A for contract 12Q4 -->
            <tc810Rec>      <!-- (buy side of) trade of Trader A for contract 12Q4 -->
    <tc810Grp>              <!-- contains all trades for Member B and contract 12Q1 -->                                                     
        <tc810Grp1>         <!-- contains all trades of Trader B for contract 12Q1 -->
            <tc810Rec>      <!-- (sell side of) trade of Trader B for contract 12Q1 -->
    <tc810Grp>              <!-- contains all trades for Member B and contract 12Q2 -->                                                   
        <tc810Grp1>         <!-- contains all trades of Trader B for contract 12Q2 -->
            <tc810Rec>      <!-- (sell side of) trade of Trader B for contract 12Q2 -->
    <tc810Grp>              <!-- contains all trades for Member B and contract 12Q3 -->                                                   
        <tc810Grp1>         <!-- contains all trades of Trader B for contract 12Q3 -->
            <tc810Rec>      <!-- (sell side of) trade of Trader B for contract 12Q3 -->
    <tc810Grp>              <!-- contains all trades for Member C and contract 12Q4 -->                                                   
        <tc810Grp1>         <!-- contains all trades of Trader C for contract 12Q4 -->
            <tc810Rec>      <!-- (sell side of) trade of Trader C for contract 12Q4 -->

6.3.4 TC810 Structure

6.4 TC820 Daily Open OTC Maintenance

6.4.1 TC820 Selection Criteria and Target Group

This report can be created to be member-specific, as well as for market operations. The latter receives the report with the OTC orders for all members.

This report shows all maintenance actions for OTC orders for the last closed trading period (day) in continuous trading.

6.4.2 TC820 Structural Logic

For each member, a <tc820Grp> contains all open OTC orders that have been modified by its users. Inside this group tag, the orders are separated by the user’s code, where the orders of each individual user are listed in an extra <tc820Grp1>. Inside this group, the orders for one trader but different contracts as listed in separate <tc820Grp2> tags.

Finally, inside each of these tags, the orders are listed inside the <tc820Rec>, while each maintenance action performed on an order is listed in an individual record.

The report does not necessarily contain the complete lifecycle of an OTC order, as it lists only the maintenance actions for one trading day, which is displayed in the tag <rptPrntEffDat>.

6.4.3 TC820 Example

Member A has two traders called Trader I and Trader II. Trader I performed two maintenance actions on an OTC order for contract X and Trader II performed one maintenance action on an OTC order for the same contract X and two maintenance actions on an OTC order for contract Y. Some of the orders have been entered the day before. However, the TC820 only contains the actions that were performed on the trading day stated in the “rptPrntEffDat” field.

The resulting report structure is:

<tc820Grp>                  <!-- contains all actions of Member A -->                                                                                       
    <tc820Grp1>             <!-- contains all actions of Trader I -->                                                   
       <tc820Grp2>          <!-- contains all actions of Trader I on contract X -->   
            <tc820Rec>      <!-- the first action of Trader I on order of contract X -->
            <tc820Rec>      <!-- the second action of Trader I on order of contract X -->
    <tc820Grp1>             <!-- contains all actions of Trader II -->                                   
        <tc820Grp2>         <!-- contains all actions of Trader II on contract X -->
            <tc820Rec>      <!-- an action of Trader II on order of contract X -->
        <tc820Grp2>         <!-- contains all actions of Trader II on contract Y -->
            <tc820Rec>      <!-- the first action of Trader II on order of contract Y -->
            <tc820Rec>      <!-- the second action of Trader II on order of contract Y -->

6.4.4 TC820 Structure

6.5 TC840 RefData Report

6.5.1 TC840 Selection Criteria and Target Group

As this report is for market operations only, it contains information for all members.

6.5.2 TC840 Structural Logic

The TC840 report contains the reference data information which was valid at the time of the report generation.

The main component of the report is the member. For each member, the report states the general member-related information such as its ID, status, contact details or cash limit settings. The member information is then followed by a list of balancing groups which are assigned to this particular member. For each balancing group, the report contains the list of its assigned delivery areas and products. After that, the users belonging to that member and their related information are listed, including their assigned balancing groups, user roles and additional rights.

6.5.3 TC840 Example

Let’s assume that the relationships between the entities and their instances are as depicted in the following diagram (users’ details, additional rights etc. which appear in the resulting report are not shown).

Figure 1: Instance Diagram

The resulting TC840 report:

<tc840>
    <member_list>
        <member>
            <idCode>ADMIN</idCode>
            <name>Demo Market Operations</name>
            <status>ACTI</status>
            <type>ADM</type>
            <cashLimit_list></cashLimit_list>
            <balGrp_list>
                <balGrp>
                    <balGrp>ADMBG----------X</balGrp>
                    <status>ACTI</status>
                    <name>Admin Balancing Group</name>
                    <otcTrading>N</otcTrading>
                        <assignedTso>
                            <assignedTso>DEMODA---------X</assignedTso>
                        </assignedTso>
                        <assignedProduct>
                            <product>Hourly</product>
                        </assignedProduct>
                        <assignedProduct>
                            <product>Quarterly</product>
                        </assignedProduct>
                </balGrp>
            </balGrp_list>
            <user_list>
                <user>
                    <idCode>ADMI01</idCode>
                    <loginId>M7ADMI01</loginId>
                    <name>Jeremy Kyle</name>
                    <status>ACTI</status>
                    <email>Jeremy.Kyle@demo.market.operations.com</email>
                    <defaultBalGrp>ADMBG----------X</defaultBalGrp>
                    <assignedBalGrp>
                        <balGrp>ADMBG----------X</balGrp>
                    </assignedBalGrp>
                    <role>AD</role>
                    <additionalRight>
                    <additionalRight>
                        <right>API</right>
                    </additionalRight>
                        <right>ASA</right>
                    </additionalRight>
                    <additionalRight>
                        <right>REF</right>
                    </additionalRight>
                </user>
                <user>
                    <idCode>RPT001</idCode>
                    <loginId>M7RPRT01</loginId>
                    <name>Marianna Mrkvickova</name>
                    <status>ACTI</status>
                    <email>Marianna.Mrkvickova@demo.market.operations.com</email>
                    <defaultBalGrp>ADMBG----------X</defaultBalGrp>
                    <assignedBalGrp>
                        <balGrp>ADMBG----------X</balGrp>
                    </assignedBalGrp>
                    <role>RE</role>
                </user>
            </user_list>
        </member>
        <member>
            <idCode>TM001</idCode>
            <name>Trading Company</name>
            <status>ACTI</status>
            <type>REG</type>
            <cashLimit_list></cashLimit_list>
            <balGrp_list>
                <balGrp>
                    <balGrp>TRDBG----------X</balGrp>
                    <status>ACTI</status>
                    <name>Demo Balancing Group</name>
                    <otcTrading>Y</otcTrading>
                        <assignedTso>
                            <assignedTso>DEMODA---------X</assignedTso>
                        </assignedTso>
                        <assignedProduct>
                            <product>Hourly</product>
                        </assignedProduct>
                </balGrp>
            </balGrp_list>
            <user_list>
                <user>
                    <idCode>TRD001</idCode>
                    <loginId>M7TRD001</loginId>
                    <name>Peter Chytry</name>
                    <status>ACTI</status>
                    <email>Peter.Chytry@trading.company.com</email>
                    <defaultBalGrp>TRDBG----------X</defaultBalGrp>
                    <assignedBalGrp>
                        <balGrp>TRDBG----------X</balGrp>
                    </assignedBalGrp>
                    <role>TR</role>
                    <additionalRight>
                        <right>API</right>
                    </additionalRight>
                    <additionalRight>
                        <right>ASA</right>
                    </additionalRight>
                    <additionalRight>
                        <right>CAP</right>
                    </additionalRight>
                </user>
            </user_list>
        </member>
</tc840>

6.5.4 TC840 Structure