PUBLIC COMMENT PERIOD - Recommended Practices - Bi-Lateral Repo Post-Trade

,
1

This Bi-Lateral Repo trade recommended practices document was produced by the FIX Repo working group to define industry practices for the common usage of FIX protocol for post-trade workflows for repurchase agreements (repos) in a bilateral setting. The post-trade workflows consist of:

  • Allocations
  • Confirmations
  • Collateral Assignment
  • Lifecycle events including early termination/close-outs, collateral substitution, and margin maintenance.

The proposal is following the technical standards review process described in the document found here: https://www.fixtrading.org/packages/technical-standard-proposal-process/

This document now enters a public comment period in which public review and feedback is encouraged. The public comment period will be open until the 25th of May 2020.

A link to the proposal can be found here: https://www.fixtrading.org/packages/fix-protocol-recommended-practices-bilateral-repos-post-trade/

Please post feedback, comments, and questions as replies to this discussion thread.

2

Why not encourage a BIC in PartyIDSource in AllocationInstruction or AllocationReport or Confirmation?

3

How do we represent closing leg details in Allocation Instruction or Allocation Report? It doesn’t cater for details like Start Cash, End Cash etc., wherever applicable.

Also can it be made explicit that AllocAvgPx is the repo rate for the respective allocation instance?

4

How do represent life cycle events in Confirmations? Is the proposal to represent everything as an amendment?

We have certain vendors and clients, where once the trade was already matched, they treat subsequent changes in some fields as life cycle events which are distinct from the original trade confirmation process.
e.g. any changes in the following fields are preferred to be sent as distinct Confirmation events rather than as amendments on the original Confirmation.

  1. Rate or Spread Lifecycle Event
  2. Price Lifecycle Event
  3. Close out Lifecycle Event
  4. End Date Lifecycle Event
  5. Substitution Lifecycle Event
  6. Roll-over Lifecycle Event
5

REPO WG suggests using LEI (Legal Entity Identifier) instead since it is adopted due to regulatory requirements especially for ESMA reporting in Europe. If needed, BIC can also be used.

1 Like
6

The AllocGrossTradeAmt(2300) can be used for Starting cash consideration and
TradeAllocAmtGrp/TradeAllocAmtType(1845)=ENDV (End Value) for end cash consideration. Repo WG thinks it is implicit that AllocAvgPx, if populated, will represent repo rate. The group also recommends not populating the field to avoid confusion as the repo rate for the respective allocation instance should not be different from the trade’s repo rate.

1 Like
7
o Rate or Spread Lifecycle Event - TradeContinuation(1937)=tbd (Rerate); Please see the ‘Rerate’ workflow added to Post-trade recommended practices document.
o Price Lifecycle Event - Assuming this is referring to the collateral mark-to-market price, this would be done through CollateralReport(35=BA) message. Please refer to the ‘Reprice’ workflow added to Post-trade recommended practices document.
o Close out Lifecycle Event - The closeout event is initially notified using TradeCaptureReport(35=AE) message with TradeContinuation(1937)=31 (Early termination) and close out date in TerminationDate(2878). Please refer to ‘Early termination’ workflow in Post-trade recommended practices document. The same fields can be used in Confirmation(35=AK) message for this life-cycle event.
o End Date Lifecycle Event - TradeContinuation(1937)=8 (Amend) with new End date. Repo WG recommends this to be an amendment of the original trade with revised end date.
o Substitution Lifecycle Event - Please refer to ‘Collateral substitution’ workflow in the Post-trade recommended practices. Account(1) can be used to specify allocated account for which substitution has been performed.
o Roll-over Lifecycle Event - TrdType(828)=tbd (Roll trade); Please refer to ‘Repo Rollover’ section in Trade recommended practices document. For workflow, ‘Rerate’ workflow can be used as an example.
1 Like
8

Thanks for the feedback… We have intermediate vendors whose systems work based on BICs, hence requesting to add BIC.

9

BICs should already be covered by FIX, for example PartyIDSource(447)=B (BIC). Where exactly did you want to add BIC?

10

Hi Klein,
Agree with you BIC is supported in FIX by tag 447=B.

What I am requesting is to make BIC as a valid recommendation in the PartyIDSource tag in the Bi-Lateral Repo Post-Trade recommended practices. At the moment, the recommendation is to use a custom code or LEI or MIC.
Custom codes are creating a reference data maintenance overhead as we see various vendors and clients using their own proprietary type of custom identifiers, hence making the onboarding process costlier.
However in our experience, we see most of them inclined a bit towards using BIC. So would be better to make BIC part of recommended practices.

Thanks,
Ramjee.

11

@ramjeepenta I understand your point now. This will be taken back to the working group (https://www.fixtrading.org/groups/repowg/) to discuss and enhance the document.

1 Like