Linkedin

Internal Market for Energy Trading

Contact us

Table of Contents

0 M
Duration
0 FTE
Consultants

BACKGROUND

A Client in the Energy sector wanted to create an Internal market for energy trading based on a vision document created by Porteg. The Digital Trading Programme included the development of such an internal market with a multitude of elements included.

ASSIGNMENT

For one of its clients, Porteg has written a vision document on the possibilities and variations of Digital Trading and how to implement these within the trading organisation.
The objective was twofold:

  • Creating an internal market to automatically match opposite positions;
  • Developing algorithms for executing specific strategies.

 

The overview below provides an overview of the methodology used and the products created to translate the outcome of the vision document into a project approach.

APPROACH

The business analysis for the internal market project consisted of five major area’s:

 

  1. The As-Is analysis has been the basis of the decision making on portfolio’s, products and markets to be assigned to desks and offices. The As-Is analysis was done based on architectural principles and delivering clear inside in markets; products and processes on all forward trading. Including automated and manual processes regarding exchange and broker based trading and internal trading.
  2. Based on the As-Is analysis, both Stakeholder requirements (user) and Solution requirements (system) where gathered and plotted on every architectural level within the as-is analysis. Creating a clear picture where improvements on processes could be achieved; data structure and data integrity could be improved and required capability of the to be implemented solution could be made specific.
  3. The To-Be architecture was based on approved and to be realized changes in all architectural levels. And helped the new organizational structure to be implemented and become operational. It also provided all the required (high prioritized) system requirements for the vendor to build and deliver.
  4. In cooperation with the trading organization “Rules of the Game” where formulated to specify the behaviour and do’s and don’ts on the internal market such as trade types (FoK, Iceberg) or transparency (visibility of origin, volume, order routing).
  5. After delivery of the solution intensive functional testing, based on functional requirements, was provide by defining all possible scenario’s, selection of testcases and organize testing and training of traders

As-Is (Current state) analysis

  • Delivery of as-is description (current state) on markets; products and processes (thorough analysis of the business architecture) and a high level analysis of data and systems (i.e. the IT-architecture)
  • Relations and structure between markets; products and processes (business architecture) and process specific details (e.g. manual versus automated / ad hoc versus scheduled)
  • Automation gaps meaning identification where systems functionality is missing (high level).

 

All descriptions captured in a Business Analysis Document containing detailed overview of markets; products and processes and relation between those architectural levels.

Process flow diagram As-Is

as-is process diagram
Figure1: as-Is Process Diagram (example)

Product definitions As-Is

As-Is product definition (example)
Figure 2: As-Is product definition (example)

To-Be (Future State) analysis

The Future State analysis for the internal market is based on the vision document mentioned in paragraph “1. Assignment”. Based on the medium / long term outlook on the future state of the trading organisation the analysis start with the gathering of the business requirements and the functional & technical requirements. The Future State analysis follows the Enterprise Architecture as described in section: Enterprise architecture Model

Enterprise architecture model

The Enterprise Architecture shows the relation between the different layers in the model and also shows the order of execution. Going from top to bottom, a vision (mission) statement is the main driver for change and direction. From the vision, requirements need to be gathered on different levels: High level on the Business requirements (BR) and more detailed in the solution requirements (Functional and Technical). NOTE: there are different ways of naming and categorising requirements, but the principal is always the same.The Enterprise Architecture shows the relation between the different layers in the model and also shows the order of execution. Going from top to bottom, a vision (mission) statement is the main driver for change and direction. From the vision, requirements need to be gathered on different levels: High level on the Business requirements (BR) and more detailed in the solution requirements (Functional and Technical). NOTE: there are different ways of naming and categorising requirements, but the principal is always the same.

 

Enterprise Architecture model
Figure 3: Enterprise Architecture model

The core part of the Enterprise Architecture model contains the five layers of the “business architecture”:

Detailed diagram Architecture
Figure 4: Detailed diagram Architecture
  1. Markets
  2. Products (Instruments)
  3. Processes
  4. Data
  5. IT (systems)

Each layer can be the origination of change or be affected by the change of a layer above (or below). But the basic principle is that upper layer initiate the change of the lower level. Specially if the direction to work from starts with the mission statement. NOTE: Digital / IT driven projects could potentially work the other way around. But need to stay within the boundaries of the layers above to be successful

Detailed diagrams for future state

Combining requirements and the different layers of the business architecture, the follow diagram can be created. This diagram shows the To-Be architecture of the five layers combined in combination with three solution requirements. Normally these are are showing one of maybe two levels of the business instead of all five. In this case the the example shows clearly the relation between the levels and the requirements.

Solution requirements

The target architecture covers all requirements (both functional and technical) and relates the requirements to the specific layer and position.

Solution Requirements
Figure 5: Solution Requirements

Detailed design for Order Management

Combining the detailed diagrams with the solution requirements lead to detailed design of functionality and screen mock-ups. And example of such detailed design is provided below:

Screen mock-up as part of To-Be analysis

The picture shows the setup of the MA screen Mock-up that should be used for manual routing

Order routing console
Figure 6: Order routing console
  • The orange box top left “Carbon” contains the instrument group the MA trader is looking at. This instrument group is selected by the MA trader. Details on how these instrument groups are setup and how traders can select those instrument groups is described in another detailed.
  • The MA trader can have multiple instrument groups assigned to himself. Meaning that this screen could have multiple widgets containing each a separate instrument group.
  • The button “Select” can be used to select multiple orders. This functionality can also be used in the first column of the grid: Select. Or use Crtl S.
  • The “Route” button will route the selected order(s). And will open up the screen as described in paragraph 5.2. If multiple orders are selected, the routing screen (5.2) will appear per order in sequence.
  • The “Withhold” button will allow the MA trader to withhold the selected orders from the external venues.
  • The “Claim” / “Execute” / “Fill” buttons will be added in later detailed design.

Order routing details mock-up

The screen below visualises the details of the internal order (on the left side) and the details to be added by the MA trader of the right side before the order can be routed.

Order routing detail
Figure 7: Order routing detail

The purpose of this screen is to provide the MA trader all the information per order to route this order with the correct details to the venue of choice. The internal section of the screen contains all the information related to the parent order:

  • Symbol refers to the internal instrument. For Carbon the EUA Monthly December contract, for the year 22, 23 or 24.
  • Side refers to either Sell or Buy
  • Price is the limit price provided on the order.
  • Quantity is the number of contracts on the order
  • Trader refers to the originator of the order on the internal market.
  • Portfolio is the target portfolio provided on the order.
  • Label is the Prop / Hedge label of the order
  • Expiry is the expiry parameter of the internal order

All details provided in the section “Internal” are all details referring to the parent / internal order. And cannot be changed by the MA trader. Therefore all the boxes are light grey, to show that this data cannot be changed by the MA trader.

The External section of the screen contains information for the MA trader referring to the routing of the order:

  • Route to refers to the venue of choice. For the Carbon release MVP this venue will always be ICE. But in future releases, multiple venues can be selected here.
  • Contract refers to the contract that will be created on the external venue. This contract is also grey. Meaning that this cannot be changed by the MA trader. The combination of internal instrument (Symbol) and the venue of choice (Route to) will determine the contract traded externally.
  • Order Type the MA trader can modify the order type. For the MVP only Limit orders are allowed. And the only change to the order type allowed, is the change to an Ice-Berg order, or a Hidden quantity.
  • Off-set price refers to the possibility for the MA trader to add or subtract a premium that will be added / subtracted from to external order price. This premium will not be charged to the internal trade but will become P&L for the MA trader.
  • Quantity The volume that will be routed external. The MA can reduce the volume that he wants to route externally but cannot increase the volume of the order.