Nordea e-markets FIX - Rules of Engagement

Version: 1.04 Date: 2014-07-11 Nordea e-markets FIX - Rules of Engagement

Table of Contents 1. Introduction... 2 1.1. FIX Protocol Compliance... 2 1.2. Supported Use-cases... 2 1.3. User Accounts... 3 1.3.1. Main User Account... 3 1.3.2. Business User Account... 3 2. Product Offering... 4 2.1. Trading Scenarios... 4 2.2. Supported Products... 4 3. Message Flows... 5 3.1. FIX Session Creation... 6 3.2. User Session Creation... 6 3.3. RFQ Trading Session... 7 3.4. RFS Pricing Session... 9 3.5. RFS Trading Session... 10 4. Client Implementation... 11 4.1. On-board Procedure... 11 4.2. Operation Hours... 11 4.3. FIX Demo Client... 11 4.4. Technical Support... 11 Appendix A: Supported Tenors... 12 Appendix B: Order Rejection Reasons... 12 Appendix C: Message Examples... 14 Disclaimer... 16 Note: The FIX message reference is provided in another document.

1. Introduction The purpose of this document is to provide details on Nordea e-markets Financial Information exchange (FIX) server. The FIX messaging protocol was developed to facilitate the electronic exchange of information related to securities transactions but was later enhanced to provide support to the Foreign exchange (FX) market. This document provides details of all FX products and pricing/trading scenarios supported by Nordea FIX server. It focuses on the technical aspects of using the FIX server to provide clients with a clear understanding of how a successful connection could be made. 1.1. FIX Protocol Compliance The Nordea e-markets FIX server is fully compliant with FIXT 1.1 for session-level administrative messages. The application level messages that are supported by this FIX server are designed based on FIX 5.0SP2 with some additional customized FIX tags, which are required in order to fully support all products and trading scenarios that Nordea e-markets offers via FIX. Furthermore, the design and implementation of FX trading message flows follows recommendations from FIXProtocol.org. More details can be found at: http://fixprotocol.org/documents/4489/fix-5.0_sp2_vol-7.pdf. 1.2. Supported Use-cases Nordea e-markets FIX server enables clients to Retrieve FX market prices; Execute FX Trades based on provided quotes; Each use-case requires a FIX connection, and therefore a typical client who implements both use-cases requires two FIX connections from their pricing engine and trading engine. These two different types of FIX connections are referred as Pricing FIX Connection and Trading FIX Connection in the rest of this document. Figure 1 shows this typical setup. Pricing Engine Pricing FIX Connection Trading FIX Connection Trading Engine Client Nordea e-markets FIX Server Nordea Figure 1 FIX Connections Each FIX connection has its own SenderCompID, FIX session and sequence numbers so that they are physically independent on each other. However, they are logically interdependent because trading FIX connection creates trades based on quotes from pricing FIX connection. The two FIX connections can be made from the same IP address in case that the client has pricing/trading engine running on a centralized server, or they can be made from two different IP addresses. In both cases, both connections should be established against one endpoint provided by Nordea e-markets.

1.3. User Accounts Two different types of user accounts are required for a client to connect to Nordea e-markets FIX server. 1.3.1. Main User Account A main account is used by Nordea e-markets to identify the connecting counterparty. A FIX client should always embed username of the main user account in SenderCompID for all their FIX connections. Table 1 describes what SenderCompID to use for each FIX connection: FIX Connection Pricing FIX Connection Trading FIX Connection Main Account {MainAccountUserName} {MainAccountUserName} SenderCompID {MainAccountUserName}-P {MainAccountUserName}-T Table 1 SenderCompID for FIX Connections Nordea e-markets uses SenderCompID to identify a FIX connection from a certain client and it s the client s responsibility to make sure that correct SenderCompID is used for all messages in their FIX connections. 1.3.2. Business User Account A business account is an identity of a user or a company who wants to trade with Nordea e- Markets via FIX. A business account is created with proper user rights, and it is linked to a main account so that the main account can act on behalf of it. For single user platforms, the client only needs a main user account which can be used to logon to Nordea e-markets FIX server and execute trades. For multi-user platforms, the client should use the main account to logon on behalf of other business accounts each representing a user in the client s platform. It is the client s responsibility to check the identity of a user before logon on behalf of that business user account.

2. Product Offering This section describes scenarios and FX products that are supported by Nordea e-markets FIX server. 2.1. Trading Scenarios FX quotes are available in two different scenarios by client sending two types of requests (QuoteRequest and MarketDataRequest) to the Nordea e-markets FIX server: Request for Quote (RFQ) and Request for Stream (RFS). An RFQ returns a series of quotes at a set interval for a predetermined amount of time, with each quote replacing the previous one. Nordea e-markets will stop sending quotes at the end of the predetermined period or when the client deals on a quote. An RFS initiates a stream of continuous quotes sent to the client that will continue to be sent even if the client deals on a quote. From the client s perspective, each new quote replaces the previous one. Nordea e-markets only send incremental updates so that the client has the responsibility to cache the full snapshot from the subscribed price stream. The RFS is usually terminated when receiving an unsubscribe message from the client. In both scenarios the client can send in an order with a reference to the quote on which they want to trade and Nordea e-markets reserves the rights of last refusal. If Nordea e- Markets accept the request to deal, whether on an RFQ or RFS quote, it is executed by the backend trading system and results in an executed transaction. Otherwise the order is rejected (see appendix B for more details). The difference between the two trading scenarios is the connection setup: The RFQ scenario only requires trading FIX connection, and quotes are received via the same connection trades are executed. The RFS scenario requires both pricing FIX connection and trading FIX connection. Quotes are sent via pricing FIX connection while trades are executed via trading FIX connection. 2.2. Supported Products Nordea e-markets FIX server supports different types of FX products which are listed below: FX Spot; FX Forward/Outright; FX Swap; FX Uneven Swap; FX Forward-Forward; FX Multi/Block Trades; All the above mentioned products are supported in the RFQ scenario, and FX Spot and FX Forward/Outright are supported in the RFS scenario. Please be aware that Nordea e-markets FIX server uses legs repeating groups in QuoteRequest, Quote and ExecutionReport messages to express multi-leg products (swap trades and block trades) in RFQ scenario. Please refer to the message reference document for details.

3. Message Flows Due to the nature of FIX protocol, every FIX message is handled within a certain context. We refer those contexts as sessions in this document. By design, Nordea e-markets FIX server handles messages in the following session contexts: FIX Session: A FIX session represents a client connection. It is created immediately after a client is connected to and successfully logged to Nordea e-markets FIX server. Nordea e-markets verify identity of the client to make sure only authorized counterparty can create a FIX session. A FIX session is terminated once the client logoff and closes the connection. Normally a FIX session is created and terminated once a day. User Session: Once a FIX session is created, the client can create multiple user sessions each encapsulating activities from a single user. A user session is created when a user login to e-markets backend system and terminated when the user logoff. The UserRequest message is used to create or terminate a user session. Trading Session: A trading session representing a trading activity performed by an end user and it is created once the user starts either RFQ or RFS scenario. A trading session lives inside a user session and it is dependent on the life cycle of a user session. There are three types of trading sessions a client can create for each user: RFQ Trading Session: RFQ trading session represents a RFQ trading scenario. It is started by receiving a QuoteRequest from the client and terminated when: The client cancels the RFQ session; The RFQ session times out; The client accepts the price and makes a deal. RFQ trading session can only be created via trading FIX connection. RFS Pricing Session: RFS pricing session represents the pricing part of a RFS trading scenario. It is created when the client subscribe to a certain price stream and terminated when the client unsubscribe from the price stream. RFS pricing session can only be created via pricing FIX connection. RFS Trading Session: RFS trading session logically depends on RFS pricing session and it is created when an order with a price that the client receives in a RFS pricing session is received. It is terminated either when Nordea e-markets fulfills the order or reject the order. RFS trading session can only be created via trading FIX connection. This section presents all FIX message flows that are supported by Nordea e-markets FIX server. Each flow described in the subsequent sections can be thought as a life cycle of a particular session described above. Examples of the message flows described in this chapter can be found in Appendix C. The complete FIX message reference is provided in separate document.

3.1. FIX Session Creation After connection has been established between the client and server, the client needs to identify itself to the server by sending a Logon-message with an identification of the caller: the sendercompid. No password is needed because this step only identifies the client endpoint. If the server recognizes the sendercompid, a FIX session is then created and maintained for the duration of the socket-connection or until a Logout-message is sent by client. Figure 2 on next page illustrates creation and termination of a FIX session. All session layer FIX messages such as Heatbeat, SequenceReset, ResendRequest and TestRequest are interpreted in context of FIX sessions, and in practice all session level FIX messages should be handled by FIX engines at client and server side. One and only one FIX session can be created for each FIX connection. Clients with multiple FIX connections need to create one FIX session in each connection, please refer to table 1 for what sendercompid is valid for each FIX connection. Client Server Figure 2 FIX Session 3.2. User Session Creation Once the FIX session is established and the client endpoint identified, the user must be authenticated by the server. For single user systems, this is accomplished by sending a UserRequest with main user account username and corresponding password as shown in table 2. Username Password OnBehalfOfID Main User Account ********* None Table 2 Single User Logon For multi-user platforms, the UserRequest should specify the multi-user platforms main user account in the username tag and this user's password in the password tag, and set the onbehalfofuser tag to be the username of the business user account as shown in table 3. Username Password OnBehalfOfID Main User Account ********* (for Username) Table 3 Logon-on-behalf-of Business User Account In logon-on-behalf-of setup, Nordea e-markets only checks if the main user account has the

right to logon on behalf of a certain business user account, and no password is required for the business user account. Therefore the FIX client being a multi-user system must validate the identity of the user who tries to logon to e-markets FIX server. User sessions live inside a FIX session, and if a FIX session terminates, all user sessions inside this FIX session are terminated as well. Figure 3 shows the creation and termination of a user session. A UserRequest FIX message supports both login and logout operations by using different values of the UserRequestType tag as figure 3 shows. A UserResponse message is made as a response to a UserRequest, and the client can use the included UserRequestID to match the original UserRequest. Once a user session is created, the user can create multiple trading sessions. The two different trading scenarios are supported inside a trading session, and they are described in the next two sections. Client Server Figure 3 User Session 3.3. RFQ Trading Session This use-case reflects the legacy trading principle. In all it's essence it resembles the historic phone-trading scenario, and is usually implemented where the client counterpart is human. It ensures that a client gets a certain time to react to a quote-update by only providing quoteupdates at certain intervals, usually at least a couple of seconds, and gives the client the ease of referring to a quote through a quote-id which the server has matched to the quote. The quote is guaranteed to be tradable for the duration of the quote-update, and usually also for the duration of the subsequent quote-update. Quotes are short-lived options that the user can trade on until they are replaced by another quote or the trade scenario ends. Figure 4 illustrates this scenario. As figure 4 shows, RFQ trading session is initiated by client sending a QuoteRequest with a unique QuoteReqID. If the QuoteRequest is accepted, it will be forwarded to Nordea e- Markets price engine, and subsequently quotes are sent out to the client. Nordea e-markets FIX server might reject a QuoteRequest in which case a QuoteRequestReject response is sent to the client. Nordea e-markets have the rights to withdraw a previous quote by sending a QuoteCancel message to the client. Once a quote is withdrawn, the client will not be able to trade on this quote. The RFQ trading session is terminated either by the client sending an

order based on the latest valid quote or a QuoteResponse with QuoteReqID to the server. When a new order is received, the FIX server first sends an acknowledgement (ExecutionReport with OrdStatus=0), and a confirmation or rejection (ExecutionReport with OrdStatus=2 or 8) once the order is handled by the execution system. Please be aware a RFQ trading session can only be created in a trading FIX connection/session. Client Server Figure 1 Request for Quote Please note that it is the clients responsibility to ensure that the ClOrdID is unique and only use once. Nordea e-markets will support a maximum of 50 trade s pr. minute.

3.4. RFS Pricing Session Request for streaming scenario has a different pricing distribution mechanism which is based on publish/subscribe model. A RFS session starts when a client subscribes to a price stream and ends when the client unsubscribes the price stream. In contrast to request for quote, new order doesn't end the trading session, so the client can ideally create multiple orders while keeping the RFS pricing session alive. RFS pricing session is designated to have a longer lifecycle, and it normally lasts several hours or even a whole day. Figure 5 shows the creation and termination of a RFS pricing session. The MarketDataRequest FIX message is used to subscribe and unsubscribe a price stream. Once the subscription is accepted, a MarketDataSnapshotFullRefresh message which contains all relevant quote entries is sent to the client. Whenever there is a quote update, the FIX server sends a MarketDataIncrementalRefresh to the client. A MarketDataIncrementalRefresh contains only quote entries that are updated. Each quote entry is either tradable or indicative (indicated by tag MDQuoteType) and contains a unique QuoteEntryID, and the client must use the ID which refers to a tradable quote entry in order to create an order. Client Server Figure 5 RFS Pricing Session Please note that a RFS pricing session can only be created in a pricing FIX connection, and orders should be executed via trading FIX connection.

3.5. RFS Trading Session RFS FIX client receives quotes via a pricing FIX connection and executes orders via a trading FIX connection. Figure 6 shows how an order is executed in the context of a RFS trading session. The order execution in RFS scenario is exactly the same as RFQ scenario with the following exceptions: Client can optionally specify a slippage on an order; Client can optionally specify a new amount which is different from what is specified in the corresponding MarketDataRequest; Client should set QuoteEntryID of the quote entry as QuoteID in NewOrderSingle. Client Server Figure 6 RFS Trading Session Please note that it is the clients responsibility to ensure that the ClOrdID is unique and only use once. Nordea e-markets will support a maximum of 50 trades pr. minute.

4. Client Implementation This section summarizes all issues that are relevant to FIX client development besides what are mentioned in the previous sections. 4.1. On-board Procedure The client on-boarding procedure can be described in the following phases: Request to Connect: The client requests a connection to Nordea e-markets FIX server. Nordea e-markets handles the request and creates a test account and make necessary network configurations for the client. Once ready, the connecting IP address/port number as well as a test account in e-markets DEMO envrioment is sent to the client. Connection Test: The connection test is carried out by both the client and Nordea e- Markets to make sure that network infrastructure is configured correctly and the FIX engine at client side has no compatibility issue with Nordea e-markets FIX server. Client Development: The client starts to develop the FIX client towards e-markets' DEMO environment. Nordea e-markets may assist the client during the development. Integration Test: The integration test is carried out together by client software engineer and e-markets software engineer to make sure that the FIX client is developed according to the requirements and all integration issues/problems should be concluded in this phase. Pre-prod test: The client receives connect endpoint IP address/port number and a user account to emarkest PROD environment. The client also receives a valid trusted certificate which can be used to establish SSL connection(s) to Nordea e-markets PROD environment. A final check is made in this phase before going live. Launch in prod: When everything works as expected, the FIX connection goes live. 4.2. Operation Hours Nordea e-markets FIX server is open for trading between 07:00 Auckland time Monday and 17:00 New York time Friday. Trading is closed between 17:00 and 17:30 New York time every weekday for date rolling. 4.3. FIX Demo Client FIX Demo client is java-swing application which uses Nordea's latest FIX specification and provides you with a user-friendly front-end to test your connectivity & set-up with nordea FIX Servers. Fix Demo client would help you to ensure: Your network connectivity with Nordea servers Check if your test/production account is set-up properly. Create / Send / Receive Sample FIX Messages. The FIX Demo client is available at: http://demo.streaming1.nordea.com/fixdemoclient/ 4.4. Technical Support Nordea e-markets offers full support for FIX clients, in case of any issue or question please contact the support by phone or email below: Hotline: +45 3333 6263 E-mail: e-markets@nordea.com The support hotline is open every weekday between 07:00 and 24:00 CET and between 18:00 and 24:00 CET on Sundays. The support email is monitored between 07:00 and 17:00 CET.

Appendix A: Supported Tenors FIX supports the use of tenors instead of having to specify a specific date for maturity. This is done by setting a tenor-name instead of an ISO-8601 date in the SettlDate field. The server acknowledges the following tenor-names: TODAY TOM SPOT 1D 1W 2W 3W 1M 2M 3M 4M 5M 6M 7M 8M 9M 10M 11M 12M 1Y 13M 14M 15M 18M 21M 22M 2Y 30M 3Y Table 4 Supported Tenors Appendix B: Order Rejection Reasons An order can be rejected for several reasons. Below is a list of common reasons for rejection. 1. Credit Breach The client is trying to trade an amount for which it has no credit-line. 2. Auto-quoting Limits The trading system has a limit to how large an amount can be automatically traded through Non negotiable execution. When the amount for a trade exceeds this limit, the trade will be rejected even if the client has sufficient credit. The only way to execute the trade is through RFQ-style execution. Autoquoting limits differ depending on currencies and other factors, and may change at any time. Current autoquoting limits are not disclosed to clients. 3. Holidays Trades can only settle on dates that are not bank-holidays in the countries of origin for both the base- and price-currencies. Furthermore, since many of the rates provided through the system are calculated from some of the major currencies, bank-holidays in the countries of origin for those currency-majors may also affect the result. The structure of these dependencies and the holiday-calendar in use is not disclosed to clients. The best way to avoid this type of rejection is to use tenor-names instead of dates for value-dates. 4. Stale Rates Rates can become stale due to market conditions, and in which case orders may be rejected in this period. 5. Speed Bumps If the client is trying to execute trades too rapidly, a subsequent trade may be rejected because the time since the last successful trade is too low. The gap-time in use is not disclosed to clients and can change at any time. 6. Opening Hours and Temporary Suspension of Trading When the backend trading system is closed, either because the trading time is outside opening hours or because trading is temporarily closed, all trades will be rejected. 7. Cut-off Times When trading, the system may reject a trade because the time of the day is after the time

when the bank is able to handle a given currency. 8. Price Moved If a trade is requested with a rate which is significantly offset from market-rate in the clients favour, the system will reject the trade. 9. Permissioning A user may not have the right to trade a specific currency in which case the trade will be rejected. 10. General Error If a network error or software error on the banks side should occur during execution the trade will most likely be rejected,

Appendix C: Message Examples This appendix includes examples of messages to and from the FIX client and server. Tags such as <length>, <msg_num>, <time> and <sum> denote the relevant message length, message number, timestamp and check sum as specified by the FIX standard. For a full description of all field definitions, please refer to the complete FIX message reference provided in a separate document. 1. FIX session creation Below are examples of message Message from client to create FIX session: 8=FIXT.1.1 9=<length> 35=A 34=<msg_num> 49=FIX_TEST_USER 52=<time> 56=NORDEA 98=0 108=30 553=TEST_USER 1137=9 10=<sum> Response from server to acknowledge the newly created session: 8=FIXT.1.1 9=<length> 35=A 34=<msg_num> 49=NORDEA 52=<time> 56=FIX_TEST_USER 98=0 108=30 1137=9 10=<sum> The FIX Session is now ready to use. Before the connection is terminated the session should be terminated by sending a logout message: 8=FIXT.1.1 9=<length> 35=5 34=<msg_num> 49=FIX_TEST_USER 52=<time> 56=NORDEA 10=<sum> The logout is acknowledged and the FIX session is terminated: 8=FIXT.1.1 9=<length> 35=5 34=<msg_num> 49=NORDEA 52=<time> 56=FIX_TEST_USER 10=<sum> 2. User session creation Once a FIX session is created as above a user session needs to be created by providing a password: 8=FIXT.1.1 9=<length> 35=BE 34=<msg_num> 49=FIX_TEST_USER 52=<time> 56=NORDEA 553=TEST_USER 554=password 923=request_id1 924=1 10=<sum> The FIX server will then acknowledge the new user session. Notice how the request and response are matched via the value of field 923: 8=FIXT.1.1 9=<length> 35=BF 34=<msg_num> 49=NORDEA 52=<time> 56=FIX_TEST_USER 553=TEST_USER 923=request_id1 926=1 10=<sum> The field 926=1 means the user session is now ready to use. The request might also fail, for instance with a response like: 8=FIXT.1.1 9=<length> 35=BF 34=<msg_num> 49=NORDEA 52=<time> 56=FIX_TEST_USER 553=TEST_USER 923=request_id1 926=2 927=Account not found 10=<sum> 3. RFS market data session Suppose a valid FIX session and a valid user session has been established like in the previous sections, we will now try to create a market data session. 8=FIXT.1.1 9=<length> 35=V 34=<msg_num> 49=FIX_TEST_USER 52=<time> 56=NORDEA 262=MDSession1 263=1 267=2 269=0 269=1 553=TEST_USER 146=1 55=NOK/SEK 29998=TEST_BU 15=NOK 64=1D 38=1000000 10=<sum>

If the market data request was rejected for any reason the response would be for instance: 8=FIXT.1.1 9=<sum> 35=Y 34=<msg_num> 49=NORDEA 52=<time> 56=FIX_TEST_USER 58=Not authenticated! 262=coswpe3rub 281=3 10=<sum> If the market data request is successful a full snapshot is returned with the price: 8=FIXT.1.1 9=<length> 35=W 34=<msg_num> 49=NORDEA 52=<time> 56=FIX_TEST_USER 262=MDSession1 268=2 269=0 278=quote1bid 270=1.137657 271=3000000 278=quote1bid 299=quote1bid 1070=0 1026=1.13769 1027=-0.000033 269=1 278=quote1ask 270=1.138228 271=3000000 278=quote1ask 299=quote1ask 1070=1 1026=1.13825 1027=-0.000022 10=<sum> The quote is identified by for instance quote1bid in case the client wish to trade on it. Once the market data session is successful, updates will continuously be sent out of the fix server: 8=FIXT.1.1 9=<length> 35=X 34=<msg_num> 49=NORDEA 52=<time> 56=FIX_TEST_USER 262=MDSession1 268=2 279=1 269=0 270=1.24315 271=3000000 278=quote2bid 280=quote1bid 299=quote2bid 1026=1.13771 1027=-0.000033 1070=1 279=1 269=1 270=1.24349 271=3000000 278=quote2ask 280=quote1ask 299=quote2ask 1026=1.13827 1027=-0.000022 1070=1 10=<sum> Notice how the quote that the update replaces is identified by field 280. 4. RFS trading session Suppose you have set up a market data session like described in the previous section and have received a price (quote_id1) on EURSEK that you wish to trade on, the message to execute is for instance: 8=FIXT.1.1 9=<length> 35=D 34=<msg_num> 49=FIX_TEST_USER 52=<time> 56=NORDEA 1128=9 11=trade_id1 38=1000000 40=E 54=1 117=quote1ask 553=TEST_USER 6950=0.000078 10=<sum> Field 6950 with value 0.000078 means that the client is willing to accept a slight price increase to ensure the order is executed, and field 54 indicates which side the client wish to trade on. Field 11 is a unique trade id chosen by the client. The FIX server will immediately acknowledge the order for trade_id1 is received: 8=FIXT.1.1 9=<length> 35=8 34=<msg_num> 49=NORDEA 52=<time> 56=FIX_TEST_USER 11=trade_id1 39=0 40=E 10=<sum> The status zero (39=0) means that the order is received, but pending execution. Once correctly executed the FIX server will send a final execution report: 8=FIXT.1.1 9=<length> 35=8 34=<msg_num> 49=NORDEA 52=<time> 56=FIX_TEST_USER 11=trade_id1 15=NOK 37=4782432 39=2 40=E 54=1 55=NOK/SEK 194=1.13769 60=20101216-14:22:44 555=1 29998= TEST_BU 687=1000000.00 588=20101108 637=1.138228 675=SEK 1073=-0.000022 1074=1138228.00 10=<sum> The execution report also contains details about the trade at the rate that was executed on. If for any reason the order is rejected a execution report with status 8 is returned: 8=FIXT.1.1 9=<length> 35=8 34=<msg_num> 49=NORDEA 52=<time> 56=FIX_TEST_USER 11=trade_id1 39=8 40=E 58=Quote denied! 103=99 10=<sum> 5. RFQ session First we will look at a successful subscription and trade in the RFQ scenario. Let s assume we want sell EUR/USD for the worth of 1.000.000 EUR. In order to subscribe to this quote we send this to the FIX server: 8=FIXT.1.1 9=<length> 35=R 34=<msg_num> 49=FIX_TEST_USER 52=<time> 56=NORDEA 55 3=TESTUSER 131=<QuoteReqID> 146=1 55=EUR/USD 15=EUR 29998=TESTBU 555=1 687=1000

000 624=2 588=SPOT 10=084 Please note that the client must ensure that the QuoteReqID is unique. Then the FIX server will respond with a series of quotes, each deprecating the previous one: 8=FIXT.1.1 9=213 35=S 49=FIX_TEST_USER 56=NORDEA 34=<msg_num> 52=<time> 131=<Qu otereqid> 117=<QuoteID> 62=<ValidUntilTime> 188=1.42114 190=1.42157 555=1 681=1.42114 684=1.42157 1067=0 1068=0 10=093 The quote we get back is valid for 3 seconds this is the timespan where the client can accept the quote. If the client wishes to accept the quote he sends: 8=FIXT.1.1 9=147 35=D 34=4 49=FIX_TEST_USER 52=<time> 56=NORDEA 553=TESTUSER 11 =<QuoteReqID> 117=<QuoteID> 40=D 54=2 10=226 And in response the client gets two execution reports back: 8=FIXT.1.1 9=96 35=8 49=FIX_TEST_USER 56=NORDEA 34=4 52=<time> 11=<QuoteReqID> 39=0 40=D 10=041 Which acknowledge that the order has been received and: 8=FIXT.1.1 9=261 35=8 49=FIX_TEST_USER 56=NORDEA 34=5 52=<time> 37=2203369 11=< QuoteReqID> 39=2 55=EUR/USD 40=D 15=EUR 194=1.42114 54=2 60=<TransactTime> 555= 1 29998=TESTBU DK103A 687=1000000.00 588=<LegSettlDate> 637=1.42114 675=USD 107 3=0 1074=1421140.00 10=098 When the order is completed. Disclaimer FIX and FIX Protocol are trademarks of FIX Protocol Limited.