FpML Issues Tracker
closed
Major
Always
Loans
Admin
None
Summary
1. Why are DealIdentifier and FacilityIdentifier derived from Product?
I cant see why they need to be as they are not used within a
2. DealIdentifier can be completely empty The design of the type does not force any component to be present.
3. FacilityIdentifier can be almost empty As with DealIdentifier the content model looks too loose.
I think both FacilityIdentifier and DealIdentifier need to be re-derived as independent types, duplicating the product fields and with a stronger content model.
Andrew Jacobs (Chair AWG)
Notes:
katirabh
07/08/08 10:54 pm
Firstly, they are drived from product because they are the loan product definition.
Within the loan industry, there is currently no standard loan identifier (e.g. CUSIP/ISIN). They are being adopted but there is not the market penetration of ids that exist in other markets.
Currently, the market uses certain ‘business fields’ to identify deals and facilities. These are the fields shown in the identifier structures.
As the market evolves and CUSIP/ISIN becomes sufficiently penetrated then these structures should only be used to capture those id fields and the requirement to populate the ‘business fields’ may become a lower priority. Since, it is often difficult to embed evolving rules within the schema structure, it was thought that we can embed such rules within business validations instead.
The point being, the optionality was embedded since the market will shift and we need to maintain flexibility through this period.
Also, when we represent the secondary trading market, the asset which will be traded will be facilities (and deals) – which follows the FpML standard… I believe…???
I would certainly like to discuss the merits and/or arguments against extending the product base.
mgratacos
07/25/08 9:35 am
The inheritance has been changed from Product to Asset. Now dealSummary and facilitySummary (old dealIdentifier and facilityIdentifier) extend IdentifiedAsset instead of Product. The IdentifiedAsset type requires at least an instrumentId element to be provided. The default scheme for the instrumentId is the CUSIP but other identifiers can be used.