FpML Issues Tracker

334: custodian receives trade twice

March 15, 2007

closed

Major

Always

Business Process

Admin

mgratacos

Summary

Custodians sometimes receive the same trade twice, once for each trade side.

How can a custodian tell who the message was on behalf of? They can't look at sender as it may be ent by an agent or proy.

Is receiving the same message twice a business process bug

I suggest adding a party reference for the role initiating the message within the business process definition.

Notes:

  • matthew

    03/19/07 1:54 pm

    As discussed in coord:

    Add a reusable type of “onBehalfOf” of type TradeSideOrPartyReferenceReference that can be added to messages.

    The usage should be optional until version 5, when it becomes mandatory.

  • matthew

    03/19/07 1:55 pm

    This would resolve issue #172.

  • matthew

    04/02/07 2:23 pm

    Has the agreement from the Coord meeting of two weeks ago been implemented yet?

  • matthew

    04/02/07 2:23 pm

    Please minute the Coord committee decision.

  • mgratacos

    04/02/07 3:12 pm

    It was minuted by Brian:

    Issue 334 (2 messages received by custodian) ============================================
    This occurs because a custodian can act on behalf of both parties in a contract.

    Agreement:

    Implement an optional onBehalfOf element, type = PartyOrTradeSideReference, created inside a reusable model group.

    This will be documented something like the following: “The party or side that that the message is sent on behalf of. The message is sent from the perspective of that party.”
    This model group should be added to all the contract notification messages.
    In the future we’ll add it other places where it’s required, which is likely to be many of the existing FpML messages. (Open question: where to add?
    Assume at the top of the message, after the message header and validation elements, but before any other business content.)

    ACTION: Irina to implement.
    The solution also addresses issue 172

    I am working on the implementation at the swiftcug branch.

  • matthewdr

    04/09/08 10:25 am

    Assigned to BPWG.

  • mgratacos

    06/03/08 7:50 am

    2008-06-02 Coord call: agreement to implement solution as stated in the following note:

    Issue 334 (2 messages received by custodian) ============================================
    This occurs because a custodian can act on behalf of both parties in a contract.

    Agreement:

    Implement an optional onBehalfOf element, type = PartyOrTradeSideReference, created inside a reusable model group.

    This will be documented something like the following: “The party or side that that the message is sent on behalf of. The message is sent from the perspective of that party.”
    This model group should be added to all the contract notification messages.
    In the future we’ll add it other places where it’s required, which is likely to be many of the existing FpML messages. (Open question: where to add?
    Assume at the top of the message, after the message header and validation elements, but before any other business content.)

    ACTION: Irina to implement.
    The solution also addresses issue 172

    I am working on the implementation at the swiftcug branch.

  • mgratacos

    04/23/10 3:20 pm

    This has been fixed in version 5.0 with the introduction of the onBehalfOf element.

  • matthew

    04/23/10 7:43 pm

    The optional onBehalfOf element refers to a Party or TradeSide, yet if the same Party is on both sides then referring to the Party doesn’t discriminate between sides. When onBehalfOf refers to a TradeSide this works, but in v5 TradeSide has been removed.

    How does this work in v5 when the same Party is on both sides?

  • mgratacos

    04/24/10 2:05 pm

    In version 5.0 as modelled by the MTF, the onBehalfOf points to a party block and optionally to an account block. So each side would point to the same party but to a different account.

    Example:

    Side 1:


    Side 2:


  • Leave an update

    You must be logged in to post an update.