Skip to main content
Version: 17

AssociatedPartiesDueDiligenceValidation

🎯 Functional documentation​

Validation that checks whether the due diligence parameters of the configured associated parties have valid results. You can scope the validation with associatedPartyTypes and validate each due diligence parameter with its own parameterConfig entry.

Per parameter the following rules can be combined:

  • required — the parameter must be present and its result may not be UNDEFINED.
  • validResults — whitelist of allowed results.
  • invalidResults — blacklist of disallowed results.
  • manualAssessmentRequiredFor — new in V2: list of system results that require a manual assessment.

Mandatory manual assessment​

When the system result of a parameter matches one of the values in manualAssessmentRequiredFor (typically YES, e.g. a hit coming from a screening provider such as WorldCheck), the validation fails until a user records a manual result for that parameter — whatever its value. Confirming the hit (manual YES) and clearing it (manual NO) both count as an assessment; whether the dossier may then proceed remains governed by validResults/invalidResults.

Notes on the rule semantics:

  • Only the system result is evaluated as trigger: a value entered manually never demands a second assessment of itself.
  • A missing parameter or an UNDEFINED system result does not trigger this rule; use required to enforce screening completeness.
  • When a due diligence recalculation produces a changed system result, the platform clears the manual result (unless the user deliberately locked it), so the new result must be assessed again.

⚙️ Configuration​

  • Implementation class: AssociatedPartiesDueDiligenceValidationV2
  • Type: Dossier Status Transition validation
  • Required module: DUE_DILIGENCE
  • Error codes: provide a general errorCode on the settings or a specific errorCode per parameterConfig entry. Entries using manualAssessmentRequiredFor must define their own errorCode.

Error reporting​

Each failing parameter maps to its errorCode (the parameter-level one, falling back to the general one) and the UI shows the translation of that code (a product translation, or a white label translation with identifier FRONT_END.ERROR.BE.GENERAL.<errorCode>). Parameters failing with the same error code are reported as a single error. Entries using manualAssessmentRequiredFor must define their own errorCode, so each parameter requiring a manual assessment is reported as a distinguishable error. To report different codes for different rules of the same parameter (e.g. missing manual assessment vs an invalid result), split the rules over multiple parameterConfig entries.

Settings​

Settings Configuration

Examples