Skip to main content
Version: 19

front-office-associated-parties-cdd-check

title: FrontOfficeAssociatedPartiesCddCheck​

FrontOfficeAssociatedPartiesCddCheck

Business goal​

This action runs an automated customer due diligence (CDD) check on the parties of a dossier, so that PEP, sanction list and adverse media hits are detected without manual intervention. It is typically linked to a status transition (e.g. when the dossier is submitted) or to an event (e.g. dossier creation).

Behaviour​

  • The screening results land on the party. Each party's due diligence record is updated, so hits are visible on the party regardless of which dossier triggered the check.
  • The RBA configuration decides which due diligence parameters apply to each party, based on the party's subject type. A party without configured parameters is skipped silently.
  • A party with a valid, unexpired due diligence result is not re-screened. The regular due diligence validity rules apply.
  • Provider failures fail the action. When a provider could not deliver results for a party, an automation logging event is written for that party and the action ends in failure, so that a partially screened dossier does not progress as if complete. The failure is retried when at least one provider exception allows it, and reported according to the exceptions' own reporting flags.
  • Preconditions are checked per party. A party that does not meet the due diligence preconditions is logged as an automation event and fails the action.
  • The dossier's RBA rating is not touched by this action. Screening a party that is not an RBA subject of the dossier does not change the dossier's rating.

The action requires the DUE_DILIGENCE module.

FrontOfficeAssociatedPartiesCddCheckV2​

V2 lets the configuration decide which parties are screened. It has two modes, selected by the useRbaConfiguration setting.

useRbaConfigurationParties screened
true (default)The parties the RBA configuration marks as subjects of the dossier's risk score, exactly like V1. A V1 settings block copied onto V2 behaves identically.
falseThe parties matching associatedPartyFilter. The RBA parameter supplier is not consulted for the selection. When the filter is absent, every associated party of the dossier is screened.

In both modes the RBA configuration still resolves the due diligence parameters of each selected party; only the party selection differs.

When to choose V2 over V1​

Choose V2 when the parties you want screened are not (all) subjects of the RBA calculation. A typical case is a dossier type whose RBA configuration scores only the dossier itself: V1 then finds no party and succeeds without screening anything, while V2 with useRbaConfiguration: false and a filter on the client screens the client without touching how the dossier's risk score is calculated.

Stay on V1 (or on V2 with the default) when the RBA subjects are exactly the parties to screen.

Configuration​

  1. Add the action FrontOfficeAssociatedPartiesCddCheckV2 to a status transition or an event.
  2. Decide on the mode: leave useRbaConfiguration out (or set it to true) to screen the RBA subjects, or set it to false and describe the parties in associatedPartyFilter.
  3. Optionally scope the action to specific dossiers (type, service, lifecycle) with dossierFilter, see Dossier Filter.

The associated party filter​

associatedPartyFilter is the same filter used by other actions and validations. It combines:

  • associatedPartyTypes: which associations to include (client, owners, signatories, related parties, ...). Some associations accept an association-specific condition, e.g. on the owner type.
  • partyTypes (optional): restrict to individuals, companies, ...
  • partyFilter (optional): a condition on the party's data.

See Harmoney Associated Parties Data for the filter's structure.

note

associatedPartyFilter is only consulted when useRbaConfiguration is false. With useRbaConfiguration: true the filter is ignored.

Settings​

Settings Configuration

Examples