Underlying Batch Reinsert Mode

In this page:

Overview

You can reinsert underlying records in batch mode (delete all the previously existing records before load with the following key: sec alias + underlying type)

Behavior

A) If the incoming record contains batch key:

1. Underlying records with sec_alias and underlying type related to the corresponding batchKey will be deleted
2. Underlying records from the incoming transaction will be loaded one by one (same order as they are positioned in the file)

In this case key for deletion is MAIN SEC ALIAS + UNDELYING TYPE

B) If incoming record contains batch key and processingOptions element contains UNDERLYING_UPSERT_MODE:

1. Underlying records from the incoming transaction will be loaded one by one (same order as they are positioned in the file)

Deletion will NOT be performed in this mode by default. The process will still try to follow usual underlying load steps meaning it will take into consideration already existing time periods for underlyings.

Structure of Data for Load

It is expected that the data is grouped and sorted in a special way:

Records should be grouped by Security alias + underlying type. Such grouping is required to fulfill requested logic suggesting that only one underlying can exist for a certain security with certain underlying type.
Based on this it is expected that each grouped record should have following structure:

<referenceTransaction>
<header>
<batchKey>PRIMARY_ASSET_ID^PRIMARY_ASSET_ID_TYPE^UNDERLYING_TYPE</batchKey>
<processingOptions>batchUnderlyingReinsertMode</processingOptions>
<objectType>UnderlyingSMF</objectType>
</header>
<underlyingSMF>
…
<beginDate>2018-07-10</beginDate>
<endDate>2018-07-12</endDate>
</underlyingSMF>
<underlyingSMF>
…
<beginDate>2019-07-11</beginDate>
<endDate>2019-07-13</endDate>
</underlyingSMF>
<referenceTransaction>

Underlying SMF records inside each referenceTransaction should be sorted by the timeline, first going with the earliest begindate/enddate, last - with the latest begindate/enddate. Date logic will remain the same as in usual underlying upload and will not allow time periods overlapping.

Since we have several ways to resolve security, batch key can be set in various ways based on the final design. Suggested structures for batch key:

• PRIMARY_ASSET_ID^PRIMARY_ASSET_ID_TYPE^UNDERLYING_TYPE – simple structure, however we can resolve records without primary id/type. So it may be an issue
• SECURITY_ALIAS^ UNDERLYING_TYPE – this structure allows to avoid any misunderstanding for record recognition, however it requires the user to perform resolution before load.
• XREF_ID1^XREF_TYPE1^UNDERLYING_TYPE – in this case it is expected that the use would take any first identifier pair in the file for batch key generation.

Batch key identifiers will be used to define records for DELETE during batchUnderlyingReinsertMode.

Batch Mode Load Process

• Mapping is executed only for header/security identificator since it is required for the first step – deletion in case of processingOption = batchUnderlyingReinsertMode.
• It is executed as pan-qdelunderlying-security with mapping for main sec alias + underlying type (the panel supports such behavior). This step deletes all existing underlying records with the same underlying type and sec alias.
• After that mapping and resolution for both Main sec alias + related sec alias are performed and all the necessary fields are populated.
• Inner load logic follows usual underlying settings such as current date option.