This page provides high-level notes outlining the scenarios that the Client must handle correctly when integrating with Whisperer. The MarketFactory Support team will ensure that all applicable scenarios are exercised and passed satisfactorily before moving forward to Production and go-live.
The focus of these tests is to ensure that the Client/Whisperer interface is implemented and works correctly.
These tests do not short-circuit the need for the Client and Venue to do further tests in order to verify that their specific needs and requirements are met.
Client Session Handling
Verify that all Client Timestamps are expressed as UTC in all messages
- 52/SendingTime
- 122/OrigSendingTime (resends only)
- 60/TransactTime (Quote, MassQuote, ExecutionReport)
Logon
Client Logon message contains the correct values for:
- HeartBtInt
- SessionType = RFS
- Username/Password - correct
- VenueName = ?/?
Session Synchronisation
Client Logon next-expected = MF actual
Receive TestRequest, correctly send Heartbeat response.
Client Logon next-expected < MF actual
Correctly handles resent messages and/or SequenceResetGapFill messages.
Receive TestRequest, correctly send Heartbeat response.
Client Logon next-expected > MF actual
Expect disconnect.
MF LogonResponse next-expected = Client actual
Correctly sends TestRequest, wait for response (this is synchronisation complete).
MF LogonResponse next-expected < Client actual
Correctly resends messages and/or SequenceResetGapFill messages.
MF LogonResponse next-expected > Client actual
Correctly disconnects.
Logoff
All client sessions must be terminated gracefully in normal circumstances.
Client-Initiated Logoff
Client may only issue Logoff when no Venue session is active.
Client waits for reciprocal Logoff message from MF.
MF-Initiated (e.g. on weekend restart)
Client responds to MF-issued Logoff message with reciprocal Logoff.
Dropped Socket Connection
Test force disconnect & automatic reconnect of session
Session Monitoring
Client Heartbeats
In the absence of sending other messages, the Client publishes Heartbeat messages at their specified interval (Logon HeartBtInt)
Client Monitoring of MF Messaging
In the event that no message has been received from MF after the HeartBtInt, the Client
- Correctly timesout and sends TestRequest.
- Correctly timesout and sends Logout.
- Correctly timesout and disconnects.
TestRequest Handling
The Client sends a Heartbeat message in response to every MF TestRequest message received.
Venue Connectivity
The sequencing matters.
UserRequest (LogOnUser)
Client directs MF to connect to Venue.
Message only sent when the client is not currently logged on.
ErrorReport
Client receives MF notification of any problems and takes the appropriate action.
Explicit verification required
It is not acceptable to simply ignore these messages.
Refer to ErrorReport Handling for context.
Individual Scenarios that need to be verified:
- Session Level - Informational notification by Whisperer of issues encountered during a UserRequest Logon cycle, and the planned next action.
- Application Level - Notification of problems identified by Whisperer relating to the client message construction. This implies that there may will be a problem with the current business/trading state, and the Client must take decisive action to correct this.
UserNotification (LoggedOn)
Client is notified when Venue connectivity is established.
UserRequest (LogOffUser)
Client directs MF to disconnect from Venue.
Message may be sent:
- When MF is in a connection-attempt cycle, after a prior UserRequest (LogOnUser)
- When client has been notified that they have been logged on via UserNotification (LoggedOn).
UserNotification (LoggedOff)
Client is notified when Venue connectivity is terminated.
Maker
Maker certification should focus primarily on outbound (Client > MF) message correctness.
RFS Workflow
QuoteRequest
Client is able to receive and correctly identify all flavours of RFS requests, i.e. permutations and combinations of the following:
- SecurityType: SPT, FWD, NDF, SWP, NDS, BLK (FXall), NDB (FXall)
- Allocations: Single and Multiple (including zero net allocs).
- Side: Buy/Sell/Two-Way
- Dealt Currency: Base/Term ccy qtys
- Regulatory framework: OFF/SEF/MTF
QuoteResponse
Ensure Client handles all RFS termination modes.
Outbound Client > Venue
Quote Request Rejection
Client should be able to send different rejection reasons, e.g. Credit check failure vs unsupported pair.
Client must be aware of availability of Custom error codes for:
- FXall QuickTrade
- Currenex RFS (TODO: Create page on TheSauce).
Quote Request Timeout
Client should terminate RFSs after a period of time (e.g. 3-5m). The Client timeout may, or may not, match the Venue setting.
Inbound Venue > Client
Client must be able to handle Venue-termination of active RFS - either due to the Venue stream timeout, or because the counterparty dealt away, or because the counterparty canceled the request.
Quote
Quote messages must be generated for all the permutations and combinations of QuoteRequest above.
Checks must be made against the following attributes:
- QuoteIDs - Uniqueness is verified. The following characters are not allowed: ¬~`_!*,-:=[]/#<>
- QuoteType - various combinations of Indicative/Tradeable for Bid and/or Offer.
- Price precision - very important for Fwds. Refer to Prices and Quantities.
- Regulatory - All regulatory regimes must be explicitly declared as in or out of scope. In scope regimes must be demonstrated to populate the required reg. fields correctly:
- MTF - EDM/IDM - missing, wrong, correct - Client must observe and understand the Venue behaviour for each scenario. Refer to Regulatory Fields FAQ.
- SEF
- OFF
QuoteCancel
The Client can explicitly withdraw a previously issued Quote.
NewOrderMultileg
Client must be able to receive orders for all the permutations and combinations of QuoteRequest above.
ExecutionReport
Ensure that Client handles both deal acceptance and deal rejection.
Deal Acceptance
Regulatory - All regulatory regimes must be explicitly declared as in or out of scope. In scope regimes must be demonstrated to populate the required reg. fields correctly:
- MTF
- SEF
- OFF
Deal Rejection
Client should be able to send different rejection reasons, e.g. Credit check failure vs stale quote.
Client must be aware of availability of Custom error codes for:
- FXall QuickTrade
- Currenex RFS (TODO: Create page on TheSauce).
ExecutionAcknowledgement
Client must be able to receive acknowledgements of all fills, and possibly rejections, for all the permutations and combinations of QuoteRequest above.
Bloomberg
In the case that the Client send Bloomberg an ExecutionReport with erroneous regulatory field values (e.g. EDM/IDM values etc), Bloomberg will drop this message silently. No ExecutionAck will be sent.
It is the Client's responsibility to ensure that:
- The correct regulatory values are populated
- Appropriate mechanisms are in place to detect such 'lost fills', should they occur. A simple timer that is cleared on receipt of the ExecutionAck and raises an alert on expiry may suffice.
ESP Workflow
TODO
Taker
RFS Workflow
TODO
ESP Workflow
TODO
CLOB
Market Data
TODO
Orders
TODO
Venue-Specific Certification
Venue-specific scenarios should be exercised, to ensure that there are no surprises when Client/Venue conformance tests are performed:
Overview
Content Tools