Failed trade status

,
1

Hello All,

In an FX market, due to regulatory rules, a trade cannot be annulled after a given period of time but it can be marked as failed, so the trade stays in the marketplace but with a failed flag. It has never happened and it seems unlikely to occur but it needs to be allowed.

Since the trade is not annulled, we think we can submit a trade amendment changing the status of the trade. Please let us know if this would be OK.

TradeCaptureReport(35=AE):

  • TradeReportType(856) = 5 (No/Was)
  • TrdRptStatus(939) = 3 (Accepted with errors)

Thanks in advance

Alexe

2

Could you clarify with an example of “failed trade” that “stays in the marketplace?” Not sure why a failed trade would “stay in the marketplace”. For me a “marketplace” means an execution venue or exchange.

3

Hi,
The scenario would be:

  1. There is an FX Spot trade between banks A and B (Could be banks u other entities permitted to trade in the marketplace).
  2. There is a 15 min period of time to cancel this trade. After this time gap the trade cannot be cancelled.
  3. At the end of the market day, bank B goes into bankruptcy so this trade between bank A-B will not be payed.
  4. Due to local regulations, this trade cannot be cancelled and must be marked as failed to indicate it did not have a fulfillment payment.
  5. It is necessary to inform this post-trade change to bank A and regulatory bodies.

Hope it helps to clarify the question.

Regards,

Alexe

4

I would see this more as a failed clearing/settlement than a failed trade. TrdRptStatus(939) is only about the trade and not about its settlement, similar to OrdStatus(39) only being about the order and not about any trade resulting from the order. The trade was conducted without failure but the obligation to pay for the trade cannot be fulfilled due to bankruptcy.

5

Taking into account that TradeClearingInstruction(1925) field shows Reserved4000Plus as Union Datatype, Would it be OK to define a reserved value for TradeClearingInstruction(1925) for this case where the trade cannot be payed?

  • TradeCaptureReport(35=AE)
    ** TradeReportType(856) = 5 (No/Was)
    ** TradeClearingInstruction(1925) = 4001 (Payment unfulfilled)
6

This is an interesting use case that is so specific and seems rare, but I’m sure there are other reasons for a failed trade. Seems to me that what you’re for is a way to indicate a reason for failed trade. I’m not sure TradeClearingInstruction fits this semantically based on how it is defined right now (and the Extension Pack that added this field has to do with Dodd-Frank reporting requirements). Does this have to do with MiFID 2 or some other regulatory jurisdiction?

7

The requirement does not have to do with MiFID2 u other international US/European regulation. It is a single country government regulation.
At first glance, the user-defined values for TradeClearingInstruction(1925) seemed OK because different failure reasons can have additional values (I.e. 4001, 4002, etc.).
Also, taking into account the possible failure reasons, the alternative of field TrdRptStatus(939)=3 (Accepted with errors) could be used among with TradeReportRejectReason(751) and RejectText(1328) fields to indicate the trade error/failure reason since the TradeReportRejectReason(751) has Reserved100Plus as Union Datatype.
However, since it is an uncommon case we would like to have the community feedback to implement the most suitable solution.
Thanks in advance

8

User-defined values of fields with union data types still need to follow the semantics of the field. The term “Instruction” in the field name means it is about information to the clearing system, asking for a specific behavior. You are looking for something different. You want to inform the trading system that a trade has failed (to settle) due to a lack of payment. Rejecting the trade does not fit your semantics as a rejection typically means that something never happened. You want that the “trade stays in the marketplace”.

It may not be perfect but have you looked at TradeReportType(856) = 8 (Defaulted)? I know this is not about a credit but after all, it is about defaulting on an obligation to pay.

9

Thanks. We will take a look at it.
It seems worth to check it out since we do not use TradeReportType(856) = 8 (Defaulted). Initially we discarded it because the trade stays in the marketplace and we thought the case as a trade amendment with TradeReportType(856)= 5 (No/Was) and some other field to indicate the payment unfulfilled.

10

This value is more applicable to characteristics of the trade that have changed. I am assuming you were not intending to also use it to explicitly convey that payment has been fulfilled, i.e. to only use it for the negative case. The positive case would then be implicit by absence of a message conveying the negative case. Default is only one of the reasons for a payment going unfulfilled. FIX currently does not have a reason field for this purpose in the TCR message. TradeReportRejectReason(751) was initially intended to explain the reason for a rejection of a TradeCaptureReportRequest(35=AD) message. It may also be used to reject the submission of a trade report but it is not applicable to a valid trade failing payment.

11

Thanks Hanno for your feedback.
After an internal checking, we think that TradeReportType(856)=8 (Defaulted) can be used to accomplish this specific requirement, so we will use it.

12

Helping content