PUBLIC COMMENT PERIOD – Post Post-Trade Confirmation Payments Proposal

The Global Technical Committee has reviewed and preliminarily approved the Post Post-Trade Confirmation Payment proposal submitted by the FIX Global Post-Trade Working Group. The purpose of this document is to provide a post post-trade confirmation message flow for reconciliation and agreement of cash movement activities between an Investment Manager and its Broker to meet obligations during the life of the a contract.

The document now enters a public comment period in which public review and feedback is encouraged. Once the public comment period closes, the Global Technical Governance Board will meet to review public comments before final approval.

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

A link to the proposal can be found at:

The public comment period ends on June 21, 2019.

-Netting functionality should be reviewed in next round-table and proposal put together for how to incorporate into the messaging

  • Bi-directional flow to be supported

A few suggestions from me.

  1. I would like to see the protocol specified in such a way that either the buy-side or sell-side could initiate the payment request. This will allow for either side to do the calculation with the other party verifying. The message set can then be used with greater flexibility in more scenarios.
  2. Please consider adding a tag to payment report to hold a payment reference used in the SWIFT payment process with the Bank (e.g. SWIFT GPI tracker).
  3. The payment reports allow for the payer to indicate that payment has been initiated. However we must note that the payer might be either of the parties. In some currencies it may be useful for the receiver to indicate that they have instructed receipt.
  1. Current FIX examples show Investment Manager as the initiator of the flow – we would expect the Broker to also be able to initiate the payment affirmation flow
  2. There are multiple types of payment supported in the proposal (e.g. trade settlement and margin calls ) – we recommend to have identifiers to be able to segregate these
  3. If Rejected is a terminal State what is next action ? – restart from internal application after manual operational error processing?
  4. More clarification required on proposal about how to deal with Missing or Incorrect Settlement Instructions. Would the Broker call clients to resolve missing instructions and restart automated flow or mark as disputed and resend as new flow?
  5. Are there any plans to support cross-account netting? The proposal has one account per message, hence as it stands does not allow netting with accounts and across accounts - should this be revised?
  6. Fraud prevention on unsolicited payment report message. Should this simply be a DISPUTE message or more specific fraud alerts/escalations? The example of how to prevent fraud requires clarification.

Submitted on behalf of Wendy Seels:

We would like to reconfirm/explore with the group the possibility of increasing the number of economic details within the message to aid with the dispute process.

The comments entered during the Public Comment period have been addressed in the track changed document, along with changes resulting from the comments. (