LIFFE CONNECT® Release 8

Developer Workshop

Amsterdam
April 28 2004
Agenda

• General Update and Progress Report

Paul MacGregor
Director, Technology Partnerships

• LIFFE CONNECT® Release 8 Key Changes

Ralph Bird
Technology Development Manager

• Key Dates and Conformance Requirements

Janneke Willekens
Senior Account Manager

2
 LIFFE CONNECT® API Software
• API Software is now released via the Developer Diary
website:
http://liffedeveloperdiary.if5.com/

• Latest version of API – 8.0.1 – now available for download

and supersedes 8.0

• Contains key enhancements to ‘Retrieve Fills’ functionality:

OnTradeFill
OnTradeFillStrategy

• Please download the new version now!

3
 LIFFE CONNECT® and “ELPS”
• Amsterdam market adopts a particular market model –
“Euronext Liquidity Provider Scheme” - which requires
competing market makers in every option series
• As a result LIFFE CONNECT® Release 8 has focused on the
capacity and functionality to support this model, e.g.:
- MMOs with delta protection
- Stock Order Routing
- Market Data Throttling
- Overall huge capacity uplift in hardware, software and
networks
• However in order for ELPS to remain successful, two further
elements are required:
Clear differentiation between Primary Market Makers
(“PMMs”), Competing Market Makers (“CMMs”) and Traders
Inbound Order Throttling

4
 LIFFE CONNECT® changes for “ELPS”
• PMMs will have the ability to submit ‘full’ MMOs i.e. 65
double-sided quotes
• CMMs will have the ability to submit ‘partial’ MMOs i.e. 7
double-sided quotes
• Batch functionality (current functionality on LIFFE
CONNECT®) will be limited to 1 for traders
• PMM / CMM differentiation will be set at the Host level –
CMMs breaching their MMO size will have all orders
rejected
• API sessions will be limited to 4 submits / revisions per
second per contract (API session limit remains at 100
msgs/sec)
• Mirrors the situation on SWITCH today – but no changes for
London, Paris, Brussels or Lisbon

5
 Implications of changes for Developers

• Inbound order throttle requires a new API - version 8.0.2

• No functionality changes – a recompilation for Developers

• New API will be available June 28

• No PMM / CMM differentiation data will be sent to the ITM

• Developer must be aware of MM commitment and have the

relevant controls in place

6
 Functionality per market
Amsterdam London, Paris, Brussels,
Lisbon
MMO Available Unavailable at launch
Delta protection Available Unavailable until MMOs are
implemented
Stock order routing Available Unavailable
Cash prices Available Unavailable
Trade fills replay Available Available
Persisted MOO Available Available
API Compression Available Available
Single ITM Available Available
Series on request Available Unavailable

7
 Market ‘rules’ per market
Amsterdam London, Paris, Brussels,
Lisbon
‘Submit’ / ‘Revise’ throttle 4 mps N/A
per API session per
contract
API session limit 100 mps

PMM MMOs submission 65 double- Unavailable

sided quotes
CMM MMOs submission 7 double- Unavailable
sided quotes
Batch submission 1 16
Batch revise 1 64
Outbound market data Configurable N/A
throttle

8
LIFFE CONNECT® Release 8
Key Changes

Ralph Bird
Technology Development Manager
Recap of Key API changes
• Market Making Orders (MMOs)
• Delta Protection
• Persisted Trade Fills
• Market Data Dissemination of Underlying
• Stock Order Routing
• Persistent Market on Open Orders (PMOs)
• Quote Spread Multiplier levels (QSMs)
• Open / Closed Indicators
• Session ID in Trade Reports
• Standing Data changes

10
Recap of Key Behavioural changes
• Indicative Opening Prices for Options
• Additional Required Order input field validation
• Block Trades outside central market hours
• Single Member ITM
• Contingent Multiple Orders (CMOs) disabled on Equities
Host
• Additional Delta Neutral Strategy
• Series on Request = non-standard strike intervals
• Market Data Control (Host & Gateway levels)
• Order Entry Restrictions (Class & ITM levels)

11
Market Making Orders (MMOs) (1)
• Allows ITMs to enter double-sided quotes (Bids & Offers)
into a series with one transaction.
• Usage depends on ITM access rights within each class.
So subject to appropriate trading rights :
Within an MMO specified Class -
• Only ITMs registered to submit MMOs in this class
(i.e. Liquidity Providers) will be allowed to do so
• These ITMs (PMMs / CMMs) will not be allowed to
submit any other order type in this class (but can
into classes where they are not a PMM or a CMM)
• Other ITMs can only submit other order types
With other Classes -
• ALL ITMs can submit other order types
• NO ITMs can submit MMOs.

12
Market Making Orders (MMOs) (2)
• Minimum number of MMOs in a batch is 1
• There will be 2 Maximum values:
- A PMM can submit up to 65 pairs
- A CMM can submit up to 7 pairs
• If a batch contains more than the maximum allowed then
the whole batch will be rejected
• Orders in a batch MMO are processed sequentially
- If two pairs are for the same market then the second
pair will supersede the first pair
• The Trading Host will not validate the spread between the
bid and offer in an MMO.

13
Market Making Orders (MMOs) (3)
• “One Replaces Other” – Absolute revision
(Bids replace existing Bids, Offers replace existing Offers)
• In order to protect against accidental backwardation,
orders are entered as follows:
IF both sides of MMO are revisions
IF offer side order revised upwards
enter offer side
enter bid side
ELSE
enter bid side
enter offer side
ELSE
enter bid
enter offer

14
Market Making Orders (MMOs) (4)
• All MMOs in a batch should be for the same class
- If NOT, the first MMO will be accepted and any MMO
not for that class will be rejected
• MMOs can be submitted as single-sided as well as
double-sided
- For example MMOFlag in the LiffeMMOPairList
structure should be set to LIFFE_MMO_NULL_SELL
when only providing the Buy side
- Note response will have a LiffeStatus for the Sell side
of LIFFE_STATUS_UNDEFINED and THIS IS NOT
AN ERROR but confirmation of request to leave the
sell side undefined

15
Market Making Orders (MMOs) (5)
• MMOs are abbreviated standard orders.
- The Account, Posting and UserSpecified data is held
in a common header
• Each MMO within a batch needs to specify :
• Series
• Bid Price & Bid Volume
• Ask Price & Ask Volume
- Volume set to zero(0) means all volume for that side
of the order will be pulled – effectively a delete
- Can specify different volumes for Bid and Ask
• Each MMO is split into individual orders with each being
allocated individual order IDs
• MMO orders may be pulled from the market using the
standard function call LiffeTradePullOrders

16
Questions on Market Making Orders
• What happens if one side of a pair fails price limits?
- If either side of a pair fails price limits then both orders
in the pair are rejected.
• Can I transfer orders if I lose connection?
- No. MMOs effectively act as Limit orders. They can be
entered during Pre-Open, Open and Pre-Close and do
not persist if ITM logs out or gets disconnected.
• Can I use the same ITM to ”Hit and Lift” as I use to
make markets?
- No. You will need a second non Market Making ITM to
submit any limit orders (i.e. Immediate & Cancel)
• Can I revise the Account and Posting info in an MMO?
- MMOs are applied to the order book as “order
revisions”. So the header information will not be revised
with an “overwriting” MMO. Pulling the old MMO and
submitting a new MMO will achieve this for you.

17
Delta Protection (1)
• Offers Market Makers a degree of protection against
being traded on multiple quotes simultaneously
• Facility only works in conjunction with Market Making
Orders (MMOs)
• System maintains a cumulative Delta Position on a
Contract or Expiry basis which is updated whenever an
MMO trades
• Delta Position can also be adjusted through the API
• When Delta Position exceeds a set limit, action is taken to
warn the trader and, optionally, to pull the remaining
MMOs

18
Delta Protection (2)
• Only available for contracts explicitly registered for use.
- New attribute DeltaProtection in standing data
• Only available to Market Makers explicitly registered to
participate in this facility in a particular class
• The Market Maker will define a set of parameters for each
class where Delta Protection is required :
CLASS EXPIRY
Parameter Type Settable Updateable
y/n y/n
Delta Protection Active boolean yes yes C&E no n/a
Delta Limit unsigned yes yes(abs) C yes(abs) E
Delta Position signed no yes(rel) C yes(rel) E
Limit Breached Action enumeration yes yes C yes all E

19
Delta Protection (3)
• The “Delta Protection Active” flag – True or False
- Used to determine whether user wants facility to be in
operation or not for a specific class
• The “Delta Limit” – Largest magnitude that the “Delta
Position” is allowed to reach before triggering the “Limit
Breached Action”
• The “Delta Position” represents the net delta position for
all MMO trades (occurring after facility was enabled) for a
given class
• The “Limit Breached Action” can be a warning message
or a warning message and Pull of any remaining MMOs in
the class or expiry

20
Delta Protection (4)
• LiffeTradeSetDeltaProtection is the function to use to
set a delta threshold using these parameters
• LiffeTradeGetDeltaProtection – this function should be
used sparingly for “refresh” purposes. It must NOT to be
used to poll the host for updates
• Position changes will be reported through the function
OnTradeDeltaPositionUpdate
New ? posn = Current ? posn ± (Option? × No Lots × Lot size)
Where the sign is
+ive for Buy a Call or Sell a Put
-ive for Buy a Put or Sell a Call
• Market Makers can adjust the value of their delta position
by specifying a relative shift using a signed value through
the function LiffeTradeAdjustDeltaPosition

21
Delta Protection (5)
• Once a Market Maker’s Delta limit has been breached in
a particular class or expiry, and he has elected to have
all remaining MMOs pulled, the system will stop further
MMOs from entering the market until …
- The appropriate delta limit is increased, or
- The magnitude of the Delta Position is decreased so
it no longer breaches the limit, or
- The facility to “Pull MMOs” on breach is deactivated,
or
- Delta-Protection is deactivated
• Note that where the class has been configured for
expiry level delta protection, class level manual updates
will not be permitted – the class level in this case is
determined by sum of the expiry level positions

22
Questions on Delta Protection (1)
• Can I submit an MMO once my delta limit has been
breached?
- If you have elected to have your remaining MMOs
pulled when your limit is breached you will need to re-
set your delta limit before you can submit a new MMO.
If delta protection is active but “Pull MMOs” on limit
breach is NOT, you will be able to continue to submit
further MMOs
• Can I set my delta limit to zero to disable the facility?
- No. Zero is not treated as a special case. With a zero
delta limit any MMO which trades with a non-zero delta
will trigger a breach
• Can I set Delta Protection for an entire member firm?
- No. Delta Protection works on a per ITM basis.

23
Questions on Delta Protection (2)
• If I adjust my Delta Position manually so that my Delta
Limit has been breached will all my outstanding
MMOs be pulled?
- No. The system will only pull remaining MMOs in
reaction to a trade. In the scenario you describe only
an additional MMO trade, whilst you are in this state,
would trigger the pull of the remaining MMOs
• What should I set the ExpiryBreachAction to when
setting my delta limit at class level only?
- We recommend that you set it to LIFFE_DP_IGNORE
leaving it undefined will cause the request to fail

24
Persisted Trade Fills (1)
• Trade reports are now available to clients who may have
missed trades through not being logged on
• Facility has been enhanced with API 8.0.1 to reflect the
method of trade reporting seen in real-time :
OnTrade ? OnTradeFill
OnTradeStrategy ? OnTradeFillStrategy
• ITM can request report of all Trades he alone has filled for
the current day, (including all ex-pit trades) through the
LiffeTradeRetrieveFills function
• The data returned includes the Automated Market
Reference (AMR), Order ID, Trade ID, Trade Price, Trade
Volume, Trade Time, Session ID, and TRS Order ID and
a record of any residual volume left

25
Persisted Trade Fills (2)
• All Trades completed on the Trading Host are reported
- Includes any trades which may have been busted in
the Clearing System
• Both OnTradeFill and OnTradeFillStrategy call-backs will
be sent following a LiffeTradeRetrieveFills request
- Regardless of whether any outright or even any
strategy trades have actually taken place
- Expect both call-backs
• The OnTradeFillStrategy call-back includes the leg
information in the same way as the OnTradeStrategy
call-back

26
Questions on Persisted Trade Fills (1)
• What is the maximum number of Trade Fills I could
get returned in one message?
- You don’t need to worry about that, both the
OnTradeFill and the OnTradeFillStrategy call-backs
contain a value for the number of trade fills contained
in the call-back’s linked list. Should more than one
call-back be required the continuation flag will be set
and subsequent call-backs made.
• Does the Trade Fill information contain the timestamp
of when the trade occurred?
- The LiffeTradeFillList structure contains the timestamp
of the time associated with the trade. The timestamp
in the OnTradeFill call-back is the time at which the
Host sent the response to the retrieve fills request,

27
Questions on Persisted Trade Fills (2)
• Can I request my Trade Fills for the previous day’s
trading?
- No. All records of fills are cleared out at the end of
every day
• How often can I check on Trade Fills?
- There is no reason to use LiffeTradeRetrieveFills
more than once per API session. This call is only
intended for use when an ITM logs on to check for
any missed trades when not logged on
• What if I submit a Block trade before the market
opens?
- All trades, including ExPit trades are included in the
persisted trades list

28
Market Data Dissemination of Underlying
• Cash prices
- Initially for Amsterdam stocks only
• Trade prices and volumes and Best Bid and Offer prices
and volumes and Total traded volume
• Contract information in standing data
- LiffeContractInfoList – TradingType set to “L”
• Subscribe using existing API function call
- LiffeMarketSubscribe
• LIFFE_LEVEL_COMMODITY
• LIFFE_SUBSCRIBE_BEST_PRICE
• Data given through OnMarketUpdate call-back

29
Stock Order Routing
• Message passing facility between front end applications –
messages routed via Trading Host
• i.e. Allows a Trader to send a stock order request to his
clearing member for execution
• Available when both users are logged onto the system
and stock order routing is enabled
• Available to ALL ITMs
• No trading takes place on the Trading Host
• No validation of the data other than for routing purposes
• Responsibility of the application solutions to determine
“protocol” of messages.

30
 Persistent Market on Open Orders (PMOs)
• Additional Market On Open order type – does not replace
existing
• Included in orders returned when requesting GTCs
- LiffeMarketRetrieveOrders
• PMOs which remain in order book after uncrossing will be
converted to GTCs
• Expiry date can be specified (“Good till Date”)
• Remain in order book if originating ITM loses connection /
logs out
- Cannot be transferred
- Survive Host failure

31
QSMs and Open / Close Indicators
• Quote Spread Multipliers
- Covers current Amsterdam “Fast Market” functionality
- Disseminated through the OnControlMode function –
MarketMode flag indicates which level is set
- QSM levels and Market Maker commitments agreed
between Exchange and Market Maker – no values for
the different QSM levels are disseminated through the
standing data
• Open / Close Indicators
- Users may specify different open / close indicators for
individual legs of a strategy
- First leg open, second leg closed – X
- First leg closed, second leg open – Y

32
Trade ID and Session ID in Trade Reports
• The following response handlers have been modified to
support the addition of a Trade ID :
- OnTrade
- OnTradeStrategy
- OnTradeExPitTrade
- OnTradeFlexTrade

• OnTrade and OnTradeStrategy have also been modified

to include a Session ID
• TradeId and SessionId are also included in the
TradeFillList and TradeFillStrategyList records returned
with the OnTradeFill and OnTradeStrategyFill call-backs

33
Standing Data changes
• Delta Protection
- The LiffeContractInfoList structure has been extended
to include an attribute to define at what level the facility
has been configured, if any, for the contract
• Market Information
- The TickSizeDenominator field has been moved from
the LiffeContractMonthInfoList structure to the
LiffContractInfoList structure as the tick size
denominator is the same for all months
- The LiffeContractInfoList structure now includes a
TradeTickSizeNumerator which facilitates the
dissemination of prices from the CASH market.
- Future and Options markets will continue to use the
TradeTickSizeNumerator in the
LiffeContractMonthInfoList structure

34
Behavioural Changes (1)
• Indicative Opening Prices
- Indicative opening prices for options will now be made
available through the API
- Uses same callback as existing futures indicative
opening prices
• OnMarketUpdate
• LIFFE_EXTENT_INDICATIVE_OPENING
• Required Order Information
- Additional validation has been introduced for EADM
when submitting orders. Required fields include
• UserSpecifiedField
• AccountCode
• CustomerReference
Affects Orders, CMO and ExPit Trade submissions

35
Behavioural Changes (2)
• Block Trades outside Central Market hours
- The availability of the Block Trade functionality is
indicated through the value of the MarketMode bit flag
in the OnControlMode message
• LIFFE_MARKET_MODE_EXPIT_BLOCK_OPEN
• CMOs are not enabled on the Equities Host
- The EADM will reside on the Equities Host so no CMO
facility is available for Amsterdam markets
• New Delta Neutral / Volatility Strategy
- Strategy code “k”
- Consists of a buy put leg, a buy call leg (at a higher
strike) and an underlying leg.

36
Behavioural Changes (3)
• Single Member ITM
- No longer necessary to have separate ITMs for
accessing the main exchanges
- Developer now has the choice. Can design solution
around multiple ITMs or single ITM with access to all
exchanges / products
• Series on Request
- Developers need to be able to cope with non-standard
strike price intervals
• Conditional Opening of Markets
- Markets open when underlying trade price is received
else markets remain in the pre-open state

37
Market Data Control (1)
• Expectation is that we will see very high volumes of
market updates following the EADM migration
• We have recognised that some measure of Client
Application load management is required
• Similar measures to those used with market data
dissemination in SWITCH system are to be adopted
- Summarisation of update Information
- Throttling of market data updates
• Measures are fully configurable
• Only Market Data updates affected

38
Market Data Control (2)
• Summarisation of updates works off the principle that the
most recent data is to be published and stale data is to be
discarded
• Can be configured for Host and/or Gateway
- Per Contract
- When at Gateway level - Per API session
• “Coalescing of data” or “Collapsing” or “Compounding of
data”
• Affects Best Bids and Offers, Depth, Implied prices and
covers strategies as well as outrights
• Does not affect Trades, Order confirmations, Market
mode messages etc.

39
Market Data Control (3)
• Summarisation of updates affects the sequence
numbering
- API Manual states sequence numbers are there to
“allow identification of missed updates”
• For an outright market the OnMarketUpdate,
OnMarketImpliedUpdate and OnMarketOrder messages
form a single sequence
• For strategy markets the sequence is made from
OnMarketStrategyUpdate messages and OnMarketOrder
messages
• When summarisation is taking place the sequence
numbers will be set to “-1”

40
Market Data Control (4)
• Summarisation of data is either ON or OFF.
- No High and Low water mark
- Just enabled and active or disabled and inactive
• Throttling of market data output to configurable levels
- Now have the ability to restrict the Host output to a
configurable maximum number of updates per second
(or per X milliseconds)
- Restrict output of a specific contract or group of
contracts to a maximum level (i.e. 5000 per second)
- Summarisation is inherent with Throttling
- Affects all Market Data users

41
Key Dates & Conformance
Requirements

Janneke Willekens
Senior Account Manager
Key Dates for Release 8
• New API 8.0.1 available April 19

• ISV/MD Conformance Testing June 7 - July 30

• ISV/MD Preliminary & Functionality Conformance June 7 - 30

• Non Amsterdam ISV/MD Volume conformance June 7 - 30

• New API 8.0.2 available June 28

• ISV/MD Volume Conformance (With Throttle) July 1 - 30

(Amsterdam)

• Backwards Compatibility Testing July 1 - 16

• Member Software Rollout July 2 – August 20

• Connectivity Test for non Amsterdam ISV/MD July 1 - 30

43
Key Dates for Release 8
• API 8.0.2 Equity host live August 9

• API 8.0.2 Financials Host live August 23

• Dress Rehearsals (Amsterdam only) Aug 23 – Sep 10

• Saturday Full Market Test September 11

44
What is Conformance Testing ?
• Preliminary conformance: connectivity & receive contract
data (New Developers only)

• Functionality: Full test of all API functionality supported

• Volume: Load testing at pre-defined levels

• Backwards Compatibility Testing-Ensuring API 7.1

communicates with upgraded trading host API 8.0.2

• API 8.0.2 Environments will be Env 14 (Financials) and

Env 53 (Equities)

45
Technical Conformance-getting started
• New Developers:
To get access to the test environments, call CTSG:
+44 (0)20 7379 2983

• There will be an Amsterdam freephone number for CTSG

routed to London and answered by Dutch speakers

• Existing Developers:
Please discuss with CTSG which functionality you will be
supporting so we can prepare scripts

• Any further questions e-mail:

- ctsg@liffe.com, or
- technologypartnerships@euronext.com

46
Conformance Details
• Test environments can be accessed via the following:
- ISDN
- VPN
- ISV Infrastructure
- Member infrastructure

• For all New Developers please liaise as soon as possible

with your Technology Partnerships Account Manager to
discuss access route

47
Conformance Details
• To access test environments test keys must be obtained
from Customer Technical Support Group (CTSG)

• CTSG helpdesk is open from 9-00 until 19-00 (CET)

Monday to Friday

• Calls must be logged with helpdesk +44 (0)20 7379 2983

• E-mail ctsg@liffe.com

48
Conformance Details
• Functional Conformance follows 5 API streams with an
analyst assisting ISV/MD throughout
• An ISV/MD script (Downloadable from Developers
Website) is used based on functionality you are
supporting
• Daily conformance schedule which includes times for host
failures and volume conformance. Volume conformance
must always be pre-booked
• We will conform the following access routes separately
- Full 2 Mb circuits
- Combined 128K leased line access/internet 128k
access

49
Volume Conformance
• Volume conformance confirms that under high levels of
market data the ISV/MD software maintains connectivity
and low latency-It will also confirm that the application
correctly works with the intelligent throttle if ISV/MD
supports Amsterdam
• There will be a staggered increase in volume during test
and we will share results and any issues with regard to
connectivity or high latency a.s.a.p
• All 2 Mbits Volume conformance will have to be accessed
via remote gateways at own site, a friendly members site
or via ISV’s own 2 Mbits infrastructure
• During volume conformance we will automatically point
members gateways from live to test and back again

50
Volume Conformance
• Remote gateways will only be used for volume
conformance. For all other tests the ISV/MD will need to
use central gateways
• All Equity gateways are being upgraded to V210 and we
are prioritising these installs for ISVs/MDs
• Volume conformance will have to be taken with
applications linked to both financials and equities
gateways (Unless we have prior agreement)
• Volume conformance over a 2 Mbits infrastructure will
take place between 23:00(CET) /22:00(London) and
00:30(CET)/23:30(London)
• ISV/MD using 2 Mbits infrastructure not currently trading
on LIFFE CONNECT® will be able to participate in
volume conformance after 19:30 (CET)/ 18:30 (London).

51
Volume Conformance – “Light Access”
• The internet VPN solution supports bandwidth allocation
on a user by user basis and each user will be allocated
128 kbits
• Volume conformance for Light access can be carried out
over a member’s light access 128 kbits connection or
from the ISVs office
• Aim of this conformance is to confirm efficient use of 128
kbits of bandwidth and confirm timely processing of data
by the application
• VPN conformance will also cover the 128 kbits leased line
conformance
• Volume conformance for Light access can be carried out
after 19:30 (CET)/ 18:30 (London).

52
“Light Access” Guidelines
• There are a number of possible combinations of contract
subscriptions at market depth across a “light access”
solution for the Amsterdam products:

• Futures Trader - All Futures contracts

• Options Trader
10% of AEX Option
2 High liquid Equity options (e.g. Royal Dutch)
1 High & 3 Medium Liquid Equity Options
5 Medium liquid Equity Options (e.g. Elsevier)

53
New Access Category for ISVs
• Euronext.liffe will introduce a new “light access” category
on website and in the “Directory of Access Solutions”

• Euronext.liffe will introduce a new Market Making category

• Tiering requirements for API 8 can be found on the

Developer Diary website:
http://liffedeveloperdiary.if5.com

• Any questions on above please contact your Account

Manager

54