How to
setup programmes for user access
Programmes also govern the level of access that your users
and teams can access and also you are in control in deciding whether a subject
(key principle) can share data across such programmes or not (to achieve the
concept of the single customer view). In fact based on the above, here are the
options that you can set.
1) A programme is to be completely
siloed
This means that any subject
data in this programme will be completely separate (logically) from all the
other programmes. Example, if you are adding an individual called TOM in this
programme, and this same TOM happens to be in some other programme, for KYCP
this would be a completely separate TOM.
2) A programme can share data on
subjects with other programmes
If this is the case you would need to identify / bear in mind the following:
a. You can decide which programmes
are to share data with which other programmes
b. If this is enabled (and referring
to the example above) – if TOM is going to be added in PROGRAMME B as a new
subject, and TOM already exists as a subject in PROGAMME A, the compliance team
of PROGRAMME B would be able to add TOM by using the USE FROM EXISTING feature.
c. When the above happens you can
decide which fields of TOM are to be share between PROGRAMME A and B. You can
decide that (for example) fields NAME, SURNAME and COUNTRY are to be shared but
the rest of the fields aren’t.
d. Same thing with the Document Types.
You can decide that the document types proof of ID, proof of address and
certificate of incorporation are to be shared but the shareholders certificate
of TOM in Programme A is not shared and only stays in Programme A.
e. When you use the feature of (b)
above (use from existing) this would also mean that the screening of subjects
for PEPs, Sanctions and Adverse Media will be linked to the single customer
view of TOM. So its one check but updating all the places were TOM is involved
in.
Apart for the above you would also need to note the user
access of your compliance teams to the different programmes.
- You can set users to have access
to one or multiple programmes (example the compliance team of the Irish office
are to only view and have access to applications in the programme of Ireland).
- If you want the above to be set
for user access but still allow for the feature of 2(b) above (the use from
existing) you do not need to give users access to the other programmes. So for
example, if users in the Irish office of Programme A (Ireland Programme) want
to add subject TOM that is in Programme B (UK Programme) you do not have to
allow the Irish user to have access to the full programme of UK. Instead KYCP
allows you to set the Irish users in a way whereby the Irish user has the right
to purely search for a subject to see if they exist in the other programmes
without seeing or having access to the application of TOM in the UK Programme.
How many
programmes do I need?
The number of programmes that you would need to setup in
KYCP can vary based on a number of aspects. We help each client decide this
based on the approach that they need to take however here are a number of
aspects that need to be factored in such a decision:
1) Regional
differences
Many clients of KYCP use the platform across the
different regions of their organisation. These would have offices in different
regions such as US, Europe and APAC which instantly leads to differences in how
the process of due diligence works. This could be in the form of different
teams which would lead to a drastic difference in the STATUSES that you create
in a programme leading to a different flow per region.
2) Difference
in risk perception
This is one of the most common reasons why a separate
programme might be needed. Jurisdictional requirements often lead to perceiving
the risk on certain fields (such as Nationality being Italian) in a different
way. The regulator in the EU might perceive this to be LOW risk but the APAC
regulator requires this to be MEDIUM. Such risk variations are also a result of
internal policy based on the product or service you are offering. Some clients
considering Italian nationality being low risk in corporate services but high
risk if I am offering Tax consultancy. Such elements would require separate
programmes to allow you to tailor the entire solution based on your granular
requirements.
3) User
access
Another factor would be user access. Some clients would have separate
compliance teams whereby one team can only see the applications of one region
or product and not the others. This instantly leads to the requirement of
having a separate programme.
Having said all of the above however, we do have some
clients whose remit is to streamline the entire process of due diligence across
products and services, across regions and all users and teams. In such a case
they create one programme that is used for all the requirements.
For more info contact us directly on info@kycportal.com or schedule your live demo with us today.