DOCUMENT TITLE

API Functional Descriptions

APPLICATION VERSION

LIFFE CONNECT® Version 9.0

STATUS

Issued Version 1.3

© LIFFE 2005
This document contains information which is confidential and of value to LIFFE Administration and Management (“LIFFE”). It
may be used only for the agreed purpose for which it has been provided.

All proprietary rights and interest in this publication shall be vested in LIFFE and all other rights including, but without limitation,
patent, registered design, copyright, trademark, service mark, connected with this publication shall also be vested in LIFFE.

No part of this publication may be redistributed or reproduced in any form or by any means or used to make any derivative
work (such as translation, transformation, or adaptation) without written permission from LIFFE.

Whilst all reasonable care has been taken to ensure that the information contained in this document is accurate and not
misleading, LIFFE shall not be liable (except to the extent required by law) for the use of the information contained herein.
Neither LIFFE, nor its servants nor agents, is responsible for any errors or omissions contained in this document which is
provided for information only and shall not constitute advice. All information, descriptions, examples and calculations contained
in this document are for guidance purposes only, and should not be treated as definitive.

LIFFE CONNECT® is a trademark of LIFFE and is registered in Australia, Hong Kong, Singapore, the United States, Japan,
and the United Kingdom and as a Community Trade Mark.

LIFFE Administration and Management

The registered office of LIFFE is

Cannon Bridge House
1 Cousin Lane
London EC4R 3XX
United Kingdom
Telephone: +44 (0)20 7623 0444 Fax: +44 (0)20 7588 3624

Registered in England and Wales no 1591809

LIFFE Administration and Management is part of the Euronext N.V. Group of Companies
http://www.euronext.com/
 About

About

The LIFFE CONNECT® Application Program Interface (API) is the software interface
between the LIFFE CONNECT® trading system (Trading Host) and a member's trading
software application (Client Application). This document provides detailed information
about the API to support members and software vendors who are undertaking
development of Client Applications.

This document can only be used by Members, Quote Vendors and Independent Software
Vendors who have signed and returned a copy of the API Licensing Agreement to their
parent Exchange.

In this document, references to the terms ‘contract’ and ‘commodity’ can relate to a
‘product’.

Related Documents
A number of other documents are available to support users of the LIFFE CONNECT®
API, these are:

The Application Program Provides a detailed description of the available function calls and
Interface (API) Reference responses.

LIFFE CONNECT® Describes how to install and set up Release 9.0 of the LIFFE
Application Program CONNECT® API for the first time.
Interface (API) Installation
Notes

External Credits
LIFFE CONNECT® includes software developed by the University of California,
Lawrence Berkeley Laboratory and its contributors, cryptographic software written by Eric
Young ([email protected]) and Tim Hudson ([email protected]).

Sun, Sun Microsystems, and Solaris are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States and other countries.

Red Hat and all Red Hat-based trademarks and logos are trademarks or registered
trademarks of Red Hat, Inc. in the United States and other countries.

Linux is a registered trademark of Linus Torvalds.

Windows® and Windows Server™ are either trademarks or registered trademarks of the
Microsoft Corporation in the United States and/or other countries.

UNIX is a registered trademark in the United States and other countries, exclusively
licensed through X/Open Company, Ltd.

VMS, OpenVMS are trademarks of HP.

API Functional Descriptions Issued Version 1.3 Page 2 of 79

 Table of Contents

Table of Contents

1. Introduction to LIFFE CONNECT® ............................................................... 6

1.1 Overview ....................................................................................................................................6
1.1.1 Operational Platforms ................................................................................................................6
1.2 Summary of Functions Provided Through the API ....................................................................7
2. Security Keys................................................................................................. 8
2.1 Requesting Security Keys ..........................................................................................................8
2.2 Security Keys Setup...................................................................................................................8
2.3 Setting System Environment Variables......................................................................................9
3. API Concepts and Examples ...................................................................... 10
3.1 Types of API Call Client Applications Can Make .....................................................................10
3.1.1 Blocking Calls...........................................................................................................................10
3.1.2 Non-Blocking Calls...................................................................................................................10
3.2 Asynchronous Response Handling..........................................................................................11
3.3 Different Threading Modes ......................................................................................................11
3.3.1 Example ...................................................................................................................................12
4. The Trading Day .......................................................................................... 13
4.1 Day Start ..................................................................................................................................14
4.2 Pre-Open..................................................................................................................................14
4.3 Open.........................................................................................................................................15
4.4 Pre-Close .................................................................................................................................15
4.5 Close ........................................................................................................................................15
4.6 Day End ...................................................................................................................................15
4.7 Multi-Session Operation...........................................................................................................16
5. Examples of Client Application/API Interaction........................................ 17
6. Client Application/API Interaction.............................................................. 19
6.1 How Data is Managed by the API ............................................................................................20
6.1.1 Example ...................................................................................................................................20
6.2 Determination of Strike values .................................................................................................20
6.2.1 Calculation of negative strike scaling factor.............................................................................22
7. System Failure Handling............................................................................. 23
7.1 Trading Host and Gateway Failures ........................................................................................24
7.1.1 Trading Host Failure.................................................................................................................24
7.1.2 Trading Host Back-up (Service Resumed) ..............................................................................24
8. All API Functions......................................................................................... 25
9. Market Access ............................................................................................. 26
9.1 API Version (LiffeAccessAPIVersion) ......................................................................................26
9.2 Handover to Replacement Trader (LiffeAccessHandover/OnAccessResponse) ....................26
9.3 Logoff (LiffeAccessLogoff/OnAccessResponse) .....................................................................26
9.4 Logon (LiffeAccessLogon) .......................................................................................................26
9.5 Nominate Replacement Trader (LiffeAccessNominate/OnAccessResponse).........................27
9.6 Initialise API (LiffeAPIInit).........................................................................................................27
9.7 Poll API (LiffeAPIPoll) ..............................................................................................................27
9.8 Shutdown API (LiffeAPIShutDown)..........................................................................................28
9.9 Order Transfer Warning (OnAccessTransfer)..........................................................................28

API Functional Descriptions Issued Version 1.3 Page 3 of 79

 Table of Contents

9.10 System Error (OnAccessResponse) ........................................................................................28

10. Data............................................................................................................... 29
10.1 Exchange Data (LiffeDataExchanges/OnDataExchanges) .....................................................29
10.2 Contract Data (LiffeDataContractInfo/OnDataContractInfo) ....................................................29
10.3 Contract Month Data (LiffeDataContractMonths/OnDataContractMonths) .............................30
10.4 Market Data (LiffeDataMarkets/OnDataMarkets) ....................................................................31
10.5 Strategy Data (LiffeDataStrategies/OnDataStrategies) ...........................................................32
10.6 Contract Notification (OnDataCNotification) ............................................................................32
10.7 Strategy Notification (OnDataSNotification).............................................................................33
10.8 Create Market (LiffeDataCreateMarket/OnDataCreate) ..........................................................33
10.9 Settlement Price Information (OnDataSettlement) ..................................................................33
11. Market Information ...................................................................................... 34
11.1 Subscribe to Market (LiffeMarketSubscribe/OnMarketResponse) ..........................................34
11.1.1 Call Life-Cycle ..........................................................................................................................35
11.2 Unsubscribe from Market (LiffeMarketUnsubscribe/OnMarketResponse) ..............................36
11.3 Get Market Depth (LiffeMarketDepth/OnMarketDepth) ...........................................................36
11.3.1 Tracking Market Depth.............................................................................................................36
11.4 Retrieve Orders (LiffeMarketRetrieveOrders/OnMarketRetrieve) ...........................................36
11.5 Retrieve Ex-Pit Trades (LiffeMarketRetrieveExPitTrades/OnMarketRetrieveExPitTrades) ....37
11.6 FLEX® Retrieve Orders (LiffeMarketRetrieveFlexTrades/OnMarketRetrieveFlexTrades)......37
11.7 Order Book Update (OnMarketOrder)......................................................................................37
11.7.1 Trade Message Sequences .....................................................................................................37
11.8 Publish Market Information (OnMarketUpdate) .......................................................................38
11.9 Publish Implied Market Information (OnMarketImpliedUpdate)...............................................38
11.9.1 Implying Out Outright Market Prices ........................................................................................39
11.9.2 Implying In Strategy Market Prices ..........................................................................................40
11.10 Publish Strategy Market Information (OnMarketStrategyUpdate) ...........................................40
12. Trading and Order Handling ....................................................................... 41
12.1 Submit Orders (LiffeTradeSubmitOrders/OnTradeSubmit) .....................................................43
12.1.1 Open Close Indicators..............................................................................................................43
12.1.2 Order Types .............................................................................................................................44
12.1.3 Order Modifiers ........................................................................................................................46
12.1.4 Order Acceptance Rules ..........................................................................................................47
12.1.5 Batch Order Validation .............................................................................................................47
12.2 Pull Orders (LiffeTradePullOrders/OnTradePull) .....................................................................48
12.2.1 Call Life-Cycle ..........................................................................................................................48
12.3 Revise Orders (LiffeTradeReviseOrders/OnTradeRevise) ......................................................48
12.3.1 Multiple Order Validation..........................................................................................................49
12.3.2 Call Life-Cycle ..........................................................................................................................49
12.4 Submit RFQ (LiffeTradeSubmitRFQ/OnTradeSubmit) ............................................................50
12.5 Submit RFQX (LiffeTradeSubmitRFQX/OnTradeSubmit) .......................................................50
12.6 Submit Ex-Pit Trade (LiffeTradeSubmitExPitTrade/OnTradeExPitTrade)...............................50
12.6.1 Trades Manually Validated by Market Control.........................................................................51
12.6.2 Automatically Validated Trades ...............................................................................................52
12.7 Submit Contingent Multiple Orders (LiffeTradeSubmitContingentOrder) ................................54
12.8 Submit FLEX® Orders (LiffeTradeSubmitFlexTrade/OnTradeFlexTrade) ..............................55
12.9 Submit Market Making Orders
(LiffeTradeSubmitMarketMakingOrders/OnTradeMarketMakingOrdersSubmit) .....................55
12.10 Receive RFQ (OnTradeRFQ) ..................................................................................................56
12.11 Order Trade Notice (OnTrade).................................................................................................56
12.12 Strategy Trade Notice (OnTradeStrategy) ...............................................................................56
12.13 Retrieve Fills (LiffeTradeRetrieveFills/OnTradeFill/OnTradeFillStrategy) ...............................57
12.14 Set Delta Protection (LiffeTradeSetDeltaProtection/OnTradeSetDeltaProtectionStatus) .......57
12.15 Adjust Delta Position (LiffeTradeAdjustDeltaPosition/OnTradeDeltaPositionUpdate) ............57

API Functional Descriptions Issued Version 1.3 Page 4 of 79

 Table of Contents

12.16 Get Delta Protection Data (LiffeTradeGetDeltaProtection/OnTradeGetDeltaProtectionStatus)

.................................................................................................................................................58
12.17 Send Stock Order Request (LiffeTradeRouteStockOrderRequest/
OnTradeRouteStockOrderRequest) ........................................................................................58
12.18 Send Stock Order Fill or Status (LiffeTradeRouteStockOrderData/
OnTradeRouteStockOrderData) ..............................................................................................58
13. ITM Monitoring............................................................................................. 59
13.1 Subscribe to Monitor ITMs (LiffeMonitorSubscribe/OnMonitorSubscribe)...............................59
13.2 Unsubscribe from Monitoring (LiffeMonitorUnsubscribe/OnMonitorUnsubscribe)...................59
13.3 Receive Notifications of Monitored ITM Order Books (OnMonitorOrderBookDetails).............60
13.4 Order Submitted by Monitored ITM (OnMonitorOrderSubmitted)............................................60
13.5 Logoff or Lock Monitored ITM (LiffeMonitorLogoffUser/OnMonitorLogoffStatus)....................60
14. Market Control ............................................................................................. 61
14.1 Session Mode Message (OnControlSMode) ...........................................................................61
14.2 Market Mode Message (OnControlMode)................................................................................61
14.2.1 Market Pre-Open......................................................................................................................62
14.2.2 Market Enabled and Disabled (Suspended) ............................................................................62
14.2.3 Market Open, Pre-Close & Close.............................................................................................63
14.2.4 Submission of trades outside market hours.............................................................................63
14.2.5 Activate/Suspend Price Limits .................................................................................................63
14.2.6 Quote Spread Multiplier ...........................................................................................................64
14.2.7 Trading Halt On/Off ..................................................................................................................64
14.3 Forced Logout (OnControlLogout) ...........................................................................................65
14.4 Trader Exchange Suspension (TraderExchangeSuspend) .....................................................65
14.5 Message (OnControlMessage) ................................................................................................65
14.6 Contract Status (OnControlStatus) ..........................................................................................65
14.7 Invalid Operation (OnControlInvalidOperation)........................................................................65
15. Order Handling Examples........................................................................... 66
15.1 General Principles....................................................................................................................66
15.1.1 A Simple Matching Trade.........................................................................................................66
15.1.2 A Partially Filled Order .............................................................................................................67
15.1.3 Trading against an Implied Outright Market Price ...................................................................69
15.1.4 Trading against an Implied Strategy Market Price...................................................................70
15.1.5 Market On Open Orders at Market Opening............................................................................72
15.1.6 ITM Monitoring - Viewing Order Book Details..........................................................................74
15.1.7 ITM Monitoring - MTM / ITM Interaction...................................................................................76
15.1.8 Stop Order activation, the converted Stop order then rests in the market...............................77
15.1.9 Stop order activation, the converted Stop order then trades ...................................................78
15.1.10 Stop order activation, the converted Stop order is then pulled................................................79

API Functional Descriptions Issued Version 1.3 Page 5 of 79

1. Introduction to LIFFE CONNECT®

This section provides an overview of the LIFFE CONNECT® system. It includes a brief
summary of the API functions and the Security Keys required to access LIFFE
CONNECT®.

1.1 Overview

LIFFE CONNECT® is a screen-based electronic system for trading a variety of

exchange-based futures and options contracts. The heart of LIFFE CONNECT® is the
Trading Host, which receives all orders to perform order matching, trade reporting and
price dissemination. In order to participate in the market, members will require a Client
Application that links to the Trading Host.

Some members develop their own bespoke Client Applications, which may be free-
standing or integrated into their existing trading or order routing systems. Other members
choose to implement a system developed by a third-party software vendor. In either case,
the API software must be used by all Client Applications to communicate with the Trading
Host. It provides a standard set of calls and responses, see All API Functions.

Note: Euronext.liffe do not supply a LIFFE CONNECT® Client Application.

The API resides on the Client Application workstation and communicates with the Trading
Host via the distribution network as shown below:

Trading
Host

Distribution Network

Central
Gateway
Member's Network

API
API
API
API Member Member
Gateway Gateway
Client
Application
API API

Client Client
Application Application

1.1.1 Operational Platforms

The API is written using the C programming language. In order to provide flexibility,
versions of the API are available for the following operating systems:

• Microsoft™ Windows 2000, Microsoft™ Windows Server 2003, Microsoft™ Windows

XP, utilising Microsoft Visual C++ Compiler version 7.1

• Sun Solaris™ 8 for Unix, 2.9 Forte C++ 5.5 Compiler.

API Functional Descriptions Issued Version 1.3 Page 6 of 79

 • Linux RedHat Advanced Server 3.0, Kernel – 2.4.21 – 27, Compiler – g++ version
3.2.

Note: For further information on installing the API software, see the API Installation
Notes.

1.2 Summary of Functions Provided Through the API

The following functions are available to a member's Client Application through the API:

Market Access These functions are used for establishing, maintaining and
managing sessions on the LIFFE CONNECT® system.

Data These functions are used for requesting standing data on the
markets, creating new markets and distributing updates of
changes to the list of available markets.

Market Information These functions are used for requesting and updating market
information during the Trading Day.

Trading and Order Handling These functions are used for trading, order handling, Request For
Quotes (RFQs), Ex-Pit and FLEX® Trades.

ITM Monitoring These functions are used by a designated Master Trader

Mnemonic (MTM) in a member firm to monitor and interact with
allocated traders orders as well as the connectivity of Individual
Trader Mnemonics (ITMs).

Market Control These functions are used for receiving market control warnings
and messages during system operation.

API Functional Descriptions Issued Version 1.3 Page 7 of 79

2. Security Keys

Security keys are required in order to access LIFFE CONNECT®, both for test and live
environments.

Note: Please contact your local Exchange for live Security Keys.

2.1 Requesting Security Keys

Individual traders using LIFFE CONNECT® have an encryption key that is used to prove
their identity to the Security Server.

Note: In order to obtain these security keys for access to the LIFFE CONNECT® live
environment, contact your Account Manager for your local Exchange.

In order to obtain security keys for access to the LIFFE CONNECT® simulated
(test) environment, contact the Conformance Testing Helpdesk for your local
Exchange.

Security keys are set up with access to all of the LIFFE CONNECT® environments and
are forwarded to the Member site by email. The email contains a number of security keys
and the associated Security Server and Certifying Authority key-files.

2.2 Security Keys Setup

The trader keys, the associated Security Server and Certifying Authority key-files reside in
the member’s key file. These keys have .pem extensions. The name of the file is derived
from the trader’s mnemonic, for example, trader ABC will have a key-file named
ABC.pem.

Each key-file is locked with the trader’s password, which will be distributed with the trader
key. Every trader must have their own key-file which must be visible on every machine
used to logon to the Trading Host. In addition, each trader must also be able to see the
Security Server’s key-file (server.pem) and the Certifying Authority’s key-file
(cacert.pem).

Once the Security keys have been received, a folder or directory needs to be created on
the PC or Unix workstation used to access the environment, and the keys copied into this
area. The API will allow trader keys to be specified in known sub-directories under the
current key-directory specified by the LSAPI_KEYDIR environment variable.

Note: Live keys and Testing keys cannot be kept in the same folder or directory. New
replacement keys that have different expiry dates should also be kept in a
separate directory with the associated new versions of the server.pem and
cacert.pem key-files.

API Functional Descriptions Issued Version 1.3 Page 8 of 79

2.3 Setting System Environment Variables

Create a directory and set the environment variable on your machine as follows:

1. Create a local directory, eg. C:\KEYS\ for Windows compliant machines and
/usr/local/KEYS/ for Unix machines.

2. If multiple directories are required, there is a strict naming convention for the
subdirectory. It must be called keys1. The validation process only recognises
correctly named subdirectories. All subsequent subdirectories must follow in order,
e.g. keys2 and keys3.

3. Set the following system environment variable:

LSAPI_KEYDIR

4. Set the environment variables value to the key location, i.e. C:\KEYS\ or
/usr/local/KEYS/

Note: If this variable is not set, the API will not be able to locate the keys.

API Functional Descriptions Issued Version 1.3 Page 9 of 79

3. API Concepts and Examples

This section provides an overview of the fundamental concepts that must be understood
by developers using the LIFFE CONNECT® API.

3.1 Types of API Call Client Applications Can Make

Client Applications communicate with the Trading Host through the API using a set of pre-
defined calls and responses. Each of the pre-defined calls is classified as either blocking
or non-blocking.

Each time an API function call is made, the API copies the structures passed to it in the
function call. It is up to the calling application to release any memory allocated to the
structures once the function call has returned.

3.1.1 Blocking Calls

Blocking calls are synchronous. The API sends the request to the Trading Host and waits
for the response before returning control to the Client Application.

3.1.2 Non-Blocking Calls

Most API calls are asynchronous, i.e. they do not block execution of the Client Application
while the API is waiting for the response from the Trading Host. The API is therefore able
to accept several calls without waiting for the response to the first one.

Non-blocking calls provide the Client Application with two types of response:

Immediate Return Values This return value is the result of the API software checking the calling parameter
values and checking the call has been successfully submitted to the Trading
Host.
The parameter values are checked against some basic rules (e.g. is a value
within a valid range). If the calling values are invalid, the function returns an error
code and the API ignores the request. If the call is valid, it is submitted to the
Trading Host.
Once the API has provided the immediate return value, control is passed back to
the Client Application, without waiting for a response from the Trading Host.

Trading Host Responses On receipt of the response from the Trading Host, the API passes this on by
calling the appropriate function within the Client Application. These functions are
called Response Handler Functions (see Asynchronous Response Handling).

The use of non-blocking calls allows a Client Application to execute several identical calls
in succession without waiting for a response from the Trading Host.

A tag value may be given to each call, which is then included in the response from the
Trading Host. If required, the Client Application can then relate the responses to the
originating calls using the tag. This is particularly necessary, as responses do not
necessarily come back in the same order as they were submitted.

API Functional Descriptions Issued Version 1.3 Page 10 of 79

 Note: The tag value '-1' should not be used as it is used for messages from the Trading
Host where no tag value is applicable.

3.2 Asynchronous Response Handling

Asynchronous responses will be received from the API as a result of the following:

• The Trading Host responding to a non-blocking call (see Types of API Call Client
Applications Can Make).

• A market control message being sent out from the Trading Host.

• Other, unsolicited messages being sent out from the Trading Host, e.g. settlement
prices.

On receipt, the API will pass these responses on by calling the appropriate function
(Response Handler Function) within the Client Application.

The API needs to know which Response Handler Function to call for each type of Trading
Host response. So, when it initialises the API, the Client Application must declare all of its
Response Handler Functions (see Initialise API).

A list of the required Response Handler Functions is provided in

LiffeResponseHandlerList (see All API Functions).

Each time a Response Handler Function is called by the API, it is passed pointers to
variables in memory. This memory is de-allocated (deleted) when the Response Handler
Function returns control to the API. The Client Application must therefore make a copy of
all variable data that needs to be retained.

When the Client Application requests a large list of information, the API returns the data in
a series of small sets. Instead of calling the Response Handler Function once with the
entire list, the API repeats the call providing the Response Handler Function with a
manageable part of the list each time. The Response Handler Function is also passed a
Continuation Flag to indicate that more of the list is to follow. The calls are repeated until
the Client Application has been given the entire list. The network architecture ensures that
the full list is passed to the API, and that the list is maintained in the same order as it was
issued from the Trading Host.

3.3 Different Threading Modes

During initialisation (see Initialise API), the API can be set to operate in one of two
different modes, Single-threaded Mode or Multi-threaded Mode. Multi-threaded Mode
is the recommended working mode to achieve optimal performance through the API.

In Single-threaded Mode, the application retrieves queued responses by polling an API

function, which in-turn invokes the correct Response Handler Function (see Poll API). If
the number of queued responses exceeds a pre-set limit, the API triggers Client
Application failure status (see System Error). Therefore, the Client Application must aim
to invoke the poll function at an adequate frequency.

In Multi-threaded Mode, each group of response functions has an execution thread in

which to invoke its Response Handler Function (see Summary Of Functions Provided
Through the API). The Client Application should also aim to return from the Response
Handler Function promptly, to free the thread for another possible message.

API Functional Descriptions Issued Version 1.3 Page 11 of 79

3.3.1 Example

The use of Response Handler Functions in Multi-threaded Mode is shown in the following
sequence of events:

1. The main code in the Client Application is running when a response arrives from the
Trading Host, the API identifies that response group, and assigns a thread to execute
the response.

2. The API identifies the response type and selects the appropriate Response Handler
Function to call.

3. The call is made and the Client Application's Response Handler Function processes
the response.

4. When the Response Handler Function is finished, control of the thread passes back
to the API.

5. The API then releases the thread for use in the next response.

Note: All API calls are designed to be completely thread-safe. It is also recommended
that Client Application Response Handler Functions are thread-safe.

API Functional Descriptions Issued Version 1.3 Page 12 of 79

4. The Trading Day

The Trading Day is the period when the LIFFE CONNECT® market is accessible by
traders and is separated into a number of periods in the following order:

• Day Start

• Pre-Open

• Open

• Pre-Close

• Close

• Day End.

Note: The following diagram is generic. Please refer to your local Exchange for specific
details of your Trading Day.

Outside Trading Day

API intialisation followed by
standing data requests permitted
Day Start Session 1
Day Start Logon and subscribe to
(n) minutes market permitted
Market Enabled
Pre-Open Order submission permitted
(n) minutes but no trades take place
Open
Uncrossing

Trading, order handling and settlement

Trading Day

Optional
Session 2

Trading, order handling and settlement

Pre-
Close
Closed
Close Issue closing prices

Day End
Day End All sessions are logged out
(n) minutes

Host Inaccessible
Time

API Functional Descriptions Issued Version 1.3 Page 13 of 79

4.1 Day Start

Prior to the start of the trading day, a Client Application can initialise the API. It can also
request standing data for all of the contracts that are available for trading (see Data). The
Trading Host sends Session Mode messages to all Client Applications that have
initialised to notify them of the start of the trading day (see Session Mode Message).

Once the day start message has been received, trader logon is enabled (see Logon).
Once logged on, a trader can then subscribe to (i.e. register an interest in) any products
that are available for trading. LIFFE CONNECT® supports trading and view-only
subscription rights. A trader must have subscription rights in order to subscribe to a
particular market (see Subscribe to Market).

No orders can be submitted during Day Start as the order book will not be active.
However Good Till Cancelled (GTC) orders that have been retained by the Trading Host
from the previous trading day are returned to the market and can be revised or pulled.

4.2 Pre-Open

At the start of Pre-Open, the Trading Host sends a market mode message to all the
participants who have subscribed to a market indicating that Pre-Open has started. The
trading times for each product are specified in the product specification and set in
standing data.

During Pre-Open, the Client Application can use the functions provided by the API,
including those used to submit, revise, pull orders and create strategies.

Traders may only enter the following order types into the market for both outrights and
strategies during this period (see Order Types):

• Market On Open orders

• Limit orders (including Good Till Cancelled and Good in Session orders but excluding
orders with IC, MV or CV permitted modifiers).

'Market On Open' orders are only valid during Pre-Open. Other order types may only be
submitted once the Open period commences. Order matching will not take place during
Pre-Open. This only occurs in the Open state.

Some ex-pit trade types can be submitted outside market open hours where this is
enabled for a contract. Contact your parent Exchange.

As the Trading Host receives orders, changes to the best buy/sell prices and volumes,
and to any other orders in the central order book, are transmitted to subscribed traders
when they occur. In addition, indicative opening prices and volumes are calculated for
each outright futures and options market and are transmitted to subscribed traders at
regular intervals. These intervals can be configured on the Trading Host for each
individual market.

During Pre-Open, price limits can be configured to be active or inactive on a per contract
basis.

API Functional Descriptions Issued Version 1.3 Page 14 of 79

4.3 Open

This is the main trading state. The time of opening may be configured separately for each
product.

At the start of Open for each product, there may be backwardation or choice markets in
some markets, in other words bids higher than or equal to offers. When this occurs the
Trading Host runs an uncrossing algorithm to calculate the price at which the maximum
volume will be traded and automatically execute those trades at the price calculated. Any
orders that are executed using this approach will be traded at a price equal to or better
than that at which they were entered. Market On Open orders are processed immediately
after uncrossing.

During the Open period, the Client Application may use any of the API functions including
the following:

• Submission, revision and pulling of orders

• Receipt of settlement prices

• Ex-Pit orders

• Strategy creation and trading.

The Open state can be divided into sessions (see Multi-Session Operation).

4.4 Pre-Close

Shortly before the close of trading in a product, the Trading Host sends a market mode
message to all participants who have subscribed to a market indicating that Pre-Close
has started. This message is issued (n) minutes before the end of the trading session for
each product. This message is designed to warn members that the market is about to
close.

During Pre-Close, the Client Application can use any of the functions provided by the API
that are available during Open, including those used to submit, revise, pull orders and
create strategies.

4.5 Close

Once the Market Close period has commenced, all trading ceases and no further orders
are accepted until the next Pre-Open. At the beginning of the Market Close, all orders,
with the exception of GTC orders, are automatically deleted.

Closing prices are usually published during this period.

Some ex-pit trade types can be submitted outside market open hours where this is
enabled for a contract. Contact you parent Exchange.

4.6 Day End

Day End is the event that follows Close. At Day End, all GTC orders are removed from
the market and stored by the Trading Host until the next trading day.

API Functional Descriptions Issued Version 1.3 Page 15 of 79

 At the end of the Day End period, the Trading Host will issue a ‘Session End’ message
and automatically log out all market participants.

4.7 Multi-Session Operation

LIFFE CONNECT® provides functionality to segment a single trading day into multiple
sessions. It is possible to configure LIFFE CONNECT® to run two or more sessions
during a single trading day. For example, it is possible to configure LIFFE CONNECT® to
run a session in the morning and afternoon, and a session in the evening. The business
transacted on LIFFE CONNECT® during the morning and afternoon session can be
considered today’s clearing business, whilst the business transacted during the evening
session can be considered as tomorrow’s clearing business.

The start and end time of each session is configurable and there will be no interruption to
trading during the session transition i.e. the market will not close during this transition.

There is functionality to enable traders to submit an order that will automatically be pulled
by the Trading Host at each session (see Order Types for further information of Good In
Session orders). All Normal Limit orders will be valid until the close of the last session in
the trading day in which they were submitted.

There will be a market mode message sent at the time of the transition between sessions
to notify traders of the change. The market mode message can be used to imply a
change in the clearing day, for example. On expiry of a contract month, the new month
will not become available to trade until the next trading day.

The session that a trade occurred will be reported to the trader via a Session ID.

API Functional Descriptions Issued Version 1.3 Page 16 of 79

5. Examples of Client Application/API Interaction

The following table shows a simplified sequence of calls and responses passing between
a Client Application and the API. It demonstrates the start of a simple trading session,
some trading taking place and the eventual close down of the market:

STEP BRIEF DESCRIPTION

Initialise API A blocking call, the reply must be checked for success or the reason for failure.
The function returns a variable confirming the state of the Trading Session. This
occurs prior to Day Start (see The Trading Day).

Request Standing Data This is performed using non-blocking calls. The data is returned through calls to
the Client Application's Response Handler Functions. The time delay between
the request and the response depends on system activity.

Session Mode Message - A message from the Trading Host indicating that the market status has moved to
Session Start Session Start. Once this has occurred, the trader is allowed to logon to LIFFE
CONNECT®.

Trader Logon A blocking call, the reply status is either success or failure, with an indication of
the reason for failure.

Subscribe to Market A non-blocking call. The call registers an interest in a particular commodity and
returns an acknowledgement later through a Response Handler Function. The
Client Application also receives an asynchronous Market Mode Message
response that confirms the state of that market. In this example this occurs prior
to Pre-Open (see The Trading Day).

Market Mode Message - A message from the Trading Host to indicate that the market status has moved to
Market Pre-Open Pre-Open. During Pre-Open the Trading Host will publish full market depth to all
subscribed Client Applications (see Get Market Depth).
At this time market participants can submit orders. However, orders will not trade
until the market is open. The Client Application subsequently receives details of
changes to the best buy and sell prices and volumes in the market, updates on
any orders submitted into the market (see Order Book Update) and indicative
opening prices and volumes for outright futures and options markets, based on
the orders that are received by the Trading Host in this period.

Market Mode Message - The Client Application is notified when the subscribed commodity market opens.
Market Open for Trading Orders will now be traded within the order book.

Note: Markets can open at different times for different commodities.

Submit Orders The Client Application can submit orders at any time between Pre-Open and
Market Close. An acknowledgement is sent, via a Response Handler Function
after a time interval. Whenever a trade takes place in the order book, updated
data is returned through other Response Handler Functions. This activity is
shown as Notice of Change in the diagram in Client Application/API Interaction.
These functions include Order Book Update for updates to any market that the
Client Application is subscribed to, and Order Trade Notice or Strategy Trade
Notice, for trade activity on orders, for outrights or strategies respectively, that
have been submitted by the Client Application.

Pull Orders The Client Application can cancel any unmatched portions of orders that have
previously been submitted. An acknowledgement is sent, via a Response
Handler Function.

API Functional Descriptions Issued Version 1.3 Page 17 of 79

 Market Mode Message - This message is sent shortly before the market closes for each subscribed
Market Pre-Close market.

Market Mode Message - The closing time for the subscribed market. This can be when the main market
Market Close closes.

Settlement Prices The Client Application is notified of the settlement prices for the subscribed
commodity.

Note: For some commodities, settlement prices are available before the
market closes, and these are transmitted to subscribed Client
Applications as soon as they are available.

Session Mode Message - Following Session End, all sessions are logged out, and the API/Trading Host
Session End connection is shutdown.

API Functional Descriptions Issued Version 1.3 Page 18 of 79

6. Client Application/API Interaction

The sequence of events is illustrated in the following diagram which shows a simplified
view of the API/Client Application interactions using only one subscribed contract.
Typically a trader would be subscribed to several contracts at the same time.

Note: Client Application Response Handler Functions must be designed to cope with
several, irregular, incoming data streams.

1. Initialise API

Reply Status : Success

Blocking Call
Session Closed State

2. Request Standing Data Blocking Call response

RHF* Standing Data Non-Blocking Call

3. Session Mode Message: Non-Blocking Call

RHF
Session Start immediate response

Asynchronous
4. Request Trader Logon
response

Reply Status : Success API calls appropriate

RHF Response Handler
Function
5. Subscribe to Market for
Commodity A
API repeatedly calls
RHF* appropriate Response
RHF Commodity A Acknowledge
Handler Function as
list is passed to Client
Market Mode Message for A : App
RHF
Market Closed
Client Application

6. Market Mode Message

RHF
for A : Market Pre-Open

RHF Update Data for Commodity A API Time

7. Market Mode Message

RHF
for A : Market Open

8. Submit Order for

Commodity A

RHF Acknowledge Order

RHF Notice of Change

RHF Notice of Change

9. Pull Orders

RHF Acknowledgement of Pull

10. Market Mode Message :

RHF
Market Pre-Close

11. Market Mode Message :

RHF
Market Close

RHF 12. Settlement Prices

13. Session Mode Message:

RHF
Session End

API Functional Descriptions Issued Version 1.3 Page 19 of 79

6.1 How Data is Managed by the API

The LIFFE CONNECT® API is provided with a header file that describes data types and
structures that must be used to make API calls and to interpret API responses. Client
Applications must use this header file.

Note: The API Reference provides a list of all the data types that have been defined,
including the data labels assigned for enumeration values and data structures.
The Variable Definitions Table provides a detailed alphabetical list of all the
variables used and their definitions.

The Automated Market Reference (AMR) data type is defined in Type Defined Arrays.
AMRs are used to uniquely identify each possible outright and strategy market. Each
AMR is a 15-byte array. All the bytes must be compared to ensure correct recognition.
The calls used by Client Applications to request outright and strategy information for
specific contracts, which will include the AMR values, are defined in Market Data.

The price of a contract can be expressed in terms of a number of points (larger part) and
ticks (smaller part). LIFFE CONNECT® however handles prices in ticks only. Price
information about an order must be converted from points and ticks into a total number of
ticks before being sent to the Trading Host via the API. Likewise, the price information
returned by the API will be in ticks.

Variable tick sizes allow expiry months, within the same contract, to accept and trade
orders at different tick sizes.

The number of ticks in a point, is given by the Tick Size Denominator. The minimum price
movement for a contract, in ticks, is given by the Tick Size Numerator. When requesting
Standing Data for a commodity, the API will provide the tick size denominator and
numerator values as part of the information returned.

6.1.1 Example

For a contract with a Tick Size Denominator of 1000 and a Tick Size Numerator of 5,
prices would take the form 97.270, 97.275, 97.280, 97.285, etc.

When converting a price from points and ticks to ticks only, multiply the number of points
by the Tick Size Denominator. For example, a price quote of 97.275 should be sent to the
Trading Host as 97275 ticks, i.e. (97.275 x 1000). If the Tick Size Denominator was 200
then a price of 97.275 would be converted to 19455 (97.275*200).

Note: The tick size denominator calculation is not to be applied to Exercise Prices for
Financials and Strikes for Equities.

6.2 Determination of Strike values

Strikes distributed over the LIFFE CONNECT® API are distributed as a numeric value,
listing the strike which is to be displayed. Prices in the underlying markets however are
distributed as ticks and require translation into the correct display format.

When relating a strike to its underlying value of an option to its strike there are a number
of components which need to be considered:

• Underlying numerator distributed within OnDataContractMonth

API Functional Descriptions Issued Version 1.3 Page 20 of 79

 Minimum tick movement of the underlying contract

• Underlying denominator distributed within OnDataContractInfo

Determines the number of ticks in a point

• Strike value distributed in OnDataMarkets

Exercise price of an option series

• Strike Scaling factor distributed within OnDataContractInfo

Parameter used to determine how exercise price are converted into the actual
underlying price

• Number order is generated from the underlying denominator

- For a denominator of 0 – 1 = 1

- For a denominator of 2 – 10 = 10

- For a denominator of 11 – 100 = 100

- For a denominator of 101 – 1000 = 1000

- For a denominator of 1001 – 10000 = 10000

Calculation:

The underlying value of a strike is determined by applying the following calculation:

Underlying value of strike = Strike value * Strike Scaling factor / Number order

Example - LIFFE contract, Short Sterling

Strike value = 091500

Underlying Denominator = 1000
Underlying Numerator = 5
Number order = 1000
Strike Scaling Factor = 1

Therefore a strike of 91500 will have an underlying value of:

091500 * 1 / 1000 = 91.500

Example – LIFFE contract, FTSE 100

Strike value = 004025

Underlying Denominator = 10
Underlying Numerator = 5
Number order = 10
Strike Scaling Factor = 10

Therefore a strike of 004025 will have an underlying value of:

004025 * 10 / 10 = 4025

API Functional Descriptions Issued Version 1.3 Page 21 of 79

 Example – CBOT contract

Strike value = 010725

Underlying Denominator = 32
Number order = 100
Strike scaling factor = 1

Underlying value of strike = 010725 * 1 / 100

= 107.25

6.2.1 Calculation of negative strike scaling factor

The underlying value of a strike, when a negative strike scaling factor is used, is
determined by dividing the Strike Scaling factor, rather than multiplying:

Underlying value of strike = Strike value / Strike Scaling factor / Number order

Example – CBOT Contract

Strike value = 15500

Underlying Denominator = 1
Number order = 1
Strike Scaling Factor = -10

Underlying value of strike = 15500 / 10 / 1

= 1550

API Functional Descriptions Issued Version 1.3 Page 22 of 79

7. System Failure Handling

In the event of a Client Application failure, all non-GTC Orders (except Ex-Pit Trade
Orders) are transferred to a nominated replacement trader, if the following two conditions
apply:

• A replacement trader has been nominated by the trader whose session failed (see
Nominate Replacement Trader).

• The replacement trader has a current trading session.

If this is not possible, these orders will be withdrawn from the market, (see Order Types).

On reconnection during the same Trading Day, a trader may request details of any orders
that were withdrawn at the point of failure (see Retrieve Orders). These orders may be re-
submitted at the trader's discretion, and then treated as new orders by the Trading Host
and processed accordingly.

The diagram illustrates the sequence of events that would typically be followed during
recovery from a Client Application failure:

Client Application recovered

from failure

Initialise API Blocking Call

Reply Status : Success Blocking Call response

Session Mode Message:

RHF Non-Blocking Call
Session Started
Client Application

Non-Blocking Call
Request Trader Logon
immediate response
API Time
Asynchronous
Reply Status : Success
response

View Order. Request details API calls appropriate

of withdrawn orders RHF* Response Handler
Function
Details returned of all
RHF*
withdrawn orders API repeatedly calls
appropriate Response
Submit Order. Resubmit one RHF Handler Function as
of the withdrawn orders list is passed to Client
Acknowledgement of 'new' App
RHF
order

In the event of a communications failure between the Trading Host and the API, the
Trading Host will start the failure procedure outlined above for all the affected Client
Applications. Once the communication failure has been resolved, recovery is the same as
for a Client Application failure.

In the event of failure of the Trading Host, the Client Application will receive a control
status message (see OnControlStatus), and all non-GTC Orders are cancelled. The client

API Functional Descriptions Issued Version 1.3 Page 23 of 79

 application will then receive a system error call (see System Error) and the connection is
lost.

When the Trading Host is restarted and the market re-opens, the central order book will
only contain the GTC orders submitted prior to the failure. It will not be possible to obtain
details of any other orders that were in the central order book prior to the failure.

After a Trading Host failure, the re-opening of the market is communicated to all potential
market participants through a Session Start message (see Session Mode Message).

There is a separate post-failure Session Start period, followed by a post-failure Pre-Open

period for all contracts, after which all contracts are available for trading once again. If a
particular contract is not due to enter its normal Pre-Open period when the post-failure
Pre-Open period is beginning, it will not enter Pre-Open until its normal time.

7.1 Trading Host and Gateway Failures

This section describes the user interaction as a result of either a Trading Host or Gateway
failure:

7.1.1 Trading Host Failure

Users will receive an OnControlStatus message with the ‘Available’ flag set to FALSE, for
every contract, to indicate that the contracts are unavailable for trading.

All orders will be pulled. All non-GTC orders are rejected. However, it is the responsibility
of the user to ensure that their local order book has been cleared.

7.1.2 Trading Host Back-up (Service Resumed)

Users will receive an OnControlStatus message, set with the ‘Available’ flag set to TRUE,
for every contract, to indicate that the contracts are available for trading. Users can re-
subscribe to the contracts at this point and request LiffeDataStrategies to update the
Strategy market data.

The user needs to confirm the status of their GTC orders, using the RetrieveOrder call on
whether the GTC orders remain in the market. This is to update the status of the GTC
orders as it could have traded at the time of the failure.

Markets will then go into Pre-open and Open.

API Functional Descriptions Issued Version 1.3 Page 24 of 79

8. All API Functions

This section provides a description of all the API functions available to Client Applications.
The following information is provided for each function:

• The function's title.

This is a text description of the function's use, and not the actual function name that
should be used (e.g. Initialise API, as opposed to LiffeAPIInit).

• A description.
Describes when and how the function is used.

• Additional information.
Provides particular business rules that should be understood when the function is
used.

Note: The API Reference provides more detailed information for developers on the
coding syntax that must be followed to use each API function.

Throughout this section references are made to the LIFFE CONNECT® Gateway. The
API uses the LIFFE CONNECT® Gateway to access the distribution network and
communicate with the Trading Host. Multiple instances of the API may link to the Trading
Host through the same LIFFE CONNECT® Gateway. The Gateways, which in many
cases will reside on member sites, will typically remain the Exchange’s property.

API Functional Descriptions Issued Version 1.3 Page 25 of 79

9. Market Access

The API market access functions are used for establishing, maintaining and managing
sessions with the Trading Host.

9.1 API Version (LiffeAccessAPIVersion)

This returns the version number of the LiffeAPI.

Note: Always use the correct version of the API, or the Client Application will be unable
to communicate with the Trading Host.

9.2 Handover to Replacement Trader

(LiffeAccessHandover/OnAccessResponse)

This call hands over any non-GTC orders to the trader's previously nominated
replacement. The trader will be logged off. Any orders transferred in this manner will
retain their original time-stamp. If the Client Application has not nominated a replacement,
or the nominated replacement trader is not logged on, the Trading Host will return a
corresponding status, the trader's non-GTC orders will be pulled and the trader will be
logged off.

Note: See to Order Types.

9.3 Logoff (LiffeAccessLogoff/OnAccessResponse)

This call closes the trader's session on the Trading Host and pulls all orders except those
which have been either successfully handed over to a replacement trader or have been
entered as GTCs.

9.4 Logon (LiffeAccessLogon)

This call establishes a session on the Trading Host for the trader. The call requires a
trader mnemonic and the corresponding trader password. The logon call returns the
trader's privilege level.

Some traders may have only a View privilege, where they may request information only,
specifically, they can use any API call with the exception of:

• Those related to Trading and Order Handling.

• The call to Retrieve Orders.

Logon attempts are refused while the Trading session is closed or while Market Control
deny logon to specific traders (see LiffeAccessLogon). An appropriate error status is
returned for each case.

In order to protect the Trading Host from multiple failed logons, the Gateway will stop
forwarding logon requests to the Trading Host after a configurable number of failed

API Functional Descriptions Issued Version 1.3 Page 26 of 79

 logins. The Gateway will continue to stop failed logons for a period of time. An appropriate
error status is returned when the maximum logon attempts has been reached. This is
counted on a per session basis, so failed logons made by one user will not affect the
ability of other users to logon.

Note: LiffeAccessLogon will return LIFFE_TOO_MANY_LOGON_ATTEMPTS if the

Gateway rejects the logon.

9.5 Nominate Replacement Trader

(LiffeAccessNominate/OnAccessResponse)

This call allows a trader to register a replacement trader. The replacement trader must:

• Be with the same member firm as the original trader.

• Have the same market trading rights (i.e. Market Maker or Broker/Proprietary trader),
if applicable.

Note: The call can also be used to cancel a nomination made previously.

All of the traders' orders, except GTCs, will be transferred to the replacement trader if the
Client Application does either of the following:

• Calls a handover (see Handover to Replacement Trader).

• Has a session failure.

9.6 Initialise API (LiffeAPIInit)

The Client Application calls this function to initialise the connection between the API and
the LIFFE CONNECT® Gateway. Its purpose is to tell the API where the Response
Handler Functions are, by passing a pointer to a structure containing a pointer to each of
the Response Handler Functions.

Note: LIFFE CONNECT® allows initialisations from before Day Start, until Day End. At
Day End, the trader session is logged out from the Trading Host and the LIFFE
CONNECT® Gateway drops the communication session.

9.7 Poll API (LiffeAPIPoll)

This synchronous call is only relevant in Single-threaded mode.

Note: If called in Multi-threaded Mode, the function will return success but have no
other effect.

The application retrieves queued responses by polling the API using this function (see
LiffeAPIPoll). This in turn, invokes the Client Application's correct Response Handler
Function for the next response on the queue. If the number of queued responses exceeds
a pre-set limit, the API triggers a Client Application failure status (see System Error).
Therefore, the Client Application must aim to invoke the Poll API function at an adequate
frequency.

API Functional Descriptions Issued Version 1.3 Page 27 of 79

9.8 Shutdown API (LiffeAPIShutDown)

The Client Application calls this function to close down the connection between the API
and the LIFFE CONNECT® Gateway, after having logged out (see LiffeAPIShutDown).
This connection should be closed prior to the Client Application terminating.

At Day End, the trader session is logged out of the Trading Host and the connection is
shut down automatically.

9.9 Order Transfer Warning (OnAccessTransfer)

This Response Handler Function is invoked when the trader receives orders transferred
from another trader. The receiving trader also receives singly linked lists of the orders that
have been transferred.

9.10 System Error (OnAccessResponse)

This Response Handler Function is invoked when the API, the LIFFE CONNECT®
Gateway or the Trading Host detects a system problem.

The Trading Host attempts to transfer all non-GTC orders to a replacement trader. If this
is not possible, all orders, with the exception of GTC orders, are withdrawn from the
market.

The LIFFE CONNECT® Gateway logs-out all Client Applications receiving the System
Error warning.

API Functional Descriptions Issued Version 1.3 Page 28 of 79

10. Data

The API provides a number of data functions, for requesting Standing Data on the
available markets, creating new markets and for the distribution of changes to the list of
available markets.

The Standing Data provides detailed definitions of all of the futures and options contracts
available for trading, including full lists of all valid contracts, and outright and strategy
markets.

The Standing Data is cached locally (on the Gateway at the member site), and is
available after the Client Application has successfully invoked an API initialisation call
(see Initialise API)

Contract details are returned in a number of separate functions, each holding data of a
different type. These functions provide a wide range of information for each contract, with
a variety of applicable fields at Exchange, Contract, Contract Month and individual market
levels.

10.1 Exchange Data (LiffeDataExchanges/OnDataExchanges)

This function is used to request a list of all valid Exchange Codes. The API returns this
information by invoking a Response Handler Function with a singly linked list of
Exchanges.

A separate Exchange Code is used for each different type of contract, such as equity and
index options, financial futures and options, commodity options, etc.

The Exchange Data call should be the first function call that a user makes when retrieving
LIFFE CONNECT® Standing Data for their Client Application, at the beginning of a new
trading session. The returned list of valid Exchanges can then be used to construct
requests for Contract Data, (see Contract Data).

10.2 Contract Data (LiffeDataContractInfo/OnDataContractInfo)

This function is used to request a list of standing data for products for a given Exchange.
The API returns this information by invoking a Response Handler Function with a singly
linked list of contracts. This function is used immediately following the retrieval of
Exchange Codes using the Exchange Data call.

The following information is returned for each contract:

• Exchange Code

• Physical Commodity Code

• Generic Contract Type

• Commodity Description

• Product Group

API Functional Descriptions Issued Version 1.3 Page 29 of 79

 • Default Lot Size

• Contract Currency

• Tick Value

• Calculation Type

• Exercise Type

• Strike Scaling Factor

• Trading Type

• Delta Protection

• Trade Tick Size Numerator

• Tick Size Denominator

The Exchange Code, Physical Commodity Code and Generic Contract Type returned for
each contract should then be used to construct requests for Contract Month and Strategy
Data for the contract, made using the Contract Month Data and Strategy Data calls.

Note: The contract data returned by this function call can also include non-tradable
products on LIFFE CONNECT®.

10.3 Contract Month Data

(LiffeDataContractMonths/OnDataContractMonths)

This function is used to request a list of all valid contract months for a given contract. The
API returns this information by invoking a Response Handler Function with a singly linked
list of Contracts Months. This function is used following the retrieval of valid Contract Data
using the Contract Data call.

The following information is returned for each contract month:

• Exchange Code

• Physical Commodity Code

• Generic Contract Type

• Expiry Date

• Expiry Month

• Delivery Month Code

• Month Position

• Spot Month Indicator

• Last Trading Date

• Trade Price Tick Size Numerator.

API Functional Descriptions Issued Version 1.3 Page 30 of 79

 The Exchange Code, Physical Commodity Code, Generic Contract Type and Expiry Date
returned for each contract month should then be used to construct requests for individual
outright market data for the Contract Month, made using the Market Data call.

10.4 Market Data (LiffeDataMarkets/OnDataMarkets)

This function is used to request a list of all valid outright markets for a given contract
month. The API returns this information by invoking a Response Handler Function with a
singly linked list of outright markets. This function is used following the retrieval of valid
Contract Month data using the Contract Month Data call.

For cash markets it returns valid markets for that contract.

The following information is returned for each outright market:

• Exchange Code

• Physical Commodity Code

• Generic Contract Type

• Expiry Date

• Exercise Price

• Contract Type

• At-the-Money Flag

• Lot Size

• Automated Market Reference

• Instrument Codes.

For Clearing Systems with their own unique and separate identifiers for financial
instrument, the mapping between the AMR and the Instrument Codes, where relevant,
will be disseminated within Standing Data.

Instrument Codes are only used for outright markets. Composite products, i.e. strategy
products that are composed of individual outright series, do not use Instrument Codes.

Notes:

• See to How Data is Managed by the API for an explanation of how Automated Market
Reference values are used.

• All Exchanges reserve the right to change an AMR at any time. Therefore, it is
recommended that the Standing Data is downloaded on a daily basis.

• Two Instrument Codes will be associated with each Instrument: Short and Long
(Instrument Code 1 and Instrument Code 2). Both fields will contain up to 20
alphanumeric characters.

API Functional Descriptions Issued Version 1.3 Page 31 of 79

10.5 Strategy Data (LiffeDataStrategies/OnDataStrategies)

This function is used to request a list of all valid strategy markets for a given Contract.
The API returns this information by invoking a Response Handler Function with a singly
linked list of strategies. This function is used following retrieval of valid Contract Data
using the Contract Data call.

The following information is returned for each strategy market:

• Strategy Market Code

• Number of Legs

• Individual Leg Details

• Automated Market Reference.

Included in this response is the Automated Market Reference value for the strategy
market. See How Data is Managed by the API for an explanation of how Automated
Market Reference values are used.

The individual leg details are returned in the form of a pointer to a singly linked list of leg
details. The following information is returned in this list for each leg:

• Exchange Code

• Physical Commodity Code

• Generic Contract Type

• Expiry Date

• Exercise Price

• Contract Type

• Buy/Sell

• Lot Ratio.

10.6 Contract Notification (OnDataCNotification)

This Response Handler Function is invoked when the LIFFE CONNECT® informs Client
Applications of any intraday changes to the valid tradable outright markets for a contract.
Only those traders who have requested outright market data for the contract in question
are notified. The Response Handler Function is passed the updated list of outright market
details for the relevant contract, which includes the Automated Market Reference value
for each outright market.

A Contract Notification will be followed by a Market Mode Message.

API Functional Descriptions Issued Version 1.3 Page 32 of 79

10.7 Strategy Notification (OnDataSNotification)

On creation of a new strategy market by a trader (see Create Market), LIFFE

CONNECT® uses this function to transmit details to Client Applications of the new active
strategy for the relevant contract. Only those traders who have requested strategy market
data for the affected contract are notified.

A Strategy Notification will be followed by a Market Mode Message.

10.8 Create Market (LiffeDataCreateMarket/OnDataCreate)

If a trader wishes to submit an order or RFQ for a strategy market that has not previously
been created, the trader must first create the market. A Create Market call, holding details
of the new strategy, should be used. LIFFE CONNECT® will then return a new
Automated Market Reference for the new strategy and notify the market. This reference
must be used for any trading or order handling related to that particular strategy.

In the case of a contingent trade strategy for options trading, the underlying component of
the strategy will be handled as one of the strategy legs.

10.9 Settlement Price Information (OnDataSettlement)

The API distributes official (final) settlement prices, as soon as they are available, for the
markets to which the Client Application is subscribed.

The following types of settlement prices can be transmitted:

• Daily prices, which are used for daily margining and settlement calculations, and may
be published before the market closes.

• Market Close prices, which are published at the end of each day’s trading on LIFFE
CONNECT®.

• Expiry prices, which are final official settlement prices for an expiring contract, and
are published as soon as a contract finishes trading on its expiry day.

• Intraday prices, which are disseminated in the same way as settlement prices. The
intraday settlements will be differentiated from daily settlements in the messages sent
via the API, at the time the prices are distributed.

• Yesterday’s prices, which were generated the previous trading day.

Settlement prices may be published at any time during either the Market Open or Day
End periods.

Note: Where relevant, Settlement prices can be set with the Publish type set to
LIFFE_PUBLISH_PROVISIONAL prior to the publication of official prices.

API Functional Descriptions Issued Version 1.3 Page 33 of 79

11. Market Information

The Trading Host makes market information available to interested market participants
throughout the Trading Day.

Aggregate volumes at best buy and sell price (either quoted or implied out), for all outright
futures and options series and explicit strategy markets, are distributed whenever a
change occurs. Volumes and traded prices for individual strategy legs are also
transmitted when strategy trades are executed.

At the start of the Pre-Open period, if there is any GTC volume standing in the market, the
Trading Host transmits full market depth, given by the aggregate volumes at all explicitly
quoted prices. Market depth can be retrieved at any time after this, until trading finishes.

Note: See The Trading Day for details of the different periods of the trading day.

As orders are received by the Trading Host in the Pre-Open period, before trading starts,
indicative opening prices and volumes are calculated for each outright futures and options
market and transmitted at regular intervals.

11.1 Subscribe to Market

(LiffeMarketSubscribe/OnMarketResponse)

Traders must subscribe to a market, using a Subscribe to Market call, before any market
information can be forwarded to them. The trader can subscribe at one of the following
market levels:

Commodity level All outrights in, or strategies with a leg in, a given commodity.

Expiry Month level All outrights in, or strategies with a leg in, a given expiry month for a given
commodity.

Market level A given outright, or a specific strategy in a given commodity (specifying

the Automated Market Reference value).

Note: Applications should subscribe at commodity level, unless specifically agreed with
their Exchange.

Subscribers will then receive market mode changes for any individual market to which
they have subscribed. In addition, the trader can subscribe independently to any of the
following optional streams of information within the above levels:

• The RFQ stream (receive RFQ calls).

• The Best Price stream (Publish Market Information, Publish Implied Market
Information and Publish Strategy Market Information calls).

• The Market Depth stream (a Market Depth update, followed by Order Book Update
calls).

• The Reference stream (receive the previous day’s settlement prices).

A trader can submit orders or RFQs to any market and receive trade confirmations on the
orders without subscribing to the market in question.

API Functional Descriptions Issued Version 1.3 Page 34 of 79

 An ITM will receive prices from the cash market if they are subscribed to that contract in
the cash market. The availability of this facility will be configurable by contract and ITM.
An ITM will receive price updates from the cash market via the OnMarketUpdate callback.

11.1.1 Call Life-Cycle

The call initially triggers several responses from LIFFE CONNECT®, some of these are
always returned, whereas others are not sent if they would not contain any information. A
Market Response acknowledgement indicates the end of the initially returned data.

Responses are given in the sequence listed below:

STREAM MESSAGE/PURPOSE CONDITIONS

1 All A single Market Response This is always returned.

acknowledgement, with its Status set to
LIFFE_STATUS_SUCCESS, which
reports whether the Trading Host accepted
the call.

2. All A Market Mode message, which reports One of these is always sent for each defined
whether each individual market is open for market covered by the subscription request.
trading or not.

3. Market Depth A Market Depth update, which provides This update will not be sent for any markets
the prices and respective aggregate that are closed, or for open markets in which
volumes in each market at the time of there are no current orders in the Trading
subscription. Host order book.

4. Best Price For outright markets, a Publish Market This will not be sent if the market has no
Information call or, for strategy markets, a current orders in the Trading Host order book
Publish Strategy Market Information call, and no volume traded in the current trading
which provides the last trade price and session.
volume, the total traded volume and the
current explicitly quoted best buy and sell
prices and volumes for the market.

5. Best Price A Publish Implied Market Information call, Only sent if an implied buy/sell price can be
which provides the best implied buy or sell calculated for the market, and it is better than
price and volume for Outright markets. or equal to the best explicitly quoted price.

6 Reference A LiffeMarketReference call provides the This is always returned if settlement prices
previous day’s settlement prices which are are available.
returned in OnDataSettlement.

7. All A single Market Response This is always returned.

acknowledgement, with its Status set to
LIFFE_MARKET_SUBSCRIBE_EOD, and
the same Tag value as the Market
Response in step 1, indicating the end of
the initially returned data.

A market information stream is subsequently provided, starting when the market enters
Pre-Open until it closes. The stream of information consists of:

• Warnings of market mode changes (open and close of market, for example).

• In the case of subscribing to the Market Depth stream, Order Book Update
information, which provides updates of the prices and aggregate volumes in the
market. Market depth information is also transmitted by the Trading Host

API Functional Descriptions Issued Version 1.3 Page 35 of 79

 automatically at the start of the Pre-Open period, for all subscribed markets in which
there is standing GTC volume at that time.

• In the case of subscribing to the Best Price stream, publish market information,
publish strategy market information and publish implied market information functions,
which provide details of traded prices and volumes, as well as changes to the best
buy and sell prices with their respective volumes.

• If subscribed to the RFQ stream, RFQ requests relevant to the market.

• The Settlement Price Information call, which can be transmitted at any time from
Open to Day End.

11.2 Unsubscribe from Market

(LiffeMarketUnsubscribe/OnMarketResponse)

This function is used to stop a stream of information for a market, to which the Client
Application has previously subscribed. It can be used to stop all streams or a single
specified stream.

An error status will be returned if the Client Application is not subscribed to the market
and stream specified in the unsubscribe request, or if the market is closed.

11.3 Get Market Depth (LiffeMarketDepth/OnMarketDepth)

This call requests all explicitly quoted prices and aggregate volumes available for buys
and sells of a specified outright or strategy market. Use of this call is monitored and
controlled, to limit degradation of service that could result from excessive use.

11.3.1 Tracking Market Depth

Client Applications should continuously track explicitly quoted market depth by updating
the initial market depth information with the order book update information provided on
subscribing to the Market Depth stream for a market. Market depth information is initially
transmitted by the Trading Host automatically at the start of the Pre-Open period, for all
subscribed markets in which there is standing GTC volume at that time.

11.4 Retrieve Orders

(LiffeMarketRetrieveOrders/OnMarketRetrieve)

Using a Retrieve Orders call, a Client Application can retrieve current details of either:

• The trader's GTC orders in the Trading Host, or

• The trader's non-GTC orders that were withdrawn at the point of a Client Application
failure (on reconnection, during the same Trading Day).

The FailureFlag parameter is set to determine which details are returned.

Note: A trader session need not be subscribed to a market to retrieve orders in that
market.

API Functional Descriptions Issued Version 1.3 Page 36 of 79

11.5 Retrieve Ex-Pit Trades
(LiffeMarketRetrieveExPitTrades/OnMarketRetrieveExPitTra
des)

This function will retrieve details of all Ex-Pit (Wholesale) Trade Orders submitted by the
trader, for a given commodity, which are awaiting Exchange authorisation.

Once Ex-Pit Trades have been authorised and executed, they will no longer be returned
by this function.

Note: A Trader session need not be subscribed to a market to retrieve Ex-Pit Trade
Orders in that market.

11.6 FLEX® Retrieve Orders

(LiffeMarketRetrieveFlexTrades/OnMarketRetrieveFlexTrad
es)

FLEX® Trades will be retrievable from the Trading Host, whilst they are awaiting
authorisation by an Exchange Official.

11.7 Order Book Update (OnMarketOrder)

A Client Application, which subscribes to the Market Depth stream receives a Market
Depth Snapshot for the market, followed by updates via the Order Book Update which
contains the price, buy or sell information and new residual volume of any change to
explicitly quoted prices/volumes in the central order book. The change may be due to a
new order submission, a withdrawal, an order revision or a trade. This enables
applications to continuously track market depth. The updates will be disseminated for all
contracts from the time that they enter Pre-Open until they close.

11.7.1 Trade Message Sequences

In the event of an outright trade in the central order book, the owners of the orders that
have traded will receive an Order Trade Notice call first before the OnMarketOrder (see
Order Trade Notice). In the event of a strategy trade, a Strategy Trade Notice call (see
Strategy Trade Notice) will be transmitted instead. Then all other traders subscribed to
the Market Depth stream of the affected market receive Order Book Update messages.
Traders subscribed to the Best Price stream of the market receive Publish Market
Information messages, and, if appropriate, Publish Implied Market Information and/or
Publish Strategy Market Information messages.

The following occurs when an order causes more than one trade, at one price:

1. An Order/Strategy Trade Notice message is sent to the owner of the new order
causing the trades.

2. The traders owning the rest of the affected orders are sent respective Order/Strategy
Trade Notice messages.

3. Order Book Update messages are sent to all traders subscribed to the Market Depth
stream, informing them of the price and volume changes resulting from all the trades.

API Functional Descriptions Issued Version 1.3 Page 37 of 79

 If an order trades at more than one price, these messages are sent for each different
traded price.

4. Publish Market Information or Publish Strategy Market Information messages are

sent to all traders subscribed to the Best Price stream. If an order trades at more than
one price, these messages are sent for each different traded price. If appropriate,
Publish Implied Market Information messages are also transmitted to all traders
subscribed to the Best Price stream.

11.8 Publish Market Information (OnMarketUpdate)

During trading, whenever any change in the central order book results in a change to one
of the following items for an outright market, Client Applications subscribed to the Best
Price stream for the market are immediately sent a Publish Market Information message:

• Explicitly quoted (not implied) best buy and/or sell price.

• Aggregate volume available at the quoted best buy and/or sell price.

• Total traded volume.

• Last trade price and/or volume.

The Publish Market Information message contains the new quoted best buy/sell prices
and aggregate volumes available at those prices, the last trade price and volume, and the
total traded volume.

The same information is also sent back to a Client Application when it initially subscribes
to the Best Price stream for an outright market.

Note: When a strategy trade is executed, this causes an update to the total traded
volume in both the strategy market itself, and in each of the individual outright
legs of the strategy. The updates to the volumes in the individual outright legs are
transmitted using Publish Market Information messages, but the update to the
strategy market volume is transmitted using a Publish Strategy Market
Information message (see Publish Strategy Market Information).

During the Pre-Open period, orders may be submitted, but no trading may take place. As
the Trading Host receives orders, changes to the best buy and sell prices and volumes
are transmitted to subscribed traders when they occur, using Publish Market Information
calls. In addition, indicative opening prices and volumes are calculated for each outright
futures and options market, based on the submitted orders. These indicative prices and
volumes are transmitted to subscribed traders using Publish Market Information calls at
regular frequent intervals. Exchange Staff set the interval frequency, according to market
requirements. It may be different for each contract, and will normally speed up shortly
before the market opens.

An ITM can receive information on underlying cash markets via the OnMarketUpdate
callback if they have subscribed to do so, see Subscribe to Market.

11.9 Publish Implied Market Information

(OnMarketImpliedUpdate)

For designated contracts, LIFFE CONNECT® calculates best implied prices and volumes
for outright markets, and publishes these prices when they are better than or equal to the
best explicitly quoted prices for the market.

API Functional Descriptions Issued Version 1.3 Page 38 of 79

 This function may be transmitted either when there is a change to implied prices/volumes,
or when a Client Application first subscribes to the Best Price stream, for the relevant
outright market.

The contracts for which LIFFE CONNECT® calculates implied prices, are determined by
the Exchange in consultation with members, and may be subject to periodic change.
Similarly, the types of strategy market for which LIFFE CONNECT® will use explicit
strategy quotes to imply outright market prices, may also change intermittently.

An outright market price can be implied when there is an explicitly quoted price in a
strategy market for which the outright market is one leg, and for which there are quoted
prices available for the other legs (see Implying Out Outright Market Prices).

Note: Implied prices will not be derived from other implied prices.

Orders in individual outright markets, which are entered in the normal way against
published implied prices and volumes, will be automatically executed by the Trading Host.
The execution will be against the relevant Strategy and Outright Orders from which the
prices are implied.

LIFFE CONNECT® does not publish implied in prices for any strategy markets. However,
implied strategy prices should be calculated by the Client Application, from the explicitly
quoted prices in the relevant outright months, which are transmitted in the Publish Market
Information call (see Publish Market Information).

Note: For applicable contracts and strategies only: Strategy Orders entered against the
calculated prices will be executed by the Trading Host against volume in the
relevant individual outright months (see Implying In Strategy Market Prices).

11.9.1 Implying Out Outright Market Prices

This example illustrates a typical scenario in which implied outright market prices may be
transmitted to Client Applications.

The following strategy market has been created:

Euroswiss Future Sep 09/Dec 09 Calendar Spread

(i.e. Buy Strategy = Buy 1 Sep 09, Sell 1 Dec 09)

There is a current order:

Euroswiss Future Sep 09/Dec 09 Calendar Spread Buy 25 lots for 0.23

The following order is submitted:

Euroswiss Future Sep 09 Sell 40 lots at 97.73

The sell price would be transmitted, using a Publish Market Information call, to Client
Applications subscribed to the outright market.

A sell price for the Dec 09 outright will be implied by subtracting the Sep 09/Dec 09
spread strategy buy price from the Sep 09 outright sell price. The available volume is the
lesser of the two quoted volumes:

Euroswiss Future Dec 09 Sell 25 lots for 97.50

API Functional Descriptions Issued Version 1.3 Page 39 of 79

 This implied outright price and volume would be transmitted, using a Publish Implied
Market Information call, to Client Applications subscribed to the Dec 09 outright
market.

11.9.2 Implying In Strategy Market Prices

This example illustrates how implied futures calendar spread strategy prices can be
calculated from information supplied by the Publish Market Information call (see Publish
Market Information). Implied spread market prices should only be calculated from
explicitly quoted buy and sell prices in the outright markets concerned, and not from
implied prices in the outright markets.

There is a current order:

Euroswiss Future Sep 09 Sell 40 lots at 97.73

The following order is submitted:

Euroswiss Future Dec 09 Bid 25 lots for 97.50

This implies the following offer in the Sep 09/Dec 09 spread:

Euroswiss Future Sep 09/Dec 09 Calendar Spread Sell 25 lots at 0.23

11.10 Publish Strategy Market Information

(OnMarketStrategyUpdate)

During trading, whenever any change in the central order book results in a change to one
of the items listed below for a strategy market, Client Applications subscribed to the Best
Price stream for the market are immediately sent a Publish Strategy Market Information
message, containing the new values of all of these:

• Explicitly quoted (not implied) best buy and/or sell price.

• Aggregate volume, available at the quoted best buy and/or sell price.

• Total traded volume.

• Last trade price or volume.

If the function is transmitted as a result of a trade, it also includes volumes and prices for
each of the individual legs in the executed strategy.

The same information is also sent back to a Client Application when it initially subscribes
to the Best Price stream for a strategy market.

Note: When a strategy trade is executed, this causes an update to the total traded
volume in both the strategy market itself, and in each of the individual outright
legs of the strategy. The update to the strategy market volume is transmitted
using a Publish Strategy Market Information message, but the updates to the
volumes in the individual outright legs are transmitted using Publish Market
Information messages (see Publish Market Information).

API Functional Descriptions Issued Version 1.3 Page 40 of 79

12. Trading and Order Handling

In the LIFFE CONNECT® markets, Client Applications submit orders to the Trading Host
via the API. The Trading Host maintains a central order book for the entire market and
matches orders when appropriate.

At all times, LIFFE CONNECT® ensures that the best possible price is achieved for any
business placed in the market, in the fairest manner to all market participants.

Note: See Order Handling Examples for a high-level overview of how orders are
handled by the Trading Host.

It is possible to submit orders for outright futures and options series and LIFFE
CONNECT® recognised strategies to the Trading Host. Orders can be of a variety of
types, for example: Complete Volume, Immediate and Cancel, Market, Limit, Market On
Open, etc. For both futures and options, a variety of commonly used strategy markets are
available for trading. A number of Strategy Orders are available for options traders,
notably orders for delta neutral trades.

Contingent Multiple Orders

Multiple Orders can be submitted as a contingent multiple order, whereby the trading of
each component order is contingent upon being able to fully trade all components within
the contingent multiple order. Contingent Multiple Orders are executed on an immediate
Fill or Kill basis.

Batch orders

Batch order functionality enables traders to perform batch order operations within a single
message in the same contract. For order submission, up to 16 orders can be submitted
as part of a batched order. Orders submitted as part of a batch are not permitted if they
would result in trade matching, so that the second order would be rejected. Batched
orders within the same message will only be permitted if in the same commodity.

Order Management

Unfilled orders can be withdrawn at any time and order prices and volumes can be
modified after submission. All orders are considered firm and available for trading in the
appropriate manner.

RFQs

A Request For Quote (RFQ) facility is supported as well as procedures for executing both
trades resulting from off-market negotiation and, for options only, cross trades.

FLEX® and Ex-Pit Trades

It is possible to submit orders for FLEX® options (if available in the market) and, for
designated contracts, for wholesale Ex-Pit business that has been pre-negotiated outside
the market (see Submit Ex-Pit Trade).

Submitted wholesale Ex-Pit Trades will not be put into the central order book or made
available to the market for trading. They will be examined by Exchange Staff and, if
acceptable, will be approved for execution off-market and clearing with other Exchange
business.

API Functional Descriptions Issued Version 1.3 Page 41 of 79

 Traders and Market Makers

In appropriate markets, the LIFFE CONNECT® system recognises and differentiates

between traders acting in a market-making capacity and brokers/proprietary traders and
also preference market makers.

Implied Prices

LIFFE CONNECT® calculates and publishes implied prices for outright contract months.
These are based on separate quotes in applicable strategy markets that include those
months, and in the other legs of the strategy (see Publish Implied Market Information).

LIFFE CONNECT® automatically matches buy and sell orders at the same price in the
same outright futures contract month, outright options series or valid strategy. Also, in
applicable markets, when implied prices permit, LIFFE CONNECT® will match orders for
several individual outright markets with orders for strategies that comprise those markets.

Account Codes

Every order submitted into LIFFE CONNECT® will require a valid Account Code.

Note: Refer to the parent Exchange for a list of valid Account Codes.

If an order is revised, then traders will be unable to amend the Account Code. Should the
trader need to change an Account Code, the order would need to be pulled and
resubmitted as a new order with an amended code.

Posting Codes

LIFFE CONNECT® supports give-ups, auto postings and manual postings (Posting
Codes). The API allows a member to submit an order with an Account Posting Code. This
code will then be passed through the Trading Host and on to the Clearing system.
Contact your parent Exchange for the relevant field combinations.

Delta Protection

The Delta Protection facility offers market makers a degree of protection against being
traded on multiple quotes simultaneously. It maintains a cumulative delta position, on a
contract or expiry basis, which is updated whenever a Market Making Order (MMO)
trades. When the delta position exceeds a set delta limit, action is taken to warn the
trader and, optionally, pull all that trader’s remaining MMOs in the same contract or
expiry.

Delta Protection will only be available to Market Makers who are explicitly registered to
participate in the facility in a particular contract. Only Option contracts may be registered.
Market Makers can only participate in this facility using Market Making Orders.

Stock Order Routing

Stock Order Routing is a message routing facility that can be used to send a stock order
request from one ITM to another. For example, a trader or market maker may send a
stock order to their clearing member for execution. The trader or market maker sends a
request to buy or sell stock to the clearing member; the clearing member then attempts to
execute the trade in the relevant stock market, and returns a response indicating the
result of the trade to the originating trader.

API Functional Descriptions Issued Version 1.3 Page 42 of 79

12.1 Submit Orders (LiffeTradeSubmitOrders/OnTradeSubmit)

Orders for outright futures and options series, and for strategies, can be submitted to the
Trading Host at any time from the start of the Pre-Open period until the relevant market
closes. A trader session need not be subscribed to a market to submit an order.

When orders are submitted to the Trading Host, they are considered firm once they have
been checked and confirmed as valid. At that point they are time-stamped. Orders must
either specify the price, in ticks, of the outright or strategy, or they must be orders to trade
at the market price or opening price of the relevant contract. All orders must specify the
volume, in lots, bid or offered at the order price. Orders that do not trade to completion
and are not of a type that require immediate completion are stored in the central order
book. The order time-stamp value is used for subsequent order prioritisation.

Note: For efficiency, Multiple Orders, with the exception of Strategy Orders, can be
submitted within the same transaction.

12.1.1 Open Close Indicators

At order submission, the Open/Closed indicators designate whether an order is opening

or closing a position for the clearing system. Open/Close Indicators are available for
outright and strategy orders and are validated by the Trading Host.

An Open/Closed indicator if applied to a strategy order will be assigned to each resultant

outright leg trade. Hence, either all legs in the strategy are opening a position or all legs
are closing a position. When submitting a strategy order (such as a Calendar Spread), the
Open/Closed indicator can be set for each leg of the strategy.

A particular value can be specified for the first 4 legs of a strategy. Strategies with greater
than 4 legs, all legs beyond the fourth leg will take the same Open/Close indicator as the
fourth leg. For outrights only the first leg is used.

The following table details the values that can be submitted:

VALUE FIRST LEG SECOND LEG THIRD LEG FOURTH LEG

(& subsequent legs)

0 Open Open Open Open

1 Open Open Open Closed

2 Open Open Closed Open

3 Open Open Closed Closed

4 Open Closed Open Open

5 Open Closed Open Closed

6 Open Closed Closed Open

7 Open Closed Closed Closed

8 Closed Open Open Open

9 Closed Open Open Closed

A Closed Open Closed Open

API Functional Descriptions Issued Version 1.3 Page 43 of 79

 VALUE FIRST LEG SECOND LEG THIRD LEG FOURTH LEG
(& subsequent legs)

B Closed Open Closed Closed

C Closed Closed Open Open

D Closed Closed Open Closed

E Closed Closed Closed Open

F Closed Closed Closed Closed

‘‘ Open Open Open Open

[Space]

O Open Open Open Open

12.1.2 Order Types

Orders can be of the following types:

12.1.2.1 Limit Orders

These are executed at the price stated or better. Unless otherwise specified, any residual
volume from an incomplete Limit Order is retained in the central order book until it is
withdrawn, has traded or the contract closes.

12.1.2.2 Good Till Cancelled (GTC) Orders

These remain in the central order book until either:

• they trade

• they are withdrawn by the submitting trader

• the contract expires, or

• the order expires.

GTC Orders can be given an expiry date, and they are then cancelled at the end of
trading on that date. If no date is specified, the orders will be valid until the contract
expires.

12.1.2.3 Good In Session (GIS) Orders

These remain in the central order book until either:

• they trade

• they are withdrawn by the submitting trader

• the contract expires, or

• the Trading Session ends.

API Functional Descriptions Issued Version 1.3 Page 44 of 79

 The Trading Session must be specified for GIS Orders.

12.1.2.4 Clip Orders

A Clip order allows a trader to specify a ratio for the order which defines the clip size for
the trade. The order should trade as much as possible (in the clip sizes), then cancel any
residual order volume. The Clip order type will only be accepted by the Trading Host
when the market is in open (which includes Pre-Close).

A Clip Order can only be entered as a normal Limit order in outright markets. As the order
is effectively a ‘Fill and Kill’ order, it cannot rest in the market.

For a contract, the order type will specify a time-out period in which the order must be
processed by the Trading Host. Orders which are not processed within the configured
time-out will be rejected. For this reason, a Clip order cannot be submitted as part of a
batch.

12.1.2.5 Market Orders

These are executed at the best price available in the market when the order is received
until all available volume at that price has been traded. Then the order executes at the
next best price and so on, until all the order volume has been consumed. Any residual
volume from an incomplete market order is cancelled. Market Orders are rejected if the
market is not open.

12.1.2.6 Market On Open (MOO) Orders

Market On Open orders can be submitted for futures and options contracts.

MOO Orders are only accepted during the Pre-Open period, and are intended for
execution at the opening market price. MOO Orders will be executed by the Trading Host
after uncrossing of the Limit Orders in the market when the market opens.

Two types of MOO orders can be submitted:

• Standard

• Persistent.

Initially, MOO Orders will trade against other MOO Orders, at the opening price calculated
after the uncrossing. After this, any residual volume remaining in MOO Orders will be
converted automatically to Limit Orders at the opening price, and may then be executed
against suitable Limit Orders that remain in the market. If residual volume still remains, it
will be retained in the central order book until it is withdrawn or traded, as for a standard
Limit Order.

Persistent MOO orders have a GTC flag and the order will remain in the Central Order
Book if the ITM loses connection, or logs out, or if there is a Host failure. If a persistent
MOO is converted to a Limit order, then it is converted into a GTC Limit order.

When submitting a persistent MOO order, the trader may also indicate an expiry date
(which may be the current day). This expiry date will be applied to the resultant GTC Limit
order if the MOO is converted. If no expiry date is set on the MOO, then the resultant
Limit order will have no expiry date and may remain in the order book until the contract
month expiry.

API Functional Descriptions Issued Version 1.3 Page 45 of 79

 All MOO Orders are processed by the Trading Host in the order that they were submitted.
The sequence of activities at the time the market opens is summarised below:

1. Uncrossing of Limit Orders.

2. Calculation of market opening price.

3. Execution of MOO Orders against other MOO Orders at the opening price.

4. Conversion of residual MOO volume to Limit Orders. Notification of this conversion

will be given by an OnTradeRevise function call.

5. Execution of converted MOO Orders against Limit Orders at the opening price.

6. Any residual volume left in the market as Limit Orders.

Note: If an opening price cannot be calculated but a mid-price exists, MOO Orders will
be converted to Limit Orders at that price, subject to price limits. If no mid-price
exists for the market when it opens, all MOO Orders will be pulled automatically.

12.1.2.7 Stop Orders

A Stop order is an order type which is submitted into the Trading Host but is not submitted
into the central order book until a specified price level, called the trigger price, has been
reached or passed. When this price is reached, indicated by an explicit outright trade at or
beyond the trigger price, the order is time stamped and submitted into the Trading Host
as a normal order, according to the order parameters set. A Stop order can be submitted
with either a Price Type of Limit or Market, and all order modifiers can be set.

A Stop can only be submitted into an outright market, during normal order submission
market states, specifically Pre-Open and Market Open.

A Stop order cannot be submitted as part of a CMO or as a Market On Open or Persisted

Market On Open order.

12.1.2.8 Strategy Orders

These are combinations of individual outright futures or options that are dealt with as a
single unit. A wide variety of strategies are recognised by LIFFE CONNECT®. Different
strategies are available for futures and options trading. Some strategies are only available
for a limited range of contracts.

The available strategies for any contract are determined by Market Solutions in
consultation with members, and may be subject to change at any time.

Note: Contact your parent Exchange for details of available strategies.

Members are limited to one strategy per order submission.

12.1.3 Order Modifiers

12.1.3.1 Immediate and Cancel (IC)

Immediate and Cancel orders executed against any existing orders at the stated price or
better, up to the volume of the IC order. Any residual volume from the IC order is
cancelled.

API Functional Descriptions Issued Version 1.3 Page 46 of 79

12.1.3.2 Complete Volume (CV)

Complete Volume orders are only executed if there is sufficient volume available, at the
stated price or better, for them to execute fully. Otherwise the entire order is cancelled.

12.1.3.3 Minimum Volume (MV)

Minimum Volume orders are only executed if there is at least the minimum volume
available, at the stated price or better. If not, the whole order is cancelled. Any residual
volume from a partially executed minimum volume order is retained in the central order
book.

12.1.4 Order Acceptance Rules

The following table details the permitted order modifiers that can be specified with price
and volume for limit and market orders:

Order Type Price Volume MV CV IC

LIMIT Normal 9 9 9 9 9

GTC 9 9 9 X X

GIS 9 9 9 X X

Market Making Order 9 9 X X X

Clip 9 9 X X X

MARKET Normal X 9 9 9 X

MARKET ON Standard X 9 X X X
OPEN
Persistent X 9 X X X

STOP Limit 9 9 9 9 9

Market X 9 9 9 9

12.1.5 Batch Order Validation

In addition to the validation undertaken on individual orders, the batch submission of

orders are subject to the following validation:

• All orders within a batch must be for the same commodity.

• All orders within a batch must be Limit Orders

• Batch orders will be subject to crossing prevention, i.e. no two orders within a batch
order may cross.

API Functional Descriptions Issued Version 1.3 Page 47 of 79

12.2 Pull Orders (LiffeTradePullOrders/OnTradePull)

Once an order has been stored in the Trading Host’s central order book, it can be
withdrawn (pulled) using this call (see LiffeTradePullOrders). The Client Application may
withdraw orders specified by the unique Order ID or as a block consisting of:

• Individual orders for a given list of order IDs.

• All orders in a given futures or options contract.

• All put or call orders for a given options contract.

• All orders in a given expiry month for a given futures or options contract.

• All orders in a specific futures or options outright or strategy market.

Block pulls also pull the Strategy Orders affected. The originating trader can pull orders
even when not subscribed to the market in question.

Ex-Pit and FLEX® Trade Orders cannot be pulled after they have been submitted.
However, a Pull Orders Response Handler Function will be transmitted to the submitting
trader if an Ex-Pit Order is rejected by the Exchange.

A Pull Orders Response Handler Function will also be transmitted in the following events:

• If a Market On Open Order is pulled automatically because no opening price can be

calculated

• If an order is pulled from the central order book manually by Exchange Staff.

• When GIS Orders are pulled automatically when the Trading Session changes.

• When a Master Trader Mnemonic (MTM) performing ITM Monitoring pulls a

monitored ITM’s order.

12.2.1 Call Life-Cycle

A Client Application receives an acknowledgement of a successful pull operation. The call

also triggers Order Book Update messages to all trader sessions subscribed to that
market, to update them with any price and volume changes.

When a trader wishes to amend an existing order in the market, the Revise Orders
function should be used. The Client Application should not pull the original order and then
re-submit a new one. Excessive pulling and re-submitting of orders will be monitored and
controlled to limit the degradation of service that could result from incorrect use of these
functions.

12.3 Revise Orders (LiffeTradeReviseOrders/OnTradeRevise)

The Revise Orders function allows a trader to amend volume, price and GTC expiry date
for a single or multiple orders. If the volume of an order is increased or its price is
changed, the order will lose its original time-stamp and be re-stamped with the current
time. A reduction of volume will have no effect on the original time-stamp.

API Functional Descriptions Issued Version 1.3 Page 48 of 79

 The originating trader can revise orders even if they are not subscribed to the market in
question.

Ex-Pit and FLEX® orders cannot be revised after they have been submitted.

Notes:

• Orders within a revision list will not necessarily be processed in the same sequence
in which they were entered. The Trading Host will alter the sequence, to prevent
inadvertent crossing occurring as a result of the revision of two-way prices by market
makers. This means, all orders where the price is worsening, will be processed
before any orders where the price is improving or remains unchanged.

• Members are limited to one strategy per order revision.

• The OnTradeRevise Response Handler Function is also used to notify traders if

residual volume in Market On Open Orders is converted automatically to Limit Orders
by the Trading Host after market opening. It is also returned to notify a trader that a
Stop Order has been triggered but has not traded.

12.3.1 Multiple Order Validation

Validation of Revise Orders messages is similar to that for Submit Orders messages. In
addition to the validation undertaken on individual orders, the revision of multiple orders
are subject to the following validation:

• All orders within a multiple order must be for the same commodity.

• A check is performed to ensure that the same order is not listed more than once
within the list. The second and subsequent occurrences of an order will be rejected.

• Multiple orders will be subject to crossing prevention, i.e. no two orders within a
multiple order may cross.

• Revisions for multiple strategies will not be permitted.

Note: Crossing may result from the generation of implied orders within the batch, given
that there is no restriction on the mix of orders for outright markets within the
batch.

12.3.2 Call Life-Cycle

A Client Application receives an acknowledgement of the successful completion of the

change in the central order book via the OnTradeRevise Response Handler Function.
The OnTradeRevise function is also used to notify traders if residual volume in Market On
Open Orders is converted automatically to Limit Orders by the Trading Host after market
opening.

The call also triggers messages that update the order book details and relevant market
information for all trader sessions subscribed to that market, containing details of any
price and volume changes.

API Functional Descriptions Issued Version 1.3 Page 49 of 79

12.4 Submit RFQ (LiffeTradeSubmitRFQ/OnTradeSubmit)

A Request-For-Quote (RFQ) call enables RFQ generation on any outright or strategy.

This may be done without having to subscribe to the market. RFQs are a request for price
for an optionally specified volume. If an RFQ is submitted without a volume, a default
volume is applied by the Trading Host. This default may be set differently for individual
contracts, and may be changed by the Exchange to suit market requirements at any time.

For any given market, submission of RFQs is not permitted for a short time after
submission of an earlier RFQ, except where the volume is greater than the initial RFQ in
that market. The length of time before another equivalent RFQ may be submitted is
specified by the Exchange and may be different for each individual market. If an RFQ is
submitted in this period, an error status will be returned.

12.5 Submit RFQX (LiffeTradeSubmitRFQX/OnTradeSubmit)

A Client Application can enter an order for one side of a pre-negotiated trade using this
function. The individual trader mnemonic (ITM), for the intended counterparty, must be
included in the order details. The counterparty may not enter a matching order for a pre-
determined minimum amount of time after the original RFQX has been entered. This
delay is specified by the Exchange, and is different for futures and options trading. It may
also be changed for individual contracts, to suit market requirements.

After the first order is submitted to the Trading Host, it will be placed in the central order
book. In the time before the intended counterparty may enter the pre-negotiated matching
order, the first order can trade against any other matching orders in the central order
book.

Orders submitted through the RFQX call must be of Limit price type.

Note: Check with your parent Exchange to see if this facility is supported.

12.6 Submit Ex-Pit Trade

(LiffeTradeSubmitExPitTrade/OnTradeExPitTrade)

Using this function, it is possible to submit orders for wholesale business that has been
pre-negotiated outside the market, for designated contracts.

Orders for wholesale, or Ex-Pit, business can be submitted at any time from the start of
the Pre-Open period until the relevant market closes. A trader session need not be
subscribed to a market to submit an Ex-Pit Trade Order.

Note: Ex-Pit trades can only be submitted in Open and Pre-Close periods.

Permitted types of wholesale business are:

• Block Trades – high volume trades in any outright or strategy market. Orders must
contain both the buy and sell side orders and include the trade price and volume. For
strategy block trades, in addition to the total strategy price and volume, the order
must include all individual leg prices and volumes. Individual contracts can be
configured to allow Block trades to be submitted before Market Open and after
Market Close. The earliest time that can be configured is the beginning of Day Start;
the latest time that can be configured is the end of Day End.

API Functional Descriptions Issued Version 1.3 Page 50 of 79

 • Basis Trades – strategies for long-term bond markets that incorporate a futures leg
and an underlying bond (or cash) leg. Orders must contain the trade volume and the
price of both the futures leg and the cash leg, and must include the necessary
reference fields to identify the order within the cash market. The trader must access
the cash market separately to buy the underlying leg.

• Against Actuals – strategies for commodities markets that incorporate a futures leg
and an underlying commodity leg. Orders must contain both the buy and sell side
orders and include the trade price and volume.

• Asset Allocation – allows traders to take positions or transfer exposure between two
different but related contracts simultaneously and without execution risk.

• Market Maker Cross Trades - allows a Market Maker to enter both sides of a cross
trade. These sides will be matched without entering the central order book, and be
sent to the Monitor and Control system for manual authorisation by a market
observer. The crosses are available in both outright and strategy markets, but the
cross can only be submitted if the strategy market has been created.

Once the Market Maker Cross has been entered, it cannot be pulled or revised. There
are no minimum or maximum volume requirements, and the Market Maker Cross will
not be subject to price limit validation.

• Professional Trades - a pre-negotiated trade between two parties that takes place
outside the central order book. A single Prof Trade consists of two ‘intentions’, each
entered by one of the counterparties to the trade. An intention is analogous to an
order in the central order book. A Prof Trade will only occur when both counterparties
enter matching intentions.

• Guaranteed Cross Trades – a pre-negotiated order that, subject to certain

conditions, will be automatically matched by the Trading Host, therefore not requiring
individual authorisation by Market Control. For certain contracts, a Request For
Quote (RFQ) may be required to have been submitted to the market prior to the
execution of the Guaranteed Cross-Trade. See Automatically Validated Trades
(Guaranteed Crosses) for further details.

Note: The availability of the above trade types may vary between Exchanges. Block
Trades, Basis Trades and Against Actuals are subject to change. Trade volumes
may be subject to minimum levels, which depend on the type of business and the
traded commodity.

12.6.1 Trades Manually Validated by Market Control

The following ex-pit trade types are manually validated by Market Control:

• Block

• Basis

• Against Actual

• Asset Allocation

• Market Maker Crosses.

The prices of trades in wholesale business orders will be verified by Exchange Staff after
submission, to ensure that they are in-line with Exchange-traded business, but are not
subject to automatic price controls.

API Functional Descriptions Issued Version 1.3 Page 51 of 79

 Once submitted, Wholesale Trades cannot be pulled, revised or handed over to another
trader.

Submitted Wholesale Trades will not be put into the central order book or made available
to the market for trading. They will be examined by Exchange Staff and, if acceptable, will
be approved for execution off-market and clearing with other Exchange business. Once
executed, Wholesale Trade’s volumes will be added to the published total traded volume
for their respective markets.

Under normal circumstances, approval of Wholesale Trades will take place within a time
period specified by the relevant regulatory body for the type of business.

Note: Contact the local Exchange for details of applicable time periods.

If a trader has submitted orders for Wholesale Trades that have been accepted but not
yet approved, and the trader logs out, or their Client Application fails, the wholesale
orders will not be affected and will remain registered with the Trading Host, awaiting
approval. The trader does not need to be logged in for approval of wholesale business to
take place.

Under normal circumstances, the last trading day for these manually validated Ex-Pit
Trades, in a given market, is earlier than the last trading day for normally traded business
(typically by about two business days).

12.6.2 Automatically Validated Trades

12.6.2.1 Guaranteed Crosses

Guaranteed Cross trades will be automatically validated by the Trading Host. Those
trades passing validation will be processed immediately. For a Guaranteed Cross trade to
be successfully validated, it must meet the following conditions:

• The trade’s market must be configured to accept the Guaranteed Cross trade type.

• The trade must be valid for the Best Bid and Offer (BBO) in the market. This
validation is configurable by the Exchange on a per-contract basis. The BBO
validation will be one of the following:

- Strictly inside the BBO - trades at or outside the BBO will be rejected.

- Inside the BBO and at adjacent BBO - trades will only be allowed inside the
BBO unless the best bid and offer prices are adjacent (i.e. they are only
separated by the minimum tick size defined for the market).

- Allowed at or inside the BBO - trades are allowed both at the best bid price, the
best offer price or any valid price in between.

Note: Depending on the configuration of the market, trades taking place at the best bid
or best offer price may be subject to minimum volume restrictions.

Determining the BBO range - In the case that a market is lacking either a bid, an
offer or both, some Exchanges may configure the BBO range to expand to the
relevant price bound for the market (eg. a market that contains only bids and is
configured to expand its BBO and to allow trades at the BBO, will allow trades from
the best bid price up to and including the maximum price allowed in the market -
subject to the other relevant validation tests).

API Functional Descriptions Issued Version 1.3 Page 52 of 79

 • The Buy and Sell side account (assignment) codes must be of a combination that
allows cross-trades to take place.

• The trade’s price must be within the price limits for the market.

• If the market to which the Guaranteed Cross is being submitted is configured to

require an RFQ prior to the trade then:

- The time between receipt of the last submitted RFQ and receipt of the
Guaranteed Cross trade lies between two configurable boundaries (eg. 30s and
60s).

- The Guaranteed Cross trade’s volume must be less than or equal to that of the
submitted RFQ.

• If the trade is a strategy, then in addition to the above validation, the following
validation will take place:

- If the trade is an option volatility cross, there must be a minimum of one lot in
volume

- It must be of a recognised strategy code and the market for that strategy must
have been created and be available for trading.

- Its legs must be in the correct order for the strategy.

- Its legs’ volumes must be in the correct ratio.

- Its price must be correct with respect to the price of its legs.

- Its outright legs must:

Be valid for the price limits in its market.

Be valid for the BBO in its market.

Have a market reference corresponding to the appropriate leg of the defined

strategy market.

- If it has an underlying leg, then:

The given leg price must equal the price defined for the strategy market’s
underlying leg.

If a market exists on the Trading Host for that underlying, its price will be
validated according to the validation specified for Delta Neutral trades.

The market reference of that leg will not be checked.

Note: Contact the local Exchange for market configuration details.

12.6.2.2 Professional Trades

Prof Trades do not have to be approved by Exchange staff. For a Prof Trade to be
successfully matched, it must meet the following conditions:

• Same series

API Functional Descriptions Issued Version 1.3 Page 53 of 79

 • Same volume

• Same price

• One is Buy, other is Sell

• At least one of the two is an Initiator

• They have the same three character entry in the password field.

If any of these conditions is not met, the intentions do not match.

The Package Id field is used to specify a Package ID. Each of the counterparties will
enter the first eleven characters of the Package ID when they submit an intention using
the following format:

• The first and second characters should be populated with hours past midnight (local
time of the Trader) that the package was agreed.

• The third and fourth characters should be populated with the minutes past the hour
that the package was agreed.

• The fifth and sixth characters should be populated with the total number of legs in the
package. (This implies a limitation of ninety nine legs per package).

• The seventh to the eleventh characters inclusive are free text for the ITM to enter a
package identifier.

• A twelfth character will complete the Package ID and will be populated by LIFFE
CONNECT® to designate the ITMs role in the package. The character will be
populated by the system with an ‘I’ for an initiator or an ‘R’ for a reactor.

LIFFE CONNECT® will not validate the contents of the field but will ensure that the
Package Id has at least 11 characters. If the Package Id is not the correct length, the
trade will be rejected.

12.7 Submit Contingent Multiple Orders

(LiffeTradeSubmitContingentOrder)

A Contingent Multiple Order (CMO) is an order that contains two or more component
orders. Trading of any component is contingent on being able to fully trade all
components within the CMO. CMOs provide clients with the ability to trade contract
strategies across two separate contracts, therefore allowing traders to submit non-resting
inter-contract spreads to LIFFE CONNECT®. They cannot be submitted during the Pre-
Open period, as all the order components must exist in open markets.

CMOs are bound by the following:

• Maximum of 8 component orders.

• All component orders must be for outright orders, i.e. no strategies.

• Only one futures component permitted if any component order is for an option.

• It is not possible to submit a CMO for products traded on separate Trading Hosts.

API Functional Descriptions Issued Version 1.3 Page 54 of 79

 Each component of a CMO can be of Limit or Market type. Any modifiers that are added
are ignored e.g. Complete Volume, Immediate & Cancel, because of the Fill or Kill nature
of the order. The CMO can be submitted as a mixture of buy and sell orders. The
permitted product pairs are pre-defined by the Exchange.

The trades are executed in the same order as the components within the submitted CMO.
All output messages accumulated during trading of the contingent order will be
transmitted once trading of all the components is complete.

A single Order ID will be allocated to all of the components within a CMO.

Note: As each individual component order is processed in turn, and as none of the
components reside in the order book, it is impossible for two orders from a CMO
to exist in the same market at the same time. Therefore, a trader cannot perform
Guaranteed Cross trades by submitting a CMO that contains two matching
component orders. If a trader does attempt a cross trade within a CMO, then the
component trades will only trade with other orders already residing in the order
book, if at all.

A component of a submitted CMO may trade with orders residing in the order book that
were submitted by the same trader, subject to the cross-trading rules applied to standard
LIFFE CONNECT® orders.

12.8 Submit FLEX® Orders

(LiffeTradeSubmitFlexTrade/OnTradeFlexTrade)

FLEX® Orders are FTSE 100 options, except that any expiry day and exercise price can
be specified.

The trade submission and authorisation process is semi-automated, requiring manual

intervention by an Exchange Official.

12.9 Submit Market Making Orders

(LiffeTradeSubmitMarketMakingOrders/OnTradeMarketMaki
ngOrdersSubmit)

Market Making Orders allow an ITM to simultaneously submit bids and offers into a
series. For each contract, only ITMs that are registered to submit MMOs will be allowed to
do so, and these ITMs will not be allowed to submit any other resting order type for that
contract.

MMOs are submitted in batches to allow bids and offers to be entered into different series
within a contract simultaneously. Each MMO within the batch should specify the series it
is to be entered into and the prices and volumes for both the bid and the offer side. The
volumes for each side of the MMO do not have to be equal and these values do not have
to be equal across different MMOs within the batch. Series, volume and price information
is stored at MMO level, rather than the batch level.

MMO orders may be entered during Pre-Open, Open or Pre-Close. They will not persist in
the order book if the ITM logs out or is disconnected. MMOs effectively act as Limit orders
and have all the attributes of limit orders.

When an MMO is submitted it will replace any existing MMO order by that ITM in that
series in the following manner:

API Functional Descriptions Issued Version 1.3 Page 55 of 79

 • Bids will replace existing bids and offers will replace existing offers, regardless of
price.

• If either side of the new order has a volume of zero, all volume in that side of the
order will be pulled.

• If an order is submitted with one side flagged as null, then that side of the order book
will remain unchanged.

All MMOs in a batch should be for the same contract. If this is not the case, the first MMO
in the batch will be accepted and any MMOs in the batch which are not in the same
contract as the first MMO will be rejected. The Account, Posting and User Specified data
for all MMOs within the batch is contained in the batch header. As such, this information
will be the same for every MMO in the batch. Account or posting information for an MMO
order is not revised, even if subsequent MMOs in the same series are submitted with
altered account and posting information.

LIFFE CONNECT® will prevent MMOs being submitted with bid and offer sides at equal
price (thus preventing the two sides of the MMO trading with each other) or with the bid
side at a higher price than the offer side (i.e. backwardation). Additionally, submission of
the two sides of an MMO will occur in such a manner as to avoid either backwardation or
trading with one side of the previous MMO occurring.

12.10 Receive RFQ (OnTradeRFQ)

If a Client Application subscribes to the RFQ stream of information for a market, it will be
notified of any RFQs submitted for that market, using the Receive RFQ Response
Handler function.

12.11 Order Trade Notice (OnTrade)

Any trade activity on an order (including Ex-Pit Trade Orders) for an outright, submitted by
the Client Application, is reported through the Order Trade Notice Response Handler
function. The call returns the order traded by the Order Identifier, the trade status, the
price at which the trade occurred, the volume traded at that price, and the residual volume
remaining on the order after the particular trade or half-trade in question. If the order is
part of a contingent order, its position within that order is also given. When the order has
traded fully, the residual volume is zero. The trade status identifies whether the order is
active or has been deleted or cancelled by Market Control.

When a FLEX® trade is authorised the originating trader is notified through the Order
Trade Notice Response Handler function.

12.12 Strategy Trade Notice (OnTradeStrategy)

Any trade activity on an order (including Ex-Pit and FLEX® Trade Orders) for a strategy,
submitted by the Client Application, is reported through the Strategy Trade Notice
Response Handler function. The call returns the order traded by the Order Identifier, the
trade status (active or cancelled), the price at which the trade occurred, the volume traded
at that price, the residual volume remaining on the order after the particular trade or half-
trade in question (this is zero when the order has traded fully), and the volume and price
of each individual leg of the strategy.

API Functional Descriptions Issued Version 1.3 Page 56 of 79

12.13 Retrieve Fills
(LiffeTradeRetrieveFills/OnTradeFill/OnTradeFillStrategy)

A trader can retrieve all of the trades that have been filled that day under that ITM,
including all ex-pit trades. This call is only intended for use when an ITM logs on – it
should not be used by an ITM more than once in a single login session.

The call will return the AMR, Trade ID, Trade Price, Trade Volume, Trade Time, Session
ID, TRS Order ID, Trade Status (active or cancelled) and Buy/Sell indicator for all filled
trades. It will also return an Order ID for all orders that resulted in filled trades, and a
record of any residual volume left in those orders. If the Retrieve Fills request has
originated from a Monitoring ITM, the call will return the Trader ID (ITM) to which the fills
belong.

The Trading Host will return two Response Handlers, OnTradeFill and
OnTradeFillStrategy which will list the number of fills for the trader. Where the number of
trades exceeds the number allowed within a single message (64 records); multiple
messages will be sent. The OnTradeFillStrategy will also include the leg information as in
OnTradeStrategy.

12.14 Set Delta Protection

(LiffeTradeSetDeltaProtection/OnTradeSetDeltaProtectionS
tatus)

Using this function a market maker can activate the Delta Protection facility for each
contract where the facility is available. For some contracts, the facility may be available at
expiry and contract levels.

At the time of activation of the delta protection facility, market makers can also set the
contract level delta limit, and limit breach action. If appropriate, they can also set a series
of expiry level delta limits and an expiry level breach action, these values may be updated
after the facility has been activated using the same function.

The “Delta Limit” defines the largest magnitude that the “Delta Position” is allowed to
reach before triggering the “Limit Breached Action(s)” The limit breach action can be set
to either:

• ”Ignore” - no checking takes place and any limit set is ignored.

• “Pull” - any remaining MMOs that the ITM has in the relevant contract or expiry will be
pulled.

• “Warning” - a warning will be issued but orders will not be pulled.

• “Warning and Pull” - a warning will be issued and remaining orders will be pulled.

12.15 Adjust Delta Position

(LiffeTradeAdjustDeltaPosition/OnTradeDeltaPositionUpdat
e)

The “Delta Position” represents the net delta position for all MMO trades which occurred
after the facility was enabled for a given contract. Where Expiry level protection is
configured, each expiry will have its own Delta Position. A Delta Position may be updated

API Functional Descriptions Issued Version 1.3 Page 57 of 79

 manually by a Market Maker by specifying a relative shift to the current position using a
signed value.

12.16 Get Delta Protection Data

(LiffeTradeGetDeltaProtection/OnTradeGetDeltaProtectionS
tatus)

This function allows a Market Maker to retrieve the current Delta Protection details held
within the Host. The details will contain the configuration details previously setup by the
Market Maker using the LiffeTradeSetDeltaProtection function. The information will
include the Delta Position and the Limit Breached Status which are sent automatically via
the OnTradeDeltaPositionUpdate whenever the Delta Position changes or the user
changes a Delta Protection configuration parameter (via LiffeOnTradeSetDeltaProtection)
in such a way that the MMOsPulled or LimitBreached flags change.

12.17 Send Stock Order Request

(LiffeTradeRouteStockOrderRequest/
OnTradeRouteStockOrderRequest)

Using this function, a trader can send a request for a stock order operation to another
trader to either:

• submit a new stock order

• cancel a stock order

• request stock order status

• request fill data.

12.18 Send Stock Order Fill or Status

(LiffeTradeRouteStockOrderData/
OnTradeRouteStockOrderData)

On receipt of the request, a trader will respond by sending one or more

RouteStockOrderData messages back to the originator. The responses will be one or
more of: stock order status; stock order trade fill data; fill cancellation data.

API Functional Descriptions Issued Version 1.3 Page 58 of 79

13. ITM Monitoring

ITM Monitoring allows a monitoring trader, otherwise known as a Master Trader

Mnemonic (MTM) to monitor and interact with allocated traders orders as well as the
connectivity of Individual Trader Mnemonics (ITMs).

An MTM is a normal ITM with additional privileges. The MTM will be able to manage the
allocated trader ITMs order details using order revise and pull functions.

The MTM will also be able to manage ITMs across different member firms to allow for
NCM/GCM relationships.

Having subscribed to monitoring capabilities the MTM will receive notifications of all
changes to the order books of their allocated ITMs. Changes may result from any of the
following actions:

• Submission of new orders or RFQXs

• Trades

• Revision of current orders

• Pull orders

• Logoff

• Lockout

• Handover

• Activated Market on Open (MOO) order

• Activated Stop order

• Market State change

• Retrieved Fills.

13.1 Subscribe to Monitor ITMs

(LiffeMonitorSubscribe/OnMonitorSubscribe)

This function is used by a Master ITM to register their interest in the ITMs they are
assigned to monitor. The Trading Host will send back the complete order book for all
ITMs of interest to the MTM in the OnMonitorOrderBookDetails callback.

13.2 Unsubscribe from Monitoring

(LiffeMonitorUnsubscribe/OnMonitorUnsubscribe)

This function is used by a Master ITM to cancel their registration in the ITMs they are
assigned to monitor.

API Functional Descriptions Issued Version 1.3 Page 59 of 79

13.3 Receive Notifications of Monitored ITM Order Books
(OnMonitorOrderBookDetails)

This Response Handler Function is used:

• To receive notification of all monitored ITM order books following a call to

LiffeMonitorSubscribe.

• To receive notification of new orders being submitted by a monitored ITM.

• To receive the order book of a monitored ITM receiving orders handed over from
another ITM when it logs out.

13.4 Order Submitted by Monitored ITM

(OnMonitorOrderSubmitted)

This Response Handler Function is used when a single order is submitted by a Trader by
way of a call to LiffeTradeSubmitOrders (if more than one order is submitted, then an
OnMonitorOrderBookDetails response handler is generated).

13.5 Logoff or Lock Monitored ITM

(LiffeMonitorLogoffUser/OnMonitorLogoffStatus)

This function is used to log off and optionally lock out an ITM that the MTM is monitoring.

Note: An MTM cannot unlock an ITM, this can only be carried out by contacting Market
Control of the parent Exchange.

API Functional Descriptions Issued Version 1.3 Page 60 of 79

14. Market Control

The market control warnings and messages include both pre-defined messages and text
messages. They can be initiated automatically by the Trading Host or by Exchange Staff
who will be able to send contract-based text messages to communicate with all traders
subscribed to a specific contract. Text can be transmitted in multiple languages, where
this functionality is supported by the Exchange.

14.1 Session Mode Message (OnControlSMode)

All Client Applications that have initialised the API are notified by the Trading Host when
the Trading Day starts and when it finishes. The Trading Host sends out a Session Mode
Message of ‘Session Start’ at the beginning of the Day Start and of ‘Session End’ at Day
End (see The Trading Day).

Once the ‘Session Start’ message has been received, a Client Application can establish a
session for a trader with the Trading Host. Once logged on, the trader can then subscribe
to (i.e. register an interest in) a particular futures or options contract with the Trading
Host.

The Day End period exists between the Close period and the end of the trading day. At
Day End, the Trading Host will:

• Issue the Session End Session Mode Message.

• Pull all non-GTC Orders that remain unmatched in the order book.

• Log out all market participants.

14.2 Market Mode Message (OnControlMode)

A Market Mode message reports changes to the current state of the market or trading
period. Notifications can apply at a commodity, commodity/month or individual outright or
strategy market level.

The start of the Pre-Open, Open and Day End periods is determined by individual
contract specifications. For each market to which a trader subscribes, Market Mode
messages will be sent to indicate the transition of one trading period to another in the
subscribed markets. These messages are:

• Market Pre-Open, for the start of the Pre-Open period.

• Market Open, for the start of the Open period.

• Market Pre-Closed, which is sent out shortly before each market closes.

• Market Close, for the start of the Day End period.

• Restricted Open, for the start of a reduced functionality period (available on some
Exchanges). The submission of new orders is restricted during this period.

API Functional Descriptions Issued Version 1.3 Page 61 of 79

 Note: A Market Mode message is produced when a new market is created intraday, i.e.
as a result of new option strikes being added, etc.

These messages also contain the Session ID for their respective Trading Session. This is
used by Exchanges that support more than one session during the trading day.

The following table shows the effects of market mode transmitted changes:

MARKET MODE CHANGE INDICATES

TRANSMITTED

For a commodity All individual outright and strategy markets in that commodity
have changed.

For a commodity month All individual outright markets in that commodity month, and all
strategy markets with at least one leg in that commodity month,
have changed.

Wherever possible, the Trading Host will transmit market mode changes for commodities
or commodity months, rather than individual markets, in order to reduce the volume of
transmitted messages (see The Trading Day).

The Market Mode Message is also used to notify if and when the Exchange declares:

• That a market has been enabled or disabled (suspended).

• That the price limits for a market have been disabled or re-enabled.

• That Block, Prof and Asset Allocation trades can be submitted outside market hours.

• A change to the Quote Spread Multiplier that Market Makers are obliged to provide.

• A Trading Halt for a contract.

14.2.1 Market Pre-Open

Market Pre-Open marks the start of the Pre-Open period. The time between Pre-Open
and Open can be configured individually for each contract, and may be changed by the
Exchange from time to time for any contract, to suit specific market requirements.

During the Pre-Open period, the Client Application can use any of the functions provided
by the API, including those used to submit, revise and pull orders. The only exceptions
are the Submit Ex-Pit Trade, FLEX® Submit Orders, and Submit RFQX functions which
can only be used during the Open period.

Although orders can be submitted to the Trading Host during the Pre-Open period, order
matching will not take place. This only occurs during the Market Trading period.

14.2.2 Market Enabled and Disabled (Suspended)

Exchange Staff may disable (suspend) or re-enable a market for a variety of reasons.
When disabled, all orders (including GTC Orders) that remain unmatched in the central
order book will be pulled automatically by the Trading Host, and no new orders will be
accepted.

API Functional Descriptions Issued Version 1.3 Page 62 of 79

 If this occurs, the Trading Host will not transmit OnTradePull messages for individual
pulled trades. To remain consistent with the Trading Host when a market is disabled,
Client Applications should remove all orders in that market from their own local order
books.

14.2.3 Market Open, Pre-Close & Close

The transition of trading periods from Open to Pre-Close and Close are notified to all
market participants who have subscribed to any outright or strategy market.

A Market Open message for each futures or options contract is sent at the time specified
for that contract plus a random time period of up to 20 seconds. The random time period
is to allow for variations in system loading on a day-to-day basis. All trading takes place
between the Open and Close periods for each individual contract.

The Open period allows all the API function calls to be used by Client Applications. Where
settlement prices are available for a contract before its market closes, these are
transmitted as soon as they are available (see Settlement Price Information).

A Market Pre-Close message is sent during the Open period to make subscribed traders
aware that the market will close shortly after the Pre-Close warning.

A Market Close message for each futures or options contract is sent at the time specified
for that contract. At this time, the Trading Host automatically pulls all non-GTC orders that
remain unmatched in the order book. The Trading Host will not transmit OnTradePull
messages for individual pulled trades.

During the Day End period, after the Market Close message has been received, the
Trading Host distributes closing settlement prices, for the contracts to which the trader
has subscribed, and any daily settlement prices which have not already been transmitted
during Market Trading.

At this time, traders can pull any GTC orders that they do not wish to remain in the market
for the following day. The Trading Host will not accept the following API calls:

• Requests for Market Depth (see Get Market Depth).

• All Trading and Order Handling calls (see Trading and Order Handling) except the
Pull Orders call (see Pull Orders).

When the Session Mode Message - Session End is sent out, all sessions are logged out,
and the API/Trading Host connection is shutdown.

14.2.4 Submission of trades outside market hours

LIFFE CONNECT® will support the submission of a number of ex-pit trade types within
configurable timeframes outside the usual market open period. The availability of this
facility will be configurable by contract.

The MarketMode message LIFFE_MARKET_MODE_EXPIT_EXTENDED_OPEN will be

used to report if a market is open to submit prof, block or asset allocation trades.

14.2.5 Activate/Suspend Price Limits

The Trading Host uses price limits to identify orders that have been incorrectly entered
into LIFFE CONNECT®. Orders will be rejected if they are outside a permitted price limit

API Functional Descriptions Issued Version 1.3 Page 63 of 79

 spread from the prevailing mid-price for that market. If the Exchange elects to suspend
price limits, Client Applications subscribed to that market receive a warning call. A
subsequent call is issued when the price limits are re-activated.

14.2.6 Quote Spread Multiplier

Quote Spreads are the spread between the bid and offer sides of the Market Making
Orders that Market Makers are obliged to submit to the market in particular classes.
These classes are specified in the Market Maker’s agreement with the exchange.

Under some circumstances the exchange may wish to change the value of the Quote
Spread that Market Makers are obliged to provide. This is done by applying a Quote
Spreads Multiplier (QSM). The market is informed of this change by the sending of a
Market Mode message to announce a change of QSM mode.

QSM Mode 1 is normal operation and would therefore normally have a specified QSM
value of 1. If QSM Mode 2 had a specified QSM value of 1.5, moving to this mode would
increase Quote Spreads by 50% from normal operation. If the QSM Mode 3 had a
specified QSM value of 2, moving to this mode would increase Quote Spreads by 100%
from normal operation. Three QSM modes are available.

Note: QSM Market Mode messages are for informational purposes only and no
monitoring of Market Maker obligations is carried out by LIFFE CONNECT®. It is
the obligation of Market Makers to alter their Quote Spreads as appropriate.

Market Mode messages will report the current QSM mode:

• LIFFE_MARKET_MODE_QSM_MODE1

• LIFFE_MARKET_MODE_QSM_MODE2

• LIFFE_MARKET_MODE_QSM_MODE3.

14.2.7 Trading Halt On/Off

The Client Application receives a Trading Halt message when the Exchange halts trading
in a commodity.

When the market has been halted:

• All existing orders will remain in the order book

• Orders can be pulled

• Order volume can be revised down.

• Strategies can be created

• Logon and subscription is allowed

• Logoff, nomination of a replacement trader and order transfer are permitted.

The following functions will not be permitted by the Trading Host:

• Revision of price

• Submission of orders including ex-pit orders

API Functional Descriptions Issued Version 1.3 Page 64 of 79

 • RFQs

• Revision of GTC date

• Calculation of the Indicative Opening Price during Pre-Open.

14.3 Forced Logout (OnControlLogout)

The Client Application receives a Forced Logout call when Exchange Staff activate a
lockout on the trader’s session.

14.4 Trader Exchange Suspension (TraderExchangeSuspend)

During the trading day, Market Control can block an ITM’s access to products on their
market only. When a trader is suspended all their orders, including GTCs, for contracts
within the chosen logical exchange, will be pulled. Any further orders submitted for that
logical exchange will be rejected. The trader is not logged out, but is notified of their
change in status by a TraderExchangeSuspend message.

14.5 Message (OnControlMessage)

The Client Application receives a message, containing text, which is sent by Exchange
Staff. Messages can be sent in other languages, where this functionality is made
available by the Exchange.

14.6 Contract Status (OnControlStatus)

The Client Application can receive a Contract Status call for every LIFFE CONNECT®
contract, to indicate whether the contract is available or unavailable for trading. This call
will be transmitted to all connected Client Applications whenever any contract’s availability
changes.

14.7 Invalid Operation (OnControlInvalidOperation)

The Client Application will receive an Invalid Operation call if it submits an invalid function
to the Trading Host or Gateway, and that function does not normally generate a response
from the Trading Host or Gateway. If a response is normally generated, the usual
response function will be used to provide details of any error in the submitted function.
The Invalid Operation function contains codes that indicate the invalid function that was
sent, and the reason that it has been rejected by the Trading Host or Gateway.

API Functional Descriptions Issued Version 1.3 Page 65 of 79

15. Order Handling Examples

This section provides an overview of how orders may result in trades in the electronic
order book by providing simplified examples.

15.1 General Principles

When developing a Trading Client Application, be aware of the following general

principles that apply to the way in which the Trading Host handles orders and executes
trades:

It is possible for a trader to have more than one order, at the same time, in the same
market. These are distinguished using a host-supplied Order ID which the Trading Host
then returns with any relevant Response Handler Function.

In general, trading is done simultaneously in several different markets. The Automated

Market References are used to distinguish them.

Where more than one trader is competing for an order at a specific price, preference is
given to the order according to certain criteria.

15.1.1 A Simple Matching Trade

In order to illustrate a simple case, assume a central order book which already has a Limit
Order to Buy 50 Euribor June 08 futures for 97.25. The sequence of events that occurs
when a matching order is entered can be illustrated as follows:

Step 1
Trader 2 Submit Order Host

Step 2
Trader 2 Acknowledge Host
Step 3
Time

Order Matches
Step 4
Trader 1 & 2 OnTrade Host
Step 5
All Traders OnMarketOrder, OnMarketUpdate Host

Explanation:

1. A second trader submits an order to Sell 50 Euribor June 08 futures at 97.25 using a
LiffeTradeSubmitOrders call.

2. The second trader is given an acknowledgement to the order using an

OnTradeSubmit Response Handler Function.

3. As the orders match, a trade occurs and the original order is deleted from the order
book.

API Functional Descriptions Issued Version 1.3 Page 66 of 79

 4. The two traders are notified of the trade using an OnTrade Response Handler
Function.

5. Subscribed traders are notified of the change in the central order book using an
OnMarketOrder Response Handler Function. An OnMarketUpdate Response Handler
Function is also given because there is a change to the Best Buy/Sell prices.

15.1.2 A Partially Filled Order

The following example, based on the same original order, shows the more complicated
sequence of events when the second trader wants to sell only 30 lots and at 97.30. The
traders then amend their prices to match the orders.

Step 1
Trader 2 SubmitOrder Host

Step 2
Trader 2 Acknowledge Host

Step 3
All Traders OnMarketOrder Host
Step 4
No Match, Orders Held

Step 5
All Traders OrderBookUpdate, OnMarketUpdate Host
Step 6
Trader 1 Revise Order Host
Step 7
Trader 1 Acknowledge Host
Time

Step 8
All Traders OrderBookUpdate, OnMarketUpdate Host

Step 9
Trader 2 Revise Order Host
Step 10
Trader 2 Acknowledge Host

Step 11
Orders Match

Step 12
Residual Order, Volume Updated

Step 13
Trader 1 & 2 OnTrade Host
Step 14
All Traders OnMarketOrder, OnMarketUpdate Host

Explanation:

1. A second trader submits an order to Sell 30 Euribor June 08 futures at 97.30. The
Trading Host puts the order into the central order book.

2. The Trading Host sends an acknowledgement of the order to the second trader using
an OnTradeSubmit Response Handler Function.

API Functional Descriptions Issued Version 1.3 Page 67 of 79

 3. Subscribed traders are notified of the Order Book Update using an OnMarketOrder
Response Handler Function, and an OnMarketUpdate because a best buy/sell price
has changed.

4. The orders do not match, and both orders are kept in the central order book pending
further trader action.

5. The first trader revises the order, to buy for 97.27, using a LiffeTradeReviseOrders
call.

6. The first trader then gets an acknowledgement using an OnTradeRevise Response

Handler Function.

7. Subscribed traders are sent an OnMarketOrder and an OnMarketUpdate because a

best buy/sell price has changed.

8. The second trader revises the order, to sell at 97.27, using a LiffeTradeReviseOrders
call.

9. The second trader then gets an acknowledgement using an OnTradeRevise

Response Handler Function.

10. As the orders now match in price, a trade takes place for 30 lots at 97.27.

11. The order to sell 30 lots is deleted and the central order book shows the residual
order to buy 20 lots for 97.27.

12. Both traders receive an OnTrade Response Handler Function.

13. All traders receive both an OnMarketUpdate and an OnMarketOrder Response

Handler Function.

The sequence of central order book changes is shown below:

After Step After Step After Step After Step

1 5 8 11

Buy Sell Buy Sell Buy Sell Buy Sell

Vol Vol Vol Vol Vol Vol Vol Vol

97.31 97.31 97.31

30 97.30 30 97.30 97.30

97.29 97.29 97.29

97.28 97.28 97.28

97.27 50 97.27 50 30 97.27 20

97.26 97.26 97.26

50 97.25 97.25 97.25

97.24 97.24 97.24

API Functional Descriptions Issued Version 1.3 Page 68 of 79

15.1.3 Trading against an Implied Outright Market Price

The following example, based on the prices and volumes in A Simple Matching Trade, in
the description of the Publish Implied Market Information call, shows the sequence of
events that occurs when explicitly quoted outright and strategy market prices allow the
Trading Host to publish an implied price for the other outright market in the strategy, and
another trader then enters an outright market order that trades at the implied price.

Assumptions:

A Euribor Sep 08/Dec 08 calendar spread strategy market has been defined, and the
central order book already has a Limit Order, from Trader 1, to Buy 25 Euribor
Sep 08/Dec 08 spread futures for 0.23.

Step 1
Trader 2 Submit Sep 08 Sell Order Host

Step 2
Trader 2 Acknowledge Host

Step 3
All Traders OnMarketOrder Sep 08 Host

All Traders OnMarketUpdate Sep 08 Host

Step 4
All Traders OnMarketImpliedUpdate Dec 08 Host

Step 5
Trader 3 Submit Dec 03 Buy Order Host

Step 6
Trader 3 Acknowledge Host

Step 7
Outright & Strategy Orders Match
Time

Step 8
Trader 3 OnTrade Dec 08 Host

Step 9
Trader 1 OnTradeStrategy Sep 08/Dec 08 * Host
Trader 2 OnTrade Sep 08 *

Step 10
All Traders OnMarketUpdate Dec 08 Host

All Traders OnMarketImpliedUpdate Dec 08 Host

Step 11
All Traders OnMarketOrder Sep 08/Dec 08

All Traders OnMarketStrategyUpdate Sep 08/Dec 08 *

Host
All Traders OnMarketOrder Sep 08 *
All Traders OnMarketUpdate Sep 08
* Sequence of messages (or message groups) may vary

Explanation:

1. A second trader submits an order to Sell 40 Euribor Sep 08 futures at 97.73.

API Functional Descriptions Issued Version 1.3 Page 69 of 79

 2. The Trading Host sends an acknowledgement of the order to the second trader using
an OnTradeSubmit function.

3. Subscribed traders are notified of the order book update using an OnMarketOrder
function, and an OnMarketUpdate because a best buy/sell price has changed.

4. The Trading Host calculates an implied sell price of 97.50 for the Euribor Dec 08
outright market (from the Sep 08 outright and Sep 08/Dec 08 spread prices), and
notifies subscribed traders using an OnMarketImpliedUpdate function.

5. A third trader submits an order to Buy 25 Euribor Dec 08 futures for 97.50.

6. The Trading Host sends an acknowledgement of the order to the third trader using an
OnTradeSubmit function.

7. The Trading Host matches the two outright orders against the strategy order.

8. Trader 3 receives notification of the trade in an OnTrade call.

9. Trader 1 receives an OnTradeStrategy call and Trader 2 receives an OnTrade call, as

notifications of their trades.

10. All traders receive an OnMarketUpdate function, to indicate the change to the
best/traded price/volume in the Dec 08 outright market, and an
OnMarketImpliedUpdate function, to indicate a change to the implied price/volume in
that market.

11. All traders receive two functions, OnMarketOrder and OnMarketUpdate, for the
Sep 08 outright market. These respectively indicate:

- changes to the central order book, and

- to the best/traded price/volume, in that market.

In addition, all traders receive two further functions, OnMarketOrder and

OnMarketStrategyUpdate, for the Sep 08/Dec 08 spread strategy market. These
respectively contain:

- changes to the central order book for the strategy market, and

- the updated best/traded price/volume for the strategy as well as the traded prices
and volumes for the individual strategy legs.

15.1.4 Trading against an Implied Strategy Market Price

This example, based on the prices and volumes in A Partially Filled Order, in the
description of the Publish Implied Market Information call, shows the sequence of events
that occurs when there are explicitly quoted prices in two outright markets (that allow the
Trading Host to calculate, but not publish, an implied strategy price), and another trader
then enters a strategy market order that trades at the implied price.

Assumptions:

A Euribor Sep 08/Dec 08 calendar spread strategy market has been defined, and the
central order book already has a Limit Order, from Trader 1, to Sell 40 Euribor Sep 08
futures at 97.73.

API Functional Descriptions Issued Version 1.3 Page 70 of 79

 Step 1
Trader 2 Submit Dec 08 Buy Order Host

Step 2
Trader 2 Acknowledge Host

Step 3
All Traders OnMarketOrder Dec 08 Host

All Traders OnMarketUpdate Dec 08 Host

Step 4
Trader 3 Submit Sep 08/Dec 08 Buy Order Host

Step 5
Trader 3 Acknowledge Host

Step 6
Outright & Strategy Orders Match
Time

Step 7
Trader 3 OnTradeStrategy Sep 08/Dec 08 Host

Step 8
Trader 1 OnTrade Sep 08 * Host
Trader 2 OnTrade Dec 08 *

Step 9
All Traders OnMarketStrategyUpdate Sep 08/Dec 08 Host

Step 10
All Traders OnMarketOrder Sep 08

All Traders OnMarketUpdate Sep 08 *

Host
All Traders OnMarketOrder Dec 08 *
All Traders OnMarketUpdate Dec 08
* Sequence of messages (or message groups) may vary

Explanation:

1. A second trader submits an order to Buy 25 Euribor Dec 08 futures for 97.50.

2. The Trading Host sends an acknowledgement of the order to the second trader using
an OnTradeSubmit function.

3. Subscribed traders are notified of the order book update using an OnMarketOrder
function, and an OnMarketUpdate because a best buy/sell price has changed.

4. A third trader submits an order to Buy 25 Euribor Sep 08/Dec 08 spread futures for
0.23.

5. The Trading Host sends an acknowledgement of the order to the third trader using an
OnTradeSubmit function.

6. The Trading Host matches the two outright orders against the strategy order.

7. Trader 3 receives notification of the trade in an OnTradeStrategy call.

8. Trader 1 and Trader 2 each receive an OnTrade call, as notifications of their trades.

API Functional Descriptions Issued Version 1.3 Page 71 of 79

 9. All traders receive an OnMarketStrategyUpdate function for the Sep 08/Dec 08
spread strategy market. This contains the updated best/traded price/volume for the
strategy as well as the traded prices and volumes for the individual strategy legs.

10. All traders receive two functions, OnMarketOrder and OnMarketUpdate, for both the
Sep 08 and the Dec 08 outright markets. These respectively indicate changes to the
central order book and to the best/traded price/volume in the relevant market.

15.1.5 Market On Open Orders at Market Opening

This shows the sequence of events that occur when a market opens, and there are a
variety of Market On Open (MOO) and Limit Orders in the central order book. In this
situation, standard uncrossing takes place, in order to determine an opening price, and
trade as many of the Limit Orders as possible at that price. Once the Limit Orders have
been traded as far as possible, the Market On Open Orders are traded against each other
at the opening price.

If the volume of MOO buy and sell orders is different, a residual volume will be left on one
side of the market. This residual volume will be converted automatically by the Trading
Host from MOO to Limit Orders, which may then trade against any residual Limit Order
volume. The market will then be open for trading against any remaining residual volume.

Note: This example shows a situation that begins in the Pre-Open period.

Assumptions:

All trading relates to the Euribor Sep 08 future, and that the central order book already
has two Limit Orders, one from Trader 1, to Buy 50 lots for 95.73, and one from Trader 2,
to Sell 20 lots at 95.71.

API Functional Descriptions Issued Version 1.3 Page 72 of 79

 Step 1
Trader 3 LiffeTradeSubmitOrders Buy 100 lots MOO Host

Step 2
Trader 3 Acknowledge Host

Step 3
Trader 4 LiffeTradeSubmitOrders Sell 200 lots MOO Host

Step 4
Trader 4 Acknowledge Host

Step 5
Market Opens - Uncrossing Performed - Opening Price calculated as 95.73
Step 6
Trader 1 OnTrade Bought 20 lots 95.73
* Host
Trader 2 OnTrade Sold 20 lots 95.73 *

Step 7
All Traders OnMarketOrder Buy at 95.73 res vol 30
* Host
All Traders OnMarketOrder Sell for 95.71 res vol 0 *
Time

All Traders OnMarketUpdate Sep 08 Host

Step 8
Trader 3 OnTrade Bought 100 lots 95.73 * Host
Trader 4 OnTrade Sold 100 lots 95.73 *

Step 9
Trader 1 OnTrade Bought 30 lots 95.73
*
Host
Trader 4 OnTrade Sold 30 lots 95.73 *

Step 10
Trader 4 OnTradeRevise convert MOO to Buy 70 at 95.73 Host

Step 11
All Traders OnMarketOrder Buy at 95.73 res vol 0
* Host
All Traders OnMarketOrder Sell for 95.73 res vol 70 *

All Traders OnMarketUpdate Sep 08 Host

Step 12
All Traders OnControlMode Market Open Host
* Sequence of messages (or message groups) may vary

Explanation:

1. Trader 3 submits a Market On Open Order to buy 100 lots.

2. The Trading Host sends an acknowledgement of the order to Trader 3 using an

OnTradeSubmit function.

3. Trader 4 submits a Market On Open Order to sell 200 lots.

4. The Trading Host sends an acknowledgement of the order to Trader 4 using an

OnTradeSubmit function.

5. The Trading Host changes the market state from Pre-Open to Open. The market is
uncrossed and an opening price of 95.73 is calculated. Before informing traders that
the state has changed, the Trading Host will notify them of the trades and order book
changes that take place at the opening of the market.

API Functional Descriptions Issued Version 1.3 Page 73 of 79

 6. The two Limit Orders trade 20 lots against each other at 95.73. Trader 1 and Trader 2
receive OnTrade notifications.

7. All traders receive three functions:

- An OnMarketOrder for the change to the central order book buy volume at 95.73.

- An OnMarketOrder for the change to the central order book sell volume at 95.71.

- An OnMarketUpdate for the changes to the total traded volume and the
best/traded prices and volumes in the Sep 08 futures market.

8. The two MOO Orders trade 100 lots against each other at 95.73. Trader 3 and Trader
4 receive OnTrade notifications.

The residual volume of 100 lots in Trader 4's order is converted to a Limit Order at
95.73. Before this conversion is notified to Trader 4, the Trading Host attempts to
match this against the volume that remains from the uncrossed Limit Orders.

9. Trader 4's converted order trades 30 lots against the residual volume in Trader 1's
Limit Order at 95.73. Trader 1 and Trader 4 receive OnTrade notifications.

10. Trader 4 receives an OnTradeRevise function, as notification of the conversion of the

residual volume of the MOO order to a Limit Order. It includes a price of 95.73 and a
volume of 70 (the original 200 lot order first traded 100 lots and then 30 lots).

11. The traders receive the following functions:

- An OnMarketOrder for the change to the central order book buy volume at 95.73.

- An OnMarketOrder for the change to the central order book sell volume at 95.73.

- An OnMarketUpdate for the changes to the total traded volume and the
best/traded prices and volumes in the Sep 08 futures market.

12. All traders receive an OnControlMode function to indicate that the market state has
changed from Pre-Open to Open.

15.1.6 ITM Monitoring - Viewing Order Book Details

This example details the message updates sent to a MTM monitoring the orders of an
ITM to which they have monitoring rights.

Assumptions:

Trader 1 is monitored by MTM 1 and has submitted a resting bid into 30 Year Treasury
Note, Mar 06 of 10910.

API Functional Descriptions Issued Version 1.3 Page 74 of 79

 Step 1
MTM subscribe to monitoring function through the
MTM1 Host
LiffeMonitorSubscribe

Step 2

MTM1 Acknowledge Host

Step 3
ITMs Order book details reported to the MTM through the
MTM1 Host
OnMonitorOrderBookDetails

Step 4

Trader 2 Submit Mar06 Ask for 10910 Host

Step 5

Trader 2 Acknowledge Host

Step 6

Orders match

Step 7

Time Trader 2 OnTrade Host

Trader 1 OnTrade Host

Step 8

MTM1 LiffeTradeFill Host

Step 9

All Traders OnMarketOrder Host

All Traders MarketUpdate Host

Step 10

Trader 1 Submit Mar06 Bid for 10910 Host

Step 11

Trader 2 Acknowledge Host

Step 12
ITMs Order book details reported to MTM through the
MTM1 Host
OnMonitorOrderBookDetails

Explanation:

1. The MTM subscribes to monitoring capabilities for all ITMs.

2. The Trading Host sends an acknowledgement of the Subscribe request using the
OnMarketResponse function.

3. The Trading Host then sends the order book details of all the orders of monitored
ITMs to the MTM through the OnMonitorOrderBookDetails function.

4. A second trader submits an order to sell 10910.

5. The Trading Host send an acknowledgement of the order to Trader 2 using the
OnTradeSubmit function.

6. The orders from Trader 1 and Trader 2 match.

7. The Trading Host notifies Trader 1 and Trader 2 of the trade.

8. The Trading Host sends notification to MTM 1 of Trader 1’s trade.

9. The Trading Host notifies all traders subscribed to the market, through the
OnMarketOrder function for market depth and OnMarketUpdate function for best and
trade updates.

API Functional Descriptions Issued Version 1.3 Page 75 of 79

 10. Trader 1 submits a new order into the market.

11. The Trading Host sends an acknowledgment of the order to Trader 1 using the
OnTradeSubmit function.

12. The Trading Host sends the order book details of the new order from Trader 1 to
MTM 1 through the OnMonitorOrderBookDetails function.

15.1.7 ITM Monitoring - MTM / ITM Interaction

This example describes the possible interaction between an MTM and an ITM with
regards to order and ITM status.

Assumptions:

Trader 1 is monitored by MTM 1 and has submitted a resting bid into 30 Year Treasury
Note, Mar 06 of 10910.

Step 1

MTM1 MTM Revises trader 1's order volume to 20 lots Host

Step 2

Trader 1 Acknowledge Host

Step 3

MTM1 Acknowledge Host

Step 4

Trader 1 Trader 1 submits a pull request Host

Step 5
Time
Trader 1 Acknowledge Host

Step 6

MTM 1 Acknowledge Host

Step 7

MTM 1 MTM 1 submits a requets to LOCK Trader 1 out of the Trading Host Host

Trader 1 OnAccessResponse Host

Step 8

MTM1 Acknowledge Host

Explanation:

1. The MTM submits a revise request for the OrderID for Trader 1’s order to change the
volume to 20 lots.

2. The Trading Host sends notification of the order revision to the Trader 1 through the
OnTradeRevise function.

3. The Trading Host sends acknowledgement of successful revision to the MTM through
the OnTradeRevise function.

4. Trader 1 submits a pull order request for the revised order to the Trading Host.

5. The Trading Host sends an acknowledgment of the successful pull to Trader 1

through the OnTradePull function.

API Functional Descriptions Issued Version 1.3 Page 76 of 79

 6. The Trading Host sends an acknowledgement of a successful pull by Trader 1 to the
MTM through the OnTradePull function.

7. The MTM submits a UserLock request to the Trading Host to Lock Trader 1 out of the
Trading Host.

8. The Trading Host notifies Trader 1 that it has been locked out of the Market through
the OnAccessResponse.

9. The Trading Host sends acknowledgement of the successful UserLock request.

15.1.8 Stop Order activation, the converted Stop order then rests in the market

This example describes the messages used to notify the trader of Stop order status.

Assumption:

Trader 1 has submitted a Normal Limit Bid of 10909 into the 30 Year Treasury Note, Mar
06.

Step 1

Trader 2 Submits a Stop (LIMIT) order with a Trigger price of 10910 Host

Step 2

Trader 2 Acknowledge Host

Step 3

Trader 3 Submits a Market Ask into the Treasury Note Mar06 Host

Step 4

Trader 3 Acknowledgement Host

Time
Step 5

Orders match

Step 6

Trader 3 OnTrade Host

Trader 1 OnTrade Host

Step 7

Trader 2 OnTradeRevise Host

1. A second trader submits a Stop (Limit) order with a trigger price of 10910 which is
accepted into the Trading Host and rests outside the central order book.

2. The Trading Host sends acknowledgement to Trader 2 through the OnTradeSubmit

function.

3. A third trader submits a Market Offer into the Treasury Note Mar 06.

4. The Trading Host sends an acknowledgement to Trader 3 of the successful

submission through the OnTradeSubmit function.

5. Trader 1 and Trader 3’s orders trade.

6. The Trading Host notifies Trader 1 and Trader 3 of their trade through the OnTrade
function.

API Functional Descriptions Issued Version 1.3 Page 77 of 79

 7. The Trading Host notifies Trader 2 that the Stop (LIMIT) order has been triggered but
not traded and hence is resting in the central order book, through the OnTradeRevise
function.

15.1.9 Stop order activation, the converted Stop order then trades

This example describes the messages used to notify the trader of Stop order status.

Assumption:

Trader 1 has submitted a Normal Limit Bid of 10909 (10) and Trader 2 has submitted a
Normal Limit Bid of 10908 (10) into the 30 Year Treasury Note, Mar 06.

Step 1

Trader 3 Submits a Stop (LIMIT) order with a Trigger price of 10910 (20) Host

Step 2

Trader 3 Acknowledge Host

Step 3

Trader 4 Submits a Market Ask into the Treasury Note Mar06 Host

Step 4

Trader 4 Acknowledgement Host

Time
Step 5

Orders match

Step 6

Trader 4 OnTrade Host

Trader 1 OnTrade Host

Step 7

Trader 2 OnTrade Host

Trader 3 OnTrade Host

Explanation:

1. A third trader submits a Stop (LIMIT) order with a trigger price of 10910 for 20 lots,
which is accepted into the Trading Host and rests outside the central order book.

2. The Trading Host sends an acknowledgement to Trader 3 through the

OnTradeSubmit function.

3. A fourth trader submits a Market Offer into the Treasury Note Mar 06.

4. The Trading Host sends an acknowledgement to Trader 4 of the successful

submission through the OnTradeSubmit function.

5. Trader 1 and Trader 4’s orders trade.

6. The Trading Host notifies Trader 1 and Trader 4 of their trade through the OnTrade
function.

7. The Trading Host notifies Trader 2 that the Stop (LIMIT) order has been triggered and
traded through the OnTrade function. The residual volume within the OnTrade
function indicates that some of the Stop order remains resting in the central order
book. The Trading Host also notifies Trader 3 of the trade through the OnTrade
function.

API Functional Descriptions Issued Version 1.3 Page 78 of 79

15.1.10 Stop order activation, the converted Stop order is then pulled

This example describes the messages used to notify the trader of Stop order status.

Assumptions:

Trader 1 has submitted a Normal Limit Bid of 10909 (10) and Trader 2 has submitted a
Normal Limit Bid of 10901 (10) into the 30 Year Treasury Note, Mar 06.

The current reference price is 10913 with the price limits set to 10, so that the price limit
range is 10903 – 10923.

Step 1

Trader 3 Submits a Stop (MARKET) order with a Trigger price of 1090 (20) Host

Step 2

Trader 3 Acknowledge Host

Step 3

Trader 4 Submits a Market Ask into the Treasury Note Mar06 Host

Step 4

Trader 4 Acknowledgement Host

Time
Step 5
Orders match

Step 6

Trader 4 OnTrade Host

Trader 1 OnTrade Host

Step 7

Trader 2 OnTradePull Host

Explanation:

1. A third trader submits a Stop (MARKET) order with a trigger price of 10909 for 10 lots
which is accepted into the Trading Host and rests outside the central order book.

2. The Trading Host sends an acknowledgement to Trader 3 through the

OnTradeSubmit function.

3. A fourth trader submits a Market Offer into the Treasury Note Mar 06.

4. The Trading Host sends an acknowledgement to Trader 4 of the successful

submission through the OnTradeSubmit function.

5. Trader 1 and Trader 4’s orders trade.

6. The Trading Host notifies Trader 1 and Trader 4 of their trade through the OnTrade
function.

7. The Trading Host notifies Trader 2 that the Stop (MARKET) order has been triggered
and but has been pulled as it attempted to trade outside price limits, through the
OnTradePull function.

API Functional Descriptions Issued Version 1.3 Page 79 of 79