Related party management demonstration

The bank U Plus Financial Services is onboarding an organization with a set of investment products. In the Capture stage of the Onboarding case, the Relationship Manager has already collected some basic data and has been granted initial approval from their manager. The case is now in the Enrich stage and a member of the Sales Support team has completed most of the enrichment process. All the necessary data must be in place before the required due diligence activities can be determined and orchestrated in the following stage, Due Diligence.

The user clicks Continue for the Enrich data for due diligence assignment and sees that all categories are complete with the exception of Related Parties. They click Continue to proceed.

This screen is a central point from which the user can manage all the relationships between the customer and other related parties. In this case, the customer is called Grinstead Finance UK. This screen is also available during parts of the Due Diligence stage and used, as allowed, in other customer journeys.

An initial set of related parties will be built up during the onboarding process. For each related party, there is configurable business logic that drives what screening, document collection, and other due diligence activities are required. Upon completion of the onboarding process, these related parties will be reused and updated accordingly across the life cycle of the customer.

The table currently shows a single row, which can be expanded to show any roles that form the relationship. Upon expansion, the user sees that Jennifer Hawton IS the Primary Contact of Grinstead Finance UK. This represents a direct relationship between these two parties. Jennifer is not deemed KYC significant or a controlling party and therefore not subject to due diligence activities. KYC Significant Parties are those that must at least undergo screening. A controlling party is one that has a significant enough controlling interest to be subject to the applicable due diligence questionnaires.

Before being able to proceed to due diligence, the Sales Support user is required to add a controlling party. This starts the discovery of the ownership structure of Grinstead Finance UK.

The Sales Support user clicks the Add related party button and is presented with an initial search. It is important to check whether they are already in the system to avoid duplicate parties being created. The party they are adding is an individual called Klaus Maddsen. When no matches are automatically found they click the Create new button and fill out at least the mandatory information in the body of the form. For this demonstration, we will fill out all of the fields.

Scrolling down, the user has the option to add relationships of three types: Direct Is, Direct Has and Indirect.
Indirect relationships cover when there are other intermediate parties involved in the relationship. After clicking Add roles, the Sales Support user can select from categories of roles or type in the role directly. Klaus Maddsen is a Beneficial Owner. When the role of Beneficial Owner is added, a set of related attributes is presented that must be completed. As a Beneficial Owner, Klaus has a 30 ownership stake in Grinstead Finance UK. The second role of CFO is available from the management role category.

The role categories, roles, and role attributes are dynamically driven by a number of factors. Certain roles and their attributes drive core business logic in the application. The user clicks Submit and Klaus is displayed in the summary table.

The user can now carry out a set of actions by clicking the three vertical dots at the end of each row. They cover the ability to make various updates to the information, override the automatically calculated values of aggregate ownership, and if the party is controlling, as well as deleting the relationship. If an existing party was reused for a relationship, that party's core data will remain in the system.

The user wishes to add another related party. In this case, it is an organization, so [the user] selects the organization party type. Again, as with the other related parties, we will see if the organization is already in the system. Blade Finance Group is returned as a match and upon selection, the full set of details is prepopulated automatically on the screen.

Scrolling down to add another relationship, again, a direct relationship, Blade Finance Group IS a majority shareholder. After the ownership reason is selected a percentage of ownership must be entered. As a majority shareholder, the value must exceed 50 percent, and then [the user] click[s] Submit.

Upon click of Submit, two new rows are added to the related parties table. Expanding the roles for Blade Financial Group, the user can see that there is an equivalent role created. Blade Finance Group IS a Majority shareholder of Grinstead Finance Group, but also, Blade Finance HAS Grinstead Finance UK as a Subsidiary.
The second added row is an individual, Preston Glance. Preston is a Beneficial Owner of Blade Finance Group and therefore also an Indirect owner of Grinstead Finance UK.

The user can click View visualizer to access a fully interactive diagram of the relationships. Elements can be selected to learn more information such as risk or the attributes of a role. Users can zoom in or out and also have the ability to move elements around. This is particularly helpful in understanding more complex hierarchies.

This concludes the demonstration of related parties management.