Sub-Weighting - Inherent Risk Methodology

Please note that the below is referring to the Sub-Weighting Inherent Risk Methodology found within the KYCMATIC Solution.

The Risk Methodology Module found within KYCMATIC is where the subject person would configure all their Inherent Risks across the different Risk Factor Pillars which would be based on the subject person's Policies and Procedures for every KYCMATIC environment. 

This module is typically solely accessible by the MLRO's, therefore by users who are set within the MLRO Group Structure. 

Inherent Risk Methodology Configuration Summary

When accessing KYCMATIC for the first time, the first action that would need to be performed (by the MLRO or designated user), would be to accepct and/or change the default inherent risk methodology (the weightings and risk definition configurations) prior to allowing themselves or any other user to access other areas of the product. This process is to ensure that the MLRO/designated user has ensured to review, alter, and accept the inherent risk methodology. 

The 'Configuration Summary' status page therefore provides the user the ability to understand whethere:

• There are pending approvals in one or more areas of the methodology;

• There is a status implying that the risks had been altered (even beyond the first approval) and require the be recalculated (as shown in the above image - whereby the 'Recalculate Risks' button is required to be selected by the user);

• A view on which user had accepted the status and the date and time of the acceptance. 

Risk Definitions - Metric Ranges

The 'Metric Ranges' is the first step in configuring the highest level configuration of your Inherent Risk Methodology. Here the MLRO would be able to define the:

• Risk Definition levels - therefore deciding on which risk levels are to be used - whether the default 6 levels, or less;

• The given asociated score (whole number) per risk definition level - which would typically match with the Obliged Entities Policies & Procedures;

• Given range per risk factor pillar. The range would define the 'bracket' of the final Customer Risk Score of the customer. Depending on the final computation of the methodology (between 0 - 10), based on where the score lands across the different available risk definitions, the final customer score is provided.

In the instance that the MLRO would deactivate a risk level, such as deactivating the 'Medium-Low' risk level above, KYCMATIC would need to replace all values within the Inherent Risk Methodology that would be set to 'Medium-Low' to another risk level. KYCMATIC would thereofore ask the MLRO to select the fallback risk level (the new risk level the Medium-Low should become) coupled with the rational to why this risk level would be deactivated. 

In doing so, the 'Associated Score' and 'Range From' / 'Range To' would need to be rectified to handle the change performed by the MLRO.

Overall Weighting & Sub-Weighting

As the Metric Ranges have been setup, therefore defining the Risk Definition levels, the next step would be configure the Overall Weighting % acorss the 4 risk factor pillars, as well as the individual sub-weighting parameters, reflecting the Obliged Entities Policies & Procedures. 

Initially, the overall weighitng per risk factor pillar is configured, ensuring that the total % amount adds up to 100%. Here, the MLRO would typically add more weighitng (therefore increase the %) on the risk factor pillar that concerns them most, where they would want to provide more weighting on. For example, the image above, we see that 50% of the overall weighting is contributing to the customer risk facotr pillar alone. The remaining 50% is then divided acorss the other 3 risk factor pillars. This implies that most of the weighting and risk contribution would emanate from the information found within the Customer risk factor pillar.

As the MLRO would configure the overall weighting per risk factor pillar, the MLRO would then, for every risk factor pillar, configure the sub-weighting based on their Policies & Procedures by selecting the risk factor pillar, exposing a list of data touch points. In doing so, the MLRO would be able to specify what weighting every data touch points should be set at, being able to give some parameters which are of greater interest a higher weighitng, compared to other data touch points which may not be of interest nor even required, thus setting them to 0%. 

As the sub-weighting parameters are set, the MLRO must ensure that the overall % adds up to 100% for every Risk Factor Pillar. 

Involvement Type Weighting

As part of the dillution of the Customer Risk score, is the risk score associated with the invovlements. From the 'Involvement Types' page, the MLRO would be able to configure the weighting % that would be taken from the involvements risk. This is then further diluted within the individual risk factor pillar whereby the invovlement sub-weighting parameter would be set, as shown in the example image in the sub-weighting section above. 

For example; Assuming the involvement is a UBO, 70% of the UBO's risk would taken. Then, for every risk factor pillar, the sub-weighting % associated with the 'Involvements' parameter, such as 10% (therefore taking 10% of the 70%) would be the ultimate contribution to the main client for that specific risk factor pillar. 

This therefore gives the MLRO the flexibility to have different weightings for the involvements across the different risk factor pillars.

Inherent Risk Methodology Per Risk Factor Pillar

The final four sub menu items featuring as part of the Risk Methdology module refer to the configuraiton of the inherent risk methodology across the different risk factor pillars. Above, we have and example extract of a list of the Source of Funds found within the 'General' section under the 'Customer' Risk Factor Pillar. 

For every value, the MLRO would be able to alter the risk of the value, take note of the rational to why the risk is being altered as well as state whether this would be an exception, whilst keeping a full audit history as shown in the extract below. This same functionality shall feature similarly in all risk factor pillars, with the exception of the Geography Risk Factor Pillar. 

Marking a Value as An Exception

As explained in the previous section, a value may be marked as an 'Exception'. in summary, an exception would bypass all overall and sub-weightings, placing the customer risk score to the given level of the value. 

For example, the above extract depicts the KYC checks which would be used in conjunction with the screening of an entity. All values, if 'Yes', are marked as an exception, implying that irrelevant of the weightings, mark this entity as a 'High', or 'Critical'. 

The exception would also work across the board with other values such as the SoF, industry, etc, and would go to the desired risk level, even if 'Medium'. This would only be superseded provided that there is a higher risk being taken into consideration, therefore overriding the exception - always taking the highest available risk. 

Geography Risk Factor Pillar

The Geography risk factor pillar functions differnelty to the others since the default 'KYCMATIC Jurisdiction Risk' is static and cannot be changed by Obliged Entities. By default, the risk shown in this section would be used whenever a jursidiction is utilised for any of the Geography data touch points such as residence, country of birth, etc. This list is typically updated by Diligex every quarter unless there is an update directly from the FATF or similar, thus invoking the prodcut team to update the list sooner, based on Diligex's AML Jurisdiction Methodology. 

In the scenario whereby the MLRO would want to maintain their own Jursidciton risks for a few or all countries, the MLRO would need to create and maintain the list of countries within the 'My Jursidiction Risk' tab as seen in the extract below. 

Here, the MLRO would be able to add a Jurisidction by selecting the 'Add Jursidiction' button which would enable the MLRO to set their own risk level for the specific country, whilst also adding their rational to why. Furthermore, the country may be set to an Exception also. Thus, if countries found within the 'My Jurisdiction Risk' tab would be used throughout an entities profile, the associated risk would not be taken from the default Jurisdiction list, but from this list. 

Diligex may therefore change the risk whenever required, yet the risks associated to the countries in this tab would not be affected. 

Product & Services Risk Factor Pillar

The Products & Services Risk factor pillar, albeit working similarly to the rest, have a few differencies since these would need to be adaptable/configured based on the Obliged Entities appetite/process. 

Activity Type

The 'Activity Type' would be set up for your tentnat by Diligex, depending on the products/services the obliged entity would provide to their clients. The risk level coupled with the rational would also be required to instantly place these directly within the methodology. The MLRO would then be able to maintain the risks and rational from then on. 

This same process shall also apply for the 'Payment Methods'

Transaction Values

The 'Transaction Values' are set up and maintained directly by the MLRO, enabling the user to set up the different brackets of values which the obliged entity may consider as low, medium, etc. Therefore, selecting a tranaction range record shall present the user a similar screen as shown below, enabling them to adjust the risk, adjust the range as well as set it, if required, as an exception. 

Inherent Risk Methodology Report