Related Party Adapted Experience

The Related Party Adapted Experience helps streamline the sometimes complex process of related party management. The existing task incorporates multiple aspects of this process, such as building the hierarchy, data and document capture and ID&V evaluation, which can become challenging with larger hierarchies. The Related Party Adapted Experience separates the building of the hierarchy and the additional data and document capture into distinct functions with the introduction of the Related Party Data & Documents task. This user guide covers the functionality which is applicable to and introduced by this task.

Related Parties Data & Documents Task

The Related Party Data & Documents task is designed to work in conjunction with the existing Related Parties task and must be configured in a journey with this task. The Related Party Data & Documents task cannot be used in isolation. The building of the hierarchy will occur via unwrapping in the Related Parties task, where the data capture can be kept as simple as possible when creating the structure. The Related Party Data & Documents task will perform that additional data and document capture that is required for certain entities within the hierarchy (traditionally controlled by the ID&V functionality with the Related Parties task).

The pre-configured Related Parties task displays all previously verified relationships and any new relationships created during the journey in a structured format. Users can manage the hierarchy from within this task. Please see the Related Party Management user guide for additional detail.

The Related Party Data & Documents task will take a selection of related parties from that hierarchy, verified or new, and present them to the user in a grid for additional requirement capture. A rule that is pre-set on the task during configuration will automate the selection of the sub-set of those related parties from the hierarchy rather than the user having to manually select each related party from within the hierarchy.

Related Parties Table

When the Related Party Data & Documents task has been triggered within an active journey, the selected related parties will be presented in a table. As part of the pre-processing of the task, Data & Document compliance will be applied, along with Document Persistence if configured, meaning at first glance users can determine the status of each related party's data and document compliance.

The table displays:

• An icon to distinguish an Individual from a Company or Other entity type
• The entity name - This is retrieved from the field with datakey "legalEntityName"
• Status - The current data and document compliance based on mandatory requirement. This will be 'In Progress' or 'Complete'
• Outstanding Actions - This will display if both data and document collection, or if either data or document collection is required to be compliant (that is a stats of 'In Progress'), or '-' when the Status is 'Complete'
• Relationship - Displays the relationship type of the related party entity. If an entity has multiple types of relationships, all relationships will be listed here, and if the relationship is not a direct relationship of the entity in journey, then the level within the hierarchy will be displayed for that association, e.g. "Director of Level 1 'X'" entity. These means a related party would only be listed once should they exist multiple times within the hierarchy.
• The bulk action to the left of the table row allows for the selection of more than one entity.

The row above the table provides the ability to Search and Filter those related parties in scope within the task. The Filter contains three options to filter by and can be selected individually or combined via the Filter icon:

• Type - Entity type
• Status - In Progress/Complete
• Relationship - list based on those relationship types for the entities displayed

Related Party Data & Documents

Selecting the entity name of a related party from a row in the table allow the user to view and capture the additional requirements triggered based on the configuration of the task, and will open a panel to the right of the window. The View panel will display the related party name, their relationship(s) and underneath the information will be broken down into the following sections:

• Details - This will display data requirements triggered from policy based on the categories configured in the task
• Data Groups - One of more data groups will display based on the data requirements triggered from policy and on the categories configured in the task
• Document Requirements - This will display document requirements triggered from policy based on the categories configured in the task

Each section will have a status icon to reflect whether all mandatory requirements have been met, which will display the green 'Complete' icon, or whether there are requirements outstanding, which will display the blue 'In Progress' icon. Underneath each section is the count of mandatory requirements and how many of those have been satisfied, e.g. "1 of 4 Details Completed". This gives the user a quick glance of what's outstanding for that related party.

The View panel can be expanded via the icon in the top right to allow for additional real estate on screen when the user is capturing detail for the selected related party. The panel will contain a vertical scroll depending on the panel and screen size.

When a user selects one of the above options in the View panel, the detail will update to reflect the selection. As the user populates and saves any mandatory requirements, on returning to the View panel the count will re-evaluate to reflect any changes, and the 'Status' and 'Outstanding Actions' will also update if applicable.

In an important change from the modal within the Related Parties task, the categories used to display data and document requirements with the panel of the Related Party Data & Documents task is no longer restricted to the 'Related Party Basic Details', 'Related Party ID&V' and 'Relationship Details' categories. This task allows for the selection of any category with a Target Entity of 'Related Party' to be used for requirement capture, which provides more flexibility and structure for the gathering of that information. For context, the 'Details' tab will always display the 'Related Party Basic Details' and 'Relationship Details' categories in position 1 and 2 of the panel and these do not need to be specified in the task configuration. Any additional categories will display below these two, in either alphabetical or the order specified.

Please note that the 'Relationship Details' category will be read only as any changes to the association details should be handled in the Related Parties task, where the hierarchy is managed. The Related Party Data & Documents task focus is on the entity data of the in scope related parties. Should the related party exist multiple times in the hierarchy, all relationship types will be listed and the association metadata from the lowest level association will display.

The Data Group requirements triggered will be listed in the View panel and the panel will update to reflect the data group selected.

When the Document Requirements option is selected in the View panel, the panel will reflect those requirements triggered. The Documents V2 component has been introduced to this task, ensuring a streamlined process throughout a journey for data collection. Aligning to the Document V2 functionality, users can use the line icons to upload a document or a virtual document, and waive or defer document requirements, or indeed drag and drop documents to the requirement line. The Document V2 modal will load providing the document categorisation capabilities of this version. Each document requirement row will also be expandable to access the 'Acceptable', 'Matching' and 'Linked' options available in the Documents v2 task. Please see Document Management V2 guide for additional information.

As mentioned, Document Persistence will be checked when this task is triggered in a journey to allow previously uploaded documents to satisfy triggered document requirements where the criteria have been met. A change to document persistence has been made within this task so that document persistence will apply to all related parties in scope within the task. This means that any related party, be it a verified association or a newly added association, will have document persistence applied to satisfy requirements.

Related Party ID&V validation

When the Related Party Data & Documents task has been triggered within an active journey, where ID&V validation rules have been configured then those rules in-scope will be displayed in the ‘Minimum Data and Document Completion’ table to the right of the related parties table. This panel will be overlayed by the ‘Details’ panel when a related party is selected from the related party table.

Each triggered validation will have a status icon which will reflect whether the requirement has been met or not, this will be indicated by the green ‘Complete’ icon when the requirement is met, or by a white circle icon when the requirement is outstanding.

The ID&V validations configured on ownership and control requirements in policy will be used in this task, however there are some key differences to their application:

• As with the existing task, the validations will apply only when the ‘Enable ID&V’ toggle is enabled during configuration.

• As this task is focusing on ID&V only, the new ‘Minimum Data and Document Completion’ panel will only display validations that are mandatory, this is a change to how validations were presented in the related parties task.

  o Note: Mandatory toggle must be used in conjunction with the minimum count or ID&V all toggles.

• The minimum count will apply where configured.

• There has been a change the ‘ID&V All’ functionality within this task. When enabled this will no longer be an attestation for the user and instead will mean when all relationships of that type must now have their data and documents complete before the requirement will be met. Ie. User adds 4 shareholders to their hierarchy and the system displays the validation , ‘ID&V all shareholders’, previously a user could select the ‘ID&V All’ toggle and progress but now the user will be forced to complete all data and documents on each shareholder before progressing.

  o Note: Given this change enabling the 'ID&V all' and minimum count toggles for a requirement would not be required, as would result in two validations to be met.

• As with the existing 'Related Parties' task, the following Ownership & Control Requirement settings will apply to the ID&V validations within this task.

Example: If an Unwrapping rule exposes a minimum of 2 Directors, set the ID&V minimum for Directors to 2 as well.

• Don’t set ID&V higher than Unwrapping. ID&V should follow Unwrapping-ensure ID&V minimums never exceed the corresponding Unwrapping minimums so the hierarchy surfaces enough entities to satisfy ID&V.

Uploading a Document Against Multiple Related Parties

In the Related Party Data & Documents task, there are cases where a single document applies to multiple Related Parties. Rather than uploading the same document multiple times, Fenergo allows users to upload it once and have it satisfy document requirements for all relevant entities in scope.

To do this, users can select multiple Related Parties from the grid using the checkboxes. Filters can also be applied to narrow down the view before making selections.

Once entities are selected, the total count appears above the table. To the right of this count-just after the De-scope icon-a document upload button is available.

Clicking this button opens the Document Upload modal. Unlike the Document V2 Task modal, the Matching Requirements panel will not be displayed and only the metadata fields will be displayed. Users must complete the mandatory fields - Document Name and Document Type - before proceeding. Optional fields such as Access Layers are also available. The selected Document Type determines whether the document can be automatically linked to requirements for the chosen entities.

Once the upload begins, the system processes each Related Party one at a time. During this process, a Document Upload progress modal is displayed, showing a message and progress bar that indicate the current stage of the upload. This provides real-time feedback and prevents users from refreshing or navigating away while the upload is in progress.

When the upload is complete, the same modal updates to show an "Upload Complete" message and a completed progress bar. A summary is also displayed, confirming how many entities the document was uploaded to and how many document requirements were satisfied across those entities.

If the document doesn’t satisfy any requirements for a relevant entity, it is still uploaded and stored against that entity for future use.

After completion, the grid updates automatically. If all mandatory documents for a Related Party are satisfied, the Outstanding Actions column will no longer display "Documents required." If both data and document requirements are fulfilled, the Status column updates to reflect "Complete."

No new permissions are required for this functionality. Users with existing document upload permissions within the task can bulk assign a single document across multiple Related Parties in the Hierarchy.

Once all related parties scoped into the Related Party Data & Documents task have a 'Complete' status, the task can be completed.

The scoping rule applied to the task should be configured to present the required related parties for additional data and document capture. However, there can be exceptions to the rule and to allow for this an option to de-scope or remove an entity from scope has been provide within the task. Once users have been granted permission, when the hover on a related party within the table, a 'De-scope' icon will appear to the right of the table line. The bulk action will allow for this to be performed for multiple entities at a time if required. Once the user selects the icon a confirmation message will be presented to complete the action. Once confirmed, this action will remove the entity/entities from the scope of the task only, and the entity is still retained in the hierarchy. Additionally, if any data or documents were updated for the selected related party/parties prior to removing from scope, the details will be retained in the draft and persisted to the verified data once the journey completes.

Please note that the opposite exception to add related parties from the hierarchy into scope of the task will be included in a future release.

Configuring Related Party Adapted Experience

The creation or linking of related parties to the hierarchy will occur in the Related Parties task. Where additional data and document requirement capture is applicable to certain related parties within the hierarchy, this can be accommodated in the Related Party Data & Documents task. This task can be configured in any journey and can be placed multiple time within one journey if desired.

Configuration

In order to correctly render the Related Party Data & Documents task there are some specific details that must be configured in Reference Data, Journey and Policy.

Related Party Scoping Rules Configuration

In order to automate the selection of related parties from the hierarchy for additional data and document collection, new Related Party Scoping Rules have been introduced. The scoping rule will determine those related parties from the hierarchy that are in scope and presented to the user, and must be applied to the instance of the Related Party Data & Documents task in Journey Builder. Once the correct permissions have been applied, the rules can be configured via the Related Party Scoping Rules options under the Journey management menu.

Once navigated to the Related Party Scoping Rules configuration, new rules can be created via the +ADD button to the top right. Configurators must define the name of the rule for creation and the logic can then be configured. The same condition configuration pattern that exists across Fenergo is applied in these rules. A number of sources can be utilised when configuring the condition(s) of the rule:

• Current Entity - Related Party entity data
• Current Entity Metadata - Entity Type
• Entity Association - Relationship Type - Association to Client - Direct/Indirect - Proportional Ownership
• Related Client - Entity data of client in journey

Scoping rules are versioned and a user must create a new draft to perform any edits to an existing rule. A scoping rule must be published in order to be available for selection on the task in Journey Builder.

Reference Data Configuration

As per the configuration of the Related Parties task, the following lookups must be configured via Reference Data configuration.

1. Relationships

   The Relationships lookup is designated as a system lookup and the List name must always be “Relationships”. This lookup will drive the values which appear in the Type field in Relationship Details in the Details panel.

2. Requirement Category The Requirement Category lookup is designated as a system lookup and this drives the Category field when configuring fields in the Policy domain. Differing from the Related Parties task, only these 2 values must be added to the Requirement Category lookup:

   • Relationship Details
   • Related Party Basic Details

Fields with these categories will drive what appears in the modal in the Related Parties task and the Details panel of the Related Party Data & Documents task, and specifically which section they appear in – see Policy Configuration for additional details. Additional fields can be configured in categories outside of these required categories and those categories can then be utilised in the Related Party Data & Documents configuration in Journey Builder, providing additional structured data capture if desired.

Journey Configuration

In Journey Builder, the following task should be added to any journey where the additional related party data and document capture applies.

Related Party Data & Documents task:

This user-completed task can be configured anywhere in a journey, but must be configured after the Related Parties task and must feature prior to the Verify Related Party Associations V2 task. It can be configured to appear at multiple points in the journey, allowing for various contexts of related parties, different scoping rules can be applied to each instance of the task should this be desired.

When configuring this task, the Task Type must be Related Party Data & Documents. The other options under Task Content are as follows:

• Related Party Scoping Rule - The rule must be specified in order for related parties to be included in the scope of the task
• Persist Documents - Document Persistence for Related Parties can be enabled using the toggle available within this task. Refer to the Functional User Guide above for more information.
• Data and Document Policy Categories - these categories will determine the data and document requirements triggered within the task for the additional information capture. In a change to the existing Related Parties task, this task is no longer tied to the three categories the existing task modal is tied to (Related Party Basic Details, Related Party ID&V, Relationship Details), meaning any category configured on data and document requirements configured with a Target Entity of Related Party can be specified and apply to this task. This provides additional flexibility in the detail that is required within the task. Please note the Related Party Basic Details and Relationship Details categories will always appear in this task so it is not necessary to include these in the category listing. Both of these categories will display in the first and second order respectively in the panel regardless of any custom ordering.

Related Parties task:

As mentioned above, the Related Party Data & Documents task must be used in conjunction with the Related Parties task as the building and maintenance of the hierarchy will occur there. The Related Party Data & Documents task removes the requirement to complete the traditional ID&V elements of the Related Parties task and therefore these will be disabled by default. Please see the functional documentation above for detail within the task.

In terms of configuration, when the Related Party Data & Documents task is configured in a journey, Journey Builder includes validation to ensure the task is configured along with the Related Parties task, and that the Related Parties task must be configured before the Related Party Data & Documents task. Similar to Mutli-Publish, the Related Party Data & Documents task and Related Parties task cannot be placed within an 'In Any Order' process or stage and validation will trigger if this is the case.

As the Related Party Data & Documents task will perform the ID&V process that exists in the Related Parties task, to avoid duplicate effort, the ID&V element of the Related Parties task will be disabled when the Related Party Data & Documents task is configured in the same journey. A new configuration toggle 'Disable ID&V' will be present on the Related Parties task, which be disabled by default. In order to configure and utilise the Related Party Data & Documents task this toggle must be enabled in the Related Parties task and validation will ensure this is the case. Once the toggle is enabled, the ID&V elements with the task will be disabled, reflected by the below changes in the task once the journey is published and the task triggered in a journey.

• The following will no longer display: - ID&V Requirements column in the task - ID&V unwrapping in the task - ID&V toggle in the modal - 'Indicate Requirements Needed to Complete ID&V' toggle in the modal
• The ID&V section of the modal will still display for data capture but the mandatory validation will no longer apply

The 'Search Exclude Client Entities' toggle allows configurators to refine duplicate search results when users add related parties within a journey. When enabled, the system automatically filters out any entities marked with the “Client” role, ensuring that only non-client entities appear as search results. This helps prevent users from accidentally linking client hierarchies where it is not required for screening or ID&V purposes.

When users perform a duplicate search in the Related Parties task, only non-client entities matching the search criteria will display - any entities identified as Client will be filtered out and not appear in the results list.

Verify Related Party Associations V2 task:

This automated service task must be configured at the end of a journey containing the Related Parties and the Related Party Data & Documents tasks, either as the final task or the penultimate task (where the final task is the Verify Entity service task).

It is recommended that this verification task is configured to appear only once in any single journey.

When configuring this task, the Task Type field in the Task Content panel must be populated exactly as you see in the below screenshot. The remaining fields can be populated as per your preference:

Policy Configuration

Please see the Related Party Management document for details on configuring policy for Related Parties.

Permissions

There are five ID&V Permissions specific to the configuration and functionality of this feature:

1. ID&V Configuration Access: This Permission allows a user to interact with and navigate into the Related Party Scoping Rules option under the Management Menu for Journey. Note: Journey Access is required to see this menu option.
2. ID&V Configuration Create: This Permission allows a user to create a Related Party Scoping Rule or clone an existing Related Party Scoping Rule set.
3. ID&V Configuration Edit: This Permission allows a user to create a new version of an existing Related Party Scoping Rule set, update an existing draft version of a Related Party Scoping Rule set, or submit an existing Related Party Scoping Rule set draft version for approval.
4. ID&V Configuration Delete: This Permission allows a user to delete an existing Related Party Scoping Rule set and all its versions and delete the selected version of an existing Related Party Scoping Rule set.
5. ID&V Configuration Approve: This Permission allows a user to approve or reject a version of a Related Party Scoping Rule set which has been submitted for approval.
6. ID&V Configuration Archive: This Permission allows a user to archive a version of a Related Party Scoping Rule set.
7. ID&V Remove Scope: This Permission allows a user access to the grid option to remove one or more selected related parties from the scope of the task. This does not remove the entity from the hierarchy and does not delete the entity draft should any changes have been made.