Page History
...
- HeartBtInt
- SessionType = RFS
- Username/Password - correct
- VenueName = ?/?
Session Synchronisation
Client Logon next-expected = MF actual
Client receives TestRequest, correctly sends Heartbeat response.
Client Logon next-expected < MF actual
Client correctly handles resent messages and/or SequenceReset(GapFill) messages.
Client receives TestRequest, correctly sends Heartbeat response.
Client Logon next-expected > MF actual
Client expects disconnect.
MF LogonResponse next-expected = Client actual
Client correctly sends TestRequest and waits for Heartbeat response (this is synchronisation complete).
MF LogonResponse next-expected < Client actual
The Client correctly resends persisted stateful messages.
The Client correctly uses SequenceReset(GapFill) messages to skip over blocks of non-persisted messages. Refer to Client Session Management -MessagePersistence for details.
MF LogonResponse next-expected > Client actual
The Client correctly disconnects.
Logoff
All client sessions must be terminated gracefully in normal circumstances.
Client-Initiated Logoff
The Client may only issue Logoff when no Venue session is active.
The Client waits for the reciprocal LogoffResponse message from MF.
MF-Initiated (e.g. on weekend restart)
The Client responds to MF-issued Logoff message with a reciprocal LogoffResponse.
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 a TestRequest.
In the event that no Heartbeat response to the Client TestRequest has been received from MF after a further HeartBtInt, the Client correctly timesout and sends a Logout.
In the event that no LogoutResponse to the Client Logout has been received from MF after a further HeartBtInt, the Client correctly timesout and disconnects.
TestRequest Handling
The Client sends a Heartbeat message with the correct TestReqID in response to every MF TestRequest message received.
Venue Connectivity
The sequencing matters.
UserRequest (LogOnUser)
Client instructs MF to connect to Venue.
Message should only be sent when the client is not currently logged on.
ErrorReport
Client receives MF notification of any problems and takes the appropriate action.
| Warning | ||
|---|---|---|
| ||
It is not acceptable to simply ignore these messages. Refer to ErrorReport Handling for context. Individual Scenarios that need to be verified:
|
UserNotification (LoggedOn)
Client is notified when Venue connectivity is established.
UserRequest (LogOffUser)
Client instructs MF to disconnect from Venue.
This message may be sent when:
- MF is in a connection-attempt cycle, after a prior UserRequest (LogOnUser)
- 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
Pricing
QuoteRequest
The 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, NDB
- 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
The Client must ensure that they handle all RFS termination modes.
Outbound Client > Venue
Quote Request Rejection
The Client should be able to specify different rejection reasons in the QuoteRequestRejectReason field, e.g. Credit check failure vs unsupported pair.
The Client should be able to specify additional detail in the Text field , e.g. "Order breaches daily settlement limit by 2m."
Quote Request Timeout
The Client should terminate RFSs after a period of time (e.g. 3-5m). The Client timeout may, or may not, match the Venue setting, or the counterparty-specified duration.
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.
The Client must demonstrate correct usage of the following attributes:
- QuoteIDs - Uniqueness is verified. The following characters are not allowed: ¬~`_!*,-:=[]/#<>
- QuoteType - various combinations of Indicative/Tradeable for Bid and/or Offer.
- ValidUntilTime - the Client should confirm whether this is part of their pricing workflow, or not.
- 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
| Tip | ||
|---|---|---|
| ||
If the Client wishes to trade on-MTF or on-SEF, it is essential that the venue has applied the necessary regulatory setup and configuration changes to support this. This is often a problematic process so the Client is advised to declare this as early as possible during the onboarding process. |
QuoteCancel
The Client can explicitly withdraw a previously issued Quote.
Trading
NewOrderMultileg
The Client must be able to receive orders for all the permutations and combinations of QuoteRequest above.
ExecutionReport
The Client must be able to demonstrate 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
The Client should be able to specify different rejection reasons in the QuoteRequestRejectReason field, e.g. Credit check failure vs stale quote.
The Client should be able to specify additional detail in the Text field , e.g. "Order breaches daily settlement limit by 2m."
ExecutionAcknowledgement
Client must be able to receive acknowledgements of all fills, and possibly rejections, for all the permutations and combinations of QuoteRequest above.
| Warning | ||
|---|---|---|
| ||
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:
|
ESP Workflow
Pricing
QuoteRequest
The Client is able to receive and correctly identify all flavours of ESP requests, i.e. permutations and combinations of the following:
- SecurityType: SPT, FWD, NDF
- SecurityGroup: The Venue may deliver requests for multiple price streams per instrument, as bilaterally agreed with Client.
- Side: Buy/Sell/Two-Way
- Dealt Currency: Base/Term ccy qtys
- Regulatory framework: OFF/SEF/MTF
QuoteResponse
The Client must ensure that they handle all ESP termination modes.
Outbound Client > Venue
Quote Request Rejection
The Client should be able to specify different rejection reasons in the QuoteRequestRejectReason field, e.g. unsupported pair.
The Client should be able to specify additional detail in the Text field , e.g. "Instrument not supported".
Inbound Venue > Client
The Client must be able to handle Venue-termination of active ESP subscriptions - typically due to day roll events.
MassQuote
MassQuote messages must be generated for all the permutations and combinations of QuoteRequest above.
The Client must demonstrate correct usage of the following attributes:
- QuoteID and QuoteEntryIDs - Uniqueness is verified. The following characters are not allowed: ¬~`_!*,-:=[]/#<>
- NoQuoteEntries - Dynamic variation in the number of rungs, and published sides for each rung vs the request.
- QuoteType - various combinations of Indicative/Tradeable for Bid and/or Offer.
- ValidUntilTime - the Client should confirm whether this is part of their pricing workflow, or not.
- 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
| Tip | ||
|---|---|---|
| ||
If the Client wishes to trade on-MTF or on-SEF, it is essential that the venue has applied the necessary regulatory setup and configuration changes to support this. This is often a problematic process so the Client is advised to declare this as early as possible during the onboarding process. |
QuoteCancel
The Client can explicitly withdraw a previously issued MassQuote.
Trading - Last-Look
NewOrderMultileg
The Client must be able to receive orders for all the permutations and combinations of QuoteRequest above.
ExecutionReport
The Client must be able to demonstrate 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
The Client should be able to specify different rejection reasons in the QuoteRequestRejectReason field, e.g. Credit check failure vs stale quote.
The Client should be able to specify additional detail in the Text field , e.g. "Order breaches daily settlement limit by 2m."
ExecutionAcknowledgement
Client must be able to receive acknowledgements of all fills, and possibly rejections, for all the permutations and combinations of QuoteRequest above.
Trading - No Last-Look
ExecutionReport
The Client must be able to demonstrate receipt of all fill notifications.
Taker
RFS Workflow
Pricing
QuoteRequest
The Client is able to submit all flavours of RFS requests, i.e. permutations and combinations of the following:
- SecurityType: SPT, FWD, NDF, SWP, NDS, BLK, NDB
- Allocations: Single and Multiple (including zero net allocs).
- Side: Buy/Sell/Two-Way
- Dealt Currency: Base/Term ccy qtys
- Regulatory framework: OFF/SEF/MTF
The the CLient does not wish to
QuoteResponse
The Client must ensure that they handle all RFS termination modes.
Outbound Client > Venue
There are nine possible scenarios as per the table below, all should be verified explicitly:
Client Logon msgSeqNum vs. Gateway-expected | Client Logon NextExpectedMsgSeqNum vs. Gateway-actual | Response | Comment |
|---|---|---|---|
| < | < | Gateway sends Logout to Client and disconnects. | Unrecoverable: Client-actual < Gateway-expected. Gateway to replay. |
| > | < | Gateway sends Logon response to Client. | Logged on to Gateway. Client to replay. Gateway to replay. |
| = | < | Gateway sends Logon response to Client. | Logged on to Gateway. Client synchronised. Gateway to replay. |
| < | > | Gateway sends Logout to Client and disconnects. | Unrecoverable: Client-actual < Gateway-expected. Client expected > Gateway-actual. |
| > | > | Gateway sends Logout to Client and disconnects. | Unrecoverable: Client to replay. Client expected > Gateway-actual. |
| = | > | Gateway sends Logout to Client and disconnects. | Unrecoverable: Client synchronised. Client expected > Gateway-actual. |
| < | = | Gateway sends Logout to Client and disconnects. | Unrecoverable: Client-actual < Gateway-expected. Gateway synchronised. |
| > | = | Gateway sends Logon response to Client. | Logged on to Gateway. Client to replay. Gateway synchronised. |
| = | = | Gateway sends Logon response to Client. | Logged on to Gateway. Client synchronised. Gateway synchronised. |
Gateway to Replay
Client correctly handles resent messages and/or SequenceReset(GapFill) messages.
Client receives TestRequest, correctly sends Heartbeat response.
Client to Replay
The Client correctly resends persisted stateful messages.
The Client correctly uses SequenceReset(GapFill) messages to skip over blocks of non-persisted messages. Refer to Client Session Management -MessagePersistence for details.
Client receives TestRequest, correctly sends Heartbeat response.
Unrecoverable
Client expects disconnect.
Synchronised
Client correctly responds to Gateway TestRequest with Heartbeat.
The Gateway always sends a final TestRequest to mark and check the overall session synchronisation status. The Client correctly sends Heartbeat response.
Thus a minimum of one TestRequest/Hearbeat exchange is initiated by the Gateway, and a maximum of three.
Logoff
All client sessions must be terminated gracefully in normal circumstances.
Client-Initiated Logoff
The Client may only issue Logoff when no Venue session is active.
The Client waits for the reciprocal LogoffResponse message from MF.
MF-Initiated (e.g. on weekend restart)
The Client responds to MF-issued Logoff message with a reciprocal LogoffResponse.
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 a TestRequest.
In the event that no Heartbeat response to the Client TestRequest has been received from MF after a further HeartBtInt, the Client correctly timesout and sends a Logout.
In the event that no LogoutResponse to the Client Logout has been received from MF after a further HeartBtInt, the Client correctly timesout and disconnects.
TestRequest Handling
The Client sends a Heartbeat message with the correct TestReqID in response to every MF TestRequest message received.
Venue Connectivity
The sequencing matters.
UserRequest (LogOnUser)
Client instructs MF to connect to Venue.
Message should only be sent when the client is not currently logged on.
ErrorReport
Client receives MF notification of any problems and takes the appropriate action.
| Warning | ||
|---|---|---|
| ||
It is not acceptable to simply ignore these messages. Refer to Error Handling for context. Individual Scenarios that need to be verified:
|
UserNotification (LoggedOn)
Client is notified when Venue connectivity is established.
UserRequest (LogOffUser)
Client instructs MF to disconnect from Venue.
This message may be sent when:
- MF is in a connection-attempt cycle, after a prior UserRequest (LogOnUser)
- 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
Pricing
QuoteRequest
The 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, NDB
- 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
The Client must ensure that they handle all RFS termination modes.
Outbound Client > Venue
Quote Request Rejection
The Client should be able to specify different rejection reasons in the QuoteRequestRejectReason field, e.g. Credit check failure vs unsupported pair.
The Client should be able to specify additional detail in the Text field , e.g. "Order breaches daily settlement limit by 2m."
Quote Request Timeout
The Client should terminate RFSs after a period of time (e.g. 3-5m). The Client timeout may, or may not, match the Venue setting, or the counterparty-specified duration.
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.
The Client must demonstrate correct usage of the following attributes:
- QuoteIDs - Uniqueness is verified. The following characters are not allowed: ¬~`_!*,-:=[]/#<>
- QuoteType - various combinations of Indicative/Tradeable for Bid and/or Offer.
- ValidUntilTime - the Client should confirm whether this is part of their pricing workflow, or not.
- Price precision - very important for Fwds. Refer to Datatypes.
- 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
| Tip | ||
|---|---|---|
| ||
If the Client wishes to trade on-MTF or on-SEF, it is essential that the venue has applied the necessary regulatory setup and configuration changes to support this. This is often a problematic process so the Client is advised to declare this as early as possible during the onboarding process. |
QuoteCancel
The Client can explicitly withdraw a previously issued Quote.
Trading
NewOrderMultileg
The Client must be able to receive orders for all the permutations and combinations of QuoteRequest above.
ExecutionReport
The Client must be able to demonstrate 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
The Client should be able to specify different rejection reasons in the QuoteRequestRejectReason field, e.g. Credit check failure vs stale quote.
The Client should be able to specify additional detail in the Text field , e.g. "Order breaches daily settlement limit by 2m."
ExecutionAcknowledgement
Client must be able to receive acknowledgements of all fills, and possibly rejections, for all the permutations and combinations of QuoteRequest above.
| Warning | ||
|---|---|---|
| ||
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:
|
ESP Workflow
Pricing
QuoteRequest
The Client is able to receive and correctly identify all flavours of ESP requests, i.e. permutations and combinations of the following:
- SecurityType: SPT, FWD, NDF
- SecurityGroup: The Venue may deliver requests for multiple price streams per instrument, as bilaterally agreed with Client.
- Side: Buy/Sell/Two-Way
- Dealt Currency: Base/Term ccy qtys
- Regulatory framework: OFF/SEF/MTF
QuoteResponse
The Client must ensure that they handle all ESP termination modes.
Outbound Client > Venue
Quote Request Rejection
The Client should be able to specify different rejection reasons in the QuoteRequestRejectReason field, e.g. unsupported pair.
The Client should be able to specify additional detail in the Text field , e.g. "Instrument not supported".
Inbound Venue > Client
The Client must be able to handle Venue-termination of active ESP subscriptions - typically due to day roll events.
MassQuote
MassQuote messages must be generated for all the permutations and combinations of QuoteRequest above.
The Client must demonstrate correct usage of the following attributes:
- QuoteID and QuoteEntryIDs - Uniqueness is verified. The following characters are not allowed: ¬~`_!*,-:=[]/#<>
- NoQuoteEntries - Dynamic variation in the number of rungs, and published sides for each rung vs the request.
- QuoteType - various combinations of Indicative/Tradeable for Bid and/or Offer.
- ValidUntilTime - the Client should confirm whether this is part of their pricing workflow, or not.
- Price precision - very important for Fwds. Refer to Datatypes.
- 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
| Tip | ||
|---|---|---|
| ||
If the Client wishes to trade on-MTF or on-SEF, it is essential that the venue has applied the necessary regulatory setup and configuration changes to support this. This is often a problematic process so the Client is advised to declare this as early as possible during the onboarding process. |
QuoteCancel
The Client can explicitly withdraw a previously issued MassQuote.
Trading - Last-Look
NewOrderMultileg
The Client must be able to receive orders for all the permutations and combinations of QuoteRequest above.
ExecutionReport
The Client must be able to demonstrate 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
The Client should be able to specify different rejection reasons in the QuoteRequestRejectReason field, e.g. Credit check failure vs unsupported pairstale quote.
The Client should be able to specify additional detail in the Text field , e.g. "Order breaches daily settlement limit by 2m."
Quote Request Timeout
ExecutionAcknowledgement
...
Client must be able to receive acknowledgements of all fills, and possibly rejections, for all the permutations and combinations of QuoteRequest above.
Trading - No Last-Look
ExecutionReport
The
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.
The Client must demonstrate correct usage of the following attributes:
- QuoteIDs - Uniqueness is verified. The following characters are not allowed: ¬~`_!*,-:=[]/#<>
- QuoteType - various combinations of Indicative/Tradeable for Bid and/or Offer.
- ValidUntilTime - the Client should confirm whether this is part of their pricing workflow, or not.
- 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
| Tip | ||
|---|---|---|
| ||
If the Client wishes to trade on-MTF or on-SEF, it is essential that the venue has applied the necessary regulatory setup and configuration changes to support this. This is often a problematic process so the Client is advised to declare this as early as possible during the onboarding process. |
QuoteCancel
The Client can explicitly withdraw a previously issued Quote.
Trading
NewOrderMultileg
The Client must be able to receive orders for all the permutations and combinations of QuoteRequest above.
ExecutionReport
The Client must be able to demonstrate both deal acceptance and deal rejection.
...
demonstrate receipt of all fill notifications.
Taker
RFS Workflow
Pricing
QuoteRequest
The Client is able to submit all flavours of RFS requests, i.e. permutations and combinations of the following:
- SecurityType: SPT, FWD, NDF, SWP, NDS, BLK, NDB
- Allocations: Single and Multiple (including zero net allocs).
- Side: Buy/Sell/Two-Way
- Dealt Currency: Base/Term ccy qtys
- Regulatory framework: OFF/SEF/MTF
The the CLient does not wish to
QuoteResponse
The Client must ensure that they handle all RFS termination modes.
Outbound Client > Venue
Quote Request Rejection
The Client should be able to specify different rejection reasons in the QuoteRequestRejectReason field, e.g. Credit check failure vs unsupported pair.
The Client should be able to specify additional detail in the Text field , e.g. "Order breaches daily settlement limit by 2m."
Quote Request Timeout
The Client should terminate RFSs after a period of time (e.g. 3-5m). The Client timeout may, or may not, match the Venue setting, or the counterparty-specified duration.
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.
The Client must demonstrate correct usage of the following attributes:
- QuoteIDs - Uniqueness is verified. The following characters are not allowed: ¬~`_!*,-:=[]/#<>
- QuoteType - various combinations of Indicative/Tradeable for Bid and/or Offer.
- ValidUntilTime - the Client should confirm whether this is part of their pricing workflow, or not.
- Price precision - very important for Fwds. Refer to Datatypes.
- 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
The Client should be able to specify different rejection reasons in the QuoteRequestRejectReason field, e.g. Credit check failure vs stale quote.
The Client should be able to specify additional detail in the Text field , e.g. "Order breaches daily settlement limit by 2m."
ExecutionAcknowledgement
- - EDM/IDM - missing, wrong, correct - Client must observe and understand the Venue behaviour for each scenario. Refer to Regulatory Fields FAQ.
- SEF
- OFF
| Tip | ||
|---|---|---|
| ||
If the Client wishes to trade on-MTF or on-SEF, it is essential that the venue has applied the necessary regulatory setup and configuration changes to support this. This is often a problematic process so the Client is advised to declare this as early as possible during the onboarding process. |
QuoteCancel
The Client can explicitly withdraw a previously issued Quote.
Trading
NewOrderMultileg
The Client must be able to receive orders Client must be able to receive acknowledgements of all fills, and possibly rejections, for all the permutations and combinations of QuoteRequest above.
| Warning | ||
|---|---|---|
| ||
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:
|
ESP Workflow
TODO
CLOB
Market Data
ExecutionReport
The Client must be able to demonstrate 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
The Client should be able to specify different rejection reasons in the QuoteRequestRejectReason field, e.g. Credit check failure vs stale quote.
The Client should be able to specify additional detail in the Text field , e.g. "Order breaches daily settlement limit by 2m."
ExecutionAcknowledgement
Client must be able to receive acknowledgements of all fills, and possibly rejections, for all the permutations and combinations of QuoteRequest above.
| Warning | ||
|---|---|---|
| ||
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:
|
ESP Workflow
TODO
CLOB
Market Data
The client must be able to demonstrate correct market data processing by provision of their view of a book, after a sequence of MarketDataIncrementalRefresh messages defining:
- A sequence of New, Change and Delete actions for individual MDEntries.
- Provision of a Snapshot.
OrderDepth and PriceDepth books must both be correctly processed by the client.
The Client must correctly handle implicit deletes for entries that drop out of the client's subscribed MDBookDepth.TODO
Orders
TODO
Venue-Specific Certification
...
Overview
Content Tools