Global Shareholding Disclosure

Implementation Guide

This document is intended for Implementation Guide only. The information is being provided to assist the recipient in evaluating a possible
commercial relationship with Adenza (formerly AxiomSL) and should not be used for any other purpose. This document is proprie tary to Adenza and
constitutes confidential information under the terms of the Mutual Non-Disclosure Agreement or similar confidentiality arrangement that
Implementation Guide may have entered into, or may in the future enter into, with Adenza. While Adenza believes that the information contained
herein is accurate and current through the date hereof, neither Adenza nor any person acting on its behalf makes any representations or
warranties, expressed or implied, as to the accuracy of such information, and expressly disclaims any and all liability that may be based on such
information or errors or omissions thereof. This document does not constitute or imply any promise to license or sell any products or services. Any
transaction between Adenza and Implementation Guide is subject to the execution and delivery of a definitive agreement between the parties.
 Summary 4

GSD Calc Input Document 4

2.1 Change Control 4

2.2 Data Input 5

Populating Calc Data Input and Reference tables 6

3.1 Entity Configuration 6

RefReportingEntity 7
RefReportingEntityGroups 8
RefReportingEntityHierarchy 9
RefEntityGroupLogic 11
RefEntityGroupLogicIssuer 12
RefMonitoringEntityGroups 13
RefReportEntityMapping 14
RefReportingEntityHierarchy Maintenance 14
3.2 Capacity Exemptions Configuration 15

Full Capacity Exemption 15

Calculated Capacity Exemption 15
Full exemption functionality 16
Fully bypass exemption functionality 16
Partial exemption functionality 16
3.3 Florange Configuration 17
3.4 Japan Configuration 18

Japan Monitoring Threshold 18

Japan Monitoring Date 19
Japan Unregistered Entities 19
Japan Change in name and address 20
3.5 ETF Processing 20
3.6 Threshold Systems 20

Delta System 21
Bracket System 22
Proximity Threshold 23
Issuer Threshold 23
3.7 Monitoring and Reporting transactions 24
3.8 Relation between security id, class of share and ISIN 24
3.9 Reporting client static 24
3.10 Optional jurisdiction specific reference inputs 25
3.11 Instance keys and historical data sources 26
3.12 How to configure flags related to share in nature scope 26
3.13 Beneficiary trigger 28

Proprietary and Confidential 1

3.14 Sub-statuses 28
3.15 Collateral logic 29
3.16 JP Change In Nature Logic 30
3.17 ETF and Index Shares Check 30
3.18 IN IGP List 30

Data Validations 31

4.1 Validations projects updates 31

4.2 Validations and Exclusions Reasons functionality 31

Short Selling Process 31

5.1 Shares 31
5.2 Sovereign Debt and Uncovered CDS 33
5.3 Monitoring frequency 34
5.4 Issuer thresholds 35
5.5 Sub statuses 35
5.6 Capacity filter by group 36
5.7 Market Maker Exemptions 37

Monitoring Frequency Configuration 38

Dashboard input and configuration tables 40

Control tables instances adjustments framework 42

Load Inputs Workflow 43

Workflows Execution Sequence 44

10.1 Individual Workflows 44

10.2 Consolidated end-to-end Monitoring Workflow 47

Proprietary and Confidential 2

Document Control

Version History

Date Author Version Comment

05/10/2017 AxiomSL 1.0 Initial Version

02/11/2017 AxiomSL 2.0 Added details about the Monitoring date, Florange, Japan
unregistered entities, ETF configuration and analysis objects
02/12/2017 AxiomSL 3.0 Added details about false positive scenarios, Short Selling process,
and key objects
25/01/2018 AxiomSL 4.0 Added 13F Pre-Conditions

09/11/2018 AxiomSL 5.0 Added following sections: custom buckets and control tables
instances adjustments framework
22/08/2019 AxiomSL 6.0 Extended entity Configuration, Japan configuration, capacity
exemptions. Added Threshold systems, added details about end to
end workflows, added list of available instances for cntr tables
30/09/2021 AxiomSL 7.0 Added monitoring frequency, voting rights override, dashboard final
status, beneficiary trigger, delisted, capacity filter by group
configuration details and sub-statuses logic
28/10/2021 AxiomSL 8.0 Added logic for SH collateral logic, JP change in nature, ETF and
Index Check, IN IGP Issuers and SS Market Maker Exemptions
30/11/2021 Adenza 9.0 Updated header and footer with Adenza naming

30/03/2022 Adenza 10.0 Changed GSD Implementation Guide to the latest Adenza template

Proprietary and Confidential 3

 Summary
This GSD Implementation documentation is aimed at implementation consultants who will be configuring
the GSD solution at client sites. This document will give a detailed description of the calculation input
specification that is released with the solution and provide a guide for how fields in the Reference and
Calc Data Input tables should be populated.

GSD Calc Input Document

This section details the different components of the GSD Calculation Inputs document and how the
document is marked up.

2.1 Change Control

The “Change Control” is the navigation panel of the document. Here you can see a breakdown of all the
tabs included in the release, marked up with any changes that have been made since the previous
release. These tabs are hyperlinked for your convenience and clicking on a label will jump you to the
target tab.

The tabs are colour coded for each different type of table, as follows:

KEY DESCRIPTION
Overview

Calc Data Input tables

Reference tables

Dimension tables

If a change has occurred since the previous version, the relevant column will be ticked in the grid below.
The comments section, on the right-hand side of the Change Control, will specify the details of any
changes that have been made to the tables that are marked with a tick, as well as indicating any changes
to the overall layout of the calc inputs file.

Figure 1: Example of Change Control table

Proprietary and Confidential 4

The Overview tab gives a breakdown of which calc inputs and reference tables are mandatory,
conditional, optional or not applicable for monitoring and reporting, for each disclosure type and specific
functionalities such as Issuer Requests.

The default instance column lists the As Of Date of the instance in question. Meanwhile, the ‘Default
Instance Empty’ column defines whether the default instance is populated with data or not.

Figure 2: Example of Overview table

2.2 Data Input

There are two types of data input tables: ‘Calc Data Inputs’ and ‘Reference Tables’.

Calc Data Input tables are the templates for entering transactional/operational data into the solution.

Reference tables, labelled with the prefix ‘Ref’, are used to store static data. These are used to enrich the
monitoring and reporting process - including common reference data that is jurisdiction agnostic, data for
specific disclosure types, as well as jurisdiction-specific data.

The Calc Data Input and Reference tables are comprised of the following components:

FIELD NAME DESCRIPTION

Field Name The name of the field as it appears in controller view.

Field description A short description of the field.

Title How the header will appear for the field.

Data Type The data type that the field is expecting to be populated with.

Field Size The maximum size that the field will allow. This is only populated for VARCHAR
values.

Proprietary and Confidential 5

 FIELD NAME DESCRIPTION

Format This indicates further details on the acceptable values for a field. Dates and
timestamps will have the expected format of entry here. If an ISO standard is
expected this will be indicated here. If the field expects a value from a specified
list, the link to the associated Dimension Table will be indicated here.
Mandatory/ This column indicates which fields are mandatory for all calculations as well as
Conditional/ specifying which fields are required for certain regimes/jurisdictions only. The
Optional column is populated using the following key:
M – Mandatory: This field must be populated. The comments section adds extra
details for these requirements.
C – Conditional: May be required for certain disclosure types or jurisdictions.
O – Optional: This field is optional.
Comment This field contains granular details on the intended function of the field.

Any changes to the tables, since the previous version, will be indicated in the comments section of the
Change Control tab, as explained above.

Figure 3: Example of Calc Input Data table

Populating Calc Data Input and Reference tables

If the format for a field is specified by a dim table, the client must ensure the values used to populate this
field are only those contained in the dim table for both Calc Data Input and Reference tables.

If a default value is specified for a mandatory field, and the client does not have any logic to fill that field,
then the specified default value must be used to populate this field.

3.1 Entity Configuration

Tables for Entity Configuration

Proprietary and Confidential 6

 Mandatory Tables Optional Tables
RefReportingEntity RefEntityGroupLogicIssuer
RefReportingEntityGroups RefMonitoringEntityGroups
RefReportingEntityHierarchy RefReportingEntityMapping
RefEntityGroupsLogic

We will be exploring the example below throughout this section to help clarify how to configure Entity
tables within GSD Solution. Bearing in mind that all mandatory tables must be populated and
subsequently maintained by the client.

Steps to Configure:

RefReportingEntity
1. All the orgUnits used by the security positions (in the fields SecurityPosition.orgUnit,
SecurityPosition.orgUnit2, SecurityPosition.orgUnit3) need to be specified in the
RefReportingEntity reference table.

RefReportingEntity - This table is used to define reporting components as in the above Entity
diagram. This table is used to define important information such as Legal entity (Y/N) and holder
type. Even the group needs to be defined as entity in this refTable (Line 12 below screenshots).

**Note: All orgUnits should be part of the RefReportingEntity table even if they are not Legal Title.
For best practice follow the example naming convention, there should be no spaces with in the
code, e.g. Axiom_USA

Proprietary and Confidential 7

2. All the parent entities required for monitoring and reporting must be specified in the
RefReportingEntity reference table. ENTITY column (Axiom_Group, Axiom_USA, Axiom_EMEA
and Axiom_APAC)
3.

RefReportingEntityGroups
4. All the groups used in the monitoring and reporting processes must be defined in the
RefReportingEntityGroups reference table.

The example below is representing a concert party that has formed with Axiom_USA &
Axiom_EMEA. In case of concert party all group entity members need to be linked to an “artificial”
parent entity, e.g. in below example the “artificial” entity is: “Axiom_US_EMEA” and this entity
must be defined in the RefReportingEntity. Group “US_EMEA” must be defined in the
RefReportingEntityGroups table. When we define the reporting entity group, we also define the
Group Type and the Leader Entity (leader entity can be any entity of the concert party excepting
“artificial” entity).

Proprietary and Confidential 8

5. For all the groups used in the monitoring and reporting processes there should be a
corresponding record in the RefReportingEntity reference table. (Page 7)

RefReportingEntityHierarchy
6. For all the orgUnits from positions and all the parent entities (used for monitoring and reporting)
there should be a SELF relation in the RefReportingEntityHierarchy.

Proprietary and Confidential 9

 **Important: ENTITY RELATIONSHIP column should
have the value from dim_EntityRelationship table
and GROUP CODE column link to
RefReportingEntityGroups table.

To avoid confusion: The ORGANISATION UNIT

column here determine what ORG UNIT LEVEL
should be.
E.g. if OrgUnit is Axiom_GB then the OrgUnit
Level will be 3 as Axoim_GB is on the third level
of the hierarchy.

Proprietary and Confidential 10

 RefEntityGroupLogic
7. All the groups used in monitoring and reporting need to be defined as record(s) in the
RefEntityGroupsLogic reference table in order to know to which disclosure types is applicable.

If the same group is applicable on more than one disclosure type or across all disclosure types,
then for each allowed disclosure type separate record should be added. “N_A” is not allowed for
the column “Disclosure Type”.

If the same group is applied across all jurisdictions, in this case the ‘Jurisdiction’ can be populated
with ‘N_A’ instead of adding a record for each jurisdiction.

However, on the same group code and disclosure type combination you cannot have two records
as in the following scenario: one record with “N_A” for jurisdiction field and other record with
value different than “N_A” for jurisdiction field because this will duplicate the data.

Proprietary and Confidential 11

**Important: DISCLOSURE TYPE column should have the value from dim_DisclosureType table. This
should be the same for jurisdiction column where the value should be from dim_Jurisdiction table.

RefEntityGroupLogicIssuer
8. In case groups are used only for specific jurisdiction and issuers then these groups must be
mentioned in the RefEntityGroupsLogicIssuer. This table is not mandatory to be populated if
groups are used across all jurisdictions and issuers for the target disclosure type.

Fields “Jurisdiction” and “IssuerId” from this table cannot be populated with “N_A”.

According to the below example if group are used only for specific jurisdiction and issuers then
we must populate RefEntityGroupLogicIssuer table further in order to specify the issuers
applicable.

Proprietary and Confidential 12

From this we would expect Axiom_Global is applicable for SI and GB just only for Apple and IBM
issuers.

RefMonitoringEntityGroups
9. Monitoring level is specified by the control table named monitoringLogic. Each disclosure type
has its own specific monitoring logic control table. Possible levels are: GROUP, DIRECT_HOLDER,
DIRECT_PARENT, ANY.

Proprietary and Confidential 13

GB Example

In case Monitoring levels is different than GROUP, if client wants to minimise the number of
entities to be monitored then the RefMonitoringEntityGroups reference table must be filled.

This table will specified for each group code, disclosure type and jurisdiction and the entities to
be monitored but these entities will be used in monitoring only if they accomplish the monitoring
logic level condition.The table is not mandatory to be populated if all entities that respect the
monitoring logic level must be monitored.

**Note: JURISDICTION column can be populated with “N_A” but ENTITY column does not allow
“N_A”.

RefReportEntityMapping
10. Another optional table is RefReportEntityMapping. For Japan, we are using conditional level
monitoring. We will monitor all (hierachy) entities from its group. If client wants to minimise the
number of entities that breaches to be display on their Dashboard, they can specify this in
RefReportingEntityMapping table.

RefReportingEntityHierarchy Maintenance
11. Relations between child entities, indirect parents and the ultimate parent are not generated
automatically by the system. They will have to be defined by the user in this reference table, this is
vital.

Proprietary and Confidential 14

 3.2 Capacity Exemptions Configuration
We have 2 types of Capacity Exemptions within Significant Disclosure:

 Full Capacity exemption

 Calculated Capacity exemption

Full Capacity Exemption

Full capacity exemption will be applied to all client. When all positions with capacity type is in the list on
SH_cntr_capacityExemptions control table, they will have to be excluded from further calculation.

The above screenshot suggests that if positions for SH disclosure type and GB jurisdiction with particular
jurisdiction classification which belong in to this list of capacity type will be excluded from further
calculation.

Calculated Capacity Exemption

For calculated capacity exemption scenario, you will be looking into control 2 tables.
SH_cntr_exemptionAggregationBasis and SH_cntr_CalcExemptionThreshold

Calculated capacity exemption algorithm is the following:

1. Identify all positions that has the same capacity type and book type as target rules exemption
scenario.
2. Positions that has been identified from step 1 then needs to be aggregated on entity level specify
in the rules SH_cntr_exemptionAggregationBasis.
3. If the aggregated results are less than the threshold rules from SH_cntr_calcExemptionThreshold
then you must exempt those positions.

Not all client wants to use calculated capacity exemption functionality at all OR partially then they need
to populate RefExemptionValidity and RefExemptionOverride table. We are going to explore different
scenarios to clarify and help you with the configuration.

Proprietary and Confidential 15

 Full exemption functionality
By default, the calculated capacity exemption will be available for all client. This is when there is no record
in both reference table RefExemptionValidity and RefExemptionOverride.

No record in RefExemptionValidity AND No record in this RefExemptionOverride

OR
1 record in RefExemptionValidity SH | Y AND no Record in RefExemptionOverride

Fully bypass exemption functionality

If client do not wish to use it at all, please see the possible scenarios. Below is the most recommended

1 record in RefExemptionValidity SH | N

Partial exemption functionality

If client want to disable calculated capacity exemption for most of the jurisdictions but apply the
exemption to a few jurisdictions.

They can have to following configuration:

Proprietary and Confidential 16

 RefExemptionValidity have 1 record where disclosure type SH | N
AND
Specify the jurisdiction(s) they want to apply calculated exemption have to be listed in the
RefExemptionOverride. For each desire jurisdiction there has to be a record in this table.

None of the fields form this table will allow “N_A” value.

If client want to apply exemption to most jurisdictions but disable exemption for a few jurisdictions.

Either have no record in RefExemptionValidity

OR
1 record in RefExemptionValidity where Disclosure Type is SH | Y
OR
Specify the jurisdictions they want to disable have to be listed in RefExem ptionOverride

None of the fields form this table will allow “N_A” value.

3.3 Florange Configuration

The issuers for which we must apply the Florante Law will need to be configured in the following
reference input: RefFlorangeIssuers. The Florange Law process will not work if the client did not hold any

Proprietary and Confidential 17

position 2 years ago. Before running for as of date '21-Sep-2017', we must ensure we run for as of date
'21-Sep-2015'.

If clients want to override the number of voting rights calculated by the system – then input
CalcVotingRightsOverride from SD_SH_CalcInput will be used.

Logic will be applied irrespective if CalcVotingRightsOverride.positionId is related to a Florange issuer or

not.

3.4 Japan Configuration

Japan has a specific configuration in terms of monitoring threshold, monitoring date, monitoring
exemption, unregistered entity and change in name and address.

Japan Monitoring Threshold

All jurisdiction except Japan, the regulation thresholds are kept in the following control table
SH_cntr_monitoringThreshold. Disclosure Time frame and reporting form are kept in
SH_cntr_disclosureTimeFrame.

For Japan monitoring threshold and disclosure time frame rules and reporting form are kept under a
specific table – SH_JP_cntr_monitoringThreshold. This is because the criterial and logic to define the
current threshold and reporting form is different than other jurisdictions. However, you may still find
disclosure time frame for Japan under SH_cntr_DisclosureTimeFrame like other jurisdictions.

Proprietary and Confidential 18

 Japan Monitoring Date
Japan has a different monitoring frequency, Japan can be monitored daily but also bimonthly. The
Bimonthly date must be defined in the RefMonitoringDate for more details about the monitoring as of
date with special monitoring frequency please see the section monitoring frequency configuration
previously.

Why bimonthly is relevant to monitoring? This is because we have different threshold for bimonthly
regime, and this is Identifiable by Bimonthly indicator column from SH_JP_cntr_monitoringThreshold.

(Y=Bimonthly) (N=Daily)

Japan Unregistered Entities

By default, we consider all entities are registered entities. However, for Japan we can have different
threshold and reporting form for unregistered entities. The rules for Japan monitor threshold is under
SH_cntr_monitoringThreshold there is Register indicator column.

(Y=Yes) (N=Not registered) (NA= same behaviour for both type of entity)

The entities can be configured as unregistered in the reference table: SH_RefUnregisteredEntity as per
below example.

Proprietary and Confidential 19

Note: None of the field allow “N_A” value and jurisdiction are populated with “JP” only.

Japan Change in name and address

 Specific control tables:
▪ SH_cntr_changeInNameAddress
▪ SH_cntr_changeInNameAddressClient
 Rules: if group breaches the initial threshold and there is no change on group or any of entities or
there is movement or there is a change in structure and if there is change in name or/and address then
this is reflected in the status displayed in the Alerts dashboard

3.5 ETF Processing

In order to apply the ETF processing for shares, the following conditions must be met:

▪ In SecurityPosition, there should be positions with productType = ETF_UNIT

▪ The issuer of these positions should have issuerType = CLOSE_ENDED_FUND
▪ There should be at least one fund component in the Fund Components input, where unitID is the
same as the securityID of the ETF_UNIT position
In order to apply the ETF processing for sovereign debt, the following conditions must be met:

▪ In SovDebtPosition, there should be positions with productType = ETF_UNIT

▪ The issuer of these positions should have issuerType = CLOSE_ENDED_FUND
▪ There should be at least one fund component in the Fund Components input, where unitID is the
same as the bondID of the ETF_UNIT position

3.6 Threshold Systems

Threshold logic is another key feature within the GSD solution. The rules are kept under
SH_cntr_monitoringThreshold control table, from this table you will be able to find and understand the
threshold information for particular jurisdiction. This will help us determine what must be monitor and if
positions have breached the threshold value. Each threshold has Threshold ID = 0 means the exit and
Threshold with ID >=1 are for states as: initials, subsequent or no change.

The main rules for Exit are:

Proprietary and Confidential 20

 ▪ Exit occurs when holdings go below the statutory threshold
▪ Exit occurs when holdings go below the statutory threshold AND the delta between the previous
holdings and the current one equals or exceed the required delta
For Japan we have a separate table for thresholds because the logic to identify the breached threshold
involves more details comparing with the other jurisdictions.

The main tables for thresholds are: SH_cntr_monitoringThreshold (regulation thresholds),

SH_JP_cntr_monitoringThreshold, RefProximityMonitoringThreshold (proximity thresholds),
RefIssuerMonitoringThreshold (issuer thresholds), SH_cntr_monitoringLogic (exitScenario attribute),
dim_exitScenario.

We will explore the two types of threshold systems below:

 Delta system
 Bracket system

Delta System
What does delta system mean?

The jurisdiction with this type of threshold system will have the Threshold ID (e.g. 0, 1) as well as the
associated lower and upper threshold trigger and most importantly the absolutely difference value,
usually this is different than 0. In order to determine a breached, the position must be higher OR lower
with the absolute different value of 1.

Australia (AU) jurisdiction utilises the delta system, for further clarity please check the scenario below
against the control table here for Australia.

Day Percentage Disclosure Event Explanation

of applicable
holding
1 4 No disclosure Currently this is sitting on Threshold ID 0 because it is not yet higher or
event equal to upper trigger 5.
2 5 Initial Now, this has breached as it has equal to 5.
3 5.2 No disclosure This will not be considered as breached as the differences or delta
event should be 1. Currently is it only 0.2 against Day 2 initial event.
4 6.1 Subsequent It is importantly to remember that we are comparing to previous
disclosed event, day 2 = 5 so therefore this would be subsequent as
this is higher than 5 with delta of 1.1
5 6.9 No change This would be no change because if you are comparing this to
previous disclosed day (day 4). Therefore, this is considered
insignificant and for AU is its non-disclosure event.
6 7.05 No change Again, we are comparing to the previous disclosed event so here (7.05
– 6.1 = 0.95 delta) it’s no change of event as the absolute delta is not 1.

Proprietary and Confidential 21

 Day Percentage Disclosure Event Explanation
of applicable
holding
7 5 Subsequent The delta here is 1.1 if we are comparing to 6.1 previous disclosed
event. This delta 1.1 decreased has caused for Subsequent event.
8 4.9 Exit This is below the initial threshold 5 so therefore this is an Exit. Exit
scenario is 1 which is why if we are below its exit. More explanation
about 1, 2 exit scenarios to follow.

It is essential to understand that you always compare the percentage holding against the previous
disclosure event not the previous day.

We don’t support intra-day reporting, this is because we don’t get the data feed in real-time.

Bracket System
For most of the jurisdictions, Bracket system threshold apply. With the bracket system field
absoluteDifference = 0 with more threshold ID (e.g. 0 to 8). The idea here is to see which bracket/band
the percentage holding belongs to. Like Delta system All important information is kept under
SH_cntr_monitoringThreshold control table.

We need to make sure that for particular jurisdiction differentiate the jurisdiction classification as this will
be the driver of which thresholds value to apply.

Great Britain (GB) jurisdiction utilises the bracket system, for further clarity please check the scenario
below against the control table here for GB.

Day Percentage Disclosure Event Explanation

of applicable
holding
1 4 No disclosure Currently this is sitting on Threshold ID 0 because it is not yet higher or
event equal to upper trigger 5. Bracket 0
2 5 Initial Now, this has breached as it has equal to 5. Based on the table above
now the holding is in Bracket 1, Threshold ID 0.
3 9.9 No change This will be considered as no change, non-disclosureable event as 9.9
will still fall in Bracket 1
4 20.1 Subsequent It is importantly to remember that we are comparing to previous
disclosed event, day 2 = 5 so therefore this would be subsequent as
this has jumped from bracket 1 to bracket 4.

Proprietary and Confidential 22

 Day Percentage Disclosure Event Explanation
of applicable
holding
5 4 Exit From the previously disclosure event Day 4, we can use this as brench
mark to compare and from this the movement is from Threshold ID 4
to Threshold ID 0 will be considered as Exit.

1. Threshold ID 0 is your base - From 0 threshold ID to anywhere is initial

2. From None 0 ID to a different threshold ID is subsequent
3. None 0 to 0 threshold ID is exit

Proximity Threshold
This is not a disclosure event. It is for the client to specify if they would like to set an alert if the percentage
holding is close to breaching the threshold. In order to defined proximity monitoring threshold client will
need to update the RefProximityMonitoringThreshold table. This information will be feed into the
Proximity Dashboard to allow client to get an alert whenever the positions are close to breaching.

Issuer Threshold
When client want to define their own threshold, they can define this information here on
RefIssuerMonitoringThreshold table. This is purely for client to input and maintain. Some jurisdiction,
(FR)France for example may want to monitor based on issuer threshold meaning that this table must be
maintained.

The issuer thresholds reference input: RefIssuerMonitoringThreshold will contain both types of
thresholds: proximity and non-proximity thresholds.

Proximity thresholds should have threshold='PROXIMITY'

Non-proximity thresholds will have threshold ids as: 0, 1,2 etc.

If there is defined issuer threshold then it will be followed the issuer threshold system for both: proximity
and non-proximity.

Else if there is no issuer threshold defined then for non_proximity will be taken in consideration
SH_cntr_monitoringThreshold and for proximity will be taken in consideration
RefProximityMonitoringThreshold.

Also, in ThresholdCheck there are different fields for proximity and non-proximity thresholds:

ThresholdCheck.currentThresholdId keeps the non-proximity breached threshold and

ThresholdCheck.proximityThresholdId keeps the proximity breached threshold.

If proximity threshold is breached, then ThresholdCheck.currentThresholdId will be NA.

Proprietary and Confidential 23

 3.7 Monitoring and Reporting transactions
Mostly transactions are used for reporting but there are also two cases when they are used in the
monitoring:

jurisdiction= KR, jurisdiction classification=KR_10PercentNoParticipation

jurisdiction=MX, jurisdiction classification=MX_10Percent

The main inputs used for transactions time frame in monitoring and reporting are:

SH_cntr_transRepTimeFrame: transactions reporting time frame; the possible options are specified in
the dimension: dim_reportingTimeFrame:

▪ SINCE_SPECIFIC_DATE
▪ SINCE_LAST_DISCLOSURE
RefMaxNumberOfTransDays: max number of transaction days: this input is used when there was no
previous disclosure or (there was previous disclosure and for the target jurisdiction is mentioned

option: SINCE_SPECIFIC_DATE in the control input: SH_cntr_transRepTimeFrame) and there are sections
at transactions level and there has to be mentioned for how many days has to be taken in consideration
the transactions prior to the target as of date. This reference input will have a default instance. In case
there is no record mentioned for the target jurisdiction - then 120 days will be the default max number of
transactions days to be used in the calculations.

Option "SINCE_LAST_DISCLOSURE” for the control input: "SH_cntr_transRepTimeFrame" will be applied

only if there was previous disclosure and it will take in consideration all transactions between previous
disclosure and current disclosure

3.8 Relation between security id, class of share and ISIN

For the same securityId there can be just one class of share and just one ISIN.

3.9 Reporting client static

Most of the reports need notifier details. The notifier details can be filled in the following optional
reference input: RefClientStatic

Proprietary and Confidential 24

 3.10 Optional jurisdiction specific reference inputs
Jurisdiction Optional Table Explanation

Korea (KR) SH_KR_RefIssuerIntentionToParticipate This reference input

contains the issuers for
which there is intention to
participate in the
management of the issuer.
By default - for GSD issuers
there is considered to be no
intention to participate.

Kazakhstan (KZ) SH_RefMCI (default instance will be

provided by the solution and
in case no record for the
target instance then MCI is
considered 1 in the
calculations): this reference
input contains the monthly
calculation index. By
default, it is equal to 1 but
if clients want to change,
they have this possibility by
using the current input.

Hong Kong (HK) RefGroupClientStatic This reference input

contains the exchange on
which parent entity is listed

Proprietary and Confidential 25

 3.11 Instance keys and historical data sources
GSD solution provides the following default instance key: version with type VARCHAR.

For a target “as of date”, there can be different runs. In order to keep the history of all runs every time
when it will be a new run this will be performed under different version.

In GSD there is frequent need of working with historical data in order to identify the threshold reason
(Initial, Subsequent, Exit or No Change). From this reason each time when it is needed to be picked up
the historical data for the target as of date it is important to know, in case there is more than one version
on the target as of date, which version will be taken in consideration for further calculations.

Each client can have its own logic to derive the “eligible” version for historical calculations like “max”
version or latest run version.

GSD default solution to find the eligible version considers the latest run version approach but clients can
override this logic.

Example:

Project: SD_SH_PositionMonitoring:

Aggregation[ThresholdChange] can have for same as of date - different instances under different versions

Workflow Load_ThresholdChange_History and data source: ThresholdChange_History with storage type:

CONTINOUS_PARTITION, no instance key, loaded from table associated to the
aggregation[ThresholdChange], expression from Loaded Parameters is: asof_date=@EXEC_DATE AND
version=@versionVar

Mirror external data source across all instances for threshold change: data source:
DisclosureHistory_Mirror; primary key of this table is: monitoring id + as of date. Version is not part as
primary key because for same as of date and monitoring id there will be just one eligible version.

3.12 How to configure flags related to share in nature scope

In the reference project there is a control table that specifies the rules for share nature in scope, e.g:
Project: SD_SH_Reference, data source: SH_cntr_shareNatureInScope that mentions if the suspending
shares, delisted shares and limited voting rights are in scope or not.

If the SH_cntr_shareNatureInScope.suspendedShareInd='IN_SCOPE' then both types of shares:

suspended and not suspended will be included in the numerator, in this case
SecurityListingData.suspendedShareInd can be set either to empty, N or Y.

If the SH_cntr_shareNatureInScope.suspendedShareInd='OUT_OF_SCOPE' then suspended shares will

not be in the numerator. So if the positions have to be included in the numerator then the
SecurityListingData.suspendedShareInd is set either to empty or N. If the positions have to be excluded
from the numerator then the securityListingData.suspendedShareInd has to be set to Y.

Same logic will be applied for delisted shares (SecurityListingData.delistedShareInd) and limited voting
rights (SecurityData.limitedVotingRightsInd)

Proprietary and Confidential 26

SH_cntr_delistedSecurityOverride logic rules:

1. Possible values allowed for RefSecurityListingData.delistedShareInd are: Y, N or empty string

2. RefSecurityListingData.delistedShareInd=’’ is treated as ‘N’ in the further calculations
3. If security does not have any related security listing data then delistedShareInd is considered to be ‘N’
4. If target jurisdiction position's security has related more than one security listing record with different
values for delistedShareInd field then when deciding what is the final delistedShareInd will be considered
minimum value, e.g if for the same security there are connected 3 security listing data records: record1
with delistedShareInd=’Y’, record2 with delistedShareInd=’N’ and record3 with delistedShareInd=’’ then
for final delistedShareInd for the particular jurisdiction and position’s delistedShareInd is considered the
minimum and in this case it is ‘N’, because empty string is defaulted to ‘N’ in the further calculations
5. Point 4 delistedShareInd field value will be overridden with below logic only if all the following
conditions are accomplished:
a. Position is tagged under jurisdiction that
has SH_cntr_delistedSecurityOverride.delistedSecExclInd='N';
b. Position security related issuer has more than one security ;
c. Position security related issuer has across all related security listing data records (irrespective of
jurisdiction) - at least one record with: RefSecurityListingData.delistedShareInd='N' or '';
d. Position’s delistedShareInd is ‘Y’ .

Rules regarding suspendedShareInd logic:

1. Possible values allowed for RefSecurityListingData.suspendedShareInd are: Y, N or empty string

2. RefSecurityListingData.suspendedShareInd=’’ is treated as ‘N’ in the further calculations
3. If security does not have any related security listing data then suspendedShareInd is considered to be
‘N’
4. If target jurisdiction position's security has related more than one security listing record with different
values for suspendedShareInd field then when deciding what is the final suspendedShareInd will be
considered minimum value, e.g if for the same security there are connected 3 security listing
data records: record1 with suspendedShareInd=’Y’, record2 with suspendedShareInd=’N’ and record3
with suspendedShareInd=’’ then for final suspendedShareInd for the particular jurisdiction and position is
considered the minimum and in this case it is ‘N’, because empty string is defaulted to ‘N’ in the further
calculations

Note: If aggregation ConsolidatedJurisdictionAndRegimeSplit from SD_SH_CalcEngine is used by any

custom reports please note that the following fields: delistedShareInd from 4_0_0 has been renamed
into notDelistedShareInd under 4_1_0 and suspendedShareInd from 4_0_0 has been renamed

Proprietary and Confidential 27

into notSuspendedInd under 4_1_0 and if these fields used in any custom report then logic needs to be
adjusted in the following way:

Custom object.delistedSharedInd if mapped to:

ConsolidatedJurisdictionAndRegimeSplit. delistedSharedInd then mapping logic should be changed in
the following way: If ConsolidatedJurisdictionAndRegimeSplit. delistedSharedInd=’Y’ THEN ‘N’ ELSE ‘Y’

Custom object.suspendedSharedInd if mapped to:

ConsolidatedJurisdictionAndRegimeSplit. suspendedSharedInd then mapping logic should be changed
in the following way: If ConsolidatedJurisdictionAndRegimeSplit. suspendedSharedInd=’Y’ THEN ‘N’
ELSE ‘Y’

3.13 Beneficiary trigger

It is handled by the following cntr tables:

▪ SH_cntr_beneficiaryTrigger
▪ SH_cntr_beneficiaryTriggerClient

Beneficiary trigger configuration rules:

▪ For jurisdiction classifications with dual trigger and with beneficiary trigger configured using
SH_cntr_beneficiaryTrigger, it will still be mandatory to populate:
SH_cntr_jurisdictionAggregationType
▪ SH_cntr_beneficiaryTrigger is optional cntr table and its purpose is to specify trigger at a more
detailed level as: beneficial ownership type
▪ SH_cntr_beneficiaryTrigger can be populated only for jurisdiction classifications that have dual
trigger defined in SH_cntr_monitoringTrigger. Dual triggers can be either
“SHARES_OR_VOTING_RIGHTS” or “NOMINAL_OR_VOTING_RIGHTS”.
▪ Possible options selected for SH_cntr_beneficiaryTrigger.benOwnerType must be in sync with
aggregation type defined in SH_cntr_jurisdictionAggregationType for target jurisdiction
classification.
⬧ For example for NL jurisdiction classifications configured aggregation type is:
“VOTING_OR_MANAGING_POWER” so in SH_cntr_beneficiaryTrigger cannot be added
configuration for NL jurisdiction classifications and beneficial ownership type: “LEGAL_TITLE”.

3.14 Sub-statuses

Monitoring logic is kept in SH_cntr_monitoringLogic.

In this table we have field named: additionalDisclosableEventsId that gives us additional disclosable
events and sub-events that can be monitored on top of global ones as: Initial, Subsequent, Exit.

Possible values for additional disclosable events can be found in the following
dimension: SH_dim_additionalDisclosableEvents

Proprietary and Confidential 28

One of the additional disclosable events is to monitor in detail change in holding.

This logic is translated in position monitoring in field named: threshold sub status.

It is accessible in SD_SH_PositionMonitoring and SD_SH_ReportAllocation projects objects

as: GlobalThresholdChange, ThresholdChange, ReportingThresholdChange etc.

Sub status can have options described in dim_thresholdSubStatus:

▪ Following options are available when disclosable event id is chosen to monitor change in holding:

⬧ ChangeInBoth: previous run exists and both numerator and denominator changed between
current and previous run
⬧ ChangeInDenominator: previous run exists, numerator did not change but denominator
changed between current and previous run
⬧ ChangeInHolding: previous run exists, denominator did not change but numerator changed
between current and previous run
⬧ NoChange: previous run exists and both numerator and denominator did not change
⬧ NoPrevRun: meaning no previous run exists on the target monitoring properties
▪ Following options is available when disclosable event id is chosen not to monitor change
in holding:
⬧ NA: Sub status not relevant

Note: this substatus is monitored as part of all statuses

Substatus will impact the business scenarios if it is configured in SH_cntr_disclosureTimeFrame.

For substatus field in the cntr table mentioned above there can be two types of configurations:

▪ N_A: meaning all substatuses are taken in consideration

▪ Only certain sub-statuses and in that case means that all the other possible sub statuses for that
combination of fields is not a reportable event; e.g: CA, MY

3.15 Collateral logic

Security Interest considers only voting rights holdings in the numerator for FR dual trigger and position
types defined as part of the SH_cntr_collateralLogic.

Exclusion reasons specific to collateral logic:

▪ SH_CalcEngine_052 Position does not have disclosable rule and share nature is out of scope and it
is exempted based on the collateral logic
▪ SH_CalcEngine_053 Position is not disclosable based on the rules and share nature is out of scope
and it is exempted based on the collateral logic
▪ SH_CalcEngine_054 Share nature is out of scope and position is exempted based on the collateral
logic
▪ SH_CalcEngine_055 Position does not have disclosable rules and capacity type is exempted and
share nature is out of scope and it is exempted based on the collateral logic
▪ SH_CalcEngine_056 Position is not disclosable based on the rules and capacity type is exempted
and share nature is out of scope and it is exempted based on the collateral logic
▪ SH_CalcEngine_057 Capacity type is exempted and share nature is out of scope and it is exempted
based on the collateral logic

Proprietary and Confidential 29

 ▪ SH_CalcEngine_058 Position does not have disclosable rule and it is exempted based on the
collateral logic
▪ SH_CalcEngine_059 Position is not disclosable based on the rules and it is exempted based on the
collateral logic
▪ SH_CalcEngine_060 Position does not have disclosable rule and capacity type is exempted and it is
exempted based on the collateral logic
▪ SH_CalcEngine_061 Position is not disclosable based on the rules and capacity type is exempted
and it is exempted based on the collateral logic
▪ SH_CalcEngine_062 Capacity type is exempted and position is exempted based on the collateral
logic
▪ SH_CalcEngine_063 Position is exempted based on the collateral logic

3.16 JP Change In Nature Logic

▪ For each below product type, will be checked if the absolute value of the ((difference between
current numerator and previous numerator) divided by current denominator)*100) is higher or
equal to the movement percentage: 1%:
⬧ CONV_DEBT_SECURITY
⬧ EXCHANGEABLE
⬧ SUBSCRIPTION_RIGHTS
⬧ WARRANT
⬧ WARRANT_COVERED
▪ For the equity it is calculated difference of percentage holdings between day 2 and day 1 and the
absolute value of this difference must be higher or equal than zero.
▪ Signage of calculations from steps 1 and 2 must be different

3.17 ETF and Index Shares Check

Check for issuer exposure within the FR ETF and Index Checks should now be done on Shares.

ETF and index scenarios for shares check are:

▪ SH_dim_ETFScenario: 5 Shares in issue Scenario

▪ SH_dim_indexScenario: 5 Shares in issue Scenario

3.18 IN IGP List

SH_RefIGPList: The new input is needed to classify positions under jurisdiction regime: IN_IGPIssuers and
it has the following properties:

▪ securityId: VARCHAR(50): it does not allow NULL; primary key

▪ issuerId: VARCHAR(50): it allows NULL
▪ issuerName: VARCHAR(100): it allows NULL

Proprietary and Confidential 30

 Data Validations

4.1 Validations projects updates

Validations project contains global validations but also product type specific validations driven by the
configuration table (SD_[DisclosureType]_PreProcessing: config_prodTypeValidations.

4.2 Validations and Exclusions Reasons functionality

Validations and exclusion reasons are maintained in the following cntr table:
[DisclosureType]_cntr_exclusionReason.

Short Selling Process

5.1 Shares
Step 1: IN SCOPE HOLDINGS PER JURISDICTION

The short selling regulation requires investors with net short positions in shares to disclose if their
holdings breach specific thresholds.

In order to determine in-scope positions for each jurisdiction, tag the positions from the SecurityPosition
input table with Jurisdiction and Jurisdiction Classification, based on the conditions defined in the
shorthands.

Step 2: IN SCOPE BENEFICIAL OWNERSHIP TYPE PER JURISDICTION

Define which beneficial ownership type is to be used for monitoring, based on

JurisdictionAggregationType. The disclosure obligation applies to those entities, which hold the
managing power over the shares, as opposed to those entities holding voting power over the shares.

Step 3: POSITION ENRICHMENT

Enrich the positions based on the rules contained in the following control tables:

- Share nature in scope: this specifies whether suspended shares, delisted shares and shares with
limited voting rights should be included in the calculation of both the numerator and the
denominator.

- Share class in scope: determine whether treasury shares and/or unissued shares are included in
the calculation.

- Monitoring trigger: define whether the numerator is calculated on the total number of shares
held, or the nominal value of the shares.

Proprietary and Confidential 31

 - Share voting nature – if the monitoring trigger is defined as SHARES, we need to specify whether
this includes either voting shares only, non-voting shares only, or both voting and non-voting
shares.

- Disclosable position rules: these rules capture the combination of product and position types that
should be included in the calculation of the holdings, per jurisdiction and jurisdiction
classification.

- Convertibles logic: determine whether convertibles are included in the calculation, and
specify which conversion period to use.

- Denominator: define whether the denominator is calculated on security level or issuer

level. If calculation is on security level, the denominator will comprise of the
number/nominal value of outstanding shares per class of shares; if the calculation is on
issuer level, the denominator will comprise of the number/nominal value of outstanding
shares across all classes of shares in issue.

- Delta adjustment basis: positions through derivatives and other financial instruments
may need to be included on a delta-adjusted basis.
Step 4: ELIGIBLE POSITIONS PER JURISDICTION

Combine the steps above to determine eligible in-scope positions for each jurisdiction and jurisdiction
classification.

Step 5: MONITORING LEVEL

The eligible in-scope positions now need to be filtered by the appropriate monitoring level (whether on
org unit or group level). These positions will need to be rolled up through the monitoring entity hierarchy,
in order to determine the holdings for each org unit and/or group (if relevant).

Step 6: MARKET MAKER EXEMPTION

Perform the market maker exemption, if applicable, based on the monitoring entity, security ID and
capacity type, as defined in RefMarketMakerExemption. This exemption is relevant in cases where the
entity has applied for the Market Making exemption on specific financial instruments (not the entire scope
of activity.) To qualify for this exemption, entities must be a member of the market on which it is
conducting market-making activities, by dealing as principal in the financial instrument for which it notifies
the exemption.

Step 7: NETTING PROCESS

Apply the netting process, by determining the netting rules (NET_SHORT_POSITION). In order to
ascertain whether the holder has a net short position, we need to net long and short positions per issuer
by deducting short positions from long positions.

The netting ID then needs to be determined based on issuer/security level and monitoring trigger.

Net the positions by portfolio and netting identifier for group type = DISCRETIONARY_INVESTMENT. Net
the positions by entity and netting identifier for group type = CONTROLLED_UNDERTAKING.

Proprietary and Confidential 32

Step 8: MONITORING PROCESS

Determine the final eligible net short positions for monitoring. If the final position is net short, determine
whether a threshold has been breached by identifying the relevant threshold ID.

5.2 Sovereign Debt and Uncovered CDS

Pre-processing operations

1. Enrich the sovereign debt positions with details about the bond, issuer, issuer threshold,
jurisdiction and market.
2. Check if there are any ETF Unit positions, in order to create the breakdown of positions based on
the information contained in the Fund Components table.
3. Check if there are any highly correlated sovereign bonds in RefCorrelatedSovDebts, in order to
allocate the correlated positions to the issuer of the sovereign bond under consideration.
4. Check if there are any positions, other than those of the underlying sovereign bond, covered by a
sovereign CDS in RefCorrelatedSovCDSUnderlying, in order to allocate these positions under the
issuer of the sovereign CDS under consideration.

Calc Engine

5. Tag the positions with the corresponding jurisdiction and jurisdiction classification, based on the
issuer’s jurisdiction, product type and information from the correlated positions.

6. Determine which org unit from the position will be used for monitoring, based on the jurisdiction
aggregation type: in the case of short selling, this will be beneficial ownership type =
MANAGING_POWER.

7. Enrich the positions with the regulatory rules:

MonitoringTrigger – for sovereign debt and uncovered CDS, monitoring is based on the nominal
value of the sovereign positions held.
Disclosable Position Rules – used to capture the combination of product type and position types
to be included in the calculation of the numerator, per jurisdiction and jurisdiction classification.
Denominator Basis – determine whether the calculation is on class of shares or issuer level. In the
case of short selling, this is on issuer level. Delta Adjustment Basis – define the product types that
need to be calculated on a delta adjusted basis or modified duration basis.

8. Determine in-scope and eligible candidate positions.

9. Calculate the NVDAInEUR for Sovereign Bond positions, and/or the DeltaNominalValue for
derivatives and other financial instruments, based on the delta adjustment basis configuration
(from step 7 above).

10. Determine the eligible bond position for the eligible candidate positions.

11. For the candidate sovereign debt positions, net the positions using the bondID and baseBondID.
For correlated sovereign debt positions, consider only those with a resulting net long position.

12. Establish the denominator for the sovereign bond under consideration.

Proprietary and Confidential 33

 13. Determine the hierarchy of monitoring entities based on the monitoring level and entity
configuration, which will be used to perform the Authorised Primary Dealer (APD) exemption for
sovereign debt, as defined in RefMarketMakerExemption. The hierarchy is defined using
RefGroupsLogic, RefEntityHierarchy, and RefMonitoringEntityGroups.

14. Perform the APD exemption based on the entity, bondID, capacityType, and originalSecurityID (if
applicable), as defined in RefMarketMakerExemption.

15. Net the positions by portfolio and issuer in order to determine the eligible net positions. Only net
short positions will be taken into consideration.

16. Set the netBondPosition for the final eligible positions.

Position monitoring operations

17. Enrich the eligible positions with the monitoring rules (monitoring trigger, monitoring basis, and
monitoring scenario which determines the aggregation level required for the numerator
calculation) and the denominator.
18. Calculate the numerator based on the net bond position (from step 16 above).
19. Calculate the bond position holding percentage.
20. Enrich the numerator with the issuer threshold information and check whether there is a threshold
breach.
21. Identify the threshold change (Initial, Subsequent, Exit, or No Change).
22. Identify the disclosure time frame.

Global report allocation operations

23. Based on the set of eligible positions and threshold changes, identify the final list of reportable
positions which breach a threshold.
24. Enrich the list of reportable positions with additional information for the report, such as client
static details.

5.3 Monitoring frequency

Special monitoring regimes are configured in SS_cntr_monitoringFrequency, e.g: CA, SG and US.

For SS there is possibility to monitor also daily the jurisdiction classifications with special monitoring
frequency, but daily override monitoring will not be part of alerts dashboard and reporting. Because daily
override is intended to be used for client’s information only and not for regulatory compliance
obligations.

▪ If client wants to monitor special regimes (SS_cntr_monitoringFrequency) also daily without mixing
the special regimes with daily override then will take use of the existing override frequency table
and new override frequency by date table
▪ In RefMonitoringFrequencyOverride: there will be mentioned the jurisdiction classifications that will
be monitored also daily (frequency ind must be on Y). In case clients want to turn off the
daily override defined before then either they remove the target record(s) or they set the flag
frequency ind to N
▪ In RefMonitoringFrequencyOverrideByDate: there will be mentioned the jurisdiction classifications
and target dates that will be daily monitored (frequency ind must be on Y). In case clients want to
turn off the daily override defined before then either they remove the target record(s) or they set
the flag frequency ind to N
▪ If both inputs RefMonitoringFrequencyOverrideByDate and RefMonitoringFrequencyOverride are
configured for same jurisdiction classification then will consider a daily override (monitoring) in

Proprietary and Confidential 34

 case RefMonitoringFrequencyOverrideByDate.frequencyInd is set to Y for the target jurisdiction
classification and date (disregarding configuration for RefMonitoringFrequencyOverride)
or RefMonitoringFrequencyOverrideByDate not configured for the target as of date and jurisdiction
classification and RefMonitoringFrequencyOverride configured for the target jurisdiction
classification and frequencyInd flag set to “Y”
▪ If there is no record for any of these two tables or it is but frequency indicator is set to N then no
daily monitoring will take place
▪ Override daily regimes events can be seen from Details dashboard

5.4 Issuer thresholds

 SS_RefIssuerMonitoringThreshold: that will keep public and private issuer threshholds
▪ disclosureType: it should be set to SS
▪ jurisdiction: it is linked to dim_jurisdiction
▪ jurisdictionClassification: it is linked to dim_jurisdictionClassification; N_A is allowed for this field
▪ monitoringTrigger: it is linked to dim_thresholdTrigger
▪ relationWithLowerLevel: it is linked to dim_relationLowerLevel
▪ publicInd: it is linked to dim_booleanwoNA

 SS_RefIssuerMarketThreshold: that will keep issuer private market thresholds

▪ disclosureType: it should be set to SS
▪ jurisdiction: it is linked to dim_jurisdiction
▪ jurisdictionClassification: it is linked to dim_jurisdictionClassification; N_A is not allowed for this
field
▪ mktStatusScenario: it is linked to SS_dim_marketStatusScenario
 SS_RefIssuerPublicMarketThreshold: that will keep issuer public market thresholds

▪ disclosureType: it should be set to SS

▪ jurisdiction: it is linked to dim_jurisdiction
▪ jurisdictionClassification: it is linked to dim_jurisdictionClassification; N_A is not allowed for this
field
▪ : that will keep issuer position thresholds
▪ disclosureType: it should be set to SS
▪ jurisdiction: it is linked to dim_jurisdiction
▪ jurisdictionClassification: it is linked to dim_jurisdictionClassification; N_A is not allowed for this
field
▪ monitoringTrigger: it is linked to dim_thresholdTrigger
▪ relationWithLowerLevel: it is linked to dim_relationLowerLevel
▪ publicInd: it is linked to dim_booleanwoNA
 All reference inputs are optional but there is needed instance for underlying model in order to register
reference aggregation input for each run operational as of date
 For all the new reference inputs associated sample data sources is provided default empty instance
under as of date: 01-Jan-1970 and version=0

5.5 Sub statuses

For SS there is more simplified model since release 310 where there is monitored change in holding for
all events.

So, comparing with the other disclosure types here there is no option to choose not to monitor change in
holding. It will always be monitored.

Proprietary and Confidential 35

This logic is translated in position monitoring in field named: threshold sub status.

It is accessible in SD_SS_PositionMonitoring and SD_SS_ReportAllocation projects objects

as: GlobalThresholdChange, ThresholdChange, ReportingThresholdChange etc.

Sub status can have options described in SS_dim_thresholdSubStatus:

▪ ChangeInBoth: previous run exists and both numerator and denominator changed between current
and previous run
▪ ChangeInDenominator: previous run exists, numerator did not change but denominator changed
between current and previous run
▪ ChangeInHolding: previous run exists, denominator did not change but numerator changed
between current and previous run
▪ NoChange: previous run exists and both numerator and denominator did not change
▪ NoPrevRun: meaning no previous run exists on the target monitoring properties

Substatus will impact the business scenarios if it is configured in SS_cntr_disclosureTimeFrame.

For substatus field in the cntr table mentioned above there can be two types of configurations:

▪ N_A: meaning all substatuses are taken in consideration

▪ Only certain sub-statuses and in that case means that all the other possible sub statuses for that
combination of fields is not a reportable event
▪ In current rules we consider all sub statuses, but clients can change from cntr disclosure time frame
client

5.6 Capacity filter by group

SD_SS_Reference:

Specific exclusion reason:

▪ Dim_exclusionReason: added new exclusion reason: SS_CalcEngine_037: Capacity type is

exempted for the target jurisdiction classification and group type
▪ Cntr_exclusionReason all instances: added new exclusion reason: SS_CalcEngine_037: Capacity
type is exempted for the target jurisdiction classification and group type

Specific reference input:

▪ RefGroupTypeCapacityExemptions:
⬧ It is an optional reference input
⬧ It has default empty instance: 01-Jan-1970. By default all capacities (excepting those from
SS_cntr_capacityExemptions) are in scope for all the jurisdiction classifications and group types
⬧ It contains the list of capacities exempted by jurisdiction classifications and group type

Capacity exemption by jurisdiction classification and group type will be checked as part of calc engine
and it will be performed only for positions where it was identified a valid monitoring entity

Proprietary and Confidential 36

5.7 Market Maker Exemptions
Rules for market maker exemption are:

 ESMA jurisdictions are defined in the following cntr table: SS_cntr_ESMA_jurisdictions

 ESMA market maker exemptions are defined as part of the: SS_RefMarketMakerExemption and in this
case jurisdiction is not needed because same rules are applied for all ESMA jurisdictions
 In addition to this reference input, added new reference input; SS_RefNonEUMktMkrExempt that will
keep the market maker exemptions for the non ESMA jurisdictions; in this table exemptions will be
defined at jurisdiction level

SS_RefNonEUMktMkrExempt has the following attributes:

 Jurisdiction: VARCHAR(3); it does not allow NULL; primary key; applicable for both types of positions:
security positions and sovereign debt positions.
 Entity: VARCHAR(50); it does not allow NULL; primary key; applicable for both types of positions:
security positions and sovereign debt positions.
 SecurityId: VARCHAR(50); it does not allow NULL; primary key
▪ It is applicable only for security positions:
⬧ The only available option is securityId
⬧ It cannot be defaulted to empty string ''

▪ For the sovereign debt positions, it must be defaulted to empty string ''

 BondId: VARCHAR(50): it does not allow NULL; primary key

▪ It is applicable only for sovereign debt positions:

⬧ The only available option is bondId

⬧ It cannot be defaulted to empty string ''

▪ For the security positions, it must be defaulted to empty string ''

 CapacityType: VARCHAR(50): it does not allow NULL; primary key;

▪ Applicable for both types of positions: security positions and sovereign debt positions
▪ For security positions:
⬧ It allows N_A meaning it is applicable for all capacity types
⬧ It cannot be defaulted to empty string ''
⬧ The only available options are either: N_A (meaning applicable for all capacity types) or specific
capacity type
▪ For sovereign debt positions: the only available option is specific capacity type (it cannot be
defaulted to N_A or empty string '')
 OriginalSecurityId: VARCHAR(50): it does not allow NULL; primary key

▪ It is applicable only for sovereign debt positions where possible options are:
⬧ It allows N_A meaning it is applicable for all original securities id
⬧ It cannot be defaulted to empty string ''

Proprietary and Confidential 37

 Monitoring Frequency Configuration
By default, monitoring frequency is “daily” but there are also jurisdiction classifications that require
special monitoring frequency as: weekly, monthly, bimonthly, quarterly and yearly.

Special monitoring frequency regimes can be identified using the table below:

Disclosure Cntr input Comments

Type
SH_AIF No cntr frequency table There is no special regime. Monitoring is daily
SH SH_cntr_monitoringFrequency It contains all jurisdiction classifications with
special monitoring frequency
SS SS_cntr_monitoringFrequency It contains all jurisdiction classifications with
special monitoring frequency
TO No cntr frequency table There is no special regime. Monitoring is daily
13F No control table There is no daily monitoring.
For monitoring there is following
special monitoring frequency as:
• MONTHLY
• YEARLY
For reporting there is following special
monitoring frequency as:
• QUARTERLY
All the operational as of dates must be added
to RefMonitoringDate with the relevant
monitoring date type

All operational as of dates that will be run for jurisdiction classifications that have
special monitoring frequency must be configured in RefMonitoringDate.

How to configure RefMonitoringDate?

1. Identify the special monitoring regimes according to the cntr input mentioned above (note: for
the 13F there is not a corresponding cntr input and in order to know the special regimes please
consult above table)

2. Next, Monitoring Date configuration is required. All the fields are mandatory. None of these
fields should have “N_A” value.

3. If the same As of Date apply for end of the month, end of the quarter and end of the year then for
each special monitoring frequency there will be different records in this table RefMonitoringDate.
In this case there will be 3 records, e.g: 13F dates:

Proprietary and Confidential 38

 4. Monitoring Date Type column highlighted below should only have value from
the dim_monitoringDateType table.

5. You cannot have 2 records with the same properties (Disclosure Type + Jurisdiction + Monitoring
Date Type + End date) but different Starting date. This is because Start date is not relevant for
calculation.

The example below describes the case of a wrong configuration.

Proprietary and Confidential 39

Notes:

For SH there is possibility to monitor also daily the jurisdiction classifications

with special monitoring frequency, but daily override monitoring will not be part of alerts
dashboard and reporting. Because daily override is intended to be used for client’s information
only and not for regulatory compliance obligations.

▪ If client wants to monitor special regimes (SH_cntr_monitoringFrequency) also

daily without mixing the special regimes with daily override then will take use of the existing
override frequency table and new override frequency by date table
▪ In RefMonitoringFrequencyOverride: there will be mentioned the jurisdiction classifications that will
be monitored also daily (frequency ind must be on Y). In case clients want to turn off the daily
override defined before then either they remove the target record(s) or they set the flag
frequency ind to N
▪ In RefMonitoringFrequencyOverrideByDate: there will be mentioned the jurisdiction classifications
and target dates that will be daily monitored (frequency ind must be on Y). In case clients want to
turn off the daily override defined before then either they remove the target record(s) or they set
the flag frequency ind to N
▪ If both inputs RefMonitoringFrequencyOverrideByDate and RefMonitoringFrequencyOverride are
configured for same jurisdiction classification then will consider a daily override (monitoring) in
case RefMonitoringFrequencyOverrideByDate.frequencyInd is set to Y for the target jurisdiction
classification and date (disregarding configuration for RefMonitoringFrequencyOverride)
or RefMonitoringFrequencyOverrideByDate not configured for the target as of date and jurisdiction
classification and RefMonitoringFrequencyOverride configured for the target jurisdiction
classification and frequencyInd flag set to “Y”
▪ If there is no record for any of these two tables or it is but frequency indicator is set to N then no
daily monitoring will take place
▪ Override daily regimes events can be seen from Details dashboard

Dashboard input and configuration tables

In the global dashboard’s users will see the disclosable events. Each disclosable event can be assigned to
a target assignee user to deal with it.

The default assignee must be configured by jurisdiction in the following dashboard mandatory input:
RefStatusStatic

Proprietary and Confidential 40

Configuration for final status:

Final status is defined using following configuration data sources from SD_[DisclosureType]_Reference:

▪ [DisclosureType]_config_finalStatus
▪ [DisclosureType]_config_finalStatusClient

If configuration changed for the [DisclosureType]_config_finalStatusClient then to be re-un

GSD_CAB_[DisclosureType]_Permanent from SD_WebUI project, GSD CAB branch

Explanations:

1. Solution will always provide instance for [DisclosureType]_config_finalStatus data source where
the default final statuses are: Closed and Non Reportable
2. Solution will provide empty instance for [DisclosureType]_config_finalStatusClient data source.
This instance to be imported by new clients or clients that use default solution final status logic
3. If clients wants to override the default logic then client will copy the target dashboard status
records from instance of data source: [DisclosureType]_config_finalStatus into instance of data
source: [DisclosureType]_config_finalStatusClient and set flag: finalStatusInd as: Y if the target
status is a final status and N if the target status is not a final status, for example if clients wants to
consider "in_progress" as final status then they will add this record to the instance of
[DisclosureType]_config_finalStatusClient and set flag: finalStatusInd as Y; the other statuses do
not need to be added because they will be taken from solution default logic meaning instance of
data source [DisclosureType]_config_finalStatus
4. If clients migrate to new branch and they had override logic in prev branch then they will not
import default empty instance for [DisclosureType]_config_finalStatusClient and they will copy the
override instance from previous branch

Proprietary and Confidential 41

Non reportable status explanations:

Global dashboards offer possibility to mark a disclosable event as "non reportable".

Example of disclosable events: Initial, Subsequent, Exit etc.

"Non reportable" event means will not trigger a report and that will not affect the subsequent days
disclosures.

"Non reportable" is a final status.

"Non reportable" events can be accessed from historical dashboards and on confirmation date they
can be accessed also from Global dashboard (but after confirmation date - the only place where they
can be accessed will be the Historical dashboard).

Control tables instances adjustments framework

Regulation rules are maintained in the control tables instances. If clients want to override the solution
rules with their own rules, then GSD solution offers this possibility by allowing clients to change the
instances of the target client control tables.

Control data sources changes:

▪ On top of existing solution control data source, there has been added a new data source with
same name as target control table + “Client”, same fields as target control tables + fields
regarding adjustment from dashboard as: “latestUpdateTime”, “latestUpdateUser”,
“latestUpdateComments”
▪ Both data sources have storage type: SEGMENTED
▪ Instances for client override control tables should be in sync with the solution control tables
▪ Every time when we release a new instance for the solution control data source then will release
also an empty instance for the target override control data source that can be overridden by
client with the target changes
▪ What we can adjust in the override data source instance? All fields excepting primary key fields
▪ There have been added two data models:

⬧ One data model that joins control and override data sources based on the primary key fields
(DM1)
⬧ Other data model that joins override and control data sources based on the primary key fields
(DM2)
⬧ Instance to be picked up for each data source will be: EQUAL

▪ To unify the solution regulation rules and client rules there have been added control
aggregations
▪ What fields will be in this aggregation: Same fields as in underlying data source + an additional
flag to mark if that record is client adjusted or not + latestUpdateTime, latestUpdateUser,
latestUpdateComments
▪ Executing aggregation, we are expecting EQUAL instances for data models
▪ The control aggregations will not be executed every time when running the daily workflows. They
will be run every time when a new release is received or there are changes in control instances
from solution and/or client perspective.

Proprietary and Confidential 42

 ▪ The workflows that must be run every time when a new instance is created for control tables are:

⬧ [DisclosureType]_Cntr_ConsolidatedDMRegister: to register the control data model instances

⬧ [DisclosureType]_Cntr_ConsolidatedInputs: to execute the control aggregations for the target
as of date

▪ All modify models that had joins with control tables data sources have been changed now to
have joins with the control aggregations. In the joins will be picked up the latest instance of
aggregation.

Load Inputs Workflow

The consolidated data load workflows listed in the table below can be run in order to load all sample
reference and calc input instances in a single step.

Project name Workflow name

SD_SH_MonitoringWorkflow SH_Sample_ConsolidatedDataLoad

SD_SS_MonitoringWorkflow SS_Sample_ConsolidatedDataLoad

SD_TO_MonitoringWorkflow TO_Sample_ConsolidatedDataLoad

SD_SH_AIF_MonitoringWorkflow SH_AIF_Sample_ConsolidatedDataLoad

SD_13F_Workflow 13F_Sample_ConsolidatedDataLoad

To run the consolidated data load workflows, please perform the following steps:

1. Make sure the relevant input files are uploaded to the SD_DATA_LOAD_DIR
2. Access the variables tab in the consolidated data load workflow
3. Fill all the Variable Value fields with the relevant file name (including file extension), for the file
to be loaded
4. Run the workflow

Proprietary and Confidential 43

 Workflows Execution Sequence
For an end to end run, either the workflows need to be run individually, or the consolidated workflow
must be run.

10.1 Individual Workflows

Order of workflows execution:

Disclosure type: SH

Order Workflow As of date

1 1_SH_Cntr_ConsolidatedDMRegister Target cntr as of date from
available list of cntr instances
2 2_SH_Cntr_ConsolidatedInputs Target cntr as of date from
available list of cntr instances
3 3_SH_GlobalRun Target as of date
4 4_SH_ValidationsAndExclusionReasons Target as of date
5 5_SH_WebUIConsolidated Target as of date
6 6_SH_WebUIRulesSummary Target cntr as of date from
available list of cntr instances
7 7_SH_ExclusionsAnalysis Target as of date
7 7_SH_ValidationsAnalysis Target as of date

Proprietary and Confidential 44

If user wants just to validate the main inputs without running the global then following workflow can be
run:

SH_InputsValidations for the target as of date

Disclosure type: SS

Order Workflow As of date

1 1_SS_Cntr_ConsolidatedDMRegister Target cntr as of date from
available list of cntr instances
2 2_SS_Cntr_ConsolidatedInputs Target cntr as of date from
available list of cntr instances
3 3_SS_GlobalRun Target as of date
4 4_SS_ValidationsAndExclusionReasons Target as of date
5 5_SS_WebUIConsolidated Target as of date
6 6_SS_WebUIRulesSummary Target cntr as of date from
available list of cntr instances
7 7_SS_ExclusionsAnalysis Target as of date
7 7_SS_ValidationsAnalysis Target as of date

If user wants just to validate the main inputs without running the global then following workflow can be
run:

SS_InputsValidations for the target as of date

Disclosure type: TO

Order Workflow As of date

1 1_TO_Cntr_ConsolidatedDMRegister Target cntr as of date from
available list of cntr instances
2 2_TO_Cntr_ConsolidatedInputs Target cntr as of date from
available list of cntr instances
3 3_TO_GlobalRun Target as of date
4 4_TO_ValidationsAndExclusionReasons Target as of date
5 5_TO_WebUIConsolidated Target as of date
6 6_TO_WebUIRulesSummary Target cntr as of date from
available list of cntr instances
7 7_TO_ExclusionsAnalysis Target as of date
7 7_TO_ValidationsAnalysis Target as of date

Proprietary and Confidential 45

If user wants just to validate the main inputs without running the global then following workflow can be
run:

TO_InputsValidations for the target as of date

Disclosure type: 13F

Order Workflow As of date

1 1_13F_Cntr_ConsolidatedDMRegister Target cntr as of date from
available list of cntr
instances
2 2_13F_Cntr_ConsolidatedInputs Target cntr as of date from
available list of cntr
instances
3 3_13F_GlobalMonitoringRun Target as of date
4 4_13F_ValidationsAndExclusionReasons Target as of date

If user wants just to validate the main inputs without running the global then following workflow can be
run:

13F_InputsValidations for the target as of date

Disclosure type: SH_AIF

Order Workflow As of date

1 1_SH_AIF_Cntr_ConsolidatedDMRegister Target cntr as of date from
available list of cntr
instances
2 2_SH_AIF_Cntr_ConsolidatedInputs Target cntr as of date from
available list of cntr
instances
3 3_SH_AIF_GlobalRun Target as of date
4 4_SH_AIF_ValidationsAndExclusionReasons Target as of date
5 5_SH_AIF_WebUIConsolidated Target as of date
6 6_SH_AIF_ExclusionsAnalysis Target as of date
6 6_SH_AIF_ValidationsAnalysis Target as of date

If user wants just to validate the main inputs without running the global then following workflow can be
run:

SH_AIF_InputsValidations for the target as of date

Proprietary and Confidential 46

 10.2 Consolidated end-to-end Monitoring Workflow
Alternatively, the consolidated end-to-end workflows can be run for each Disclosure Type. The relevant
consolidated workflows for each disclosure type are listed below. Running these consolidated workflows
will have the same effect as running a set of individual workflows (outlined in the previous section).

Disclosure Type Workflow

SH 0_SH_ConsolidatedMonitoringAnalysis
SS 0_SS_ConsolidatedMonitoringAnalysis
TO 0_TO_ConsolidatedMonitoringAnalysis
13F 0_13F_ConsolidatedMonitoring
SH_AIF 0_SH_AIF_ConsolidatedMonitoringAnalysis

The AsOfDate and CntrAsOfDate values will need to be filled accordingly before the workflows are run.

Proprietary and Confidential 47