Prospective clients are added to the Client Owners (Advisors) repository by clicking the “Add Prospect” button. We will walk through an Individual Onboarding “Track”. (There are many more tracks for the more complex entity types)
At this point, prospects can only be used with opportunities or tasks. In order for the prospect to become an ACTIVE client, it needs to be onboarded. This process uses a Compliance Track to first capture all the relevant required fields and supporting documents, and then send these for approval. First, we add the prospect:
Once the Prospect is added you will be able to see and interact with it in the portal, either as the Client Owner, or as a member of the Client Services Role. Client Services users can see all Clients across Client Owners. Client Owners can only see their clients.
Clicking on the Prospect will bring up the Client Summary View (you can customize this using the Designer Role). As you can see, there are no Statuses (see the Compliance Track Builder for more on this)
Select the Second Tab (also has the Clients Name). This is the Client Details Tab. On the right hand side, select “Onboard Client”
This will bring up the List of ROOT Statuses to choose from. Select “Individual“. This will select the Tracks Available for that status for this client for their Country of Risk. Select Default, and then click on Load Compliance Track.
NOTE: If this was a “Self Service” Track, you would have an opportunity here to send this directly to the Client.
Now you will see the ubiquitous “Run Track” dialog. This dialog will have a Card for each concurrent track or sub track that has been generated via the Compliance Rules we created earlier. There are 4 main components to each Card (and hence track)
Edit: This will take you to the DDQ (Due Diligence Questionnaire) that you designed earlier using the Questionnaire Builder. This DDQ is the temporary storage area where you can retrieve data from the DataView Record and/or get it filled in by the Client or Client Administrator (or via an API!). Only when a Compliance Track (aka Change Request) is fully approved, will the rules copy it back to the original record, and the Change Request is the only way to edit those fields, ensuring compliance in your organization.
Submit: Once you have filled in all the compulsory questions and uploaded all the required documentation, you can submit the Change Request for Approval. This takes the Change Request from the NEW state into the SUBMITTED state, where no more edits are allowed.
AutoApprove: This will Submit the Change Request, and then try to Approve one of the Approval Slots as the logged in user.
More: If the Approval of the Change Request results in it being fully approved, and the Approval Rules trigger further Compliance tracks to be created, then the More button will become available for you to make a start on those Change Request, just like you have here.
We will start with Edit on the Individual Track:
This brings up the Questionnaire we designed for the Client Services user (or Client Owner) to answer to discern which Sub Tracks and Statuses (Proofs/Evidence) we require. For this example we answer that the Client is acting suspiciously.
We click Submit and are taking back the “Run Track” dialog:
For this Card we are going to Select “Auto Approve” to that we can see what rules ran and what statuses were marked as Required
By clicking on “More” we can see that we need all of the ProofOf statuses, and the Compliance Engine has created Change Requests for Each:
This can be seen in the Clients Change Request tab:
Starting with the ProofOfIdentity Card (Edit) we see that the original details from the Prospect record have been copied across to the DDQ. We need to submit the rest:
Once we submit, we return to the Card:
For this one, we are going to select “Submit” to show it to manually approve:
If we switch to the Change Requests tab on the client record, we will see that the ProofOfIdentity is now in the Submitted state. If we open this (as Client Services) we have the option to click through to the Client Service View and then we will see the Approvals Tab
Here we see that we have 3 approval required.
NOTE: From the Rules we created we only added one approver for this demo. In practice, you would add both a Reviewer and an Approver to cater for the 4-eyes (or maker/checker) compliance requirement. We will approve as the Approver (as we are not in the other roles!) and click Accept
We will come back to this ProofOfIdentity later. For now we will tackle all the rest, as they only require one approver (see note above)
For the ProofOfTax we enter the details and submit:
For this card we will choose AutoApprove and you will see it marked as Approved
This is reflected in the Statuses in the Compliance Section under the client Account. We will now go and approve all the rest:
Now we can see that all the remains is the Original ProofOfIdentity, as the rules required additional Approvers:
We will now log in as each of the 2 remaining roles and approve this request:
We approve as the Enhanced CDD Reviewer, and log in as an Enhanced CDD Aprpover user and approve.
Now we can see the the Client is ACTIVE:
Navigating to the Client Details Tab we can also see that the Root Status is now Valid:
We can also see from the Compliance View that the Client has picked up 125 Risk Points for their permutation of data:
