MultiLeg SMF Inbound Interface

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.

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 

Direct Load via SP Option

MultilegSMF interface supports data load without accounting validations in the panel. Setting <noLoadValidationFlag> element in the incoming message to Y allows data insert and update directly via INSERT_UPDATE_SECURITY_INFO stored procedure without any calls to the panel.
Underlying links for the Pay and Receive legs are created with a begin date which corresponds to the effective date for the Contract leg in the incoming file. In the case of a MultilegSMF update, the underlying links are updated only if the new record has an effective date higher than the previously loaded begin dates on the Pay and Receive legs for the corresponding Contract leg.

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:

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>