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. |
Verify that all Client Timestamps are expressed as UTC in all messages
Client Logon message contains the correct values for:
Receive TestRequest, correctly send Heartbeat response.
Correctly handles resent messages and/or SequenceResetGapFill messages.
Receive TestRequest, correctly send Heartbeat response.
Expect disconnect.
Correctly sends TestRequest, wait for response (this is synchronisation complete).
Correctly resends messages and/or SequenceResetGapFill messages.
Correctly disconnects.
All client sessions must be terminated gracefully in normal circumstances.
Client may only issue Logoff when no Venue session is active.
Client waits for reciprocal Logoff message from MF.
Client responds to MF-issued Logoff message with reciprocal Logoff.
Test force disconnect & automatic reconnect of session
In the absence of sending other messages, the Client publishes Heartbeat messages at their specified interval (Logon HeartBtInt)
In the event that no message has been received from MF after the HeartBtInt, the Client
The Client sends a Heartbeat message in response to every MF TestRequest message received.
The sequencing matters.
Client directs MF to connect to Venue.
Message only sent when the client is not currently logged on.
Client receives MF notification of any problems and takes the correct planned action. It is not acceptable to ignore these. Refer to ErrorReport Handling for context.
Client is notified when Venue connectivity is established.
Client directs MF to disconnect from Venue.
Message may be sent:
Client is notified when Venue connectivity is terminated.
Maker certification should focus primarily on outbound (Client > MF) message correctness.
Client is able to receive and correctly identify all flavours of RFS requests, i.e. permutations and combinations of the following:
Ensure Client handles all RFS termination modes.
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:
Client should terminate RFSs after a period of time (e.g. 3-5m). The Client timeout may, or may not, match the Venue setting.
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 messages must be generated for all the permutations and combinations of QuoteRequest above.
Checks must be made against the following attributes:
The Client can explicitly withdraw a previously issued Quote.
Client must be able to receive orders for all the permutations and combinations of QuoteRequest above.
Ensure that Client handles both deal acceptance and deal rejection.
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:
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:
Client must be able to receive acknowledgements of all fills, and possibly rejections, for all the permutations and combinations of QuoteRequest above.
TODO
TODO
TODO
TODO
TODO
Venue-specific scenarios should be exercised, to ensure that there are no surprises when Client/Venue conformance tests are performed: