Configuring Due Diligence

The following screenshot shows that the user can configure the CRS Indicia rule for Trusts with Known Trustees within CRS.CLIENT.TYPE using the Rule Type and Rule Id fields and then select the Rule Id from the drop-down options.

The mapping and the indicia sample rules for 'Entity Trusts whose Trustees are Known' can also be found in the RT.REGULATORY.RULES application.

The following screenshot shows the sample use of Rule API field. A sample API RT.GET.TRUSTEE.INDICIA has been set up.

The RT.GET.TRUSTEE.INDICIA API uses the Address Country field in the CUSTOMER application to check the reportable jurisdiction to identify the trustee indicia. This API is modified to allow the user to select the preferred country field for indicia check, which is subject to the accurate configuration of the Residence field in the CUSTOMER application to be considered for indicia check. This modification is also based on the configuration of the RELATION.CODE (which defines the trustee) in the Poa Code field in CRS.PARAMETER.

Following are the steps required:

• Configure the reporting jurisdiction in the CRS.PARAMETER application.

  

• Configure CRS.CLIENT.TYPE for both individual customers and entities as shown in the following screenshot.

  

The user can configure which types of customers will have a CRS.CUST.SUPP.INFO record created prior to the indicia assessment.

Following are the configuration steps for the CRS exclusion functionality:

1. Set the Auto Create Recs field as All in ST.REGULATORY.PARAMETER.

   

2. Create a new rule in the RT.REGULATORY.RULES application with the required exclusion condition definitions.
   • The user can refer to the CCSI.CUSTOMER.EXCLUSION.RULE sample record that is released with the CUSTOMER.TYPE exclusion definition.
   • Each Rule Type works as OR condition, that is, if any one of the conditions are satisfied, then the customer is excluded from the CRS.CUST.SUPP.INFO processing during COB (close of business).
     

3. Attach the CRS CUSTOMER EXCLUSION rule in CRS.PARAMETER.
   • The Rule Type should be selected as Customer Selection.
   • The Rule Id should be the above created exclusion condition RT.REGULATORY.RULES rule.

     

4. After the user creates a customer record and runs a COB (close of business), the user can check the exclusion in the CRS.CUST.SUPP.INFO record. A CRS.CUST.SUPP.INFO (CCSI) record is created for every customer who has not been excluded under the configuration facility.
5. If there are any changes in the rules or criteria, the user can amend them in the RT.REGULATORY.RULES application.
   • When there is a change in CRS.CLIENT.TYPE (where the customer types are defined), all the customers in the CUSTOMER application are validated against the new definition and the corresponding CCSI creation or update will be done by the ST.IDENTIFY.INDICIA COB job.
   • When the information in the CUSTOMER application changes, RT.CREATE.REGULATORY.RECS revalidates the customer type against the definition in CRS.CLIENT.TYPE.

The below configurations are necessary for the automatic creation of CRS customer supplementary information:

1. Set the value of the Auto Create Recs field to Yes in the ST.REGULATORY.PARAMETER application to enable the automated creation of the CRS supplementary information record and the associated indicia identification.

   

2. The required setup in CRS.PARAMETER is available.

   

3. The selection criteria to distinguish individual and entity type customers is defined using the CRS.CLIENT.TYPE application.
4. The RT.REGULATORY.RULES application is configured for the customer identification rules, document rules and indicia determining rules.
5. The RT.REGULATORY.RULES application is configured with field mappings that are required to populate the CRS.CUST.SUPP.INFO record including the mapping for indicia fields.
6. The batch job, ST.IDENTIFY.INDICIA controls the creation and update of CRS.CUST.SUPP.INFO records of the eligible customers. The ST.IDENTIFY.INDICIA service identifies the indicia conditions for both individual and corporate customers based on the rules defined in the RT.REGULATORY.RULES application. This service creates or updates the CRS.CUST.SUPP.INFO records for those customers who satisfy any of the indicia rules defined. This service can be configured to review all customers in the database and assess their indicia conditions as a one-time activity as shown below.

   

   This service is also auto triggered during COB in the below circumstances:

   • If there is an amendment to the rule definition in RT.REGULATORY.RULES
   • If there is an amendment to the rule ID or indicia details in CRS.PARAMETER

   The RRR.TRIGGER table tracks the changes in the applications, which are used to identify and map the indicia, for example, when the Residence field in the CUSTOMER application is changed, the ID in the RRR.TRIGGER table acts as a trigger for indicia identification through the RT.CREATE.REGULATORY.RECS service.

• The mapping rules for documents are defined in the mapping definition records like CRS.INDIVIDUAL.MAPPING.RULE and CRS.ENTITY.MAPPING.RULE in the RT.REGULATORY.RULES application for CRS.
• An API that is attached to the above records fetches the mapping data corresponding to the documents from CUST.DOCUMENT (application name defined using the User Application field in RT.REGULATORY.RULES) and updates the CRS.CUST.SUPP.INFO record for the customer.
  • The API accepts the Customer ID and CCSI record as input parameter.
  • This Customer ID is used to validate if the document defined in CUST.DOCUMENT corresponds to the CRS documents defined in CRS.PARAMETER, in which case, the details are updated in the corresponding CCSI of the customer with the Sc Cust Ref field updated for primary owner.
  • In addition, if a controlling person is identified for the primary owner, relevant documents are validated against the document names parametrised in CRS.PARAMETER for each of the linked controlling persons. For CRS-related documents, details are updated in CCSI with the Sc Cust Ref field updated for controlling person.
  • The CRS.ROLE.CUSTOMER is an internal system maintained file that contains the list of controlling persons linked to the primary customer owning a record in the CRS.CUST.SUPP.INFO application .
  • After the initial document update in CCSI, any modifications to the document data in CUST.DOCUMENT is tracked online and updated by the jobs indicated above. This API facilitates tracking of the changes made to the documents in CUST.DOCUMENT such as DOC.STATUS, EXPIRY.DATE and EFFECTIVE.DATE, online.
• The update to this file is managed as part of RT.CREATE.REGULATORY.RECS.

The following configuration is required for the standing instruction indicia functionality to work:

• Configure the applications used for standing instruction indicia processing in the RT.REGULATORY.RULES application defined for individual indicia identification.

  

The CRS indicia associated with Power Of Attorney (POA) and Authorised Signatory conditions can be tracked. These are defined using the Customer Relationship and Arrangement Role fields respectively.

Customers might have configured their transact system to utilise different customer relationship codes to define the POA and/or different arrangement role codes to define the authorised signatory conditions. The following fields are added in the CRS.PARAMETER application.

• Poa Code.1 - Defines the customer relationship code used to define a POA condition by the client.
• Poa Code.2 - Defines the arrangement role code used to define an ‘Authorised Signatory’ condition by the client.

The system accounts for different indicia depending on the availability and validity of the self-certification form. These conditions are pre-configured in RT.REGULATORY.RULES corresponding to the different client types and using the matrix indicated under each client type head, below.

The customer’s self-certification submission status is managed by the bank’s Document Management system. This could be within Temenos Transact or in any external system. It is expected that banks manage at least the meta data information of the document within Temenos Transact with the help of Transact’s Document Management module.

The indicia conditions related to the self-certificate document status is pre-configured in the RT.REGULATORY.RULES application. Sample CRS documents considered by the RT.REGULATORY.RULES application, both at the time of reception and expiry of the document is shown below.

Depending on the self-certificate submission status and its validity, the system derives the reportability factor. The attributes used to generate the reportability depends on the type of the customer and indicia rules applied. The following matrices describe the indicia conditions to be configured in RT.REGULATORY.RULES for each client type. For this purpose, the bank is assumed to have maintained the meta data information related to self-certificate within Document Management module and in the CUST.DOCUMENT application.

Individual Customers

For individual customers, the self-certification linked indicia logic is configured in the CRS.INDIVIDUAL.INDICA.V2.0 record in RT.REGULATORY.RULES.

The following matrix is for pre-existing Individuals (customers who are on-boarded by the bank prior to the CRS effective date) and its corresponding self-certificate form status.

The following matrix is for new Individuals (customers who are on-boarded by the bank after the CRS effective date) and its corresponding self-certificate form status.

The following screenshots show RT.REGULATORY.RULES configured to define the indicia determination rules based on the self-certificate form status.

Trusts with known Trustees

For trusts with known trustees, the self-certification linked indicia logic is configured in the CRS.ENTITY.WITH.TRUST.INDICA.V1.0 record.

The following matrix is for pre-existing trusts with known trustees (customers who are on-boarded by the bank prior to the CRS effective date) and its corresponding self-certificate form status.

The following matrix is for new trusts with known trustees (customers who are on-boarded by the bank after the CRS effective date) and its corresponding self-certificate form status.

The following screenshots show RT.REGULATORY.RULES configured to define the indicia determination rules based on the self-certificate form status.

Non-Trusts or Other Entities

For Non-Trusts or Other Entities, the self-certification linked indicia logic is configured in the CRS.OTHER.ENTITIES.INDICIA.V1.0 record.

The following matrix is for new trusts without or unknown trustees (customers who are on-boarded by the bank after the CRS effective date) and its corresponding self-certificate form status.

The following screenshot shows RT.REGULATORY.RULES configured based on the rules described above.

In the RT.REGULATORY.RULES application, the user can find a number of pre-defined sample rules and APIs. The following screenshots demonstrate an API, which has been introduced to support the USED.PHYSICAL.ADDRESS Rule Type indicia for individuals.

In the screenshot below, the RT.CHECK.MAILING.PREFERENCES API checks the address preference in the DE.CUSTOMER.PREFERENCES application and the address country in DE.ADDRESS. If the address country is a CRS reportable jurisdiction, the USED.PHYSICAL.ADDRESS Rule Type will be identified as an Indicia for the particular customer.

This API supports the customer mailing preferences created at the customer, account and portfolio levels. Whenever changes are applied in the DE.CUSTOMER.PREFERENCES and DE.ADDRESS applications, the indicia is updated for both the ‘owning’ customers and all applicable related and/or joint customers.

The system tracks the addition and removal of customers in the ACCOUNT, SEC.ACC.MASTER and CUSTOMER.RELATIONSHIP tables. Whenever there are changes to these tables, the Used Address Indicia is recalculated for the impacted customers. This is applicable only for individual customers.

Following are the steps to set up the additional indicia for CRS for corporate customers:

1. CRS indicia mapping rules are defined for corporate customers with the following field values:
   • Controlling Person Residence
   • Entity Headquarters

     

2. The record is authorised as shown in the below screenshot.

   

3. Once the rules are defined for CRS indicia, the user must link (associate) the field mapping with the indicia mapping (set up previously) in the CRS.PARAMETER application.

   

4. The record is authorised as shown in the below screenshot.

   

5. Set the value of the Auto Create Recs field to Yes in the ST.REGULATORY.PARAMETER application to enable the automated creation of the CRS supplementary information record and the associated indicia identification.

   

6. Set up the CRS.CLIENT.TYPE application for corporate customers.

   

Once the above configuration is completed, the user must reset the system to ensure that all the configuration settings take effect
7. The user can now view the CRS.CUST.SUPP.INFO application to ensure that the configuration steps are configured correctly and the system is operating accordingly.

The following screenshot shows the results of the above configuration, where the newly configured corporate indicia conditions are populated. The Indicia Summary multivalue field in the screenshot below shows:

• Controlling Person Residence
• Entity Headquarters

  

8. Once all the indicia configuration steps are completed, the user needs to ensure that the updated indicia conditions are reflected in the configuration of the reasonableness check. The CUSTOMER.REASONABLENESS.CHECK.PARAMETER application needs to be updated to accommodate the Controlling Person Residence and Entity Headquarters indicia conditions as shown in the below screenshot.

   

After the above configuration steps are completed, CRS Customer Reasonableness Check considers the updated indicia conditions and checks for inconsistencies in the following field values:

• Controlling Person Residence
• Entity Headquarters

If any inconsistencies are detected in the above fields, the CRS Reasonableness Check (CRS.CUSTOMER.REASONABLENESS.CHECK) enquiry will return an NOK result with the reason for inconsistency, as shown in the below screenshot.

If there are no inconsistencies, the CRS Reasonableness Check (CRS.CUSTOMER.REASONABLENESS.CHECK) enquiry will return an OK result, as shown in the below screenshot.