Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 11 Next »

Multiple Leg SMF provides the customer with an instrument to describe a multileg asset.

Currently, the "legs" are:

  • contractLeg - describes the conditions agreed in the contract;
  • payLeg - describes the payment;
  • receiveLeg - describes what has been obtained by the contract.

All three legs have an identical structure in EagleML, but should be filled in a specific way reflecting a real asset.
It is assumed, that MultiLeg SMF goes through accounting validation regardless of the accountingVatidationFlag value.

Loading Logic

'eagle_ml-2-0_default_in_xml_smf_generic' stream is used. It involves the following rules:

  • /eagle_default/in/xml/xml-smf_multileg_swap.xml
  • /eagle_default/in/xml/xml-smf_objects.rsf

Each leg record is sent to the following panel: eagle/star/reference/pan-addsecmastermultilegswap.htm 

Required Fields

  • Issue Name (tag 961)
  • Primary Asset Id (tag 14)
  • Primary Asset Id Type (tag 1432)
  • Processing Security Type (tag 3931)
  • Issue Date (tag 68)         
  • Dated Date (tag 1183)       
  • Maturity Date (tag 38)      
  • Issue Country Code(tag 1418)
  • Asset Currency (tag 85)     
  • Settlement Currency (tag 63)
  • Income Currency (tag 1186)  

Panel Logic

Each Leg group (contractLeg, payLeg, receiveLeg) is loaded into the SECURITY_MASTER table as a separate record.
2 to 5 entries in the XREFERENCE  table can be created for each Leg record.
There are special asset identifiers used for MultiLeg SMF, they are hardcoded as described in the following table:

primaryAssetId

primaryAssetType

instrumentId

instrumentIdType

uniqueProductId

Hardcoded as 'UPI'

uniqueSwapId

Hardcoded as 'USI'

primaryAssetId+"C1"  [Only for Contract Leg]

Hardcoded as 'SWAPID'

primaryAssetId+"P1" [Only for Pay Leg]

Hardcoded as 'SWAPID'

primaryAssetId+"R1" [Only for Receive Leg]

Hardcoded as 'SWAPID'


PAY and RECEIVE are cross linked with the corresponding CONTRACT via SECURITYDBO.UNDERLYING_SECURITY table 
CONTRACT (parent) -> PAY (child)
CONTRACT (parent) -> RECEIVE (child)
One can also specify a child underlying record for each of the three legs (CONTRACT,PAY,RECEIVE).

For example:

<underlyingCusip>CCSTGVFERTRF</underlyingCusip>
<underlyingSecurity>TEST1A</underlyingSecurity>
  • No labels