FpML Issues Tracker
assigned
Minor
Always
Coordination
FpML 6 (Build 1)
none
Admin
mgratacos
Summary
Coordination Committee has agreed on 2010-10-19 teleconference that it is important for FpML shared payment types to be normalized (to re-use NonNegativePayment type that includes payer/receiver direction, paymentDate and paymentAmount). Since it is a non backward compatible change, the proposal is to deprecate all payment structures in favor of normalized ones. Alternatively, (assuming nobody is using 5.0 yet) make the change within the existing types.
Notes:
h_mcallister
11/12/10 6:22 pm
Please see the attached zip (PaymentNormalization.zip), containing a proposal to improve the representation of payment dates in the normalized payment structure.
andrew
11/15/10 9:58 am
Nice job Harry.
I think I would prefer to keep the paymentDate element and not go as far as the radical option. From the point of view of processing a document its nicer to be able to point to a single element node that represents a ‘concept’ rather than a node list (as it would be for an unadjusted date).
We need to be careful that this change to the NonNegativePayment and PositivePayment types is NOT carried over the to the Payment type as that would allow relative payment dates to be a option within the FX products where they are not a valid product option.
It might be sensible to reposition the ‘paymentAmount’ within Payment to make it consistent with the others (e.g. after the date rather than before it). If the Payment type is only used for FX products then maybe it should be renamed to make it more FX specific?
h_mcallister
11/29/10 4:20 pm
I agree that payment type normalization must not introduce redundant or inappropriate content e.g. permitting a relative date in contexts where it is not required. I also agree with the suggestion of re-ordering payment elements for consistency across types – in fact, this should constitute de-facto derivation by restriction from a single super-type.
Please note that Payment is not only used for Fx products, having been introduced in the early IRD model to support additionalPayments and otherPartyPayments. The concept originates with FpML_Fee in FpML 1.0, the current form of the type apprearing in FpML 2.0.
However there is another argument for specialising the payment type used in FxSingleLeg/exchangedCurrency1 and -2; here the payment date is typically supplied by the valueDate element, and paymentDate + adjustedPaymentDate are omitted altogether, as permitted by the 4-x Payment type. This behaviour should continue to be supported in FpML 5-x.
To Andrew’s point, it would be equally undesirable to introduce spurious relative payment dates in any of these contexts.