Regulatory Compliance
R24 AMR | Min(s) read
Related topics:
Disclaimer

Introduction to Customer Data Protection

The Customer Data Protection (CDP) module provides tools and functionalities to help certain data protection related to processing.

The module allows the user to do the following:

  • Identify personal data within the system.
  • Define a central store of personal data fields and tag these fields with specific properties that determine their processing.
  • Determine the types of individuals in scope for data protection related processing.
  • Store and record data protection related requests from individuals in relation to the use of their personal data.
  • Provide specific personal data reports based on request.
  • Monitor a customer’s activity status.
  • An erasure process, which erases or anonymises data within the system after bank-defined conditions are met and the completion of retention periods for holding the data.

The CDP module has two menus:

  • Admin Menu – Used for configuration
  • User Menu - Helps with day-to-day processing

It allows the user to set up and configure the module. This includes the configuration of the following:

  • Parameter
  • Data Definition
    • Purposes
    • Erase Options
  • Use of the Search Utility
  • Request Types

It allows the user to perform specific tasks such as logging and updating requests. This includes the following:

  • Creating and managing Data Protection requests
  • Viewing and managing Customer Activity
  • Viewing and exporting Subject Access Requests and Data Portability

Configuring Customer Data Protection

The bank is responsible for configuring the Customer Data Protection module.

The below outlines the module components that are to be configured by the bank.

This configures the high-level rules and settings for the module.

Application Description
CZ.CDP.PARAMETER
  • Defining the Customers eligible for data protection processing
  • Process of handling requests made by non-eligible customers
  • Erasure process handled by the system

Read Parameter user guide for more information.

This helps in the analysis of personal data fields within the bank’s own system.

Application Description
CZ.CDP.PDD.SEARCH.REQUEST Defines the search criteria to identify likely personal data fields
CZ.CDP.PDD.SEARCH.RESULTS Provides the output of the search request
Service Description
BNK/PDD.SEARCH.UTILITY Selects the trigger created by the Search Request and generates an output based on the search criteria

Read Search Utility user guide for more information.

Application Description
CZ.CDP.DATA.DEFINITION Allows the client to define the Personal Data fields available in the system and processing of such fields
CZ.CDP.PURPOSE Allows the client to define the following:
  • Bank purposes or lawful basis or processing certain data
  • Associated retention period for holding personal data, generic or company specific
CZ.CDP.ERASE.OPTION Allows the client to define the mechanism of anonymising data.

Read Data Definition, Purpose and Erase Option user guide for more information.

Application Description
ST.CUSTOMER.ACTIVITY.PARAMETER
  • Determines the applications which impact a Customer’s Activity
  • Link to the customer within the application for Customer Activity
  • Link to the customer within the application for getting information for reports and erasure
ST.CUSTOMER.ACTIVITY Maintains the list of Active and Completed contracts and other linked applications for an individual
CZ.CUSTOMER.ACTIVITY Maintains additional details related to an individual’s activity and Customer Data Protection details such as:
  • Customer Activity Status
  • CDP Eligibility Details
  • Details related to the erasure process (such as Erasure dates and status)
CZ.CUSTOMER.ACTIVITY.CAPTURE Confirms whether the customer is blocked for erasure and the customer remain active because of an externally held product with the bank
Service Description
BNK/ST.TAKEOVER.CUS.ACTIVITY Builds the original customer activity records for the module. Without this, the CDP processing cannot occur. The full configuration of the module should be set up correctly before this service is run.
BNK/ST.BUILD.CUS.ACTIVITY
  • Maintains customer’s activity and identifies any new contracts that are linked to a customer, and updates them as Active.
  • Identifies changes and updates eligibility criteria for a customer.
BNK/ST.WATCHOUT.COMPLETED.CONTRACTS Identifies whether a customer is removed from a contract and moves the contract to Completed.

Read Customer Activity user guide for more information.

Applications

Application Description
CZ.CDP.REQUEST.TYPE
  • Allows the bank to define the types of customer data protection requests supported by the bank
  • Also defines the time frame in which the bank should reply to such requests
CZ.CDP.REQUEST.CAPTURE Allows a mechanism to log data protection related requests for customers
Service Description
BNK/CDP.BUILD.ACCESS.RESULT Generates the report for a Subject Access Request
BNK/CDP.BUILD.PORTABLE.REQUEST Generates the report for a Data Portability request.
BNK/CZ.ERASURE.PROCESS Provides an anonymisation process which pseudonymises personal data within the system – as per the set up of the Personal Data Definition.

Read Rights Management user guide for more information.

A high-level visual representation of the module is shown below.

For optimal performance of the CZ module, it is recommended to ensure efficient data management. Data archiving and/or purging processes are recommended before executing any tasks related to data protection. Certain processes, such as Transaction Erasure, are specifically applicable to archived tables. Additionally, considering the nature of these processes, which involve large table scan activities, it is advisable to schedule their execution during ‘off-peak hours’ to minimise any potential impact on overall system performance.

Illustrating Model Parameters

This section covers the following Model parameters.

Parameters Description
CZ.CDP.PARAMETER This application defines the following:
  • Eligibility rules for defining a customer subjected to General Data Protection Regulation compliance. The rules are defined through API or Temenos Transact Rules Engine.
  • Rules for Erasure and the trigger of erasure process. It can be triggered automatically or a manual confirmation from a user to initiate the process for a customer.
  • Enables the user to hold the data of the erased customer by setting the Build Erasure Log field to Yes. The records are captured in CZ.CDP.DATA.ERASED.TODAY and can be used for reporting purposes.
  • Allow Active Erasure field allows the user to define if erasure is allowed or not. The default field value is NO and a blank field value will also mean No, where erasure is not allowed for active customers. If the field value is set to Yes, erasure is allowed while customer is active.
  • Erasure functionality is enabled by setting the Allow Contract Erasure field to Yes. This field allows erasure of personal data in a customer record. Applications that are allowed for contract erasure are to be defined in the Cont Erasure Appln field, with a valid CZ.CDP.DATA.DEFINITION record.

  • Cus Ret Field Name is a field from the CUSTOMER application. It is used in CZ processing to determine the retention period for the customers data. This field allows the ‘null’ option, which can be used as the default value for the customers who does not meet the defined criteria.

  • Cus Ret Field Value is used to define a value in the field (given within Cus Ret Field Name), which determines a specific retention period for the Customer.

  • Customer Retention Period is used to define the retention period for the Customer who met Cus Ret Field Name and Cus Ret Field Value criteria. The value provided in this field will be the retention period for holding the Customer’s data from the date of Customer’s inactivity.

  • Product Category is used to define the CATEGORY code for a product which determines retention period. This field allows the ‘null’ option, which can be used to apply to all other CATEGORYs that are not defined specifically.

  • Product Retention holds the retention period for the type of CATEGORY defined within the CUST.PROD.CATEG.RET field. The date provided in this field will be the minimum retention period for holding the Customer’s data from the Completed Date or Delinked Date of the account contract from Customer Activity.

  • Erasure Date Priority defines the erasure date priority when calculating the overall erasure date of the Customer in the CZ erasure process.

  • Prospect Retention Field Name is a field from the CUSTOMER application, which impacts the prospect’s retention period. This field allows the ‘null’ option, which can be used as the default value for any prospect that does not match the defined criteria.

  • Prospect Retention Field Value must be a valid entry within the relevant field listed in Prospect Retention Field Name.

  • Prospect Default Retention Period defines the default time period to hold prospect’s data without raising a manual request by the prospect. This retention period starts from the prospect’s creation date and the value entered should be defined in the form of days or months or years.

  • Prospect Request Retention Period defines the time period to hold prospect’s data by raising a manual requested by the prospect. This retention period starts from the prospect’s creation date as requested and the value entered should be defined in the form of days or months or years.

  • Transaction Application holds the application name of the master transaction to be erased.

  • Transaction Application Retention Period holds the retention period for each master transaction application. Users can define either Retention Period, API, or Rule for each application.
CZ.CDP.PURPOSE This table defines the purpose of holding or processing the data. Additionally, it enables the user to define how long the data should be held before it is erased.Based on the underlying lawful basis, the bank processes the data and the following values are defined:
  • Legal
  • Legitimate
  • Consent
  • Contract

Erasure of personal data can be requested for customers who are still active, by setting the Allow Active Erasure field to Yes. The default value is No.
CZ.CDP.ERASE.OPTION It allows the user to define how the data should be erased within the erasure process. The following values can be defined in the Erase Action field:
  • Default − Sets the value to a default value
  • Nullify − Clears the content of the field (if not mandatory) or applies default value (if the field is mandatory)
  • Obfuscate − Value in the field is masked to hide the original contents
  • No Action − Value in the field is not cleared or erased
CZ.CDP.DATA.DEFINITION As part of the General Data Protection Regulation (GDPR) regulation, it is important to know the personal data which is stored in the system and how it is processed. It is important to have central metadata store, where the personal data is held within the system and allow specific processing to be exercised on the data that is identified.
  • It defines the metadata and holds all the fields and tables that contain personal data definition.
  • The table has a set of system fields that holds the definition as defined from the underlying application for fields flagged as Personal Data Definition.
  • The metadata store allows both Core provided (system and feature) and locally added (user) fields to be stored.
    1. System Defined Fields

      2. System defined fields are based on initial analysis of fields that may contain personal data within the database. These fields are pre populated based on an initial analysis of the database and are no input. It enables the user to exclude by populating the field within the user fields section and setting the Exclude field as Yes.

    2. Feature Fields
      • It holds the country specific provided and maintained fields. These fields can be selected by the CZ module processes and processed accordingly.
      • The newly added fields follow the same naming conventions of the system.
    3. User Defined Fields

      4. It allows the user to record their own definition of personal data. Field names and additional properties can be attached here. If a field has both a system and user defined field, the user field’s properties takes precedence during all CDP processing. User can define their own definition of personal data, where core and local fields can be added. The User Field Name is multi-valued so multiple fields can be added within each application.

      FieldDescription
      User Field Name, Feature Field Name and System Field NameDefines a field name with the application defined in @ID of the record.
      User Field Attributes, Fea Field Attributes and System Field AatributesDefines any other properties linked to a field. Allowed values are:
      • Direct
      • Indirect
      • Sensitive
      User Purpose, Fea Purpose and System PurposeDefines the lawful basis data processed by the bank.
      User Erase Option, Fea Erase Option and System Erase OptionDefines how the field is erased within the erasure process.
    4. Access Details
      5. FieldDescription
      Use In ActivityIndicates if the table determines customer activity or only linked to show a relationship between the customer and the bank. Allowed values are:
      • Activity
      • Link
      • Blank
      Cust Access LinkIndicates how the table is accessed using the customer Id.
      Cust Access TypeProvides the value to be used based on the Access Type. Allowed values are:
      • ID
      • CONCAT
      • FIELD
      • API
      • PARTIAL.ID
      • RELATED.CONTRACT
      • ACTIVITY
      Party Access LinkIndicates how the table is accessed using the party application’s Id.

Include for Prospect field defines whether the given application is required to consider for prospect data erasure processing. This field allows the below values:

  • YES – Prospect related erasure processing is applicable for this application.

  • NO or NULL – Prospect related erasure processing is not applicable for this application.
CZ.CDP.REQUEST.TYPE It defines the request type and expiry days. Valid request types are:
  • Subject Access Request
  • Data Portability
  • Erasure
  • Object
  • Rectification
  • Restriction

Delink Pty Rln Api field is input only if the request type is Erasure. This field accepts an EB.API record Id to attach the routine for removal of party relationships.

Illustrating Model Products

Model Products are not applicable for this module.

Copyright © 2020- Temenos Headquarters SA

Contact Us

knowledge@temenos.com

Published on :
Monday, May 27, 2024 1:49:53 PM IST