Understanding FIX support of Collateral Trading

, ,
1

Imported from previous forum

2

Hello,

I am looking to get an understanding of how collateral trading works using FIX, and which message types a client would send vs responder.

I am only interested in knowning about how the following can correlate:
Collateral Assignment (AY)
Collateral Request (AX)
Collateral Response (AZ)

Questions:

  1. What message type is used to send a collateral cancel or update from the client end? Collateral Response?

I would gladly appreciate the help.

Thanks,

Dwayne

3

Dwayne,
I prefer to view this less about “client” vs. “responder”, but as “party who has to post collateral” vs. “party who receives collateral”.

CollateralRequest is used by the “party who receives collateral” to request from “party who has to post collateral” that they need to post collateral

CollateralAssignment is used by the “party who has to post collateral” to specify or propose the collateral assets they are posting to meet requested collateral requirements

CollateralResponse is used by the “party who receives collateral” as a response msg to CollateralAssignment

If by “client” you mean “party who has to post collateral”, for the client to cancel or replace, take a look at the CollAsgnTransType field in the CollateralAssignment message.

Lisa

4

Hello Lisa,

Thanks for the information.

Client B/D Custodian

  1. CollateralRequest | >> | | |
  2.                       | << | CollateralAssignment       |   |

  3.                       |    | CollateralAssignment       |>> |

  4.                       |    |           		       |<< | CollateralResponse

Sample Flow Description:

  1. Client will send a CollateralRequest to post collateral in order to be able to trade.
  2. B/D trading the collateral position on behalf of the client will respond with a CollateralAssignment as an indication that it has received the request to be traded. Let’s say, CollAsgnTransType == NEW (903=0)
  3. In turn, the B/D also sends a CollateralAssignment message to post collateral to the party who receives collateral (e.g. custodian).
  4. The Custodian who receives the collateral, responds with a CollateralResponse indicating it has received the request. I assume that a CollAsgnRespType = RECEIVED, implies that the collateral request is being reviewed. And the Custodian will follow up with a CollAsgnRespType == ACCEPTED, DECLINE or REJECTED.

Questions:

  1. What is the difference between a CollAsgnRespType of “DECLINED” and “REJECTED”.
  2. What does a CollAsgnRespType == RELEASE and REVERSE imply? I assume “RELEASE” means that after settlement of the trade that the collateral is in relation to takes place.
  3. In the sample flow, how does the client cancel or amend a collateral request, if this is not possible using a CollateralRequest?

I gladly appreciate the help.

Thanks,

Dwayne

5

Hi Dwayne,

your sample flow does not seem to match with Lisa’s definitions. In general, your sample says who sends a message but not to whom it is sent, or? The lines prior to your sample flow may show that but then it does not display correctly, maybe due to the usage of special characters.

To use your terminology, a client wanting to post collateral (to be able to trade) would not send a CollateralRequest but a CollateralAssignment which identifies the collateral for posting. The B/D would use a CollateralResponse to acknowledge/reject the assignment. The B/D may send a CollateralRequest to the client if the client wants to trade but has not posted any collateral yet. Or you wanted to say that the client sends a request to the B/D asking him to post collateral. Then the CollateralRequest would apply. Can you please clarify the use case a little more?

The party posting collateral (e.g. client) may send multiple CollateralAssignment messages to cancel or amend previous assignments. Does that answer your third question?

I could not find CollAsgnRespType == RELEASE and REVERSE. Where did you find these values? Lisa may be able to find the FIX 4.4 document where declined vs rejected is defined. It does seem redundant due to the lack of any elaboration in FIXimate and we should try to clarify the semantics. Rejections may be related to technical aspects (e.g. syntax error) whereas a decline refers to the business process. Received is like a technical ACK indicating that the assignment will now be processed and followed up with a second message giving the final response.

Regards,
Hanno.

6

Hey Hanno,

Thanks for the information thus far. I guess the format I had did not save.

At a minimum, this is what I am trying to understand:

Client - party that wants to post collateral (e.g. client has to post collateral before they can trade).
B/D - party that is posting collateral on behalf of the client.
Custodian - party who receives collateral

  1. The client sends a request to the B/D asking him to post collateral. What message do I use?
  2. B/D receives the request, what message would they send?
  3. B/D sends or pass-through the request to the Custodian, what message should be sent?
  4. Custodian receives the collateral request, what message should be sent?

For #1, lets say the client wanted to update or cancel the original request.
For #4, lets say the Custodian wanted to send an unsolicited cancel.

7

Ok, that makes things a little clearer. The use case is that the client has to post collateral at the custodian and the B/D needs to know about it because he is the one that lets the client trade. That is a complex workflow if you want all 3 parties to be able to accept/reject and also change their mind later on. The basic flow should be as follows, Lisa may comment as well if I get something wrong.

The client always sends a CollateralAssignment, CollAsgnTransType conveys whether this is a new transaction (i.e. posting of collateral) or the amendment or cancellation of an existing transaction. The B/D can send a CollateralResponse to the client to let him know he received the transaction and will take care of it. He can then send a CollateralAssignment to the custodian on behalf of the client. I suggest to use the Parties block to indicate the entering party(= B/D) and the executing party (= client). The custodian will send a CollateralResponse back to the B/D, confirming or refusing the transaction. That allows the B/D to send a second CollateralResponse back to the client with the final status of the transaction. Any changes to the assignment should follow the same principle.

An unsolicited cancel from the custodian means that the B/D needs to be prepared to get another CollateralResponse refusing the collateral after getting a positive response earlier. The same needs to happen for the communication back to the client who then hasa to start a new transaction or the B/D will not let him continue to trade. That kind of workflow needs to be agreed between the 3 parties so that their applications can cope with unsolicited responses.

What is the business requirement for the custodian to be able to cancel a post after having accepted it?

8

Hey Hanno,

Thanks for the help thus far. In regards to your question, the custodian would not cancel a post after having accepted it. Rather, I think the application facing the Custodian, could send an unsolicited cancel in the event that it does not receive a response from the custodian at a certain time. For example, if collateral posted is for same day settlement but no response by the custodian, then I would think you would send a CollateralResponse with a CollAsgnRespType == DECLINED maybe?

If the client would like to receive back the collateral posted (note: not cancel or replace), should they send a CollateralAssignment with CollAsgnTransType == RELEASE

In addition, what does a CollAsgnTransType == RELEASE and REVERTED mean? Also, what are the meaning for the various CollAsgnReason?

Again, I gladly appreciate the help.

Thanks,

Dwayne

9

Hi Dwayne,

the CollateralResponse is to respond to a CollateralAssignment, i.e. the application facing the custodian cannot send an assignment and then a response in case he does not get a response from the custodian. If the Rules of Engagement foresee a response from the custodian then it is a technical error if there is none. From a business point of view the client can deposit or withdraw collateral, i.e. the client could send another assignment message reversing the effect of the first one. The business intent is expressed with CollAsgnReason. Please see EP192 (http://www.fixtradingcommunity.org/pg/extensions/extension-pack?ExtensionID=EP192) for details. It has been published in December and also covers extensions for collateral management.

In FIX there is not always a complete description of all valid values in terms of associated use cases. Rather than trying to find out the meaning of such values, I usually suggest to come from a given use case and then to look for the best valid values, possibly resulting in the identification of a gap.

Regards,
Hanno.

10

Hey Hanno,

Thanks. So if the client would like to receive back the collateral posted (note: not cancel or replace), should they send a CollateralAssignment with CollAsgnTransType == RELEASE?

Could you please valid that the below scenario and FIX usage would be inline?

Scenario #1: Client would like to send a request to post collateral, which is accepted and settled.
Expected Behavior: A CollateralAssignment should be sent with CollAsgnTransType == NEW (903=0) along with the rest of the require fields set appropriately. In response, a CollateralResponse is sent by the counterparty with the CollAsgnRespType == Received(905=0). Once the collateral has been settled, then a a CollateralResponse is sent by the counterparty with the CollAsgnRespType == Accepted(905=1).

Scenario #2: Client would like to send a request to cancel the collateral post, which is accepted.
Expected Behavior: A CollateralAssignment should be sent with CollAsgnTransType == CANCEL (903=2) along with the rest of the require fields set appropriately. In response, a CollateralResponse is sent by the counterparty with the CollAsgnRespType == Accepted(905=0).

Additional questions:

  1. How does a CollAsgnRespType of “DECLINED” and “REJECTED” differ?
  2. How does a CollAsgnTransType of “RELEASE” and “REVERTED” differ?

Thanks again,

Dwayne

11

CollAsgnTransType is a field that addresses a transaction, hence the “Trans” in the field name. One the transaction is completed, you cannot cancel it, you can only start a new transaction. Therefore, you cannot use it in the way you describe. CollAsgnReason is the field to describe the business intent, i.e. to deposit or withdraw collateral. If you want to “cancel the collateral post” as you say, then you need to start a new transaction (CollAsgnTransType == NEW) with a different CollAsgnReason, e.g. 4=Margin Excess to withdraw collateral. That new transaction may be rejected with CollAsgnRespType if the collateral is already tied to something and cannot be given back.

12

A bit confused why you would set CollAsnTransType == NEW, as oppose to CollAsgnTransType == CANCEL? If your intent is to cancel a previous request that has not yet been processed (i.e., settled by the custodian), then a CollateralAssignment with a CollAsnTransType == CANCEL seems appropriate. You previously stated that “the client always sends a CollateralAssignment, CollAsgnTransType conveys whether this is a new transaction (i.e. posting of collateral) or the amendment or cancellation of an existing transaction.”

A request to post collateral accepted (i.e. settled by the custodian):

  1. Client post collateral, therefore, a CollateralAssignment is sent with CollAsgnTransType == NEW (903=0) and CollAsgnReason == Margin Deficiency (895=3).
  2. B/C sends a CollateralResponse with CollAsgnTransType == RECEIVED (905=0) as an indication that the request has been received but not yet processed.
  3. Once the B/D has confirmed with the Custodian that the security has been deposited, the B/D will confirm to the customer via a CollateralReponse with CollAsgnRespType = ACCEPTED (905=1) indicating the collateral has been accepted/settled.

vs.

A cancel request accepted since the collateral request to post has not yet been processed:

  1. Client post collateral, therefore, a CollateralAssignment is sent with CollAsgnTransType == NEW (903=0) and CollAsgnReason == Margin Deficiency (895=3).
  2. B/C sends a CollateralResponse with CollAsgnTransType == RECEIVED (905=0) as an indication that the request has been received but not yet processed.
  3. Client would like to cancel the previous request to post collateral, therefore, a CollateralAssignement is sent with CollAsgnTransType == CANCEL (903=2) and CollAsgnReason == Margin Deficiency (895=3).
  4. B/D accepts the request to cancel since it has not yet received confirmation from the custodian that the initial request to post collateral has been settled (accepted). The B/D would respond with a CollateralReponse with CollAsgnRespType = ACCEPTED (905=1, in response to the request to cancel.

I am a bit confused on why CollAsgnReason = Margin Excess (895=4) would mean withdraw collateral and CollAsgnReason = Margin Deficiency would mean deposit collateral. My guess is that if you want to “post collateral”, it is assumed that you don’t have enough securities or cash to cover the margin deficiency?

In what cases would you use a CollAsgnReason of “Initial”, “Scheduled”, “Time Warning”, etc?

Thanks again. Everything is becoming clearer now.

Dwayne

13

@hanno.klein/ @ltaikit,

Hi Hanno/ Lisa,

On this occasion which tags would you be using on the CollateralResponse (35=AZ) to confirm,

a) The type of collateral deposited (say if it’s Cash/ any other asset)
b) The amount deposited.

Much appreciated.

Thanks,
Deran.

14

Hi Deran,

have you seen that CollateralAmountGrp was added to the CollateralResponse with EP192 (https://www.fixtrading.org/packages/ep192/) in mid-2017? It has CollateralType(1706) for a) and CurrentCollateralAmount(1704) for b).

Regards,
Hanno.

1 Like
15

thanks @hanno.klein. Yes, noticed that the Group is introduced in FIX 5.0. I guess for 4.4, what it does is an acknowleding a 35=AY request with minimal information going out via the response.

Thanks anyways

16

You can use elements (messages, components, fields, valid values) of a higher FIX version “as-is” in your given FIX version if cannot move entirely to the higher version. Your FIX engine must allow these elements to reach the application and you have to validate them there as your FIX engine has no knowledge about them (similar to user-defined fields above 5000).

17

Thanks Hanno.