RBA (risk based approach)

Business goal

Risk Based Analysis of a Dossier, specific risk calculation to determine the risk of a dossier. The risk is expressed in a rating (for example: low / medium / high). Based on the risk, a conclusion can be made: the risk assessment (for example: approved / rejected).

Functional documentation

Prerequisites

Read Due diligence (step 1 in the diagram below), as the aggregated Due Diligence Results are used as input for the RBA aggregation. This page describes the 2nd step.

RBA Result

The RBA result describes the risk of a dossier. The following properties are available:

Property	Type	Notes
Rating	Enum	Categorizes the risk of a dossier. One of UNDEFINED, LOW, MEDIUM_LOW, MEDIUM, MEDIUM_HIGH, HIGH, VERY_HIGH, EXTREMELY_HIGH, NOT_ACCEPTABLE. Which of them apply is defined in the module settings.
Escalation	Boolean	If the risk is a above a certain level, a dossier has an escalated risk and can be treated differently. E.g. approval by a compliance officer is necessary. Only available when the subfeature escalation is enabled. See RBA escalation
System assessment	String	Categorizes what you want to do with the risk of the dossier. E.g. APPROVED / REJECTED. Only available when the sub-feature assessment is enabled. Calculated by the system.
Manual assessment	String	Same as system assessment. Can optionally be completed by a user.
Assessment	String	The eventual assessment is equal to the manual assessment when there is one, else it’s equal to the system assessment.
Total score	Integer	Score of the dossier: this is the sum of the scores of all parameter results. Only available when the RBA calculation is a score-based.
Sensitivity	String	Categorizes the sensitivity of a dossier. E.g. certain dossier services are more sensitive to shady activities than other. This sensitivity can be taking into account when calculating the score for a parameter. Only available when configured.
Parameter results	List	The source for the calculation of the RBA result. Parameter results are aggregated from all Due Diligence Subjects of the dossier.

info

The assessments are not a fixed set of values in the product. They come from the autocomplete lists you configure on the assessment fields (see RBA assessment configuration). The lists shipped by default are DEFAULT_RBA_ASSESSMENT (TO_INVESTIGATE, APPROVED, REJECTED) and DEFAULT_MANUAL_RBA_ASSESSMENT (APPROVED, REJECTED).

RBA calculation

RBA calculation depends on the Due Diligence results of the underlying entities of the dossier. See section below for a more detailed explanation of how the RBA calculation works: RBA calculation in detail

RBA escalation

If the risk is a above a certain level, a dossier has an escalated risk and can be treated differently. This is a feature that needs to be enabled through module settings & field definitions (see configuration).

The escalation value will become visible in the RBA card and will be shown in the dossier list as well.

info

The escalation feature is often used together with a validation that the dossier should follow a different process (e.g. not every user can approve the dossier). One of the generic validations can be used InvalidStatusTransition together with a dossier filter that filters on the escalation property.

RBA assessment

It’s possible to override the system assessment with a manual assessment. The manual assessment is stored together with its author, its timestamp and optional comments.

On every recalculation, the system decides whether that manual assessment is still trustworthy and should be kept. When it is cleared, the author, timestamp and comments are cleared with it. The trigger is configurable through assessment.clearManualAssessmentOn:

• DUE_DILIGENCE_CHANGE (default): clear whenever the raw input of any DD parameter changed. Even though the eventual RBA rating and even the RBA parameter results may be the same, the underlying risk might be different.
• RBA_RATING_INCREASE: clear only when the new rating is strictly higher than the previous one.
• NEVER: the manual assessment is authoritative and is always retained.

Functional example

For example, assume Individual X is flagged in a due diligence provider as PEP, because he is the mayor of some small city.

• Execute due diligence checks
  • DueDiligence provider result: PEP: YES
    • Save the raw result of the provider response
  • Aggregated DueDiligence result for Individual X: PEP: YES
• Calculate RBA
  • RBA parameter result: PEP: YES
  • RBA rating: HIGH
  • System assessment: REJECTED

Manual override:

• Manual assessment: APPROVED

Rescreening (with the default DUE_DILIGENCE_CHANGE trigger):

• Execute due diligence checks
  • Compare the raw result of the response with the previous response
    • There are no changes in the response
      • Nothing changed on the aggregated due diligence result
    • There are changes in the response
      • Changes on the aggregated due diligence result
• Calculate RBA
  • Compare the previous RBA input with the new RBA input
    • If nothing changed on the input:
      • Manual assessment is kept as-is
    • If something changed on the input:
      • Manual assessment is reset

Configuration

Settings

Settings Configuration

Enable RBA

• Enable the module RBA on the FSP Definition.
• Configure fields related to RBA in the field definition provider to be visible.

RBA calculation configuration

In the module settings, define:

• All used Due Diligence Parameters (see Configuration of DD parameters)

  {
    "rbaConfiguration": {
      "dueDiligenceParameterDefinitions": { ... }
    }
  }

• The list of possible RBA ratings (ℹ️ For escalation, see RBA escalation configuration)

  {
    "rbaConfiguration": {
      "ratings": [
        {
          "rating": "LOW",
          "upperBound": 9
        },
        {
          "rating": "MEDIUM",
          "lowerBound": 10,
          "upperBound": 19
        },
        {
          "rating": "HIGH",
          "lowerBound": 20
        }
      ]
    }
  }

  The bounds are validated, so make sure that:

  • the first rating is the only one without a lowerBound, and the last rating is the only one without an upperBound;
  • the upperBound of each rating is exactly one less than the lowerBound of the next one (no gaps, no overlap);
  • a configuration with a single rating has no bounds at all.

• How the calculation of the RBA works: parameter based vs scoring based

  • Parameter based calculation
  • Score based calculation

• Which RBA parameters apply for which subject (dossier, party): rbaParameterSupplier

  • If not provided, all configured DD parameters are taken into account for the associated parties defined in the FSP definition.

  • associatedPartyTypes: same as above, but using these associations instead of the ones on FSP definition ⚠️ DOSSIER is always included!

    {
      "rbaConfiguration": {
        "rbaParameterSupplier": {
          "associatedPartyTypes": ["CLIENT", "OWNER"]
        }
      }
    }

  • rbaParametersByType: define the parameters yourself for each association (allows different set of parameters based on the association)

    {
      "rbaConfiguration": {
        "rbaParameterSupplier": {
          "rbaParametersByType": {
            "DOSSIER": ["ESG"],
            "CLIENT": ["PEP","SANCTION_LIST"],
            "RESPONSIBLE": ["PEP"]
          }
        }
      }
    }

  • rbaParameterSupplierClass: implement the parameters in code, for more specific request not possible through configuration

    {
      "rbaConfiguration": {
        "rbaParameterSupplier": {
          "rbaParameterSupplierClass": "eu.myharmoney.customer.xxx.XxRbaParameterSupplier"
        }
      }
    }

Additional options inside rbaConfiguration:

• hideScores (default: false): hide the calculated scores in the UI.
• sensitivitySupplier: fully qualified class name of a DynamicSensitivitySupplier implementation that determines the sensitivity of a dossier. Required if you want to use sensitivityMultipliers in a score-based configuration.
• dueDiligenceMetadataSupplier: fully qualified class name of a DynamicDueDiligenceMetadataSupplier implementation that provides additional input data towards the due diligence providers.
• includeAllDueDiligenceResults (default: false)
  • If enabled, all parameters of all specified associated parties that are not UNDEFINED will be taken into account in the RBA calculation
  • Functional goal:
    • Let’s say you start with a default config: all parameters of all associated parties (here: client and UBO) are taken into account for RBA.
    • All data is required for the client, so you add a score for UNDEFINED on all params to make sure missing data is highlighted.
    • You might not have all data for the UBOs so some DD params will be UNDEFINED. That’s OK. The data is not really required.
    • You now get UNDEFINED on RBA because the data is missing on the UBOs. So you exclude some parameters for UBO.
    • Now you no longer get UNDEFINED, because the data is present.
    • The question: but what if the data IS present on the UBO. Wouldn’t it be good to use that too? If the answer is yes, set includeAllDueDiligenceResults: true.
  • Example 1:
    • RbaParameterSupplier: include PEP for CLIENT, but not for UBO
    • Data: client has PEP:NO, UBO has PEP:YES
    • RbaScoring: PEP:YES → 100
    • Result with includeAllDueDiligenceResults:false → PEP:0 (not interested in PEP of the UBO, so don’t use it)
    • Result with includeAllDueDiligenceResults:true → PEP:100 (we have a value for PEP for the UBO, so we want to take that into account)
  • Example 2 (undefined behavior):
    • RbaParameterSupplier: include PEP for CLIENT, but not for UBO
    • Data: client has PEP:NO, UBO has PEP:UNDEFINED
    • RbaScoring: PEP:YES → 100, PEP:UNDEFINED → 1000
    • Result with includeAllDueDiligenceResults:false → PEP:0 (not interested in PEP of the UBO, so don’t use it)
    • Result with includeAllDueDiligenceResults:true → PEP:0 (we don’t have a value for PEP for the UBO, so don’t use it)

Options next to rbaConfiguration:

• fullDueDiligenceTimeout (default: 120): the UI timeout, in seconds, when a full Due Diligence is executed in the context of an RBA calculation.
• rbaConfigurationClass: fully qualified class name of an RbaConfiguration implementation, for hard-coded complex configurations that cannot be expressed through rbaConfiguration. This is the legacy extension point — prefer the more specific rbaParameterSupplier, sensitivitySupplier and dueDiligenceMetadataSupplier settings above.

Parameter based calculation

• parameterConfig
  • Contains a map where the key is the DD parameter and the value is a list of DD results for which RBA is a hit ⚠️ Only 2 RBA ratings are supported and the highest one is considered as the hit

{
  "rbaConfiguration": {
    "basedOn": "PARAMETER",
    "parameterBasedConfiguration": {
      "parameterConfig": {
        "PEP": ["YES"],
        "SANCTION_LIST": ["MEDIUM","HIGH"]
      }
    }
  }
}

Score based calculation

• initialScore: Defines an initial score (default 0)
• parameterConfig
  • _XXX_.resultScores: defines the score for a due diligence result
    • ⚠️ The order of the scores is important for the aggregation (multiple parties with a result for the same parameter). Define them from lowest risk to highest risk!
  • _XXX_.sensitivityMultipliers: multiplies the score of this parameter depending on the sensitivity of the dossier. Requires rbaConfiguration.sensitivitySupplier to be configured, since the sensitivity itself is determined in code.
  • _XXX_.customRbaCalculationClass: override calculation using code

{
  "rbaConfiguration": {
    "basedOn": "SCORE",
    "scoreBasedConfiguration": {
      "initialScore": 0,
      "parameterConfig": [
        {
          "parameter": "INDUSTRY",
          "resultScores": [
            {
              "result": "MEDIUM",
              "score": 10
            },
            {
              "result": "HIGH",
              "score": 20
            },
            {
              "result": "UNDEFINED",
              "score": 1000
            }
          ]
        },
        {
          "parameter": "PREMIUM",
          "customRbaCalculationClass": "eu.myharmoney.app.bll.rba.PremiumRbaParameterConfiguration"
        }
      ]
    }
  }
}

RBA escalation configuration

• Module settings

  • escalation.enabled: Enables the escalation feature.

  • To set the value based on the RBA score/rating, add this to the configuration of the RBA ratings.

  • Example:

    {
      "escalation": {
        "enabled": true
      },
      "rbaConfiguration": {
        "ratings": [
          {
            "escalation": true,
            "lowerBound": 50,
            "rating": "VERY_HIGH"
          }
        ]
      }
    }

    ℹ️ The ratings entry above is an excerpt: it is the last rating of a complete list that still has to satisfy the bound rules described in RBA calculation configuration.

• Configure the field definitions to make the field visible

  • RbaDTO_.escalation: the field on the RBA card
  • DossierDTO_.escalation: added to the risk score when shown in a dossier list

RBA assessment configuration

• Configure the lists that contain the possible system & manual assessments.
  • ⚠️ When both system & manual are used, make sure the system assessment list contains ALL values of the manual assessment. The dossier list and the dossier filter show the eventual assessment (manual if present, else system) and use the system assessment list for their autocomplete, so a manual-only value would not be selectable there.
• Configure the field definitions to make the fields visible. FieldDefinitionsUtil.configureRbaFieldsVisibility( showEscalation, showComments, systemAssessmentsListIdentifier, manualAssessmentsListIdentifier, conditions...) does this in one call, and sets:
  • on the RBA card: RbaDTO_.escalation, RbaDTO_.comments, RbaDTO_.systemAssessment, RbaDTO_.manualAssessment, RbaDTO_.manualAssessmentBy and RbaDTO_.timeManualAssessment — the two assessment fields get the configured list as their autocomplete;
  • on the dossier list and on related dossiers: the rating and assessment columns of RbaResultDTO_;
  • on the dossier overview filter: FinancialSpDossierFilter_.rbaRatings, FinancialSpDossierFilter_.escalation and FinancialSpDossierFilter_.rbaAssessments.
• Add module settings when you want to calculate the system assessment automatically:
  • assessment property:
    • enabled: Enables the feature to automatically set the system assessment
    • clearManualAssessmentOn: Trigger that decides when the manual assessment (with author, timestamp and comments) is cleared on recalculation. One of:
      • DUE_DILIGENCE_CHANGE (default): clear whenever any DD parameter raw input changes.
      • RBA_RATING_INCREASE: clear only when the new rating is strictly higher than the previous one. Equal or lower ratings retain the manual assessment.
      • NEVER: the manual assessment is authoritative and is always retained.
    • Exactly one of the two mappings below. scoreBased can only be used together with a score-based calculation.
      • ratingBased: Mapping between the rating (key) and the system assessment (value)
      • scoreBased: A list of score ranges, each mapping to a system assessment. minScore is inclusive, maxScore is exclusive.

Example rating based:

{
  "assessment": {
    "enabled": true,
    "ratingBased": {
      "LOW": "APPROVED",
      "MEDIUM": "REJECTED",
      "HIGH": "REJECTED"
    },
    "clearManualAssessmentOn": "DUE_DILIGENCE_CHANGE"
  }
}

Example score based:

{
  "assessment": {
    "enabled": true,
    "scoreBased": [
      {
        "minScore": 0,
        "maxScore": 10,
        "systemAssessment": "APPROVED"
      },
      {
        "minScore": 10,
        "maxScore": 20,
        "systemAssessment": "REJECTED"
      }
    ],
    "clearManualAssessmentOn": "DUE_DILIGENCE_CHANGE"
  }
}

RBA calculation in detail

1. Calculate the sensitivity (optional)

Given the dossier, the sensitivity can be calculated. The sensitivity of a dossier can be used in a score-based calculation to multiply the score for a parameter (see point 3). The sensitivity is determined in code, by a DynamicSensitivitySupplier configured through rbaConfiguration.sensitivitySupplier. The product defines the constants WEAK, AVERAGE and SENSITIVE, but the value is a free-form string: whatever the supplier returns is matched against the keys of sensitivityMultipliers. An example:

DossierType	DossierService	→	Sensitivity
KYC	KYC		WEAK
INSURANCE	PENSION SAVING		AVERAGE
INSURANCE	IPT		SENSITIVE

2. Gather the input

All Due Diligence parameter results of these entities can be taken into account during the calculation:

• Dossier
• Associated parties of the dossier:
  • Client
    • Associated parties of the client:
      • UBOs (if the client is of type company)
      • Members (if the client if of type indivision or membership)
      • Related parties
  • Responsibles
  • Insured persons
  • Related parties
  • Beneficiaries

We do not allow using any other data, such as related parties of related parties.

Limiting the input

• It is possible to specify a different set of associated party types, e.g. you’re only interested in the responsibles and the related parties of the client, but not in the ubos.
• It is possible to limit the Due Diligence parameters of certain entities. For example:
  • For the responsibles: we take all available DD parameters into account
  • For the related parties: we only take a limited set of DD parameters into account
  • If there is a party field metadata X: we take this specific set of DD parameters into account

Required parameters

All the parameters that result from the definition above are considered required. There must be a parameter calculation configuration for each required parameter. The calculation will be applied even if there is no due diligence parameter result available or if the result is UNDEFINED.

Optional parameters

Due to the input limitation, certain due diligence parameter results are not taken into account. To exploit this data it is possible to configure RBA to take this data into account. The scoring of these additional parameters is as follows:

• If UNDEFINED: no result for the parameter
• Else: apply the defined scoring for the parameter (standard behavior).

For example

• There is a configuration for PEP, with mapping YES -> score:100; UNDEFINED -> score 1000
• PEP is a required parameter for CLIENT, but not for RESPONSIBLE

Assume there is PEP: true defined in the due diligence of the responsible and PEP: false for the client:

• When RBA is configured to ignore optional parameters: no score will be added for PEP: true of the responsible, even though we have the data
• When RBA is configured to include optional parameters: score of 100 will be added

When there is PEP: UNDEFINED for the responsible, no score will be added, because the parameter is not required.

3. Calculate the RBA parameter result for each parameter

A calculation is executed per due diligence parameter result per subject as defined above. Each due diligence parameter result is mapped to an RBA parameter result. Depending on the configuration, there might be no RBA parameter result, because we’re not interested. This is to make sure we only see things in the UI that are relevant.

Score-based

A score can be defined for one or more of the parameter results. Scores need to be integers (negative allowed). For example for the parameter INDUSTRY_RISK, we know from the Due Diligence configuration that the following results are possible:

• NONE
• UNDEFINED
• MEDIUM
• HIGH

We want to add a score for all results except NONE, so we define the following mapping:

Result	Score
MEDIUM	5
HIGH	10
UNDEFINED	1000

Since we did not include NONE, there will be no RBA parameter result for this entity and parameter.

Next to this basic score, it is also possible to apply a sensitivity multiplier based on the sensitivity of the dossier. This multiplier can be specified on parameter-level. For example:

Sensitivity	Multiplier
WEAK	1
AVERAGE	2
SENSITIVE	4

For example: INDUSTRY_RISK: HIGH for a dossier with AVERAGE sensitivity results in a score of 20.

Parameter based

Verify similar to score-based, but there is no score involved. The only required configuration is the set of results that need to be included per parameter. For example:

Parameter	Results to include
INDUSTRY_RISK	MEDIUM HIGH UNDEFINED
EU_COUNTRY	NO UNDEFINED

If a result is included in the config, it will lead to an RBA parameter result.

4. Aggregate the parameter results

In this step, we need to go from multiple RBA parameter results to a single result per parameter. For example if we have:

• INDUSTRY_RISK: MEDIUM
• INDUSTRY_RISK: HIGH
• INDUSTRY_RISK: UNDEFINED

In the parameter calculation configuration (see step 3), the results that are included are ordered from lowest to highest risk:

• If we configure MEDIUM < HIGH < UNDEFINED, the example above will be aggregated to UNDEFINED
• If we configure MEDIUM < UNDEFINED < HIGH, the example above will be aggregated to HIGH

5. Calculate the total score (optional)

Only applicable when the parameter calculation configurations are score-based.

The total score is the sum of all RBA parameter result scores as explained above. Since this sum is calculated after the aggregation, each parameter result score is only counted once in the RBA score.

E.g. in case the responsible is PEP (score 10) and the client is PEP (score 10) → score taken into account on dossier level will be 10

The starting value before calculating the sum can be configured. By default this value is 0.

6. Calculate the rating

Score-based

The rating is a readable classification of the score. For example:

• LOW if score < 10
• MEDIUM if score >= 10 and score < 20
• HIGH if score >= 20

Parameter-based

The rating is a readable classification of the final RBA parameter results. For example:

• LOW if there are no RBA parameter results
• MEDIUM if the RBA parameter results include COUNTRY_RISK or INDUSTRY_RISK
• HIGH if the RBA parameter results include COUNTRY_RISK and INDUSTRY_RISK

7. Calculate the escalation (optional)

The escalation can for example be used to:

• Restrict dossier status transitions to users with a certain role
• Automate dossier status transitions
• Send out an email for escalated dossiers
• …

The escalation of a dossier is derived from the rating, e.g. :

• escalated: true if rating = HIGH

8. Calculate the system assessment (optional)

The system assessment can be used in a similar way as escalation.

Score-based

The system assessment is derived from the total RBA score. A list of ranges needs to be defined, where the minimum score is inclusive and the maximum score is exclusive. For example:

• Score from 0 (inclusive) to 10 (exclusive) → system assessment = APPROVED
• Score from 10 (inclusive) to 20 (exclusive) → system assessment = REJECTED

Rating based

• Rating = LOW → system assessment = APPROVED
• Rating = HIGH → system assessment = REJECTED

Reopening of a dossier due to rescreening

Many FSPs have a rescreening in place. Rescreening itself is not part of the RBA module: a rescreening provider selects the dossiers and fires an automation event, and the actions configured on that event recalculate the RBA and perform the status transition. See Periodic screening for how to set that up.

What the RBA module contributes is the answer to the question did the input for the risk calculation change? — which is what decides whether a dossier has to be looked at again.

For explanatory purposes, we will discuss one commonly used configuration:

• Daily rescreening
• For dossiers in status DONE
• Bringing these dossiers to the status SUBMITTED in case of change in the RBA input.

The daily rescreening was implemented to make our users aware of any changes within the dossier with impact on the RBA. If there is a change in the dossier, we want to make our user aware of this by reopening the dossier in the status SUBMITTED. This way our users can reassess the dossier. In order for the system to know if there are any changes, it runs DD checks and calculates the RBA score.

The mechanism behind that comparison is the unchangedSince timestamp. When the raw response of a provider differs from the previous one, unchangedSince is updated on the DueDiligenceProviderResult, then on the aggregated DueDiligenceCheck, and finally on the RbaResult. If nothing changed, the timestamps stay as they are. This is the input that the DUE_DILIGENCE_CHANGE trigger compares to decide whether a manual assessment survives the recalculation.

General rule: change in input

In most use cases, the RBA matrix remains unchanged. This means the dossier will end up in SUBMITTED due to a change in the input/output from a provider e.g. the questionnaire, sector list, LexisNexis,...

The dossier will end up in submitted if there is a change in the input/output for a parameter whose system assessment is included in the RBA calculation.

Use case: change in input for included system assessment

• Provider = questionnaire
• DD parameter = Industry
• Included system assessments in the RBA calculation = weak, medium, high

warning

This means the dossier will also reopen if the input changes but the system assessment does not, as long as the system assessment is included in the RBA calculation.

Use case 2: change in input for not-included system assessment

• Provider = LexisNexis
• DD parameter = PEP
• Included system assessments in the RBA calculation = yes

Changes to the RBA matrix

Next to a change in provider data, a change to the RBA configuration itself can also change the input of the calculation, and therefore reopen dossiers. The use cases below show when that happens.

Use case: a parameter is added to the RBA calculation

Is considered a change of input. Reopening depends on the system assessment.

Use case: a party type is added to the RBA calculation

An FSP decided that the insured person (and all CDD parameters) should be included into the RBA calculation.

If the insured person = a party type in the dossier already included in the RBA calculation e.g. the client, there is no new input, so the dossiers are not reopened.

If the insured person is not = to a party type in the dossier already included in the RBA calculation e.g. the client, the input changes and the dossiers are reopened.

Use case: splitting up an existing parameter into two.

An FSP mapped both Sanction and Special Interest to the DD parameter Sanction. They wanted to split this up to be able to differentiate between both risks.

To avoid reopening of all dossiers, we added the DD parameter Special Interest, since this parameter had the highest chance of NO HIT. This new parameter would then lead to the flow below.

Use case: merging two existing parameters into one.

An FSP wanted one single country risk on dossier level. Initially, there were parameters nationality and address defined, which could lead to two HITS related to country on dossier level, which would increase the overall risk of the dossier.

One single DD parameter was created country risk which was fed by the same provider as nationality and address, being country list.

As there was a change in the input for the risk calculation, dossiers were expected to reopen.

Use case: changing the risk score of an assessment

An FSP wanted to increase the score related to the system assessment on two parameters.

These dossiers do reopen as the score is considered a change in the input for the RBA calculation.