MEFFGate · 2010. 3. 8. · 8.1 Prior considerations ... This document provides examples for a specific version of the MEFFGate FIX interface. In this case version C1.3. The version

MEFFGate EXAMPLES FIX INTERFACE C1.3

Version: C1.3.a 31 January 2008

This document refers exclusively to version C1.3 of the MEFFGate

FIX Interface

The information contained in this document is subject to modification without notice. Unless otherwise indicated, the companies, names and data used in the examples are fictitious. No part of this document may be reproduced or transmitted in any form or by any means, be it electronic or otherwise, for any reason without written permission. © 2008 MEFF. All rights reserved

To generate some examples the time and date in some of the equipment used had to be modified. Accordingly, the dates and times given in the example messages should not be considered. More information on how these fields behave can be found in the manual or by crossing similar messages in the test environment.

MEFFGate - Examples FIX Interface C1.3.a Introduction

i

Table of Contents

1. Introduction....................................................................................................................................1 1.1 Scope of this manual .............................................................................................................................1 1.2 Version of manual .................................................................................................................................1 1.3 Structure of the document .....................................................................................................................1 1.4 Conventions used..................................................................................................................................1 1.5 Prior considerations...............................................................................................................................1 1.6 Related documents ...............................................................................................................................2

2. FIX Session.....................................................................................................................................3 3. Common Application Messages ................................................................................................11 4. Contracts Information .................................................................................................................13

4.1 Contract Information – Definition and Status .......................................................................................14 4.2 Contracts dynamic information ............................................................................................................17

5. Monitoring and Managing Position............................................................................................20 6. Consultation of trades of session..............................................................................................29 7. Trade Management ......................................................................................................................32

7.1 Allocations and transfers .....................................................................................................................32 7.2 Give-up (Executing Broker) .................................................................................................................36 7.3 Give-up (Clearing Broker)....................................................................................................................39 7.4 Give-up (Clearing Member) .................................................................................................................41 7.5 Give-up – Use of the Give-Out/In mnemonic.......................................................................................43

8. Exercise Instructions ..................................................................................................................45 8.1 Prior considerations.............................................................................................................................45 8.2 American options before the expiration date .......................................................................................46 8.3 Expiration date ....................................................................................................................................49 8.4 Exercise result .....................................................................................................................................52

9. Communication of Events ..........................................................................................................54 10. Give-up References and Filters Management...........................................................................55


ii

Index of Examples

1. Introduction....................................................................................................................................1 1.1 Scope of this manual .............................................................................................................................1 1.2 Version of manual .................................................................................................................................1 1.3 Structure of the document .....................................................................................................................1 1.4 Conventions used..................................................................................................................................1 1.5 Prior considerations...............................................................................................................................1 1.6 Related documents ...............................................................................................................................2

2. FIX Session.....................................................................................................................................3 1 Logon to start FIX session............................................................................................................................................................. 3 2 Reception of heartbeats ................................................................................................................................................................ 4 3 Receiving and sending session messages .................................................................................................................................... 4 4 Logout ........................................................................................................................................................................................... 5 5 Reconnection Logon ..................................................................................................................................................................... 5 6 Sending Test Request message.................................................................................................................................................... 5 7 Logout ........................................................................................................................................................................................... 6 8 Reconnection Logon (with request to resend messages) .............................................................................................................. 6 9 Request repetition of messages from the beginning of the session ............................................................................................... 7 10 Logon to restart session ................................................................................................................................................................ 7 11 Logout ........................................................................................................................................................................................... 8 12 Logon with higher sequence number than expected by MEFFGate............................................................................................... 8 13 Sending GapFill (Sequence Reset message) ................................................................................................................................ 8 14 Logout ........................................................................................................................................................................................... 9 15 Logon with lower sequence number than expected by MEFFGate................................................................................................ 9 16 Logon rejected because password incorrect.................................................................................................................................. 9 17 Logon indicating incorrect environment ....................................................................................................................................... 10

3. Common Application Messages ................................................................................................11 1 Request subscription to MEFFGate communication status.......................................................................................................... 11 2 Loss of connectivity with the central systems .............................................................................................................................. 11 3 Restoration of connectivity with central systems.......................................................................................................................... 11 4 Disconnection by ending of session ............................................................................................................................................ 12 5 Password change........................................................................................................................................................................ 12

4. Contracts Information .................................................................................................................13 4.1 Contract Information – Definition and Status .......................................................................................14

1 Request definition and status of all the contracts with updates.................................................................................................... 14 2 Contract definition request. Rejected because field 55 (Symbol) missing.................................................................................... 15 3 Request definition and status of contract IXZ05 with updates...................................................................................................... 15 4 Request to terminate previous subscription................................................................................................................................. 16 5 Request of definition and status of all call options contracts without updates .............................................................................. 16 6 Request termination of initial subscription ................................................................................................................................... 16

4.2 Contracts dynamic information ............................................................................................................17 1 Request price information with updates for contract IXZ05.......................................................................................................... 17 2 Request price information with updates for all contracts.............................................................................................................. 17 3 Traded volume variation .............................................................................................................................................................. 18 4 Request to terminate second subscription................................................................................................................................... 18 5 Determination of closing price ..................................................................................................................................................... 18 6 Request price information. Rejected due to error in field 267 (NoMDEntryTypes) ....................................................................... 19 7 Request price information. Rejected due to duplicated identifier ................................................................................................. 19

5. Monitoring and Managing Position............................................................................................20 1 Solicitud de snapshot de posición abierta (sin posición abierta) .................................................................................................. 20 2 Request subscription of open (without open position).................................................................................................................. 20 3 First modification in the position of accounts requested............................................................................................................... 22 4 Second modification in the position of the requested accounts.................................................................................................... 23 5 Position adjustment ..................................................................................................................................................................... 23 6 Position adjustment end .............................................................................................................................................................. 24 7 End of session............................................................................................................................................................................. 24 8 New clearing session .................................................................................................................................................................. 25 9 Subscription request of open position (with open position) .......................................................................................................... 25 10 Modification of the position .......................................................................................................................................................... 27 11 Position adjustment ..................................................................................................................................................................... 28 12 Termination of previous subscriptions ......................................................................................................................................... 28

6. Consultation of trades of session..............................................................................................29 1 Request snapshot of proprietary trades....................................................................................................................................... 29 2 Request subscription of all proprietary trades.............................................................................................................................. 29 3 Trade crossed ............................................................................................................................................................................. 30 4 Request snapshot of all cleared trades........................................................................................................................................ 30 5 Query of a trade by clearing register number............................................................................................................................... 31

7. Trade Management ......................................................................................................................32 7.1 Allocations and transfers .....................................................................................................................32

1 Subscription to all the clearing house trades via Trade capture Report Request message.......................................................... 32 2 Request of partial allocation of a daily account trade................................................................................................................... 34


iii

3 Request of daily account allocation. Rejected for exceeding the pending volume to allocate ...................................................... 35 7.2 Give-up (Executing Broker) .................................................................................................................36

1 Subscription to all the clearing house trades via Trade Capture Report Request message......................................................... 36 2 Request of Give-up. Pending acceptance by the Clearing Broker ............................................................................................... 37 3 Acceptance of Give-up by the Clearing Broker. Pending acceptance by Clearing Member of the destination account ................ 38 4 Acceptance of Give-up by the Clearing Member of destination account ...................................................................................... 38

7.3 Give-up (Clearing Broker)....................................................................................................................39 1 Reception of request of acceptance for a Give-up....................................................................................................................... 39 2 Acceptance of a Give-up ............................................................................................................................................................. 40 3 Reception of a give-up notice still pending of acceptance by the Clearing Member of the destination account ........................... 40 4 Reception of a Give-up notice accepted by the Clearing Member of the destination account ...................................................... 40

7.4 Give-up (Clearing Member) .................................................................................................................41 1 Reception of Give-up acceptance request in a cleared account .................................................................................................. 41 2 Give-up acceptance .................................................................................................................................................................... 41 3 Notification of the Give-up final status ......................................................................................................................................... 42

7.5 Give-up – Use of the Give-Out/In mnemonic.......................................................................................43 1 Request of Give-up. Pending acceptance by the Clearing Broker ............................................................................................... 43 2 Acceptance of Give-up by the Clearing Broker. Pending acceptance by Clearing Member of the destination account ................ 43 3 Acceptance of Give-up by the Clearing Member of destination account ...................................................................................... 43

8. Exercise Instructions ..................................................................................................................45 8.1 Prior considerations.............................................................................................................................45 8.2 American options before the expiration date .......................................................................................46

1 Early exercise instruction............................................................................................................................................................. 46 2 Cancellation of early exercise instruction (cancellation request).................................................................................................. 46 3 Early exercise instruction............................................................................................................................................................. 47 4 Cancellation of early exercise instruction (Exercise instruction with volume 0) ............................................................................ 47 5 Early exercise instruction............................................................................................................................................................. 47 6 Early exercise instruction. Rejected because there is no open position....................................................................................... 48 7 Early exercise instruction. Rejected as it refers to a European option ......................................................................................... 48

8.3 Expiration date ....................................................................................................................................49 1 Solicitud explicita de no ejercer ................................................................................................................................................... 49 2 Request cancellation of instruction to exercise ............................................................................................................................ 49 3 Request state of exercise instructions ......................................................................................................................................... 50 4 Partial exercise instruction........................................................................................................................................................... 50

8.4 Exercise result .....................................................................................................................................52 1 Early exercise.............................................................................................................................................................................. 52 2 Automatic exercise of option in-the-money.................................................................................................................................. 52 3 Position partially exercised on the expiration day ........................................................................................................................ 53

9. Communication of Events ..........................................................................................................54 1 Reception of message from Market Supervisor ........................................................................................................................... 54 2 Sending of Market Supervisor message ...................................................................................................................................... 54 3 Sending message to Market Supervisor. Rejected due to error in field 148 (Headline) ............................................................... 54

10. Give-up References and Filters Management...........................................................................55 1 Consulta ......................................................................................................................................... ¡Error! Marcador no definido. 2 Alta de referencia de Give-out por Miembro Origen..................................................................................................................... 56 3 Modificación de referencia de Give-out por Miembro Origen .......................................................... ¡Error! Marcador no definido. 4 Baja de referencia de Give-out por Miembro Origen....................................................................... ¡Error! Marcador no definido. 5 Alta de referencia de Give-in por Miembro Destino ........................................................................ ¡Error! Marcador no definido. 6 Modificación de referencia de Give-in por Miembro Destino........................................................... ¡Error! Marcador no definido. 7 Baja de referencia de Give-in por Miembro Destino ....................................................................... ¡Error! Marcador no definido. 8 Alta de Filtros de Give-in por Miembro Destino ........................................................................................................................... 59 9 Modificación de Filtros de Give-in por Miembro Destino................................................................. ¡Error! Marcador no definido. 10 Baja de Filtros de Give-in por Miembro Destino ............................................................................. ¡Error! Marcador no definido.


31 January 2008 © MEFF 2008 1

1. Introduction

1.1 Scope of this manual This document is intended for the members and ISV that wish to develop software applications to access the Market through the FIX interface of the MEFFGate server.

The document is made up of a set of selected examples covering the most common situations and places emphasis on those aspects of the protocol that are more complex.

The examples provided here should help to understand the FIX protocol implemented in MEFFGate, facilitate the work of developers and highlight some particular cases that should be taken into account.

This document is directly related to one version of the MEFFGate FIX interface, using the corresponding manual as its main reference (consult ¡Error! No se encuentra el origen de la referencia. for the complete reference of this manual).

In any case, the examples provided here should be viewed just as examples. In the event of any discrepancies with the reference manual, the later document should be considered valid.

1.2 Version of manual This document provides examples for a specific version of the MEFFGate FIX interface. In this case version C1.3.

The version of this examples document is based on the FIX interface version that it refers to followed by a letter identifying the specific version of the document. New versions of the examples document for the same MEFFGate FIX interface will build on previous ones by providing new examples or correcting errata in earlier versions. Thus, each new version replaces the previous version.

1.3 Structure of the document The document has a chapter for each group of messages, organised by functionalities, as in the reference manual.

In those chapters where it is considered appropriate, the examples have been organised in sections dealing with functionalities that are independent and differentiated.

1.4 Conventions used The messages sent by the client are preceded by the symbol “→”. The messages sent by the MEFFGate server are preceded by the symbol “←”.

Fields are separated by the symbol “·”, representing the unprintable ASCII character “SOH” (hex. 0x01).

1.5 Prior considerations To generate some examples it was necessary to modify the time and date in some of the equipment used in their development. Accordingly, the dates and times shown in the example messages should not be considered. More information on how these fields behave can be found in the manual or by crossing similar messages in the test environment.


31 January 2008 © MEFF 2008 2

1.6 Related documents # Título Autor Versión 1 MEFFGate Liquidación - Especificaciones de la Interfaz FIX C1.3 MEFF 31 de enero de

2008 2 Financial Information Exchange Protocol (FIX) 4.4 with errata 20030618 FIX Committee June 18, 2003

3 Financial Information Exchange Protocol (FIX) 5.0 candidate release FIX Committee Octubre 2006

MEFFGate - Examples FIX Interface C1.3.a FIX Session

31 January 2008 © MEFF 2008 3

2. FIX Session This chapter presents examples of the messages described in the chapter of the same name of the MEFF FIX protocol manual.

1 Logon to start FIX session

The client program sends a Logon message. The member is “A894” and the trader “351”, values assigned in fields 49 (SenderCompID) and 50 (SenderSubID) respectively.

The Clearing House for which the connection is requested is MEFF RV as indicated with the value “C2” in field 57 (TargetSubID).

The value “Y” of field 464 (TestMessageIndicator) indicates that the connection is to the test environment.

Field 5680 (ProprietaryFixProtocolVersion) indicates the version of the MEFF FIX protocol, which in this case is version “C1.3”.

Fields 553 (UserName) and 554 (Password) contain the user name and password respectively.

The frequency in seconds at which the Heartbeat messages are to be received is indicated by the value 10 in field 108 (HeartBtInt).

The name of the application being connected is specified in the optional field 5679 (FixEngineName), which in this case the value is “MEFF FIX CLIENT”.

Given that it is the first connection of the session the client assigns the sequence number 1 in field 34 (MsgSeqNum). Likewise, the client indicates the sequence number that it expects to receive from MEFFGate in field 789 (NextExpectedMsgSeqNum) with the value 1. This combination of the sequence number sent and the expected sequence number is also used to start a new FIX session during a session where a previous FIX session had been established that is not to be continued.

MEFFGate accepts the request responding with a Logon message. MEFFGate always includes in its Logon message the fields 5680 (ProprietaryFixProtocolVersion) and 464 (TestMessageIndicator). The field 789 (NextExpectedMsgSeqNum) will be present provided that it is used in the Logon message of the client application.

→ Logon Msg Type = A 8=FIX.4.4·9=142·35=A·34=1·49=A894·50=351·56=MEFF·57=C2·52=20040517-10:13:15·789=1·464=Y·553=A894351·554=aaaaaaaaaa·98=0·108=10·5680=C1.3·5679=MEFF FIX CLIENT·10=009·

← Logon Msg Type = A 8=FIX.4.4·9=94·35=A·34=1·52=20040517-10:13:15·49=MEFF·50=C2·56=A894·57=351·98=0·108=10·5680=C1.3·464=Y·789=2·10=195·


31 January 2008 © MEFF 2008 4

2 Reception of heartbeats

In the Logon message the client indicated in field 108 (HeartBtInt) the frequency at which it wished to receive Heartbeat messages from the server.

The example below shows two Heartbeat messages sent by MEFFGate. Note that these messages do not contain the field 112 (TestReqID) as they are not replies to a TestRequest message.

This type of message does not require any action by the client. Failure to receive messages during a period greater than that requested in field 108 (HeartBtInt) should be interpreted as a possible problem of connectivity at the application level. In this event, it is recommended to run a check by sending a TestRequest message before discarding the current connection.

← Heartbeat Msg Type = 0 8=FIX.4.4·9=60·35=0·34=2·52=20040517-10:13:26·49=MEFF·50=C2·56=A894·57=351·10=100·

← Heartbeat Msg Type = 0 8=FIX.4.4·9=60·35=0·34=3·52=20040517-10:13:36·49=MEFF·50=C2·56=A894·57=351·10=102·

3 Receiving and sending session messages

During the session a series of public and private messages are produced. A possible sequence of messages received from MEFFGate is shown below.

←

...·35=A·34=1·...

←

...·35=0·34=2·...

←

...·35=0·34=3·...

←

...·35=0·34=4·...

←

...·35=0·34=5·...

←

...·35=AK·34=6·...

←

...·35=AK·34=7·...

...


31 January 2008 © MEFF 2008 5

4 Logout

MEFFGate answers the sending of a Logout message with another Logout message indicating that the communication session in course is closed.

From this point on the only message that MEFFGate accepts for this trader is a Logon requesting the continuation of the previous FIX session, or a Logon message initiating a new FIX session (substituting the previous session).

→ Logout Msg Type = 5 8=FIX.4.4·9=60·35=5·34=4·49=A894·50=351·56=MEFF·57=C2·52=20040517-10:19:40·10=109·

← Logout Msg Type = 5 8=FIX.4.4·9=100·35=5·34=73·52=20040517-10:19:40·49=MEFF·50=C2·56=A894·57=351·58=%MFIMLRLRU-Logout requested by user·10=203·

5 Reconnection Logon

A Logon message is sent to continue with the FIX session that has been previously initiated. As can be observed in the example message, the client uses a consecutive sequence number (field 34, MsgSeqNum) after the last message.

The client uses field 789 (NextExpectedMsgSeqNum) to indicate to MEFFGate the message number that it expects to receive. MEFF recommends the use of this field to facilitate synchronisation of the session. Note that when the client application makes use of this field, MEFFGate will do the same in the Logon message reply.

During the disconnection period a change has taken place in the give-up status where the member to whom the connected trader belongs to participates. A Confirmation message is received.

For more information on the messages for which MEFFGate ensures delivery, consult the corresponding section in the documentation on the FIX protocol implemented by MEFF.



← Confirmation Msg Type = AK

...·35=AK·34=75·...

6 Sending Test Request message

The client application can verify the status of the connection at any moment by sending a Test Request message. MEFFGate replies to this with a Heartbeat message. The reply is related with the request by field 112 (TestReqID).

→ Test Request Msg Type = 1 8=FIX.4.4·9=73·35=1·34=6·49=A894·50=351·56=MEFF·57=C2·52=20040517-10:25:36·112=TESTREQ1·10=156·


31 January 2008 © MEFF 2008 6

← Heartbeat Msg Type = 0 8=FIX.4.4·9=74·35=0·34=76·52=20040517-10:25:36·49=MEFF·50=C2·56=A894·57=351·112=TESTREQ1·10=211·

7 Logout

The session is ended with the corresponding Logout message.



8 Reconnection Logon (with request to resend messages)

The following Logon message continues the FIX session, as the message number used continues with the previous sequence. In this case the value 1 in field 789 (NextExpectedMsgSeqNum) indicates to MEFFGate the number of the message expected to be received. Given that these messages were previously sent, this request is considered as a request for message repetition.

Independently of whether the reception of a lower message number is requested, MEFFGate replies to the Logon message with the consecutive number to the last message sent, and then does the repetition of messages.

When the request is made to send messages with a lower sequence number than the last message sent by MEFFGate to the client, MEFFGate does not repeat all the previous messages. Instead it discards those that cannot be repeated through the use of the Sequence Reset message as contemplated in the specifications of the MEFF FIX protocol.

Note that all the messages that MEFFGate considers were sent previously contain the value “Y” in field 43 (PossDupFlag) and the date and time originally sent in field 122 (OrigSendingTime).



← Sequence Reset Msg Type = 4 8=FIX.4.4·9=98·35=4·34=1·52=20040517-10:27:10·49=MEFF·50=C2·56=A894·57=351·43=Y·122=20040517-10:27:10·123=Y·36=6·10=170·


...·35=AK·34=6· … ·43=Y·122=20040517-13:58:51· ...


31 January 2008 © MEFF 2008 7


...·35=AK·34=7· … ·43=Y·122=20040517-13:58:58· ...

...

← Sequence Reset Msg Type = 4

8=FIX.4.4·9=100·35=4·34=76·52=20040517-10:27:10·49=MEFF·50=C2·56=A894·57=351·43=Y·122=20040517-10:27:10·123=Y·36=79·10=064·

9 Request repetition of messages from the beginning of the session

A Resend Request message is sent to request the repetition of messages previously received. The request is rejected as MEFFGate only accepts this message when it is sent immediately after a Logon message where nothing has been specified in the NextExpectedMsgSeqNum field. In this case the rejection is given through a Logout message as it is considered that there is a problem of synchronisation that will not be resolved.

When this type of message is accepted the procedure is equivalent to that shown in the section above.

→ Resend Request Msg Type = 2 8=FIX.4.4·9=69·35=2·34=9·49=A894·50=351·56=MEFF·57=C2·52=20040517-10:32:07·7=1·16=0·10=241·

← Logout Msg Type = 5 8=FIX.4.4·9=131·35=5·34=79·52=20040517-10:32:08·49=MEFF·50=C2·56=A894·57=351·58=%MFEMLRNRR-Resend Request not allowed in the current session state·10=076·

10 Logon to restart session

On starting a communication session you can opt to discard the continuation of a previous FIX session and choose to replace it with a new session. To carry out this process the sequence number 1 must be used in the Logon message and the value 1 indicated in field 789 (NextExpectedMsgSeqNum).

In contrast to those cases when a previous FIX session is continued with, none of the messages contain the field 43 (PossDupFlag). MEFFGate does not send Sequence Reset messages either, as the sequence numbers used in the previous session are not taken into account.




...·35=AK·34=2·...


31 January 2008 © MEFF 2008 8


...·35=AK·34=3·...

11 Logout

The session is ended with the corresponding Logout message.



12 Logon with higher sequence number than expected by MEFFGate

When a Logon message is sent with a higher sequence number than expected by MEFFGate, MEFFGate understands that it failed to receive some messages from the previous session and requests the repetition of the messages.

When the message sent by the client contains field 789 (NextExpectedMsgSeqNum), MEFFGate uses this mechanism to request the repetition of messages.

When the message sent by the client does not contain field 789 (NextExpectedMsgSeqNum), as in the example, MEFFGate makes the repetition request with a Resend Request message.

→ Logon Msg Type = A 8=FIX.4.4·9=139·35=A·34=100·49=A894·50=351·56=MEFF·57=C2·52=20040517-10:44:33·464=Y·553=A894351·554=aaaaaaaaaa·98=0·108=600·5680=C1.3·5679=MEFF FIX CLIENT·10=145·

← Logon Msg Type = A 8=FIX.4.4·9=89·35=A·34=5·52=20040517-10:44:33·49=MEFF·50=C2·56=A894·57=351·98=0·108=600·5680=C1.3·464=Y·10=236·

← Resend Request Msg Type = 2 8=FIX.4.4·9=69·35=2·34=6·52=20040517-10:44:33·49=MEFF·50=C2·56=A894·57=351·7=3·16=0·10=242·

13 Sending GapFill (Sequence Reset message)

When the client receives a Resend Request message, it must use the value contained in field 7 (BeginSeqNo) of the Resend Request message as the sequence number in its next message.

The client can choose to use these numbers for sending messages or simply send a Sequence Reset message to set the sequence number at the value requested in the Logon.

In the example the client has opted to send a Sequence Reset message.

The value 101 in field 36 (NewSeqNo) indicates the next sequence number that the client will use.

→ Sequence Reset Msg Type = 4 8=FIX.4.4·9=73·35=4·34=3·49=A894·50=351·56=MEFF·57=C2·52=20040517-10:45:47·123=Y·36=101·10=219·


31 January 2008 © MEFF 2008 9

14 Logout

The session is ended with the corresponding Logout message. Note that the sequence number used, field 34 (MsgSeqNum), corresponds with the value that is specified in field 36 (NewSeqNo) of the previous Sequence Reset message.



15 Logon with lower sequence number than expected by MEFFGate

The start of a session is requested by sending a Logon message with a lower sequence number than expected by MEFFGate. In this case MEFFGate rejects the connection, as a previously used sequence number cannot be reused.

When a client application cannot identify the last number used in the previous FIX session it is recommended that a new FIX session is begun as explained in the MEFF FIX protocol documentation.

→ Logon Msg Type = A 8=FIX.4.4·9=137·35=A·34=2·49=A894·50=351·56=MEFF·57=C2·52=20040517-10:54:05·464=Y·553=A894351·554=aaaaaaaaaa·98=0·108=600·5680=C1.3·5679=MEFF FIX CLIENT·10=048·

← Logout Msg Type = 5 8=FIX.4.4·9=125·35=5·34=8·52=20040517-10:54:05·49=MEFF·50=C2·56=A894·57=351·58=%MFEMSNLTE-Message sequence number lesser than expected [102]·10=136·

16 Logon rejected because password incorrect

The start of the session is requested by sending a Logon message. The request is rejected with a Logout message as the value specified in field 554 (Password) does not correspond with the user password.

Note that the Logon request rejected by MEFFGate does not use a sequence number and therefore the next Logon attempt should contain the same number.

When the connection is not authorised MEFFGate always replies with a Logout message with sequence number 1.

→ Logon Msg Type = A 8=FIX.4.4·9=144·35=A·34=102·49=A894·50=351·56=MEFF·57=C2·52=20040517-10:55:02·789=1·464=Y·553=A894351·554=bbbbbbbbbb·98=0·108=10·5680=C1.3·5679=MEFF FIX CLIENT·10=121·

← Logout Msg Type = 5 8=FIX.4.4·9=89·35=5·34=1·52=20040517-10:55:02·49=MEFF·50=C2·56=A894·57=351·58=%MFELIRWPW-Wrong Password·10=173·


31 January 2008 © MEFF 2008 10

17 Logon indicating incorrect environment

The start of a session is requested by sending a Logon message. The value “N” in field 464 indicates that you want to access the production environment. Given that the member and trader codes used correspond to the test environment, the request is rejected with a Logout message.

→ Logon Msg Type = A 8=FIX.4.4·9=144·35=A·34=102·49=A894·50=351·56=MEFF·57=C2·52=20040517-10:55:59·789=1·464=N·553=A894351·554=aaaaaaaaaa·98=0·108=10·5680=C1.3·5679=MEFF FIX CLIENT·10=112·

← Logout Msg Type = 5 8=FIX.4.4·9=92·35=5·34=1·52=20040517-10:55:59·49=MEFF·50=C2·56=A894·57=351·58=%MFELIRWES-Wrong environment·10=006·

MEFFGate - Examples FIX Interface C1.3.a Common Application Messages

31 January 2008 © MEFF 2008 11

3. Common Application Messages This chapter provides examples of the messages described in the chapter of the same name in the MEFF FIX protocol manual.

1 Request subscription to MEFFGate communication status.

A Network Counterparty System Status Request is sent with the value 2 (Subscribe) in field 935 (NetworkRequestType). Field 933 (NetworkRequestID) contains an identifier that enables the messages received in response to this subscription to be related.

The server responds with the corresponding Network Counterparty System Status Response message, where the field 928 (StatusValue) indicates the current status. In this case the value 1 (Connected) indicates that the connection between MEFFGate and the central systems is correct.

→ Network Counterparty System Status Request Msg Type = BC 8=FIX.4.4·9=78·35=BC·34=3·49=A894·50=351·56=MEFF·57=C2·52=20040524-09:24:21·935=2·933=NCSSR1·10=110·

← Network Counterparty System Status Response Msg Type = BD 8=FIX.4.4·9=123·35=BD·34=4·52=20040524-09:24:22·49=MEFF·50=C2·56=A894·57=351·937=1·932=23EE26800000·936=1·930=MEFF·931=C2·928=1·933=NCSSR1·10=095·

2 Loss of connectivity with the central systems

When MEFFGate detects that it has lost connectivity with the central systems, it informs the subscribed clients through a Network Counterparty System Status Response message with the value 2 (Not connected – down expected up) in field 928 (StatusValue).

When MEFFGate is in this state, it accepts the messages sent by the client application and responds only considering the local data that it has. It is the responsibility of the client application to continue sending messages or wait until the connection is re-established.

← Network Counterparty System Status Response Msg Type = BD 8=FIX.4.4·9=123·35=BD·34=9·52=20040524-09:58:47·49=MEFF·50=C2·56=A894·57=351·937=1·932=240DAC050000·936=1·930=MEFF·931=C2·928=2·933=NCSSR1·10=119·

3 Restoration of connectivity with central systems

When MEFFGate restores connectivity with the central systems, it informs the subscribed clients through the Network Counterparty System Status Response message with the value 1 (Connected) in field 928 (StatusValue).

← Network Counterparty System Status Response Msg Type = BD 8=FIX.4.4·9=125·35=BD·34=191·52=20040524-10:21:32·49=MEFF·50=C2·56=A894·57=351·937=1·932=24227D1F0003·936=1·930=MEFF·931=C2·928=1·933=NCSSR1·10=190·

MEFFGate - Examples FIX Interface C1.3.a Common Application Messages

31 January 2008 © MEFF 2008 12

4 Disconnection by ending of session

When the clearing session ends, MEFFGate notifies this to subscribed clients via Network Counterparty System Status Response message with a value 3 (Not connected – down expected down) in field 928 (StatusValue)

With this message MEFFGate notifies to the client that the clearing session has ended and that has no longer connection with the central systems. From this moment on MEFFGate will reject those messages that need an action in central systems, like an exercise request or a trade transfer.

MEFFGate will continue accepting and answering the rest of messages, said that it the consultation messages.

← Network Counterparty System Status Response Msg Type = BD 8=FIX.4.4·9=154·35=BD·34=234·52=20040524-18:31:32·49=MEFF·50=C2·56=A894·57=351·937=1·932=24227D1F0232·936=1·930=MEFF·931=C2·928=3·929=%MFICSNEND-Session ended·933=NCSSR1·10=156·

5 Password change

This functionality allows to change the individual user password used in the connection between the client application and MEFFGate.

The new password is valid for all the next future communication sessions between the client application and MEFFGate.

An User Request message is sent saying in the 925 (NewPassword) the new password, while the tag 554 (Password) contains the current password.

If the request has been successful, an User Response message is received with the tag 926 (UserStatus) = 5 meaning that the new password has been accepted by MEFFGate:

→ User Request Msg Type = BE 8=FIX.4.4·9=123·35=BE·34=2·52=20080121-09:34:30·56=MEFF·57=C2·49=A894·50=351·923=CPW_010_2·924=3·553=A894351·554=aaaaaaaaaa·925=nnnnnnnnnn·10=109·

← User Response Msg Type = BF 8=FIX.4.4·9=94·35=BF·34=2·52=20080121-09:34:30·49=MEFF·50=C2·56=A894·57=351·923= CPW_010_2·553=A894351·926=5·10=153·

If the request is not valid, an User Response message is received with the tag 926 (UserStatus) = 6 meaning that a mistake has happened which explanation is shown in the tag 927 (UserStatusText):

← User Response Msg Type = BF 8=FIX.4.4·9=123·35=BF·34=3·52=20080121-17:02:43·49=MEFF·50=C2·56=A894·57=351·923=CPW_020_8·553=A894351·926=6·927=%MFEUSRWPW-Wrong password·10=075·

MEFFGate - Examples FIX Interface C1.3.a Contracts Information

31 January 2008 © MEFF 2008 13

4. Contracts Information This chapter shows examples related to the messages described in chapter of the same name in MEFF FIX protocol manual.

This chapter contains the following sections:

• Contract static information

• Contract dynamic information


31 January 2008 © MEFF 2008 14

4.1 Contract Information – Definition and Status This section presents some examples related with the definition of the contracts (Security List Request message). Each of the cases presented takes into account the effect of the previous messages in this section.

1 Request definition and status of all the contracts with updates

A Security List Request message is sent requesting subscription to the definition of contracts (value 1 in field 5682, NewSecuritySubscription).

The identifier of the subscription is “SLR1” field 320 (SecurityReqID). This identifier can be found in the associated response messages, in field 320 (SecurityReqID) of the Security List messages.

The ISIN code for the contract IXH06 can be found in the tag 455 (SecurityAltID) = ES0B00005678.

In the tag 969 (MinPriceIncrement) there is the minimal amount aalowed for price change in the order entry.

The total number of contracts that meet the selection criteria of the request is indicated in field 393 (TotNoRelatedSym) of each Security List message.

→ Security List Request Msg Type = x

8=FIX.4.4·9=102·35=x·34=3·52=20051118-08:49:43·56=MEFF·57=C2·49=A899·50=351·320=SLR1·559=1·55=[N/A]·461=XXXXXX·5682=1·10=063·

← Security List Msg Type = y

8=FIX.4.4·9=250·35=y·34=3·52=20051118-08:49:43·49=MEFF·50=C2·56=A899·57=351·146=1·55=IXH06·48=FIE·22=8·454=1·455=ES0B00005678·456=4·461=FFICSX·200=200603·541=20060317·225=20050221·231=10·107=IBEX PLUS·969=1·15=EUR·320=SLR1·322=003306410000·560=0·393=347·893=N·325=N·10=128·


8=FIX.4.4·9=250·35=y·34=3·52=20051118-08:49:43·49=MEFF·50=C2·56=A899·57=351·146=1·55=ITH06·48=ITX·22=8·461=FFSPSX·200=200603·541=20060317·225=20050321·231=100·107=INDITEX·969=0.01·15=EUR·320=SLR1·322=003306410001·560=0·393=347·893=N·325=N·10=154·


8=FIX.4.4·9=222·35=y·34=5·52=20051118-08:49:43·49=MEFF·50=C2·56=A899·57=351·146=1·55=BKT·48=BKT·22=8·461=ESXXXX·200=203012·541=20301231·225=19990319·231=100·107=BANKINTER·969=0.01·15=EUR·320=SLR1·322=003306410002·560=0·393=347·893=N·325=N·10=038· …


...35=y...

...


31 January 2008 © MEFF 2008 15


8=FIX.4.4·9=249·35=y·34=349·52=20051118-08:49:43·49=MEFF·50=C2·56=A899·57=351·146=1·55=IT 2300R·48=ITX·22=8·461=OPASPS·200=200506·541=20050617·225=20040621·202=23·231=100·107=INDITEX·969=0.01·711=1·311=ITX·15=EUR·320=SLR1·322=003306700050·560=0·393=347·893=Y·325=N·10=120·

2 Contract definition request. Rejected because field 55 (Symbol) missing

The request is rejected as it is missing field 55 (Symbol), which is required for this message. In this case, MEFFGate rejects the message by sending a Reject message, as it does not comply with the protocol.


8=FIX.4.4·9=75·35=x·34=4·52=20051118-09:01:45·56=MEFF·57=C2·49=A899·50=351·320=SLR2·559=1·10=198·

← Reject Msg Type = 3

8=FIX.4.4·9=130·35=3·34=351·52=20051118-09:01:45·49=MEFF·50=C2·56=A899·57=351·45=4·373=99·58=%MFEMC1MFM-Mandatory field missing or misplaced [55]·10=166·

3 Request definition and status of contract IXZ05 with updates

A new subscription (identifier “SLR2”) is made for the definition and status of the contract IXZ05. Note that this information was already contained in the previous subscription, so messages with repeated information will be generated when a change occurs in this contract.

Note that field 893 (LastFragment) of the Security List message contains the value “Y”, which indicates that it is the last Security List message of the snapshot.

In spite of having indicated value 1 (Subscribe) in field 5682 (NewSecuritySubscription), new messages related to this subscription will not be produced, due to the contract code being specified, there is no possibility that a new contract register fulfils the selection criteria.

Field 393 (TotNoRelatedSym) of the Security List message indicates, as might be expected, that there is a single contract that meets the selection.


8=FIX.4.4·9=91·35=x·34=5·52=20051118-09:04:23·56=MEFF·57=C2·49=A899·50=351·320=SLR2·559=0·55=IXZ05·5682=1·10=015·


8=FIX.4.4·9=220·35=y·34=352·52=20051118-09:04:24·49=MEFF·50=C2·56=A899·57=351·146=1·55=IXZ05·48=FIE·22=8·461=FFICSX·200=200512·541=20051216·225=20040705·231=10·107=IBEX PLUS·969=1·15=EUR·320=SLR2·322=00407A0A0000·560=0·393=1·893=Y·325=N·10=156·


31 January 2008 © MEFF 2008 16

4 Request to terminate previous subscription

The previous subscription was ended (identifier “SLR2”) via Security List Request message with value 2 (Unsubscribe) in field 5682 (NewSecuritySubscription) and the identifier of the subscription in field 320 (SecurityReqID)

As specified in FIX protocol, MEFFGate does not give any response message back to this kind of request.


8=FIX.4.4·9=91·35=x·34=6·52=20051118-09:07:07·56=MEFF·57=C2·49=A899·50=351·320=SLR2·559=0·55=[N/A]·5682=2·10=044·

5 Request of definition and status of all call options contracts without updates

A snapshot request is made for all call options contracts, field 461 (CFICode) with value “OCXXXS” (multileg contracts). As it is a snapshot request, new messages will not be received when registering contracts with these selection criteria.


8=FIX.4.4·9=102·35=x·34=9·52=20051118-09:09:51·56=MEFF·57=C2·49=A899·50=351·320=SLR3·559=1·55=[N/A]·461=OCXXXS·5682=0·10=031·


8=FIX.4.4·9=247·35=y·34=355·52=20051118-09:09:51·49=MEFF·50=C2·56=A899·57=351·146=1·55=M5 9200D·48=FIEM·22=8·461=OCEICS·200=200504·541=20050415·225=20050124·202=9200·231=1·107=IBEX MINI·969=1·711=1·311=FIE·15=EUR·320=SLR3·322=004577D00000·560=0·393=115·893=N·325=N·10=076·

…

6 Request termination of initial subscription

The subscription with identifier “SLR1” is terminated. From this moment no more information will be received related to the subscription. Note that MEFFGate does not send any message in reply to this request.


8=FIX.4.4·9=92·35=x·34=10·52=20051118-09:18:40·56=MEFF·57=C2·49=A899·50=351·320=SLR1·559=0·55=[N/A]·5682=2·10=086·


31 January 2008 © MEFF 2008 17

4.2 Contracts dynamic information This section presents some examples of Market Data requests. Each of the cases presented takes into consideration the previous messages in the section.

1 Request price information with updates for contract IXZ05

A subscription (identifier “MDR1”) is made requesting price information on contract IXZ05. The type of information requested is specified in field 269 (MDEntryType) with the values 6 (Settlement Price), B (Trade Volume), C (Open Interest).

The MEFFGate answer is a Market Data Snapshot Full Refresh message for each selected contract, in this case a single message.

→ Market Data Request Msg Type = V

8=FIX.4.4·9=127·35=V·34=11·52=20051118-09:22:14·56=MEFF·57=C2·49=A899·50=351·262=MDR1·263=1·264=0·265=0·267=3·269=6·269=B·269=C·146=1·55=IXZ05·10=124·

← Market Data Snapshot Full Refresh Msg Type = W

8=FIX.4.4·9=142·35=W·34=471·52=20051118-09:22:14·49=MEFF·50=C2·56=A899·57=351·262=MDR1·55=IXZ05·268=3·269=6·270=9237·286=4·811=1.00·269=B·271=0·269=C·271=886·10=103·

2 Request price information with updates for all contracts

A new subscription (identifier “MDR2”) is made requesting information on all contracts.

A Market Data Snapshot Full Refresh message will be received for each contract with the requested information. In the example only a message corresponding to a contract is included.


8=FIX.4.4·9=127·35=V·34=12·52=20051118-09:23:48·56=MEFF·57=C2·49=A899·50=351·262=MDR2·263=1·264=0·265=0·267=3·269=6·269=B·269=C·146=1·55=[N/A]·10=156·

...



…


31 January 2008 © MEFF 2008 18

3 Traded volume variation

A trade for 1 contract is made on IXZ05 contract. Please note that the same information is received twice, because of two subscription were made (identifiers “MDR1” and “MDR2”) that included IXZ05 contract.

Fields that comprise the block started by field 269 (MDEntryType) with value “B” (Trade Volume) inform of the new traded total volume.

Take into account that Market Data Snapshot Full Refresh message contains all of the data requested in the subscription message no matter which changes.





4 Request to terminate second subscription

The subscription with identifier “MDR2” is finalised. From this moment no more information related to the subscription will be received. Note that MEFFGate does not send any message in reply to this request.


8=FIX.4.4·9=100·35=V·34=16·52=20051118-11:48:45·56=MEFF·57=C2·49=A899·50=351·262=MDR2·263=2·264=0·267=0·146=0·265=0·10=027·

5 Determination of closing price

The Exchange fixes the closing price of contract IXZ05 at 9317. In this moment a Market Data Snapshot Full Refresh message is received with the new closing price. This value is given in field 270 (MDEntryPx) of the block associated by the MDEntryType with value 6 (Settlement Price). Note that the value 1 (Session Open / Close / Settlement entry) of field 286 (OpenCloseSettleFlag) indicates that is the settlement price for today’s session.




31 January 2008 © MEFF 2008 19

6 Request price information. Rejected due to error in field 267 (NoMDEntryTypes)

A Market Data Request message is sent to request price information of contract IXZ05. Field 267 (NoMDEntryTypes) indicates that the message should contain 2 269 fields (MdentryType), and the message contains 3. The message is rejected with a Reject message because it does not comply with the protocol.



← Reject Msg Type = 3

8=FIX.4.4·9=123·35=3·34=711·52=20051118-12:06:14·49=MEFF·50=C2·56=A899·57=351·45=17·373=99·58=%MFEMC1NFM-Number of fields mismatch [267=2]·10=039·

7 Request price information. Rejected due to duplicated identifier

The attempt to make a subscription with an identifier that was previously used is rejected. In contrast to the previous case, the rejection is made using a Market Data Request Reject message.



← Market Data Request Reject Msg Type = Y

8=FIX.4.4·9=123·35=Y·34=712·52=20051118-12:07:49·49=MEFF·50=C2·56=A899·57=351·262=MDR1·281=1·58=%MFEMDRDPI-Duplicate identifier [262=MDR1]·10=095·

MEFFGate - Examples FIX Interface C1.3.a Monitoring and Managing Position

31 January 2008 © MEFF 2008 20

5. Monitoring and Managing Position This chapter presents examples of the messages described in the chapter of the same name in the MEFF FIX protocol manual.

Each of the cases presented takes into account the effect of previous messages in this section.

At the outset none of the accounts have positions associated.

1 Solicitud de snapshot de posición abierta (sin posición abierta)

A Request For Positions message is sent requesting the open position.

Value 0 (Snapshot) in field 263 (SubscriptionRequestType) indicates that only the current situation is desired, without receiving further messages when movements in the position take place.

The query made includes the accounts of the “B06” holder (value “B06??” in field 1, Account) and all the contracts (value “[N/A]” in field 55, Symbol). The selection has not been restricted by any other field.

MEFFGate replies to the request with a Request For Positions Ack message. The value 2 (No positions found that match criteria) in field 728 (PosReqResult) indicates that no account has been found with positions.

As the request is for a Snapshot there is no new messages are produced associated with this request.

→ Request For Positions Msg Type = AN

8=FIX.4.4·9=138·35=AN·34=2·52=20051124-09:03:15·56=MEFF·57=C2·49=A899·50=351·710=SAB·724=0·263=0·1=B06??·581=1·55=[N/A]·715=20050426·60=20050426-09:01:15·10=239·

← Request For Positions Ack Msg Type = AO

8=FIX.4.4·9=135·35=AO·34=3·52=20051124-09:03:15·49=MEFF·50=C2·56=A899·57=351·721=004F0AFC0000·710=SAB·728=2·729=0·1=B06??·581=1·58=%MFIPTRNXM-No match·10=127·

2 Request subscription of open (without open position)

The next messages make the same request as the first of the messages but for the “B06” plus the “C06” holders, but this time requesting receipt of the changes in the position through the value 1 (Snapshot + Update) in field 263 (Subscription Request Type).

The reply from MEFFGate is once again a Request For Positions Ack notifying that there is no account with positions.

From that moment, when a position variation in some of the selected accounts takes place the corresponding messages will be received:

o Trade Capture Report for trades

o Position Report for position adjustments




31 January 2008 © MEFF 2008 21


8=FIX.4.4·9=135·35=AO·34=4·52=20051124-09:05:14·49=MEFF·50=C2·56=A899·57=351·721=0050DA8C0000·710=SAB·728=2·729=0·1=B06??·581=1·58=%MFIPTRNXM-No match·10=114·


8=FIX.4.4·9=138·35=AN·34=5·52=20051124-09:07:57·56=MEFF·57=C2·49=A899·50=351·710=SAC·724=0·263=1·1=C06??·581=1·55=[N/A]·715=20050426·60=20050426-09:01:15·10=255·


8=FIX.4.4·9=135·35=AO·34=6·52=20051124-09:07:57·49=MEFF·50=C2·56=A899·57=351·721=005356880000·710=SAC·728=2·729=0·1=C06??·581=1·58=%MFIPTRNXM-No match·10=093·


31 January 2008 © MEFF 2008 22

3 First modification in the position of accounts requested

A trade is crossed between two accounts amongst the previous requests. When the position of said accounts is modified the corresponding Trade Capture Report messages are received notifying of this situation.

The information on the trade is as follows:

o Contract: IXJ05

o Buyer account: B0601 (A899)

o Seller account: C0601 (A899)

o Volume: 10

o Price: 9300

In each of the Trade Capture Report messages the trade information is presented. For the purposes of monitoring the position the following fields are of note:

o 77 (PositionEffect): Open/close position indicator

o 1 (Account) indicates the account

o 55 (Symbol) indicates the contract

o 54 (Side) indicates whether it is a buy or sell trade

o 32 (LastQty) notifies the trade volume

Note that field 325 (UnsolicitedIndicator) informs us through the value “Y” that the message is an update and does not form part of the Snapshot.

In the <TrdRegTimestamps> block there is the timestamp (date and hour) when the initial trade was made in the Trading System.

In the GrossTradeAmt [381] tag the Nominal/Effective amount is informed.

← Trade Capture Report Msg Type = AE

8=FIX.4.4·9=405·35=AE·34=8·52=20051125-08:24:17·49=MEFF·50=C2·56=A899·57=351·571=002A87C10000·150=F·818=101·527=FI0000000001·5681=M·570=Y·55=IXJ05·32=10·31=9300·75=20050330·60=20050330-07:24:17·768=1·769=20050330-07:24:17·770=3·63=0·881=101·880=101·552=1·54=1·37=050330OA89935170001·198=FI1·453=1·448=A899·447=D·452=13·1=B0601·381=930000·77=O·136=2·137=0.00·138=EUR·139=4·891=0·137=5.00·138=EUR·139=7·891=0·710=SAB·325=Y·10=053·


8=FIX.4.4·9=405·35=AE·34=9·52=20051125-08:24:17·49=MEFF·50=C2·56=A899·57=351·571=002A87C10001·150=F·818=101·527=FI0000000001·5681=M·570=Y·55=IXJ05·32=10·31=9300·75=20050330·60=20050330-07:24:17·768=1·769=20050330-07:24:17·770=3·63=0·881=101·880=101·552=1·54=2·37=050330OA89935170002·198=FI2·453=1·448=A899·447=D·452=13·1=C0601·381=930000·77=O·136=2·137=0.00·138=EUR·139=4·891=0·137=5.00·138=EUR·139=7·891=0·710=SAC·325=Y·10=060·


31 January 2008 © MEFF 2008 23

4 Second modification in the position of the requested accounts

Por cada nueva operación que se produzca sobre alguna de las cuentas seleccionadas se irán recibiendo los correspondientes mensajes Trade Capture Report.

La datos de la operación son los siguientes:

o Contrato: IXJ05

o Cuenta compradora: C0601 (A899)

o Cuenta vendedora: B0601 (A899)

o Volumen: 10

o Precio: 9310


8=FIX.4.4·9=406·35=AE·34=10·52=20051125-08:26:43·49=MEFF·50=C2·56=A899·57=351·571=002CC1C30000·150=F·818=102·527=FI0000000002·5681=M·570=Y·55=IXJ05·32=10·31=9310·75=20050330·60=20050330-07:26:43·768=1·769=20050330-07:26:43·770=3·63=0·881=102·880=102·552=1·54=1·37=050330OA89935170003·198=FI3·453=1·448=A899·447=D·452=13·1=C0601·381=931000·77=O·136=2·137=0.00·138=EUR·139=4·891=0·137=5.00·138=EUR·139=7·891=0·710=SAC·325=Y·10=119·


8=FIX.4.4·9=406·35=AE·34=11·52=20051125-08:26:43·49=MEFF·50=C2·56=A899·57=351·571=002CC1C30001·150=F·818=102·527=FI0000000002·5681=M·570=Y·55=IXJ05·32=10·31=9310·75=20050330·60=20050330-07:26:43·768=1·769=20050330-07:26:43·770=3·63=0·881=102·880=102·552=1·54=2·37=050330OA89935170004·198=FI4·453=1·448=A899·447=D·452=13·1=B0601381=931000··77=O·136=2·137=0.00·138=EUR·139=4·891=0·137=5.00·138=EUR·139=7·891=0·710=SAB·325=Y·10=122·

·

5 Position adjustment

A position adjustment is requested via Position Maintenance Request message. The adjustment is for 4 contracts at account B0601 and contract IXJ05.

Once the adjustment is done a Position Maintenance Report message is received informing about the adjustment done and the resulting position. This message is only sent to the user who requested the adjustment.

All the traders subscribed to the open position receive two Trade Capture Report messages, corresponding to the trades derived from the position adjustment. Note that messages of these trades contain value “C” (Close) in field 77 (PositionEffect)

→ Position Maintenance Request Msg Type = AL

8=FIX.4.4·9=158·35=AL·34=5·52=20051125-08:28:56·56=MEFF·57=C2·49=A899·50=351·710=PMA1·709=3·712=1·715=20050420·1=B0601·581=1·55=IXJ05·60=20050917-09:10:21·702=1·703=PA·704=4·10=122·

← Position Maintenance Report Msg Type = AM

8=FIX.4.4·9=223·35=AM·34=12·52=20051125-08:28:56·49=MEFF·50=C2·56=A899·57=351·721=002ECB3F0000·710=PMA1·709=3·712=1·713=NONE·715=20051125·1=B0601·581=1·55=IXJ05·60=20050917-09:10:21·753=0·702=2·703=PA·704=4·703=TOT·704=6·705=6·722=0·723=0·10=042·


31 January 2008 © MEFF 2008 24


8=FIX.4.4·9=357·35=AE·34=13·52=20051125-08:28:56·49=MEFF·50=C2·56=A899·57=351·571=002ECBBC0000·150=F·818=103·5681=P·570=Y·55=IXJ05·32=4·31=0·75=20050330·60=20050330-07:28:56·768=1·769=20050330-07:28:56·770=3·63=0·881=103·880=103·552=1·54=1·37=NONE·453=1·448=A899·447=D·452=13·1=B0601·381=0·77=C·136=2·137=0.00·138=EUR·139=4·891=0·137=0.00·138=EUR·139=7·891=0·710=SAB·325=Y·10=040·


8=FIX.4.4·9=357·35=AE·34=14·52=20051125-08:28:56·49=MEFF·50=C2·56=A899·57=351·571=002ECBBC0001·150=F·818=103·5681=P·570=Y·55=IXJ05·32=4·31=0·75=20050330·60=20050330-07:28:56·768=1·769=20050330-07:28:56·770=3·63=0·881=103·880=103·552=1·54=2·37=NONE·453=1·448=A899·447=D·452=13·1=B0601·381=0·77=C·136=2·137=0.00·138=EUR·139=4·891=0·137=0.00·138=EUR·139=7·891=0·710=SAB·325=Y·10=043·

6 Position adjustment end

When the position adjustment period is finished, no more adjustments can be done, and the system might generate a position adjustment trade for every account where some adjustments have been done to inform of the commissions.


8=FIX.4.4·9=357·35=AE·34=15·52=20051125-08:32:13·49=MEFF·50=C2·56=A899·57=351·571=0031CDB10000·150=F·818=104·5681=P·570=Y·55=IXJ05·32=0·31=0·75=20050330·60=20050330-07:32:13·768=1·769=20050330-07:32:13·770=3·63=0·881=104·880=104·552=1·54=1·37=NONE·453=1·448=A899·447=D·452=13·1=B0601·381=0·77=C·136=2·137=0.00·138=EUR·139=4·891=0·137=2.00·138=EUR·139=7·891=0·710=SAB·325=Y·10=228·


8=FIX.4.4·9=357·35=AE·34=16·52=20051125-08:32:13·49=MEFF·50=C2·56=A899·57=351·571=0031CDB10001·150=F·818=104·5681=P·570=Y·55=IXJ05·32=0·31=0·75=20050330·60=20050330-07:32:13·768=1·769=20050330-07:32:13·770=3·63=0·881=104·880=104·552=1·54=2·37=NONE·453=1·448=A899·447=D·452=13·1=B0601·381=0·77=C·136=2·137=0.00·138=EUR·139=4·891=0·137=2.00·138=EUR·139=7·891=0·710=SAB·325=Y·10=231·

7 End of session

When the final clearing calculation are done, a Position Report message is received for each one of the accounts with open position to inform of the situation at the end of the day with he value “FIN” (End-of-Day Qty) in the filed 703 (PosType).

← Position Report Msg Type = AP

8=FIX.4.4·9=244·35=AP·34=17·52=20051125-08:32:38·49=MEFF·50=C2·56=A899·57=351·721=00322E7F0000·724=0·728=0·730=9310·731=1·734=9304.5·581=1·715=20051125·453=1·448=A899·447=D·452=13·1=C0601·55=IXJ05·702=1·703=FIN·704=10·705=10·753=1·707=FMTM·708=0·710=SAC·325=Y·10=187·


8=FIX.4.4·9=242·35=AP·34=18·52=20051125-08:32:38·49=MEFF·50=C2·56=A899·57=351·721=00322E7F0001·724=0·728=0·730=9310·731=1·734=9304.5·581=1·715=20051125·453=1·448=A899·447=D·452=13·1=B0601·55=IXJ05·702=1·703=FIN·704=6·705=6·753=1·707=FMTM·708=0·710=SAB·325=Y·10=099·


31 January 2008 © MEFF 2008 25

8 New clearing session

The Market ends the clearing session and consequently the previous subscriptions are considered to have ended.

A new session is initiated taking into account the position generated in the previous session:

• Account B0601

o 6 long IXJ05 contracts

o 6 short IXJ05 contracts

• Account C0601



• Account B9901


• Account C9901


9 Subscription request of open position (with open position)

In the new session the requests made in point 2 are repeated, namely, two open position subscription requests for the holder “B06” and “C06”.

Also new requests are made for the holders “B99” and “C99”.

MEFFGate replies with a Request For Positions Ack message with value 0 (Valid Request) in field 728 (PosReqResult).

In this case, there is open position in some of the accounts of the selected holders, and MEFFGate informs in field 727 (TotNumPosReports) of the Request For Positions Ack message of the number of messages that it will send informing of the current situation (Snapshot). In this case there is one message for each subscription.

Each of the Position Report messages informs of the position at the start of the day of the account referred to in field 1 (Account) and the contract that is indicated in field 55 (Symbol). Field 704 (LongQty) indicates the number of contracts bought in the position and field 705 (ShortQty) gives the contracts sold.

In the field PosAmt [708] (within the <PositionAmountData> block) there is the Mark-to-Market position amount (with sign) for this contract-account combination.

In the example it is considered that no new trades were made during the day. If they had occurred, in addition to the messages presented, a Trade Capture Report message would have been received for each new trade made on accounts included in the selection, whether or not there was a position at the start of the day.

Also, it has been taken into account that no position adjustments have been done during the day. If so, in addition of the messages showed, a Position Report message informing of the adjustments made on the accounts included in the selection, will also have been received, independently whether they have a position or not at the beginning of the day.


31 January 2008 © MEFF 2008 26




8=FIX.4.4·9=118·35=AO·34=2·52=20051125-12:43:50·49=MEFF·50=C2·56=A899·57=351·721=003CDC140000·710=SAB·727=1·728=0·729=0·1=B06??·581=1·10=210·


8=FIX.4.4·9=244·35=AP·34=3·52=20051125-12:43:50·49=MEFF·50=C2·56=A899·57=351·721=003CDC140001·724=0·728=0·730=9310·731=2·734=9310·581=1·715=20051125·453=1·448=A899·447=D·452=13·1=B0601·55=IXJ05·702=1·703=SOD·704=6·705=6753=1·707=SMTM·708=0·710=SAB·325=N·727=1·10=227·




8=FIX.4.4·9=118·35=AO·34=4·52=20051125-12:43:58·49=MEFF·50=C2·56=A899·57=351·721=003CFD860000·710=SAC·727=1·728=0·729=0·1=C06??·581=1·10=234·


8=FIX.4.4·9=247·35=AP·34=5·52=20051125-12:43:58·49=MEFF·50=C2·56=A899·57=351·721=003CFD860001·724=0·728=0·730=9310·731=2·734=9310·581=1·715=20051125·453=1·448=A899·447=D·452=13·1=C0601·55=IXJ05·702=1·703=SOD·704=10·705=10·753=1·707=SMTM·708=0·710=SAC·325=N·727=1·10=085·




8=FIX.4.4·9=118·35=AO·34=2·52=20051125-12:43:50·49=MEFF·50=C2·56=A899·57=351·721=003CDC140000·710=SAB·727=1·728=0·729=0·1=B99??·581=1·10=222·


8=FIX.4.4·9=244·35=AP·34=3·52=20051125-12:43:50·49=MEFF·50=C2·56=A899·57=351·721=003CDC140001·724=0·728=0·730=9310·731=2·734=9310·581=1·715=20051125·453=1·448=A899·447=D·452=13·1=B9901·55=IXJ05·702=1·703=SOD·704=6·753=1·707=SMTM·708=558600·710=SAB·325=N·727=1·10=232·


31 January 2008 © MEFF 2008 27




8=FIX.4.4·9=118·35=AO·34=4·52=20051125-12:43:58·49=MEFF·50=C2·56=A899·57=351·721=003CFD860000·710=SAC·727=1·728=0·729=0·1=C99??·581=1·10=246·


8=FIX.4.4·9=246·35=AP·34=5·52=20051125-12:43:58·49=MEFF·50=C2·56=A899·57=351·721=003CFD860001·724=0·728=0·730=9310·731=2·734=9310·581=1·715=20051125·453=1·448=A899·447=D·452=13·1=C9901·55=IXJ05·702=1·703=SOD·705=10·753=1·707=SMTM·708=-931000·710=SAC·325=N·727=1·10=080·

10 Modification of the position

During the session a trade is made. Since it was a subscription request, further Trade Capture Report messages will be received, after position changes.

The information on the trade is as follows:

o Contract: IXJ05

o Buyer account: C0601 (A899)

o Seller account: B0601 (A899)

o Volume: 10

o Price: 9340


8=FIX.4.4·9=405·35=AE·34=6·52=20051125-12:51:37·49=MEFF·50=C2·56=A899·57=351·571=0043FC4C0000·150=F·818=105·527=FI0000000003·5681=M·570=Y·55=IXJ05·32=10·31=9340·75=20050331·60=20050331-11:51:37·768=1·769=20050331-11:51:37·770=3·63=0·881=105·880=105·552=1·54=1·37=050331OA89935170001·198=FI5·453=1·448=A899·447=D·452=13·1=C0601·381=934000·77=O·136=2·137=0.00·138=EUR·139=4·891=0·137=5.00·138=EUR·139=7·891=0·710=SAC·325=Y·10=091·


8=FIX.4.4·9=405·35=AE·34=7·52=20051125-12:51:37·49=MEFF·50=C2·56=A899·57=351·571=0043FC5B0000·150=F·818=105·527=FI0000000003·5681=M·570=Y·55=IXJ05·32=10·31=9340·75=20050331·60=20050331-11:51:37·768=1·769=20050331-11:51:37·770=3·63=0·881=105·880=105·552=1·54=2·37=050331OA89935170002·198=FI6·453=1·448=A899·447=D·452=13·1=B0601·381=934000·77=O·136=2·137=0.00·138=EUR·139=4·891=0·137=5.00·138=EUR·139=7·891=0·710=SAB·325=Y·10=093·


31 January 2008 © MEFF 2008 28

11 Position adjustment

A position adjustment is requested via Position Maintenance Request message. The adjustment is for 2 contracts at account B0601 and contract IXJ05.

Once the adjustment is done a Position Maintenance Report message is received informing about the adjustment done and the resulting position. This message is only sent to the user who requesting the adjustment.

All the traders subscribed to the open position receive two Trade Capture Report messages, corresponding to the trades derived from the position adjustment. Note that messages of these trades contain value “C” (Close) in field 77 (PositionEffect).


8=FIX.4.4·9=158·35=AL·34=4·52=20051125-12:53:20·56=MEFF·57=C2·49=A899·50=351·710=PMA1·709=3·712=1·715=20050420·1=B0601·581=1·55=IXJ05·60=20050917-09:10:21·702=1·703=PA·704=1·10=102·


8=FIX.4.4·9=223·35=AM·34=8·52=20051125-12:53:20·49=MEFF·50=C2·56=A899·57=351·721=004590880000·710=PMA1·709=3·712=1·713=NONE·715=20051125·1=B0601·581=1·55=IXJ05·60=20050917-09:10:21·753=0·702=2·703=PA·704=1·703=TOT·704=5·705=15·722=0·723=0·10=232·


8=FIX.4.4·9=356·35=AE·34=9·52=20051125-12:53:20·49=MEFF·50=C2·56=A899·57=351·571=004590A70000·150=F·818=106·5681=P·570=Y·55=IXJ05·32=1·31=0·75=20050331·60=20050331-11:53:20·768=1·769=20050331-11:53:20·770=3·63=0·881=106·880=106·552=1·54=1·37=NONE·453=1·448=A899·447=D·452=13·1=B0601·381=0·77=C·136=2·137=0.00·138=EUR·139=4·891=0·137=0.00·138=EUR·139=7·891=0·710=SAB·325=Y·10=158·


8=FIX.4.4·9=357·35=AE·34=10·52=20051125-12:53:20·49=MEFF·50=C2·56=A899·57=351·571=004590B70000·150=F·818=106·5681=P·570=Y·55=IXJ05·32=1·31=0·75=20050331·60=20050331-11:53:20·768=1·769=20050331-11:53:20·770=3·63=0·881=106·880=106·552=1·54=2·37=NONE·453=1·448=A899·447=D·452=13·1=B0601·381=0·77=C·136=2·137=0.00·138=EUR·139=4·891=0·137=0.00·138=EUR·139=7·891=0·710=SAB·325=Y·10=201·

12 Termination of previous subscriptions

Two messages are sent requesting the termination of the previous subscriptions. In the requests to end the subscriptions, field 263 (SubscriptionRequestType) must contain the value 2 (Unsuscribe). The other fields must coincide with the subscription message.

As specified in the FIX protocol, MEFFGate does not return any message in reply to this type of request.


8=FIX.4.4·9=138·35=AN·34=7·52=20051125-12:55:51·56=MEFF·57=C2·49=A899·50=351·724=0·710=SAB·263=2·1=B06??·581=1·55=[N/A]·60=20040426-16:02:21·715=20040426·10=248·


8=FIX.4.4·9=138·35=AN·34=8·52=20051125-12:55:51·56=MEFF·57=C2·49=A899·50=351·724=0·710=SAC·263=2·1=C06??·581=1·55=[N/A]·60=20040426-16:02:21·715=20040426·10=251·

MEFFGate - Examples FIX Interface C1.3.a Consultation of trades of session

31 January 2008 © MEFF 2008 29

6. Consultation of trades of session This chapter presents some examples of the messages related to the consultation of the trades of the session. Each one of the presented cases considers the previous messages of this same section.

1 Request snapshot of proprietary trades

In the next Trade Capture Report Request message, not specifying any selection criteria implies the selection of all the proprietary trades.

The value 0 (Snapshot) of field 263 (SubscriptionRequestType) indicates that it is a request without subscription.

The Trade Capture Report Request Ack message sent by MEFFGate indicates that there is no trade through the value 0 in field 748 (TotNumTradeReports).

→ Trade Capture Report Request Msg Type = AD

8=FIX.4.4·9=83·35=AD·34=3·52=20051130-08:00:01·56=MEFF·57=C2·49=A899·50=351·568=TCR1B·569=0·263=0·10=017·

← Trade Capture Report Request Ack Msg Type = AQ

8=FIX.4.4·9=125·35=AQ·34=3·52=20051130-08:00:01·49=MEFF·50=C2·56=A899·57=351·568=TCR1B·569=0·263=0·748=0·749=99·750=1·58=%MFITCRNXM-No match·10=090·

2 Request subscription of all proprietary trades

The same request is made as in the above case, this time requesting the subscription to receive the new trades that are made.

Given that at the moment there are no trades, the same Trade Capture Report Request Ack message is received as the above case.

In contrast to the above case, from this point on, when a trade is made the corresponding Trade Capture Report message will be received informing of this.


8=FIX.4.4·9=83·35=AD·34=4·52=20051130-08:25:18·56=MEFF·57=C2·49=A899·50=351·568=TCR1B·569=0·263=1·10=034·

← Trade Capture Report Request Ack Msg Type = AQ

8=FIX.4.4·9=125·35=AQ·34=7·52=20051130-08:25:18·49=MEFF·50=C2·56=A899·57=351·568=TCR1B·569=0·263=1·748=0·749=99·750=1·58=%MFITCRNXM-No match·10=110·


31 January 2008 © MEFF 2008 30

3 Trade crossed

A trade is made between account 00101 of member A899 (buy) and 00301, also of member A899 (sell) for 10 MNJ05 contracts.

Due to the subscription made in the previous message, a Trade Capture Report message is received for each party to the trade, as both are accounts of the member that made the query.

The value “Y” in field 325 (UnsolicitedIndicator) indicates that the messages are the result of a subscription.

In each of these messages all the information corresponding to the trade can be found, as outlined in the manual.


8=FIX.4.4·9=407·35=AE·34=10·52=20051130-08:43:08·49=MEFF·50=C2·56=A899·57=351·571=003AC0E40000·150=F·818=101·527=FI0000000001·5681=M·570=Y·55=MNJ05·32=10·31=9300·75=20050330·60=20050330-07:43:07·768=1·769=20050330-07:43:07·770=3·63=0·881=101·880=101·552=1·54=1·37=050330OA89903090001·198=FI1·453=1·448=A899·447=D·452=13·1=00101·381=93000·77=O·136=2·137=0.00·138=EUR·139=4·891=0·137=1.50·138=EUR·139=7·891=0·568=TCR1B·325=Y·10=168·


8=FIX.4.4·9=407·35=AE·34=11·52=20051130-08:43:08·49=MEFF·50=C2·56=A899·57=351·571=003AC1040000·150=F·818=101·527=FI0000000001·5681=M·570=Y·55=MNJ05·32=10·31=9300·75=20050330·60=20050330-07:43:07·768=1·769=20050330-07:43:07·770=3·63=0·881=101·880=101·552=1·54=2·37=050330OA89903090002·198=FI2·453=1·448=A899·447=D·452=13·1=00301·381=93000·77=O·136=2·137=0.00·138=EUR·139=4·891=0·137=1.50·138=EUR·139=7·891=0·568=TCR1B·325=Y·10=154·

4 Request snapshot of all cleared trades

When wanting to make queries on the trades that are cleared the member code will have to be included in the parties block of the request, associated to the role of the clearer.

In the example it has been considered that member A899 is clearer of its account holder 001 (and therefore of account 00101) but not of the holder 003.

MEFFGate sends a message, corresponding to the partie in the previous trade with the self cleared account.

The fact that member A899 is not clearer of its proprietary account 00301 means that it does not receive the other side of the trade that was reported in the above case.

The parties’ block of the Trade Capture Report message makes it possible to determine the member that the account belongs to, on which the information is provided.


8=FIX.4.4·9=110·35=AD·34=7·52=20051130-09:03:10·56=MEFF·57=C2·49=A899·50=351·568=TCR1C·569=0·263=1·453=1·448=A899·447=D·452=4·10=068·


8=FIX.4.4·9=413·35=AE·34=16·52=20051130-09:03:10·49=MEFF·50=C2·56=A899·57=351·571=004D196D0000·150=F·818=101·527=FI0000000001·5681=M·570=Y·55=MNJ05·32=10·31=9300·75=20050330·60=20050330-07:43:07·768=1·769=20050330-07:43:07·770=3·63=0·881=101·880=101·552=1·54=1·37=050330OA89903090001·198=FI1·453=1·448=A899·447=D·452=13·1=00101·381=93000·77=O·136=2·137=0.00·138=EUR·139=4·891=0·137=1.50·138=EUR·139=7·891=0·568=TCR1C·325=N·912=Y·10=198·


31 January 2008 © MEFF 2008 31

5 Query of a trade by clearing register number

As shown in the example, the Trade Capture Report message allows trades to be queried by the clearing register number. Said number will have to be included in field 818 (SecondaryTradeReportID) of the request.

The reply may be made up of two messages if both parties to the trade are under the same member.


8=FIX.4.4·9=91·35=AD·34=9·52=20051130-09:06:41·56=MEFF·57=C2·49=A899·50=351·568=TCR1D·569=0·263=0·818=101·10=148·


8=FIX.4.4·9=413·35=AE·34=18·52=20051130-09:06:41·49=MEFF·50=C2·56=A899·57=351·571=005051B40000·150=F·818=101·527=FI0000000001·5681=M·570=Y·55=MNJ05·32=10·31=9300·75=20050330·60=20050330-07:43:07·768=1·769=20050330-07:43:07·770=3·63=0·881=101·880=101·552=1·54=1·37=050330OA89903090001·198=FI1·453=1·448=A899·447=D·452=13·1=00101·381=93000·77=O·136=2·137=0.00·138=EUR·139=4·891=0·137=1.50·138=EUR·139=7·891=0·568=TCR1D·325=N·912=N·10=170·


8=FIX.4.4·9=413·35=AE·34=19·52=20051130-09:06:41·49=MEFF·50=C2·56=A899·57=351·571=005051B40001·150=F·818=101·527=FI0000000001·5681=M·570=Y·55=MNJ05·32=10·31=9300·75=20050330·60=20050330-07:43:07·768=1·769=20050330-07:43:07·770=3·63=0·881=101·880=101·552=1·54=2·37=050330OA89903090002·198=FI2·453=1·448=A899·447=D·452=13·1=00301·381=93000·77=O·136=2·137=0.00·138=EUR·139=4·891=0·137=1.50·138=EUR·139=7·891=0·568=TCR1D·325=N·912=Y·10=188·

MEFFGate - Examples FIX Interface C1.3.a Trade Management

31 January 2008 © MEFF 2008 32

7. Trade Management This chapter shows examples related to messages described in the chapter of the same name in MEFF FIX protocol manual.

The examples of this chapter are grouped in the following sections:

• Allocations and transfers

• Give-up – Executing Broker

• Give-up – Clearing Broker

• Give-up – Destination account Clearing Member

• Give-up – Use of the Give-Out/In mnemonic

7.1 Allocations and transfers

1 Subscription to all the clearing house trades via Trade capture Report Request message

In order to show all the implications of daily account allocation and transfer operative, a subscription to all the clearing house trades is previously made via Trade Capture Report Request message. Trade Capture Report messages shown in the examples are a result of that subscription.

Trades shown in this section come from the previous operation. These trades will be used in later allocations and transfers.

Field 818 (SecondaryTradeReportID) of Trade capture Report messages contains the clearing house register number of the trade that along with the sign will be used to identify the trade to allocate or transfer.


8=FIX.4.4·9=84·35=AD·34=4·52=20051118-12:50:58·56=MEFF·57=C2·49=A899·50=351·568=TCRYY1·569=0·263=1·10=150·


8=FIX.4.4·9=414·35=AE·34=7·52=20051118-12:50:58·49=MEFF·50=C2·56=A899·57=351·571=010FE96F0000·150=F·818=101·527=FI0000000001·5681=M·570=Y·55=IXZ05·32=10·31=9300·75=20050330·60=20050330-11:46:49·768=1·769=20050330-11:46:49·770=3·63=0·881=101·880=101·552=1·54=2·37=050330OA89935100002·198=FI2·453=1·448=A899·447=D·452=13·1=00101·381=930000·77=O·136=2·137=0.00·138=EUR·139=4·891=0·137=5.00·138=EUR·139=7·891=0·568=TCRYY1·325=N·912=N·10=107·


8=FIX.4.4·9=414·35=AE·34=8·52=20051118-12:50:58·49=MEFF·50=C2·56=A899·57=351·571=010FE96F0001·150=F·818=102·527=FI0000000002·5681=M·570=Y·55=IXZ05·32=10·31=9305·75=20050330·60=20050330-11:46:49·768=1·769=20050330-11:46:49·770=3·63=0·881=102·880=102·552=1·54=1·37=050330OA89935100004·198=FI4·453=1·448=A899·447=D·452=13·1=00101·381=930500·77=O·136=2·137=0.00·138=EUR·139=4·891=0·137=5.00·138=EUR·139=7·891=0·568=TCRYY1·325=N·912=N·10=126·


31 January 2008 © MEFF 2008 33


8=FIX.4.4·9=414·35=AE·34=9·52=20051118-12:50:58·49=MEFF·50=C2·56=A899·57=351·571=010FE96F0002·150=F·818=101·527=FI0000000001·5681=M·570=Y·55=IXZ05·32=10·31=9300·75=20050330·60=20050330-11:46:49·768=1·769=20050330-11:46:49·770=3·63=0·881=101·880=101·552=1·54=1·37=050330OA89935100001·198=FI1·453=1·448=A899·447=D·452=13·1=00D01·381=930000·77=O·136=2·137=0.00·138=EUR·139=4·891=0·137=0.00·138=EUR·139=7·891=0·568=TCRYY1·325=N·912=N·10=122·


8=FIX.4.4·9=415·35=AE·34=10·52=20051118-12:50:58·49=MEFF·50=C2·56=A899·57=351·571=010FE96F0003·150=F·818=102·527=FI0000000002·5681=M·570=Y·55=IXZ05·32=10·31=9305·75=20050330·60=20050330-11:46:49·768=1·769=20050330-11:46:49·770=3·63=0·881=102·880=102·552=1·54=2·37=050330OA89935100003·198=FI3·453=1·448=A899·447=D·452=13·1=00D01·381=930500·77=O·136=2·137=0.00·138=EUR·139=4·891=0·137=0.00·138=EUR·139=7·891=0·568=TCRYY1·325=N·912=Y·10=194·


31 January 2008 © MEFF 2008 34

2 Request of partial allocation of a daily account trade

An Allocation Instruction message is sent as a request for partial allocation of a daily account trade.

The trade to be allocated should be identified by the clearing house register number with field 818 (SecondaryTradeReportID).

In addition to the field for identifying the trade; a group of fields containing additional information of the original trade should be included

• 32 (LastQty) original trade volume

• 31 (LastPx) original trade price

• 54 (Side) position (bid/ask) taken on the original trade

• 55 (Symbol) contract code

Rest of relevant fields of this message is as follows:

• 53 (Quantity) y 80 (AllocQty) volume to allocate

• 6 (AvgPx) price to which the new trade is registered. It should now agree with the price of the original trade.

• 79 (AllocAccount): destination account

After the sending of a request message, two Allocation Instruction Ack messages are received. The first message indicates the acceptance from the MEFFGate server with value 3 (Received not yet processed) in field 87 (AllocStatus). The second one informs of the acceptance from central systems with value 0 (Accepted) in field 87 (AllocStatus)

The Confirmation message is sent to all the traders of the Member and includes the request information and its status. To facilitate monitoring of this message includes the following fields:

• 70 (AllocID): request identifier. Allows the trader who made the request to reconcile the information received with the request.

• 793 (SecondaryAllocID) unique identifier of the transfer assigned by central systems.

Both Trade Capture Report messages inform of the trades derived from the allocation made. They include field 881 (SecondaryTradeReportRefID) that refers to the original trade and field 880 (TrdMatchID) that refers to the starting trade. In this case both fields are the same because the original trade was a market trade.

The new trade identifier is in field 818 (SecondarytradeReportID) of Trade Capture Report messages.

Field 77 (PositionEffect) shows when a trade closes “C” (Close) or opens “O” (Open) position

The tag 381 (GrossTradeAmt) informs the Nominal/Effective amount traded.

As the example shows, Trade Capture Report messages inform of MEFF trade type in field 5681 (ExchangeTradeType). This field can serve to distinguish the daily account and transfers allocations.

← Allocation Instruction Ack Msg Type = P

8=FIX.4.4·9=109·35=P·34=13·52=20051118-12:58:16·49=MEFF·50=C2·56=A899·57=351·70=050330A899351A899351YYALOA1·75=20040426·87=3·10=236·


31 January 2008 © MEFF 2008 35


8=FIX.4.4·9=109·35=P·34=14·52=20051118-12:58:16·49=MEFF·50=C2·56=A899·57=351·70=050330A899351A899351YYALOA1·75=20051118·87=0·10=234·


8=FIX.4.4·9=248·35=AK·34=15·52=20051118-12:58:16·49=MEFF·50=C2·56=A899·57=351·664=1·666=0·773=1·70=050330A899351A899351YYALOA1·793=1·75=20051118·60=20051118-12:58:16·55=IXZ05·80=1·54=1·6=9300·79=00301·5683=A·818=103·881=101·665=1·711=0·555=0·862=0·381=93000·118=0·10=127·


8=FIX.4.4·9=384·35=AE·34=16·52=20051118-12:58:16·49=MEFF·50=C2·56=A899·57=351·571=011697D30000·150=F·818=103·527=FI0000000001·5681=D·570=Y·55=IXZ05·32=1·31=9300·75=20050330·60=20050330-11:58:16·768=1·769=20050330-11:46:49·770=3·63=0·881=101·880=101·552=1·54=2·37=NONE·453=1·448=A899·447=D·452=13·1=00D01·381=93000·77=C·136=2·137=0.00·138=EUR·139=4·891=0·137=0.00·138=EUR·139=7·891=0·568=TCRYY1·325=Y·10=155·


8=FIX.4.4·9=384·35=AE·34=17·52=20051118-12:58:16·49=MEFF·50=C2·56=A899·57=351·571=011697D30001·150=F·818=103·527=FI0000000001·5681=D·570=Y·55=IXZ05·32=1·31=9300·75=20050330·60=20050330-11:58:16·768=1·769=20050330-11:46:49·770=3·63=0·881=101·880=101·552=1·54=1·37=NONE·453=1·448=A899·447=D·452=13·1=00301·381=93000·77=O·136=2·137=0.00·138=EUR·139=4·891=0·137=0.50·138=EUR·139=7·891=0·568=TCRYY1·325=Y·10=156·

3 Request of daily account allocation. Rejected for exceeding the pending volume to allocate

A new request of allocation for the same trade is made which the previous examples refer to. In this case it is rejected because it requests the allocation of a number of contracts higher to the one pending to allocate.

→ Allocation Instruction Msg Type = J

8=FIX.4.4·9=175·35=J·34=8·52=20051118-13:07:55·56=MEFF·57=C2·49=A899·50=351·70=YYALOA3·71=0·626=1·857=0·124=1·32=10·31=9300·818=101·54=1·55=IXZ05·53=10·6=9300·75=20050426·78=1·79=00301·80=10·10=055·


8=FIX.4.4·9=154·35=P·34=18·52=20051118-13:07:56·49=MEFF·50=C2·56=A899·57=351·70=050330A899351A899351YYALOA3·75=20050426·87=1·88=7·58=%MFEAVF047-There is no open position·10=123·


31 January 2008 © MEFF 2008 36

7.2 Give-up (Executing Broker) This section shows examples related to the give-up operation from the Executing Broker’s point of view.

1 Subscription to all the clearing house trades via Trade Capture Report Request message

In order to show all the implications for daily account allocation and transfer operations, a subscription to all the clearing house trades is made previously via Trade Capture Report Request message. Trade Capture Report messages shown in the examples are a result of that subscription.

Trades shown in this section come from the previous operation. These trades will be used in later give-ups.

Field 818 (SecondaryTradeReportID) of Trade Capture Report messages will be used to identify the trades to transfer.


8=FIX.4.4·9=84·35=AD·34=2·52=20051121-08:39:49·56=MEFF·57=C2·49=A899·50=351·568=TCRYY1·569=0·263=1·10=154·


8=FIX.4.4·9=413·35=AE·34=2·52=20051121-08:39:50·49=MEFF·50=C2·56=A899·57=351·571=003C4E2B0000·150=F·818=101·527=FI0000000001·5681=M·570=Y·55=MNZ05·32=10·31=9365·75=20050330·60=20050330-07:39:21·768=1·769=20050330-07:39:21·770=3·63=0·881=101·880=101·552=1·54=2·37=050330OA89935100002·198=FI2·453=1·448=A899·447=D·452=13·1=00101·381=93650·77=O·136=2·137=0.00·138=EUR·139=4·891=0·137=1.50·138=EUR·139=7·891=0·568=TCRYY1·325=N·912=N·10=048·


31 January 2008 © MEFF 2008 37

2 Request of Give-up. Pending acceptance by the Clearing Broker

An Allocation Instruction message is sent to request the give-up of a trade.

The trade wanted to be allocated should be identified by a clearing house register number with field 818 (SecondaryTradeReportID)

In addition to the field for identifying the trade; a group of fields containing additional information of the original trade should be included:

• 32 (LastQty) original trade volume

• 31 (LastPx) original trade price

• 54 (Side) position (bid/ask) taken on the original trade

• 55 (Symbol) contract code

In addition to the trade data, the Clearing Broker and the Give-up reference should be specified. Also the Give-out internal reference is informed (this is an optional field):

• 524 (NestedPartyID), within the NestedParties block:

o 538 (NestedPartyRole) = 3. Give-out internal reference

o 538 (NestedPartyRole) = 14. Clearing Broker code

o 538 (NestedPartyRole) = 24. Give-up reference for the Clearing Broker

Rest of relevant fields of this message are as follows:

• 53 (Quantity) y 80 (AllocQty) volume to transfer

• 6 (AvgPx) price at which the new trade is registered. Should now agree with the price of the original trade

• 381 (GrossTradeAmt): Nominal/Effective amount traded

Note that unlike a request for a daily account allocation or transfer, MEFFGate does not consider the value of field 79 (AllocAccount) because of the destination account will be fixed by the Clearing Broker. The field should be present in the message and it is included to meet requirements of the standard

After the sending of a request message, two Allocation Instruction Ack messages are received. The first message indicates the acceptance from the MEFFGate server with value 3 (Received not yet processed) in field 87 (AllocStatus). The second one informs of the acceptance from central systems with value 0 (Accepted) in field 87 (AllocStatus).

Later a Confirmation message is received and sent to all the traders with data and status of the Give-up.


8=FIX.4.4·9=266·35=J·34=3·52=20051121-10:14:13·56=MEFF·57=C2·49=A899·50=351·70=ZZALOA1·71=0·626=1·857=0·124=1·32=10·31=9365·818=101·54=2·55=MNZ05·53=10·6=9365·75=20040426·78=1·79=00000·80=10·539=3·524=GIRA899A831GIV060·525=D·538=3·524=A831·525=D·538=14·524=REFERENCE01·525=D·538=24·10=176·

232 ← Allocation Instruction Ack Msg Type = P

8=FIX.4.4·9=108·35=P·34=5·52=20051121-10:14:13·49=MEFF·50=C2·56=A899·57=351·70=050330A899351A899351ZZALOA1·75=20051121·87=0·10=162·


31 January 2008 © MEFF 2008 38


8=FIX.4.4·9=373·35=AK·34=6·52=20051121-10:14:13·49=MEFF·50=C2·56=A899·57=351·664=1·666=0·773=1·70=050330A899351A899351ZZALOA1·793=1·75=20051121·60=20051121-10:14:13·55=MNZ05·80=10·54=2·6=9365·79=[N/A]·5683=P·881=101·665=1·711=0·555=0·862=0·381=93650·118=0·453=5·448=A899·447=D·452=1·448=351·447=D·452=12·448=A831·447=D·452=14·448=GIRA899A831GIV060·447=D·452=3·448=REFERENCE01·447=D·452=24·10=211·

3 Acceptance of Give-up by the Clearing Broker. Pending acceptance by Clearing Member of the destination account

Whenever the Give-up changes status, all traders of the Executing Broker are informed by the corresponding Confirmation message.

As seen in the example, field 793 (SecondaryAllocID), Give-up identifier, remains constant during all its life.

The Give-out internal reference is received in the tag 524 (NestedPartyID), within the NestedParties block with 538 (NestedPartyRole) = 3.


8=FIX.4.4·9=379·35=AK·34=8·52=20051121-11:33:57·49=MEFF·50=C2·56=A899·57=351·664=2·666=1·773=1·70=050330A899351A899351ZZALOA1·793=1·75=20051121·60=20051121-11:33:57·55=MNZ05·80=10·54=2·6=9365·79=[N/A]·5683=N·881=101·772=1·665=1·711=0·555=0·862=0·381=93650·118=0·453=5·448=A899·447=D·452=1·448=351·447=D·452=12·448=A831·447=D·452=14·448=GIRA899A831GIV060·447=D·452=3·448=REFERENCE01·447=D·452=24·10=254·

4 Acceptance of Give-up by the Clearing Member of destination account

All Executing Broker users receive the corresponding Confirmation message.

In addition, those users subscribed to the Trade Capture Report messages receive the message corresponding to the trade derived from the Give-up.

The Give-out internal reference is received in the tag 524 (NestedPartyID), within the NestedParties block with 538 (NestedPartyRole) = 3.


8=FIX.4.4·9=387·35=AK·34=9·52=20051121-11:39:11·49=MEFF·50=C2·56=A899·57=351·664=3·666=1·773=1·70=050330A899351A899351ZZALOA1·793=1·75=20051121·60=20051121-11:39:11·55=MNZ05·80=10·54=2·6=9365·79=[N/A]·5683=A·818=102·881=101·772=2·665=1·711=0·555=0·862=0·381=93650·118=0·453=4·448=A899·447=D·452=1·448=351·447=D·452=12·448=A831·447=D·452=14·448=GIRA899A831GIV060·447=D·452=3·448=REFERENCE01·447=D·452=24·10=092·


8=FIX.4.4·9=386·35=AE·34=10·52=20051121-11:39:11·49=MEFF·50=C2·56=A899·57=351·571=00E07C230000·150=F·818=102·527=FI0000000001·5681=G·570=Y·55=MNZ05·32=10·31=9365·75=20050330·60=20050330-10:39:11·768=1·769=20050330-07:39:21·770=3·63=0·881=101·880=101·552=1·54=1·37=NONE·453=1·448=A899·447=D·452=13·1=00101·381=93650·77=C·136=2·137=0.00·138=EUR·139=4·891=0·137=-1.50·138=EUR·139=7·891=0·568=TCRYY1·325=Y·10=230·


31 January 2008 © MEFF 2008 39

7.3 Give-up (Clearing Broker)

1 Reception of request of acceptance for a Give-up

When the Executing Broker requests a Give-up, all the Clearing Broker traders receive a Confirmation message informing of the data and status of the give-up.

The message contains the following information related to the original trade:

• 55 (Symbol): Contract

• 54 (Side): Sign of the trade

• 80 (AllocQty): Trade volume

• 6 (AvgPx): Trade price

• 448 (PartyID), within the Parties block:

o 452 (PartyRole) = 1. Executing Firm code

o 452 (PartyRole) = 24.Give-up reference assigned by the Executing Firm


Field 793 (SecondaryAllocID) contains a unique Give-up identifier allocated by central systems. This field does not vary in the different Give-up notifications and matches with the value received by the rest of participants.

Field 79 (AllocAccount) contains the value “[N/A]” because in the example it has been considered that the Clearing Broker has not associated any account to the reference entered by the Executing Broker. If so, this field would contain the corresponding account.

Field 5683 (SecondaryConfirmStatus) informs of the status of the Give-up. Its value, along with the value of the field 773 (ConfirmType) allows the receiver to distinguish if it is a notification or a request of acceptance/rejection.


8=FIX.4.4·9=321·35=AK·34=2·52=20051121-11:33:15·49=MEFF·50=C2·56=A831·57=001·664=1·666=0·773=2·793=1·75=20051121·60=20051121-11:33:15·55=MNZ05·80=10·54=2·6=9365·79=[N/A]·5683=P·665=1·711=0·555=0·862=0·381=93650·118=0·453=5·448=A899·447=D·452=1·448=351·447=D·452=12·448=A831·447=D·452=14·448=351·447=D·452=36·448=REFERENCE01·447=D·452=24·10=025·


31 January 2008 © MEFF 2008 40

2 Acceptance of a Give-up

To accept or reject a Give-up, one of the Clearing Broker users should send a Confirmation Ack message.

The Confirmation Ack message should identify the Confirmation message to which it responds with field 664 (ConfirmID). In addition, field 793 (SecondaryAllocID), Give-up identifier, should contain the same value received in the Confirmation message.

To indicate that it is an acceptance, field 940 (AffirmSttatus) should contain value 3 (Affirmed).

Because it is an acceptance, the message should contain field 79 (AllocAccount) with the Give-up destination account.

→ Confirmation Ack Msg Type = AU

8=FIX.4.4·9=121·35=AU·34=2·52=20051121-11:33:56·56=MEFF·57=C2·49=A831·50=001·664=1·60=20050330-09:41:22·75=20040426·940=3·79=83001·793=1·10=255·

3 Reception of a give-up notice still pending of acceptance by the Clearing Member of the destination account

In this example, the chosen account is settled by a different member, so that the give-up remains pending until approved by the Clearing Member. Give-up status is located in field 5683 (SecondaryConfirmStatus).


8=FIX.4.4·9=348·35=AK·34=3·52=20051121-11:33:57·49=MEFF·50=C2·56=A831·57=001·664=2·666=1·773=1·793=1·75=20051121·60=20051121-11:33:57·55=MNZ05·80=10·54=2·6=9365·79=83001·5683=N·772=1·665=1·711=0·555=0·862=0·381=93650·118=0·453=6·448=A899·447=D·452=1·448=351·447=D·452=12·448=A831·447=D·452=14·448=001·447=D·452=36·448=A830·447=D·452=4·448=REFERENCE01·447=D·452=24·10=164·

4 Reception of a Give-up notice accepted by the Clearing Member of the destination account

Once the Clearing Member of a destination account accepts the Give-up, Executing Broker users receive the corresponding Confirmation message.

In addition, those users subscribed to the Trade Capture Report messages receive the message corresponding to the trade of opposite sign that takes place in the source account.


8=FIX.4.4·9=356·35=AK·34=4·52=20051121-11:39:11·49=MEFF·50=C2·56=A831·57=001·664=3·666=1·773=1·793=1·75=20051121·60=20051121-11:39:11·55=MNZ05·80=10·54=2·6=9365·79=83001·5683=A·818=102·772=2·665=1·711=0·555=0·862=0·381=93650·118=0·453=6·448=A899·447=D·452=1·448=351·447=D·452=12·448=A831·447=D·452=14·448=001·447=D·452=36·448=A830·447=D·452=4·448=REFERENCE01·447=D·452=24·10=003·


31 January 2008 © MEFF 2008 41

7.4 Give-up (Clearing Member)

1 Reception of Give-up acceptance request in a cleared account

When the Give-up destination account is defined, if the Clearing Broker is not the Clearing Memberof the account, all Clearing Member users of that account are notified of the give-up status.

Like for the Clearing Broker, the Confirmation message contains the Give-up data and its status.

Field 5683 (SecondaryConfirmStatus) informs about the Give-up status. Its value, along with value of the field 773 (ConfirmType), allows the receiver to distinguish if it is a notification or an acceptance/rejection request.

The message contains the following information related to the original trade:

• 448 (PartyID), within the Parties block:

o 452 (PartyRole) = 14. Clearing Broker code

• 55 (Symbol): Contract

• 54 (Side): Sign of the trade

• 80 (AllocQty): Trade volume

• 6 (AvgPx): Trade price


Field 793 (SecondaryAllocID) contains a unique Give-up identifier allocated by central systems. This field does not vary in the different notifications of a Give-up and matches the value received by the rest of participants.

Field 79 (AllocAccount) contains the Give-up destination account.


8=FIX.4.4·9=279·35=AK·34=2·52=20051121-11:37:13·49=MEFF·50=C2·56=A830·57=001·664=2·666=0·773=2·793=1·75=20051121·60=20051121-11:37:13·55=MNZ05·80=10·54=2·6=9365·79=83001·5683=N·665=1·711=0·555=0·862=0·381=93650·118=0·453=3·448=A831·447=D·452=14·448=A830·447=D·452=4·448=REFERENCE01·447=D·452=24·10=241·

2 Give-up acceptance

To accept or reject a Give-up, one of the users of the Clearing Member destination account should send a ConfimationAck message.

The ConfirmationAck message should identify the Confirmation message to which it responds with field 664 (ConfirmID). In addition, field 793 (SecondaryAllocID), Give-up identifier, should contain the same value that was received in Confirmation message.

To indicate acceptance, field 940 (AffirmStatus) should contain value 3 (Affirmed)

Unlike the acceptance by the Clearing Broker, message sent by the Clearing Member should not include the account.

→ Confirmation Ack Msg Type = AU

8=FIX.4.4·9=112·35=AU·34=3·52=20051121-11:39:11·56=MEFF·57=C2·49=A830·50=001·664=2·60=20040426-14:40:15·75=20040426·940=3·793=1·10=085·


31 January 2008 © MEFF 2008 42

3 Notification of the Give-up final status

Once one of the Clearing Member users of the destination account have accepted the Give-up, all its users receive the corresponding Confirmation message.


8=FIX.4.4·9=293·35=AK·34=5·52=20051121-11:39:11·49=MEFF·50=C2·56=A830·57=001·664=3·666=1·773=1·793=1·75=20051121·60=20051121-11:39:11·55=MNZ05·80=10·54=2·6=9365·79=83001·5683=A·818=102·772=2·665=1·711=0·555=0·862=0·381=93650·118=0·453=3·448=A831·447=D·452=14·448=A830·447=D·452=4·448=REFERENCE01·447=D·452=24·10=102·


31 January 2008 © MEFF 2008 43

7.5 Give-up – Use of the Give-Out/In mnemonic This section shows the same examples related to the give-up operation from the Executing Broker’s point of view but using the mnemonic instead of the Clearing Broker - Give-up reference - Give-out internal reference

1 Request of Give-up. Pending acceptance by the Clearing Broker

An Allocation Instruction message is sent to request the Give-up of a trade. In this message the mnemonic is used:

• 524 (NestedPartyID), within the NestedParties block:

o 538 (NestedPartyRole) = 33. Give-up mnemonic

Note that this information is also present in the Confirmation messages received.


8=FIX.4.4·9=207·35=J·34=3·52=20051121-10:14:13·56=MEFF·57=C2·49=A899·50=351·70=ZZALOA1·71=0·626=1·857=0·124=1·32=10·31=9365·818=101·54=2·55=MNZ05·53=10·6=9365·75=20040426·78=1·79=00000·80=10·539=1·524=MNGU_110·525=D·538=33·10=156·

232 ← Allocation Instruction Ack Msg Type = P

8=FIX.4.4·9=108·35=P·34=5·52=20051121-10:14:13·49=MEFF·50=C2·56=A899·57=351·70=050330A899351A899351ZZALOA1·75=20051121·87=0·10=162·


8=FIX.4.4·9=399·35=AK·34=6·52=20051121-10:14:13·49=MEFF·50=C2·56=A899·57=351·664=1·666=0·773=1·70=050330A899351A899351ZZALOA1·793=1·75=20051121·60=20051121-10:14:13·55=MNZ05·80=10·54=2·6=9365·79=[N/A]·5683=P·881=101·665=1·711=0·555=0·862=0·381=93650·118=0·453=6·448=A899·447=D·452=1·448=351·447=D·452=12·448=A831·447=D·452=14·448=MNGU_110·447=D·452=33·448=GIRA899A831GIV060·447=D·452=3·448=REFERENCE01·447=D·452=24·10=066·

2 Acceptance of Give-up by the Clearing Broker. Pending acceptance by Clearing Member of the destination account


8=FIX.4.4·9=405·35=AK·34=8·52=20051121-11:33:57·49=MEFF·50=C2·56=A899·57=351·664=2·666=1·773=1·70=050330A899351A899351ZZALOA1·793=1·75=20051121·60=20051121-11:33:57·55=MNZ05·80=10·54=2·6=9365·79=[N/A]·5683=N·881=101·772=1·665=1·711=0·555=0·862=0·381=93650·118=0·453=6·448=A899·447=D·452=1·448=351·447=D·452=12·448=A831·447=D·452=14·448=MNGU_110·447=D·452=33·448=GIRA899A831GIV060·447=D·452=3·448=REFERENCE01·447=D·452=24·10=091·

3 Acceptance of Give-up by the Clearing Member of destination account ← Confirmation Msg Type = AK

8=FIX.4.4·9=413·35=AK·34=9·52=20051121-11:39:11·49=MEFF·50=C2·56=A899·57=351·664=3·666=1·773=1·70=050330A899351A899351ZZALOA1·793=1·75=20051121·60=20051121-11:39:11·55=MNZ05·80=10·54=2·6=9365·79=[N/A]·5683=A·818=102·881=101·772=2·665=1·711=0·555=0·862=0·381=93650·118=0·453=6·448=A899·447=D·452=1·448=351·447=D·452=12·448=A831·447=D·452=14·448=MNGU_110·447=D·452=33·448=GIRA899A831GIV060·447=D·452=3·448=REFERENCE01·447=D·452=24·10=186·


31 January 2008 © MEFF 2008 44


8=FIX.4.4·9=386·35=AE·34=10·52=20051121-11:39:11·49=MEFF·50=C2·56=A899·57=351·571=00E07C230000·150=F·818=102·527=FI0000000001·5681=G·570=Y·55=MNZ05·32=10·31=9365·75=20050330·60=20050330-10:39:11·768=1·769=20050330-07:39:21·770=3·63=0·881=101·880=101·552=1·54=1·37=NONE·453=1·448=A899·447=D·452=13·1=00101·381=93650·77=C·136=2·137=0.00·138=EUR·139=4·891=0·137=-1.50·138=EUR·139=7·891=0·568=TCRYY1·325=Y·10=230·

MEFFGate - Examples FIX Interface C1.3.a Exercise Instructions

31 January 2008 © MEFF 2008 45

8. Exercise Instructions This chapter presents examples of the messages described in the chapter of the same name in the MEFF FIX protocol manual.

The chapter contains the following sections:

• Prior considerations

• American options before expiration day

• Expiration day

• Exercise result

The first section sets out the prior considerations that need to be taken into account in the following sections.

The second section shows how the early exercise instruction works.

The third section shows how the exercise instruction on the expiration date works.

The last section shows the resulting messages generated by the different exercise instructions in the chapter.

8.1 Prior considerations The expiration date in the examples is June 2005.

The initial situation is that the following open position is held in account “00101”:

• 23 “BB 1200R” contracts. This contract expires on the session date

• 23 “BB 1250R” contracts. This contract expires on the session date

• 23 “B5 1250L” contracts. This contract does NOT expire on the session date

• 0 “B5 1250X” contracts. This contract does NOT expire on the session date


31 January 2008 © MEFF 2008 46

8.2 American options before the expiration date This section shows how the early exercise instruction works. Each of the cases presented takes into account the previous messages in this section.

1 Early exercise instruction

An early exercise is requested using the Position Maintenance Request message. The instruction is to exercise 2 “B5 1250L” option contracts on account “00101”.

In reply a Position Maintenance Report message of acceptance is received with the value 0 (Accepted) in field 722 (PosMaintStatus).

The number of contracts to exercise is indicated in field 704 (LongQty), which is found after field 703 (PosType) with value “EX”. The current position for the contract and account is shown in field 704 (LongQty) after field 703 (PosType) with value “TOT”. Field 704 is replaced by 705 (ShortQty) when a short position is held in the account.

Field 710 (PosReqID) enables the reply and request to be related.

As can be seen in the example, a News message is generated for all traders notifying that there are exercise instructions for the corresponding contract.


8=FIX.4.4·9=161·35=AL·34=2·52=20051122-08:01:06·56=MEFF·57=C2·49=A899·50=351·710=PMA1·709=1·712=1·715=20050617·1=00101·581=1·55=B5 1250L·60=20050617-09:10:21·702=1·703=EX·704=2·10=177·


8=FIX.4.4·9=226·35=AM·34=2·52=20051122-08:01:06·49=MEFF·50=C2·56=A899·57=351·721=001049300000·710=PMA1·709=1·712=1·713=NONE·715=20051122·1=00101·581=1·55=B5 1250L·60=20050617-09:10:21·753=0·702=2·703=EX·704=2·703=TOT·704=23·705=0·722=0·723=0·10=022·

← News Msg Type = B

8=FIX.4.4·9=182·35=B·34=3·52=20051122-08:01:06·49=MEFF·50=C2·56=A899·57=351·148=HAY OPERACIONES DE EJERCICIO PARA EL CONTRATO B5 1250L·33=1·58=HAY OPERACIONES DE EJERCICIO PARA EL CONTRATO B5 1250L·10=188·

2 Cancellation of early exercise instruction (cancellation request)

A Position Maintenance Request message is sent to cancel any existing exercise instruction on the contract “B5 1250L” and account “00101”. The cancellation request for cancellation is indicated with the value 3 (Cancel) in field 712 (PosMaintAction).

In the reply message, if field 703 (PosType) is not present with value “EX” it should be understood that there is no exercise instruction.


8=FIX.4.4·9=142·35=AL·34=3·52=20051122-08:02:10·56=MEFF·57=C2·49=A899·50=351·710=PMA2·709=1·712=3·715=20050617·1=00101·581=1·55=B5 1250L·60=20050617-09:11:21·10=041·


8=FIX.4.4·9=220·35=AM·34=4·52=20051122-08:02:10·49=MEFF·50=C2·56=A899·57=351·721=001142650000·710=PMA2·709=1·712=3·713=NONE·715=20051122·1=00101·581=1·55=B5 1250L·60=20050617-09:11:21·753=0·702=2·703=EX·703=TOT·704=23·705=0·722=0·723=0·10=009·


31 January 2008 © MEFF 2008 47


Request early exercise of 4 “B5 1250L” contracts.




8=FIX.4.4·9=226·35=AM·34=5·52=20051122-08:03:05·49=MEFF·50=C2·56=A899·57=351·721=0012193D0000·710=PMA3·709=1·712=1·713=NONE·715=20051122·1=00101·581=1·55=B5 1250L·60=20050617-09:12:21·753=0·702=2·703=EX·704=4·703=TOT·704=23·705=0·722=0·723=0·10=051·

4 Cancellation of early exercise instruction (Exercise instruction with volume 0)

An exercise instruction is made on the same contract as requested in the above case, but this time with volume 0. For early exercise instructions this action is equivalent to cancellation.




8=FIX.4.4·9=226·35=AM·34=6·52=20051122-08:03:44·49=MEFF·50=C2·56=A899·57=351·721=0012B0AB0000·710=PMA4·709=1·712=1·713=NONE·715=20051122·1=00101·581=1·55=B5 1250L·60=20050617-09:13:21·753=0·702=2·703=EX·704=0·703=TOT·704=23·705=0·722=0·723=0·10=073·


Request early exercise of 3 “B5 1250L” contracts.




8=FIX.4.4·9=226·35=AM·34=8·52=20051122-08:16:40·49=MEFF·50=C2·56=A899·57=351·721=001E8CAD0000·710=PMA5·709=1·712=1·713=NONE·715=20051122·1=00101·581=1·55=B5 1250L·60=20050617-09:14:21·753=0·702=2·703=EX·704=3·703=TOT·704=23·705=0·722=0·723=0·10=110·


31 January 2008 © MEFF 2008 48

6 Early exercise instruction. Rejected because there is no open position

An early exercise instruction is made for contract “B5 1250X”, which is rejected because there is no position in the account referred to in field 1 (Account) for said contract.


8=FIX.4.4·9=162·35=AL·34=10·52=20051122-08:33:23·56=MEFF·57=C2·49=A899·50=351·710=PMA6·709=1·712=1·715=20050617·1=00101·581=1·55=B5 1250X·60=20050617-09:15:21·702=1·703=EX·704=3·10=252·


8=FIX.4.4·9=267·35=AM·34=13·52=20051122-08:33:23·49=MEFF·50=C2·56=A899·57=351·721=002DC8170000·710=PMA6·709=1·712=1·713=NONE·715=20051122·1=00101·581=1·55=B5 1250X·60=20050617-09:15:21·753=0·702=2·703=EX·704=3·703=TOT·704=0·705=0·722=2·723=99·58=%MFEAVF047-There is no open position·10=068·

7 Early exercise instruction. Rejected as it refers to a European option

An early exercise instruction is made for contract “M9 9400L”. The request is rejected, as it is a European option.


8=FIX.4.4·9=162·35=AL·34=16·52=20051122-08:46:20·56=MEFF·57=C2·49=A899·50=351·710=PMA7·709=1·712=1·715=20050617·1=00101·581=1·55=M9 9400L·60=20050617-09:16:21·702=1·703=EX·704=3·10=013·


8=FIX.4.4·9=289·35=AM·34=19·52=20051122-08:46:20·49=MEFF·50=C2·56=A899·57=351·721=0039A9B80000·710=PMA7·709=1·712=1·713=NONE·715=20051122·1=00101·581=1·55=M9 9400L·60=20050617-09:16:21·753=0·702=2·703=EX·704=3·703=TOT·704=100·705=0·722=2·723=99·58=%MFEAVF046-Exercise requests not allowed on the contract·10=145·


31 January 2008 © MEFF 2008 49

8.3 Expiration date This section displays how the exercise instruction works on the day of expiration. Each of the cases presented takes into account the previous messages in this section. In addition the considerations detailed in section 8.1 have been taken into account.

Each case indicates the time in the session when the request is made.

1 Solicitud explicita de no ejercer

During the trading session a Position Maintenance Request message is sent requesting the exercise of zero contracts. Note that on the expiration day this action is different from the cancellation request. The cancellation request means changing a decision by default, and the volume 0 indicates that the option is not exercised even if it is in-the-money.


8=FIX.4.4·9=163·35=AL·34=9·52=20051122-08:55:56·56=MEFF·57=C2·49=A899·50=351·710=PMA100·709=1·712=1·715=20050617·1=00101·581=1·55=BB 1250R·60=20050617-10:00:21·702=1·703=EX·704=0·10=048·


8=FIX.4.4·9=229·35=AM·34=11·52=20051122-08:55:56·49=MEFF·50=C2·56=A899·57=351·721=004272600000·710=PMA100·709=1·712=1·713=NONE·715=20051122·1=00101·581=1·55=BB 1250R·60=20050617-10:00:21·753=0·702=2·703=EX·704=0·703=TOT·704=23·705=0·722=0·723=0·10=195·

2 Request cancellation of instruction to exercise

During the trading session a Position Maintenance Request message is sent with value 3 (Cancel) in field 712 (PosMaintAction). With this action any previous instruction to exercise on the selected account and contract is cancelled, leaving the system to decide if the option should be exercised based on the closing prices.

In the reply message, if field 703 (PosType) is not present with value “EX” it should be understood that there is no exercise instruction.


8=FIX.4.4·9=145·35=AL·34=10·52=20051122-08:56:36·56=MEFF·57=C2·49=A899·50=351·710=PMA101·709=1·712=3·715=20050617·1=00101·581=1·55=BB 1250R·60=20050617-10:11:21·10=214·


8=FIX.4.4·9=223·35=AM·34=12·52=20051122-08:56:36·49=MEFF·50=C2·56=A899·57=351·721=00430DB50000·710=PMA101·709=1·712=3·713=NONE·715=20051122·1=00101·581=1·55=BB 1250R·60=20050617-10:11:21·753=0·702=2·703=EX·703=TOT·704=23·705=0·722=0·723=0·10=214·


31 January 2008 © MEFF 2008 50

3 Request state of exercise instructions

A Request For Positions message is sent to see the state of the exercise instructions made up to that point.

The Request For Positions message can be used for other purposes. To indicate that the query is for exercise instructions the value 2 (Exercises) must be entered in field 724 (PosReqType).

The query made includes all the accounts (value “?????” in field 1, Account) and all the contracts (value “[N/A]” in field 55, Symbol). The selection has not been restricted by any other field.

The Request For Positions Ack message notifies that the query is valid, with the value 0 (Valid Request) in field 728 (PosReqResult). Field 727 (TotalNumPosReports) indicates the number of Position Report messages to be received.

Finally a Position Report message is received for each account-contract where there is an exercise instruction. These messages contain two blocks identical to those in the Positions Maintenance Report message indicating the volume to exercise and the available volume. For example, fields “702=2·703=TOT·704=23·705=0·703=EX·704=3” indicate that there is a position of 23 contracts and an instruction to exercise 3.

This query returns the instructions made by the member, regardless of the trader that sent them.


8=FIX.4.4·9=141·35=AN·34=11·52=20051122-08:57:14·56=MEFF·57=C2·49=A899·50=351·710=RFPA1·724=2·263=0·1=?????·581=1·55=[N/A]·715=20050617·60=20050617-10:11:21·10=185·


8=FIX.4.4·9=121·35=AO·34=13·52=20051122-08:57:14·49=MEFF·50=C2·56=A899·57=351·721=0043A5130000·710=RFPA1·727=2·728=0·729=0·1=?????·581=1·10=126·


8=FIX.4.4·9=216·35=AP·34=14·52=20051122-08:57:14·49=MEFF·50=C2·56=A899·57=351·724=2·728=0·730=0.39·731=2·734=0.64·581=1·715=20051122·1=00101·55=B5 1250L·702=2·703=TOT·704=23·705=0·703=EX·704=3·721=0043A5130001·710=RFPA1·325=N·727=2·10=013·


8=FIX.4.4·9=210·35=AP·34=15·52=20051122-08:57:14·49=MEFF·50=C2·56=A899·57=351·724=2·728=0·730=0.39·731=2·734=0.39·581=1·715=20051122·1=00101·55=BB 1250R·702=2·703=TOT·704=23·705=0·703=EX·721=0043A5130002·710=RFPA1·325=N·727=2·10=018·

4 Partial exercise instruction

During the trading session a request to exercise a certain number of contracts on an account is made. This action indicates the number of contracts to exercise regardless of the closing price of the underlying. The rest of the position will not be exercised under any circumstances.

The same action can be undertaken during the exercise extension.


8=FIX.4.4·9=165·35=AL·34=13·52=20051122-09:05:39·56=MEFF·57=C2·49=A899·50=351·710=PMA200·709=1·712=1·715=20050617·1=00101·581=1·55=BB 1250R·60=20050617-18:10:21·702=1·703=EX·704=10·10=149·


31 January 2008 © MEFF 2008 51


8=FIX.4.4·9=230·35=AM·34=17·52=20051122-09:05:39·49=MEFF·50=C2·56=A899·57=351·721=004B570C0000·710=PMA200·709=1·712=1·713=NONE·715=20051122·1=00101·581=1·55=BB 1250R·60=20050617-18:10:21·753=0·702=2·703=EX·704=10·703=TOT·704=23·705=0·722=0·723=0·10=025·


31 January 2008 © MEFF 2008 52

8.4 Exercise result This section shows the result of exercising options, based on the actions previously taken in this chapter.

The situation is summarised as:

• Open position of 23 “B5 1250L” contracts that DOES NOT expire today. 3 contracts are exercised early.

• Open position of 23 “BB 1250R” contracts that expires today. Exercised automatically as the contracts are in-the-money and no specific request has been made

• Open position of 23 “BB 1200R” contracts that expires today. The contracts are out-of-the-money. 10 contracts are exercised as explicitly requested

The Trade Capture Report messages presented in this section are the result of the subscription to that information. The message requesting this subscription has not been included.

Note that the Trade Capture Report messages notify the trade type in field 5681(ExchangeTradeType), in this case with the value “E” (Option Exercise) for the exercise and the value “V” (Expiry) for abandonment (not exercised).

1 Early exercise

The next message notifies of the early exercise of 3 contracts (field 32, LastQty) of the option “B5 1250L” (field 55, Symbol).

Note that the exercise of a long position is expressed through the value 2 (Sell) in field 54 (Side).


8=FIX.4.4·9=363·35=AE·34=25·52=20051122-09:12:27·49=MEFF·50=C2·56=A899·57=351·571=0051930E0001·150=F·818=104·5681=E·570=Y·55=B5 1250L·32=3·31=0·75=20050617·60=20050617-08:12:27·768=1·769=20050617-08:12:27·770=3·63=0·881=104·880=104·552=1·54=2·37=NONE·453=1·448=A899·447=D·452=13·1=00101·381=0·77=C·136=2·137=0.00·138=EUR·139=4·891=0·137=0.30·138=EUR·139=7·891=0·568=TCRYY1·325=Y·10=044·

2 Automatic exercise of option in-the-money

The first message notifies the automatic exercise of the entire position (23 contracts) of the option “BB 1250R” held in account “00101”. This exercise is not derived from any prior action and occurs because the option ends up being in-the-money.

For this case it has been assumed that there is an opposite position in another account (00301) that has been selected as counterparty of some exercise. Accordingly a second Trade Capture Report message is received with the value 1 (Buy) in field 54 (Side).


8=FIX.4.4·9=364·35=AE·34=30·52=20051123-08:25:37·49=MEFF·50=C2·56=A899·57=351·571=00298B9E0007·150=F·818=107·5681=E·570=Y·55=BB 1250R·32=23·31=0·75=20050617·60=20050617-07:25:36·768=1·769=20050617-07:25:36·770=3·63=0·881=107·880=107·552=1·54=2·37=NONE·453=1·448=A899·447=D·452=13·1=00101·381=0·77=C·136=2·137=0.00·138=EUR·139=4·891=0·137=2.30·138=EUR·139=7·891=0·568=TCRYY1·325=Y·10=166·


31 January 2008 © MEFF 2008 53



3 Position partially exercised on the expiration day

The following Trade Capture Report messages reflect the situation of the partial exercise (10 contracts) from a position of 23 contracts of option “BB 1200R”.

In this case two Trade Capture Report messages are received. The first notifies the exercise of 10 contracts and the second notifies the abandonment (no exercise) of 13 contracts. Note that this situation is reflected in field 5681 (ExchangeTradeType), which contains the value “E”·(Option Exercise) in the first case and value “V” (Expiry) in the second.

The messages received are independent of whether the contract ends up out-of-the-money or in-the-money, as the rest of the position that has not been requested to be exercised is not exercised in any event.




8=FIX.4.4·9=364·35=AE·34=28·52=20051123-08:25:37·49=MEFF·50=C2·56=A899·57=351·571=00298B9E0005·150=F·818=106·5681=V·570=Y·55=BB 1200R·32=13·31=0·75=20050617·60=20050617-07:25:36·768=1·769=20050617-07:25:36·770=3·63=0·881=106·880=106·552=1·54=2·37=NONE·453=1·448=A899·447=D·452=13·1=00101·381=0·77=C·136=2·137=0.00·138=EUR·139=4·891=0·137=0.00·138=EUR·139=7·891=0·568=TCRYY1·325=Y·10=174·

MEFFGate - Examples FIX Interface C1.3.a Communication of Events

31 January 2008 © MEFF 2008 54

9. Communication of Events This chapter presents examples of the messages described in the chapter of the same name of the MEFF FIX protocol manual.

1 Reception of message from Market Supervisor

The next News message corresponds to the reception of a Market Supervisor message.

← News Msg Type = B 8=FIX.4.4·9=133·35=B·34=14·52=20040513-15:51:53·49=MEFF·50=C2·56=A894·57=351·43=Y·122=20040513-15:25:36·148=160926·33=1·58=MENSAJE DEL ADMINISTRADOR·10=144·

2 Sending of Market Supervisor message

Sending a message by the Market Supervisor. When the message is sent without any problem no confirmation message is received.

→ News Msg Type = B 8=FIX.4.4·9=116·35=B·34=3·49=A894·50=351·56=MEFF·57=C2·52=20040517-07:43:49·61=0·148=H1·33=1·58=ESTE ES UN MENSAJE AL ADMINISTRADOR·10=205·

3 Sending message to Market Supervisor. Rejected due to error in field 148 (Headline)

Sending a message to Market Supervisor. The message is rejected as field 148 (Headline) contains a null chain, which is not allowed by the standard in any field.

→ News Msg Type = B 8=FIX.4.4·9=114·35=B·34=2·49=A894·50=351·56=MEFF·57=C2·52=20040517-07:43:39·61=0·148=·33=1·58=ESTE ES UN MENSAJE AL ADMINISTRADOR·10=080·

← Reject Msg Type = 3 8=FIX.4.4·9=110·35=3·34=2·52=20040517-07:43:39·49=MEFF·50=C2·56=A894·57=351·45=2·58=%MFEMC1IVF-Invalid value for field [148=]·10=053·

MEFFGate - Examples FIX Interface C1.3.a Give-up References and Filters Management

31 January 2008 © MEFF 2008 55

10. Give-up References and Filters Management This chapter presents examples of the messages described in the chapter of the same name of the MEFF FIX protocol manual.

1 Query

A Registration Instructions message is sent requesting information to Give-up References and Filters (value 0 in field 263, SubscriptionRequestType).

The identifier of the subscription is “GRFCO030” field 513 (RegistID). This identifier can be found in the associated response messages, in the same field of the Registration Instructions Response messages.

In response to the petition, if correct, a message Registration Instructions Response is received for each reference and filter available at this point in the system with the tag 506 (RegistStatus) = “A” (Accepted).

Note that field 912 (LastRptRequested) of the Registration Instructions Response List message contains the value “Y”, which indicates that it is the last Security List message of the snapshot.

The tag 523 (PartySubID), within the Parties block of each Registration Instructions Response message, allows us to distinguish what type of record involved. For example:

• 523 = GOR (Give-out references by the Executing Broker)

• 523 = GIR (Give-in references by the Clearing Broker)

• 523 = GIF (Give-in filters by the Clearing Broker)

• 523 = GIFCM (Give-in filters by the Clearing Member)

• …

→ Registration Instructions Msg Type = o 8=FIX.4.4·9=87·35=o·34=548·52=20080115-17:30:38·56=MEFF·57=C2·49=A899·50=351·513=GRFCO030·514=1·263=0·10=020·

← Registration Instructions Response Msg Type = p 8=FIX.4.4·9=344·35=p·34=5461·52=20080115-17:30:38·49=MEFF·50=C2·56=A899·57=351·513=GRFCO030·514=0·508=050330A700001A899351M000000001·912=N·453=4·448=GIRA899A831GU110·447=D·452=3·802=1·523=GOR·803=5000·448=A831·447=D·452=14·802=1·523=GOR·803=5000·448=REFA899A831GIV01OK·447=D·452=24·802=1·523=GOR·803=5000·448=MNGU_110·447=D·452=33·802=1·523=GOR·803=5000·506=A·10=106·

← Registration Instructions Response Msg Type = p 8=FIX.4.4·9=287·35=p·34=5462·52=20080115-17:30:38·49=MEFF·50=C2·56=A899·57=351·513=GRFCO030·514=0·508=050330A899351A899351M000000012·912=N·453=3·448=A830·447=D·452=1·802=1·523=GIR·803=5000·448=GU_RE_030·447=D·452=24·802=1·523=GIR·803=5000·448=GU_RE_030·447=D·452=33·802=1·523=GIR·803=5000·1=00401·506=A·10=186·

← Registration Instructions Response Msg Type = p 8=FIX.4.4·9=275·35=p·34=5463·52=20080115-17:30:38·49=MEFF·50=C2·56=A899·57=351·513=GRFCO030·514=0·508=050330A899351A899351M000000006·912=N·453=2·448=A830·447=D·452=1·802=1·523=GIF·803=5000·448=GU_RE_030·447=D·452=24·802=1·523=GIF·803=5000·232=2·233=TAL·234=6000000·233=SAL·234=6000000·506=A·10=233·


31 January 2008 © MEFF 2008 56

← Registration Instructions Response Msg Type = p 8=FIX.4.4·9=238·35=p·34=5464·52=20080115-17:30:38·49=MEFF·50=C2·56=A899·57=351·513=GRFCO030·514=0·508=050330A899001A899001M000000015·912=N·453=1·448=A831·447=D·452=14·802=1·523=GIFCM·803=5000·1=GIA01·232=2·233=TAL·234=60000000·233=SAL·234=60000000·506=A·10=135·

← Registration Instructions Response Msg Type = p 8=FIX.4.4·9=238·35=p·34=5465·52=20080115-17:30:38·49=MEFF·50=C2·56=A899·57=351·513=GRFCO030·514=0·508=050330A899001A899001M000000016·912=N·453=1·448=A831·447=D·452=14·802=1·523=GIFCM·803=5000·1=LB201·232=2·233=TAL·234=60000000·233=SAL·234=60000000·506=A·10=120·

← Registration Instructions Response Msg Type = p 8=FIX.4.4·9=238·35=p·34=5466·52=20080115-17:30:38·49=MEFF·50=C2·56=A899·57=351·513=GRFCO030·514=0·508=050330A899001A899001M000000017·912=Y·453=1·448=A831·447=D·452=14·802=1·523=GIFCM·803=5000·1=LN101·232=2·233=TAL·234=60000000·233=SAL·234=60000000·506=A·10=144·

2 Add a new Give-out reference by the Executing Broker

A Registration Instructions message is sent with tag 514 (RegistTransType) = 0 (New) and tag 523 (PartySubID) within the Parties block = GOR.

When the request has been accepted a Registration Instructions Response message is received with tag 506 (RegistStatus) = “A” (Accepted).

Note that the request has the identifier “GRFGOR010” in tag 513 (RegistID). The reply message is related with the entry message by the same field 513 (RegistID) that contains the original value starting from position 21. The first 20 positions are formed following the criteria explained in the reference manual.

→ Registration Instructions Msg Type = o 8=FIX.4.4·9=210·35=o·34=602·52=20080115-17:31:13·56=MEFF·57=C2·49=A899·50=351·513=GRFGOR010·514=0·453=3·448=A830·447=D·452=14·802=1·523=GOR·448=GU_GRF_GOR_010·447=D·452=24·802=1·523=GOR·448=GOR_010M·447=D·452=33·802=1·523=GOR·10=166·

← Registration Instructions Response Msg Type = p 8=FIX.4.4·9=264·35=p·34=5484·52=20080115-17:31:13·49=MEFF·50=C2·56=A899·57=351·513=050330A899351A899351GRFGOR010·514=0·453=3·448=A830·447=D·452=14·802=1·523=GOR·803=5000·448=GU_GRF_GOR_010·447=D·452=24·802=1·523=GOR·803=5000·448=GOR_010M·447=D·452=33·802=1·523=GOR·803=5000·506=A·10=020·


31 January 2008 © MEFF 2008 57

3 Replace a Give-out reference by the Executing Broker

Request to modify previous reference is sent.

A Registration Instructions message is sent with tag 514 (RegistTransType) = 1 (Replace).

The register to modify is referenced in field 508 (RegistIRefD) “GRFGOR010”. The modification request contains the RegistID “GRFGOR050” (field 513).

In this example the Give-out internal reference is added (tag PartyID [448] within the Parties block with PartyRole [452] = 3). This information was not included in the previous request because is an optional field.

Note that all the information is required in a modification request (as was reported at the time).


→ Registration Instructions Msg Type = o 8=FIX.4.4·9=273·35=o·34=620·52=20080115-17:31:21·56=MEFF·57=C2·49=A899·50=351·513=GRFGOR050·514=1·508=GRFGOR010·453=4·448=GOR_050INTERNALREF·447=D·452=3·802=1·523=GOR·448=A830·447=D·452=14·802=1·523=GOR·448=GU_GRF_GOR_010·447=D·452=24·802=1·523=GOR·448=GOR_010M·447=D·452=33·802=1·523=GOR·10=209·

← Registration Instructions Response Msg Type = p

8=FIX.4.4·9=356·35=p·34=5490·52=20080115-17:31:21·49=MEFF·50=C2·56=A899·57=351·513=050330A899351A899351GRFGOR050·514=1·508=050330A899351A899351GRFGOR010·453=4·448=GOR_050INTERNALREF·447=D·452=3·802=1·523=GOR·803=5000·448=A830·447=D·452=14·802=1·523=GOR·803=5000·448=GU_GRF_GOR_010·447=D·452=24·802=1·523=GOR·803=5000·448=GOR_010M·447=D·452=33·802=1·523=GOR·803=5000·506=A·10=006·



The field to be modified is the Give-up reference (tag PartyID [448] within the Parties block with PartyRole [452] = 24).

Note that the Give-out internal reference is nor informed (tag PartyID [448] within the Parties block with PartyRole [452] = 3). Therefore this information is deleted from the system. If you want to preserve it must send in the Registration Instructions modification message

→ Registration Instructions Msg Type = o 8=FIX.4.4·9=242·35=o·34=623·52=20080115-17:31:23·56=MEFF·57=C2·49=A899·50=351·513=GRFGOR060·514=1·508=GRFGOR050·453=3·448=A830·447=D·452=14·802=1·523=GOR·803=5000·448=GU_GRF_GOR_060·447=D·452=24·802=1·523=GOR·803=5000·448=GOR_010M·447=D·452=33·802=1·523=GOR·10=045·


8=FIX.4.4·9=298·35=p·34=5491·52=20080115-17:31:23·49=MEFF·50=C2·56=A899·57=351·513=050330A899351A899351GRFGOR060·514=1·508=050330A899351A899351GRFGOR050·453=3·448=A830·447=D·452=14·802=1·523=GOR·803=5000·448=GU_GRF_GOR_060·447=D·452=24·802=1·523=GOR·803=5000·448=GOR_010M·447=D·452=33·802=1·523=GOR·803=5000·506=A·10=143·



The field to be modified is the Give-up Clearing Firm (tag PartyID [448] within the Parties block with PartyRole [452] = 14).


31 January 2008 © MEFF 2008 58

→ Registration Instructions Msg Type = o 8=FIX.4.4·9=242·35=o·34=626·52=20080115-17:31:25·56=MEFF·57=C2·49=A899·50=351·513=GRFGOR070·514=1·508=GRFGOR060·453=3·448=A820·447=D·452=14·802=1·523=GOR·803=5000·448=GU_GRF_GOR_060·447=D·452=24·802=1·523=GOR·803=5000·448=GOR_010M·447=D·452=33·802=1·523=GOR·10=051·


8=FIX.4.4·9=298·35=p·34=5492·52=20080115-17:31:25·49=MEFF·50=C2·56=A899·57=351·513=050330A899351A899351GRFGOR070·514=1·508=050330A899351A899351GRFGOR060·453=3·448=A820·447=D·452=14·802=1·523=GOR·803=5000·448=GU_GRF_GOR_060·447=D·452=24·802=1·523=GOR·803=5000·448=GOR_010M·447=D·452=33·802=1·523=GOR·803=5000·506=A·10=147·

4 Cancel a Give-out reference by the Executing Broker

A cancel request for the previous reference is sent.

A Registration Instructions message is sent with tag 514 (RegistTransType) = 2 (Cancel).

The register to cancel is referenced in field 508 (RegistIRefD) “GRFGOR070”. The cancel request contains the RegistID “GRFGOR130” (field 513).

Note that all the information is required in a cancel request (as was reported at the time).


→ Registration Instructions Msg Type = o 8=FIX.4.4·9=251·35=o·34=644·52=20080115-17:31:37·56=MEFF·57=C2·49=A899·50=351·513=GRFGOR130·514=2·508=GRFGOR070·453=3·448=A820·447=D·452=14·802=1·523=GOR·803=5000·448=GU_GRF_GOR_060·447=D·452=24·802=1·523=GOR·803=5000·448=GOR_010M·447=D·452=33·802=1·523=GOR·803=9999·10=242·

← Registration Instructions Response Msg Type = p 8=FIX.4.4·9=298·35=p·34=5498·52=20080115-17:31:37·49=MEFF·50=C2·56=A899·57=351·513=050330A899351A899351GRFGOR130·514=2·508=050330A899351A899351GRFGOR070·453=3·448=A820·447=D·452=14·802=1·523=GOR·803=5000·448=GU_GRF_GOR_060·447=D·452=24·802=1·523=GOR·803=5000·448=GOR_010M·447=D·452=33·802=1·523=GOR·803=5000·506=A·10=155·

5 Add a new Give-in reference by the Clearing Broker

A Registration Instructions message is sent with tag 514 (RegistTransType) = 0 (New) and tag 523 (PartySubID) within the Parties block = GIR. The request has the identifier “GRFGIR020” in tag 513 (RegistID).


→ Registration Instructions Msg Type = o 8=FIX.4.4·9=244·35=o·34=554·52=20080115-17:30:41·56=MEFF·57=C2·49=A899·50=351·513=GRFGIR020·514=0·453=3·448=A830·447=D·452=1·802=1·523=GIR·803=5000·448=GU_GRF_GIR_020·447=D·452=24·802=1·523=GIR·803=5000·448=GIR_020M·447=D·452=33·802=1·523=GIR·803=9999·1=00401·10=187·


31 January 2008 © MEFF 2008 59

← Registration Instructions Response Msg Type = p 8=FIX.4.4·9=271·35=p·34=5468·52=20080115-17:30:41·49=MEFF·50=C2·56=A899·57=351·513=050330A899351A899351GRFGIR020·514=0·453=3·448=A830·447=D·452=1·802=1·523=GIR·803=5000·448=GU_GRF_GIR_020·447=D·452=24·802=1·523=GIR·803=5000·448=GIR_020M·447=D·452=33·802=1·523=GIR·803=5000·1=00401·506=A·10=035·

6 Replace a Give-in reference by the Clearing Broker



The register to modify is referenced in field 508 (RegistIRefD) “GRFGIR020”. The modification request contains the RegistID “GRFGIR090” (field 513).

The field to be modified is the Give-in mnemonic (tag PartyID [448] within the Parties block with PartyRole [452] = 33).


→ Registration Instructions Msg Type = o 8=FIX.4.4·9=259·35=o·34=578·52=20080115-17:30:57·56=MEFF·57=C2·49=A899·50=351·513=GRFGIR090·514=1·508=GRFGIR020·453=3·448=A830·447=D·452=1·802=1·523=GIR·803=5000·448=GU_GRF_GIR_020·447=D·452=24·802=1·523=GIR·803=5000·448=GIR_020MX·447=D·452=33·802=1·523=GIR·803=9999·1=00401·10=092·


8=FIX.4.4·9=306·35=p·34=5476·52=20080115-17:30:57·49=MEFF·50=C2·56=A899·57=351·513=050330A899351A899351GRFGIR090·514=1·508=050330A899351A899351GRFGIR020·453=3·448=A830·447=D·452=1·802=1·523=GIR·803=5000·448=GU_GRF_GIR_020·447=D·452=24·802=1·523=GIR·803=5000·448=GIR_020MX·447=D·452=33·802=1·523=GIR·803=5000·1=00401·506=A·10=233·

7 Cancel a Give-in reference by the Clearing Broker

A cancel request for the previous reference is sent.


The register to cancel is referenced in field 508 (RegistIRefD) “GRFGIR090”. The cancel request contains the RegistID “GRFGIR130” (field 513).


→ Registration Instructions Msg Type = o 8=FIX.4.4·9=258·35=o·34=590·52=20080115-17:31:05·56=MEFF·57=C2·49=A899·50=351·513=GRFGIR130·514=2·508=GRFGIR090·453=3·448=A830·447=D·452=1·802=1·523=GIR·803=5000·448=GU_GRF_GIR_020·447=D·452=24·802=1·523=GIR·803=5000·448=GIR_020M·447=D·452=33·802=1·523=GIR·803=9999·1=00401·10=250·


8=FIX.4.4·9=305·35=p·34=5480·52=20080115-17:31:05·49=MEFF·50=C2·56=A899·57=351·513=050330A899351A899351GRFGIR130·514=2·508=050330A899351A899351GRFGIR090·453=3·448=A830·447=D·452=1·802=1·523=GIR·803=5000·448=GU_GRF_GIR_020·447=D·452=24·802=1·523=GIR·803=5000·448=GIR_020M·447=D·452=33·802=1·523=GIR·803=5000·1=00401·506=A·10=136·

8 Add a new Give-in Filter by the Clearing Broker


31 January 2008 © MEFF 2008 60

A Registration Instructions message is sent with tag 514 (RegistTransType) = 0 (New) and tag 523 (PartySubID) within the Parties block = GIF. The request has the identifier “GFIGID020” in tag 513 (RegistID).


In this example the following infomation is entered:

• Executing Firm = “?”s (tag PartyID [448] within the Parties block with PartyRole [452] = 1)

• Give-up reference = GU_GRF_GIR_010 (tag PartyID [448] within the Parties block with PartyRole [452] = 24)

• Transaction Amount Limit = 999999999 (tag StipulationValue [234] within the Stipulations block with StipulationType [233] = TAL)

• Session Amount Limit = 0 (tag StipulationValue [234] within the Stipulations block with StipulationType [233] = SAL)

→ Registration Instructions Msg Type = o 8=FIX.4.4·9=211·35=o·34=698·52=20080115-17:32:00·56=MEFF·57=C2·49=A899·50=351·513=GFIGID020·514=0·453=2·448=????·447=D·452=1·802=1·523=GIF·448=GU_GRF_GIR_010·447=D·452=24·802=1·523=GIF·232=2·233=TAL·234=999999999·233=SAL·234=0·10=127·


8=FIX.4.4·9=256·35=p·34=5522·52=20080115-17:32:00·49=MEFF·50=C2·56=A899·57=351·513=050330A899351A899351GFIGID020·514=0·453=2·448=????·447=D·452=1·802=1·523=GIF·803=5000·448=GU_GRF_GIR_010·447=D·452=24·802=1·523=GIF·803=5000·232=2·233=TAL·234=999999999·233=SAL·234=0·506=A·10=057·



• Executing Firm = A830 (tag PartyID [448] within the Parties block with PartyRole [452] = 1)

• Give-up reference = “?”s (tag PartyID [448] within the Parties block with PartyRole [452] = 24)

→ Registration Instructions Msg Type = o 8=FIX.4.4·9=224·35=o·34=701·52=20080115-17:32:01·56=MEFF·57=C2·49=A899·50=351·513=GFIGID025·514=0·453=2·448=A830·447=D·452=1·802=1·523=GIF·803=5000·448=??????????????????·447=D·452=24·802=1·523=GIF·232=2·233=TAL·234=999999999·233=SAL·234=0·10=091·


8=FIX.4.4·9=260·35=p·34=5523·52=20080115-17:32:01·49=MEFF·50=C2·56=A899·57=351·513=050330A899351A899351GFIGID025·514=0·453=2·448=A830·447=D·452=1·802=1·523=GIF·803=5000·448=??????????????????·447=D·452=24·802=1·523=GIF·803=5000·232=2·233=TAL·234=999999999·233=SAL·234=0·506=A·10=126·



• Executing Firm = A831 (tag PartyID [448] within the Parties block with PartyRole [452] = 1)

• Give-up reference = “?”s (tag PartyID [448] within the Parties block with PartyRole [452] =


31 January 2008 © MEFF 2008 61

24)

• Transaction Amount Limit = [N/A] (tag StipulationValue [234] within the Stipulations block con StipulationType [233] = TAL)

• Session Amount Limit = 0 (tag StipulationValue [234] within the Stipulations block StipulationType [233] = SAL)

→ Registration Instructions Msg Type = o 8=FIX.4.4·9=211·35=o·34=704·52=20080115-17:32:02·56=MEFF·57=C2·49=A899·50=351·513=GFIGID030·514=0·453=2·448=A831·447=D·452=1·802=1·523=GIF·448=??????????????????·447=D·452=24·802=1·523=GIF·232=2·233=TAL·234=[N/A]·233=SAL·234=0·10=047·


8=FIX.4.4·9=256·35=p·34=5524·52=20080115-17:32:02·49=MEFF·50=C2·56=A899·57=351·513=050330A899351A899351GFIGID030·514=0·453=2·448=A831·447=D·452=1·802=1·523=GIF·803=5000·448=??????????????????·447=D·452=24·802=1·523=GIF·803=5000·232=2·233=TAL·234=[N/A]·233=SAL·234=0·506=A·10=247·

9 Replace a Give-in Filter by the Clearing Broker

Request to modify previous filter is sent with identifier “GFIGID030”.


The filter to modify is referenced in field 508 (RegistIRefD) “GFIGID030”. The modification request contains the value “GFIGID070” in the tag 513 (RegistID).

In this example the field to be modified is the transaction amount limit (tag StipulationValue [234] within the Stipulations block with StipulationType [233] = TAL).


→ Registration Instructions Msg Type = o

8=FIX.4.4·9=225·35=o·34=716·52=20080115-17:32:06·56=MEFF·57=C2·49=A899·50=351·513=GFIGID070·508=GFIGID030·514=1·453=2·448=A831·447=D·452=1·802=1·523=GIF·448=??????????????????·447=D·452=24·802=1·523=GIF·232=2·233=TAL·234=50000·233=SAL·234=0·10=215·


8=FIX.4.4·9=290·35=p·34=5528·52=20080115-17:32:06·49=MEFF·50=C2·56=A899·57=351·513=050330A899351A899351GFIGID070·514=1·508=050330A899351A899351GFIGID030·453=2·448=A831·447=D·452=1·802=1·523=GIF·803=5000·448=??????????????????·447=D·452=24·802=1·523=GIF·803=5000·232=2·233=TAL·234=50000·233=SAL·234=0·506=A·10=204·

10 Cancel a Give-in Filter by the Clearing Broker

A cancel request for the previous reference is sent with identifier “GFIGID025”.


The filter to cancel is referenced in field 508 (RegistIRefD) “GFIGID025”. The cancel request contains the value “GFIGID100” in the tag 513 (RegistID).



31 January 2008 © MEFF 2008 62

→ Registration Instructions Msg Type = o

8=FIX.4.4·9=229·35=o·34=734·52=20080115-17:32:12·56=MEFF·57=C2·49=A899·50=351·513=GFIGID100·508=GFIGID025·514=2·453=2·448=A830·447=D·452=1·802=1·523=GIF·448=??????????????????·447=D·452=24·802=1·523=GIF·232=2·233=TAL·234=999999999·233=SAL·234=0·10=226·


8=FIX.4.4·9=294·35=p·34=5534·52=20080115-17:32:12·49=MEFF·50=C2·56=A899·57=351·513=050330A899351A899351GFIGID100·514=2·508=050330A899351A899351GFIGID025·453=2·448=A830·447=D·452=1·802=1·523=GIF·803=5000·448=??????????????????·447=D·452=24·802=1·523=GIF·803=5000·232=2·233=TAL·234=999999999·233=SAL·234=0·506=A·10=212·

Documents

MEFFGate · 2010. 3. 8. · 8.1 Prior considerations ... This document provides examples for a specific version of the MEFFGate FIX interface. In this case version C1.3. The version