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

« Previous Version 13 Current »

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.

MultiLeg SMF always goes through accounting validation (is loaded thru panel) 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