KYC requires solid control
We’ve already touched upon KYC within a previous post where we intended to share best practices to collect business critical information from your Customers.
But this is not enough as a proper KYC process must rely on a sharp validation flow to assess the quality of information your Customers upload. What if they would update wrong bank details or non-compliant ID?
Now, it’s time to understand how Integromat can help your company follow a strict approval process to guarantee that any KYC document is valid prior to being stored into your CRM.
Start approval flow from your CRM
In order to make it as easy as possible, the approval process shall start from within your CRM (Salesforce or Hubpsot for instance), and ideally in the form of a basic link to click to perform the action.
Do not underestimate the need for over-simplifying any process you can to help internal users as they need to cope with tens of procedures all along the day. In our example below, we made it available in the form of an explicit dynamic link named “Click here to review KYC documents“.
As depicted in most of our posts, we mostly use Typeform as our preferred interface for collecting information from either customers or internal users.
Thus, when clicking the link, internal users can easily navigate through a really straight forward questionnaire to either approve or discard an uploaded KYC document. We made the decision to ask for additional information in case of rejection so that we could notify customers and ask them to submit a new version.
Processing approvals and rejections
Once in Integromat, we then need to retrieve KYC document status so that we know whether we can approve or discard them.
The below flow illustrate the practice that we always stick to which consists in separating data collection from the processing for easier maintenance.
As you already know, our HTTP module will call an Integromat webhook which will trigger the next scenario to start processing answers.
Which leads us to the core of our approval processing scenario which is illustrated in the picture below. As you see, we are dealing with some more complexity but overall, this scenario remains quite simple.
This scenario comprises 3 different branches as this example aims to deal with 3 types of documents : customer ID, company registration ID and bank details. And we created a flow for each to cope with differences in terms of processing. But for the sake of simplicity, we’ll only focus on the IBAN branch which is more than useful.
Listing all uploaded documents
First step consists in retrieving all documents uploaded by a Customer to date. The idea is to process them based upon :
- their age (the most recent the one to assess)
- the decision made by internal user (approved or discarded)
The most practical way to list such documents is to use an SOQL request, which is Salesforce’s querying framework and that is pretty similar to SQL.
The one we use in this context is:
SELECT Id, CreatedDate, Name, description, body, isPrivate, isDeleted, ownerID
FROM Attachment
WHERE
ParentId = '{{69.value}}'
AND
Name LIKE '%PENDING%'
AND
Name LIKE '{{121.value}}_%'
ORDER BY CreatedDate DESC
ParentID points to the Account that we are currently looking at (which is passed from Salesforce to Typeform in the form of an hidden field).
Then we make sure that we only consider pending documents (not yet reviewed) and which contain the “IBAN” tag (thanks to the {{121. value}} Integromat field).
Discriminate viable documents from obsolete ones
According to our SOQL request, we order results in a descending way, which means that the most recent document will come first.
It allows us to distinguish the document to be processed from obsolete ones that we instantly discard as illustrated below.
Obsolescence happens through a simple renaming where we modify our _PENDING_ tag with an _OBSOLETE_ one. Therefore, attachments in Salesforce we’ll be easily recognizable by their plain name.
Managing approved and discarded KYC documents
Overall, the approach is similar in both cases. But for the sake of maintenance simplicity, it’s always better to design a clean visual scenario to foster fast fixing and/or improvement when required.
As a first step, we are going to rename the document based upon their status. We use the same taxonomy showed above where _PENDING_ shall be replaced by either _APPROVED_ or _DISCARDED_.
But the most important part lies into the Account updating step where we have to capture contextual information to enrich our Salesforce CRM.
In that example, we are approving an IBAN which invites us to stamp a “YES” value into our "kyc_iban_approved__c" custom field.
But we also want to keep track of key timestamps, and especially the ones that relate to both the effective approval date but also the last review date.
Finally, we record the user which processed that flow for this specific document in order to investigate properly when needed.
Documents accessibility to Salesforce users
See below how the “Notes & Attachment” section of a given account would look like after a couple of tests.
As you see, an interal user would have instant access to all uploaded documents, seeing at a glance whether some of them need approval (_PENDING_) or whether they are either discarded (_DISCARDED_) or even obsolete (_OBSOLETE_).
But more importantly, all files are renamed with a specific prefix to immediately understand which type of KYC document has been, or needs to be investigated for final approval (IBAN, REGID or IDCARD).
Lastly, as you see in the picture hereafter, Salesforce keeps track of all sensitive information, thus enabling advanced reporting capabilities for managers, but this is another story. 🙂
Wrap-up
We’ve seen how to trigger an approval flow from our CRM (Salesforce) by designing a specific URL pointing to a straight forward Typeform questionnaire.
We’ve stressed the need for separating the data collection scenario from the processing one for easier maintenance and improvements.
We’ve reviewed how to pass information from one scenario on to the other using HTTP calls, webhooks and JSON payloads.
We’ve touched some SOQL query to simplify the way to list items within Salesforce in a quite elegant and effective way.
And we’ve focused on basic but useful taxonomy in order to sort documents into Salesforce so that internal users can immediately gain access to critical information, without any pain.