Actimize AML-CDD 2 0 8 Solution Guide

Actimize Anti-Money Laundering
(AML)
Customer Due Diligence (CDD)
Solution
Solution Guide
AML-CDD Version 2.0.8
Company Confidential
December 12, 2014
Legal Statement
This document contains proprietary information belonging to Actimize Ltd. and/or its
affiliates. Such information is supplied solely for the purpose of assisting explicitly and
properly authorized employees or consultants to evaluate or use Actimize products. No
part of its contents may be used for any other purpose, disclosed to any person or firm
or reproduced by any means, electronic or mechanical, without the express prior
written permission of Actimize Ltd. and/or its affiliates. The text, graphics and
examples included herein are for the purpose of illustration and reference only. The
specifications on which they are based are subject to change without notice. No legal
or accounting advice is provided hereunder and any discussion of regulatory
compliance is purely illustrative.
The software described in this document is furnished under a license. The software
may be used or copied only in accordance with the terms of that license. Certain
features and functionality described in this document are optional features not included
in a base product license and may only be accessed and used by licensees expressly
licensed to use such features and functionality. Licensees should refer to their
respective license agreements to determine whether they have licensed a particular
feature or functionality.
Corporate and individual names and data used in examples herein are fictitious unless
otherwise noted. Information in this document is subject to change without notice.
Actimize reserves the right to revise or withdraw this document or any part thereof,
including, without limitation, the elimination or modification of any product functionality,
at any time.
The software described herein may be protected by one or more of the US patents
listed at www.nice.com/Patents. Actimize, the Actimize logo, NICE, and the NICE logo
are trademarks or registered trademarks of NICE Systems Ltd. and/or its subsidiaries.
All other marks are trademarks of their respective owners. Other company, brand,
product and service names are trademarks or registered trademarks of their respective
holders.
Copyright ©2014 Actimize Ltd. All rights reserved.
Document Version: 2.0.8.6

Catalog Number: 6243
COMPANY CONFIDENTIAL
Contents
Chapter 1: Overview ............................................................................................................... 1
1.1 About this Guide .......................................................................................................................... 1
1.2 About Customer Due Diligence ................................................................................................... 2
1.3 About the Actimize AML-CDD Solution ....................................................................................... 2
1.3.1 Main Features of the Actimize AML-CDD Solution ........................................................ 3
1.3.2 Key Objectives of the Actimize AML-CDD Solution ....................................................... 3
1.4 What’s New in This Version ......................................................................................................... 3
Chapter 2: Solution Summary ................................................................................................. 5

2.1 Actimize AML-CDD Solution Methodology .................................................................................. 5
2.1.1 Input Sources .................................................................................................................. 5
2.1.2 Customer Record............................................................................................................ 6
2.1.3 Calculation of Risk Factor Scores .................................................................................. 7
2.1.4 Determination of Risk Levels .......................................................................................... 7
2.1.5 Detection and Alert Generation ...................................................................................... 7
2.1.6 CDD Review and Investigation ....................................................................................... 8
2.1.7 Risk-Based Dynamic Interviewing .................................................................................. 9
2.1.8 Solution Cleanup ............................................................................................................ 9
2.2 Overview of the Solution Flow ................................................................................................... 10
2.3 Actimize AML-CDD Web Services ............................................................................................ 10
Chapter 3: Customer Risk Scoring ........................................................................................ 12

3.1 About Risk Factors and Scoring Scales .................................................................................... 12
3.2 Risk Factor Score Calculation ................................................................................................... 12
3.3 List of Solution Risk Factors ...................................................................................................... 13
3.4 Custom Risk Factors ................................................................................................................. 15
3.5 Risk Factor Score Reference Tables......................................................................................... 15
3.5.1 Countries ...................................................................................................................... 15
3.5.2 Mail Code ...................................................................................................................... 16
3.5.3 Account Opening Channel ............................................................................................ 16
3.5.4 Client Segment ............................................................................................................. 16
3.5.5 Account Classification................................................................................................... 17
3.5.6 Service Type ................................................................................................................. 17
3.5.7 Employee Type ............................................................................................................. 17
3.5.8 Account Relation Type.................................................................................................. 17
3.5.9 Risk Adjustments .......................................................................................................... 18
Chapter 4: CDD Detection Models ........................................................................................ 19

4.1 High Risk Customer (CDD-HRB)............................................................................................... 19
4.2 Change in Customer Risk (CDD-INR) ....................................................................................... 20
4.3 Identity Verification Issues (CDD-CIP) ...................................................................................... 22
Actimize AML-CDD Solution Guide Page i
Contents
4.4 Documentary Tracking (CDD-DOC) .......................................................................................... 24

4.5 Periodic Review (CDD-PRE) ..................................................................................................... 27
4.6 Expected Behavior Deviation (CDD-EBD) ................................................................................ 28
4.7 Trigger Events ........................................................................................................................... 31
Chapter 5: On-Boarding Parties ............................................................................................ 32

5.1 Overview .................................................................................................................................... 32
5.2 Locking Mechanism and Auto-Expiry ........................................................................................ 33
5.3 Search Restrictions According to Business Unit ....................................................................... 33
5.4 On-Boarding a New Party .......................................................................................................... 34
5.4.1 Initiating the On-Boarding Process ............................................................................... 34
5.4.2 Enhanced Due Diligence (EDD) Tab ............................................................................ 40
5.4.3 Summary Tab in On-Boarding Record ......................................................................... 41
5.5 Viewing the On-Boarding Client Alert ........................................................................................ 41
5.5.1 View Party History ........................................................................................................ 43
5.6 Relating a New Party to the Current Party ................................................................................ 44
5.6.1 Searching for an Existing Related Party ....................................................................... 44
5.6.2 Selecting a Related Party ............................................................................................. 46
5.6.3 Adding a Related Party to the Current Party ................................................................ 47
5.6.4 Orphan Related Parties ................................................................................................ 48
5.7 Cloning an On-Boarding Record ............................................................................................... 49
5.7.1 Cloning from the Summary Tab .................................................................................... 49
5.7.2 Cloning from the Search Results .................................................................................. 50
5.8 Changing the Party Type of an On-Boarding Record................................................................ 54
Chapter 6: Review and Investigation .................................................................................... 56

6.1 Overview .................................................................................................................................... 56
6.2 Workflow for Reviewing a Customer Record ............................................................................. 56
6.2.1 Searching for a Customer ............................................................................................. 56
6.2.2 About the Customer Record ......................................................................................... 57
6.2.3 Header Information and Action Buttons........................................................................ 58
6.2.4 Reviewing the Customer Profile ................................................................................... 59
6.2.5 Reviewing Account Profile ............................................................................................ 59
6.2.6 Reviewing CIP Records ................................................................................................ 60
6.2.7 Reviewing Customer Risk Scores ................................................................................ 60
6.2.8 Reviewing On-Boarding Questions .............................................................................. 61
6.2.9 Reviewing a Relation Diagram ..................................................................................... 62
6.2.10 Reviewing Audit History ................................................................................................ 62
6.2.11 Reviewing Related Documentation .............................................................................. 62
6.2.12 Reviewing Beneficial Ownership Records .................................................................... 63
6.3 Options for Reviewing AML-CDD Items and Item Details ......................................................... 63
6.3.1 About the Main List of Work Items ................................................................................ 63
6.3.2 Solution Alert Types...................................................................................................... 64
Actimize AML-CDD Solution Guide Page ii
Contents
6.3.3 Document Management ............................................................................................... 64

6.4 Adjusting Thresholds and Scoring Scales ................................................................................. 66
6.4.1 Thresholds .................................................................................................................... 66
6.4.2 Scoring Scales .............................................................................................................. 67
6.5 Viewing and Managing Solution Lists ........................................................................................ 68
Chapter 7: CDD Maintenance Model .................................................................................... 70

7.1 Old Customer Purge .................................................................................................................. 70
7.2 Old Account Purge..................................................................................................................... 70
Chapter 8: AML-CDD Policy Manager .................................................................................. 74

8.1 Overview .................................................................................................................................... 74
8.2 Policy Manager Rules ................................................................................................................ 75
8.3 Examples of User-Defined Policies ........................................................................................... 77
Chapter 9: Risk Factor Specifications ................................................................................... 79

9.1 List of Risk Factors .................................................................................................................... 79
9.2 CDD-RSK Risk Factor Specifications ........................................................................................ 81
9.2.1 Address in High Risk Geography ................................................................................. 82
9.2.2 Foreign Individual ......................................................................................................... 84
9.2.3 Political Exposure ......................................................................................................... 86
9.2.4 Foreign Corporate Entity............................................................................................... 87
9.2.5 Foreign Trading Area .................................................................................................... 89
9.2.6 Embassies and Foreign Consulates ............................................................................. 90
9.2.7 Client with SAR reports................................................................................................. 91
9.2.8 Customer Under Suspicion ........................................................................................... 92
9.2.9 Customer Under Subpoena .......................................................................................... 93
9.2.10 Mail Code ...................................................................................................................... 94
9.2.11 Account Type ................................................................................................................ 95
9.2.12 Collateral Type .............................................................................................................. 96
9.2.13 Employee Status........................................................................................................... 97
9.2.14 High Risk Businesses ................................................................................................... 98
9.2.15 Money Service Business ............................................................................................ 100
9.2.16 Client Segment ........................................................................................................... 101
9.2.17 Channel of Account Opening ...................................................................................... 102
9.2.18 Occupation .................................................................................................................. 103
9.2.19 Initial Source of Funds ................................................................................................ 104
9.2.20 Ongoing Source of Funds ........................................................................................... 105
9.2.21 Relationship to Higher Risk Entity .............................................................................. 106
9.2.22 Service Type ............................................................................................................... 109
9.2.23 Behavioral Trends....................................................................................................... 110
9.2.24 Client Net Worth ......................................................................................................... 111
Actimize AML-CDD Solution Guide Page iii
Chapter 1: Overview
The Actimize AML-CDD Solution Guide is intended for use by the following personnel in financial
institutions:
• Compliance officers – responsible for compliance with anti-money laundering regulations.
• Operation center employees – responsible for reviewing and assessing solution alerts,
gathering missing information, and reviewing and managing customer responses.
• Relationship managers – typically the bank employees who are located at the bank's local
branches and have direct communication with the customers.
1.1 About this Guide

This guide provides general information about the Actimize AML-CDD solution. The following
chapters are included:
• Chapter 1: Overview – High-level introduction to the Actimize AML-CDD solution, including a
description of the Customer Due Diligence (CDD) process, and the main features and
objectives of the Actimize AML-CDD solution.
• Chapter 2: Solution Summary – Overview of the AML-CDD solution methodology, including
an overview of the solution’s main components, solution flow, and web services.
• Chapter 3: Customer Risk Scoring – Describes the Actimize AML-CDD solution default out-
of-the-box risk factors, including risk factor score calculation, solution risk factors, custom risk
factors, and risk factor score reference tables.
• Chapter 4: CDD Detection Models – Describes the CDD detection models provided with the
Actimize AML-CDD solution, including High Risk Customer, Change in Customer Risk,
Identity Verification Issues, Documentary Tracking, Periodic Review, and Expected Behavior
Deviation; as well as the events that trigger these models.
• Chapter 5: On-Boarding Parties – Describes the on-boarding process, including search
restrictions, on-boarding new parties, viewing on-boarding client alerts, relating new parties to
the current party, cloning an on-boarding record, and changing the party type of an on-
boarding record.
• Chapter 6: Review and Investigation – Highlights the review process that’s conducted via
Actimize Risk Case Manager (RCM), including the workflow for reviewing a customer record,
reviewing AML-CDD items and item details, adjusting thresholds and scoring scales, and
viewing and managing solution lists.
• Chapter 7: CDD Maintenance Model – Describes how users can purge legacy records of
customers and accounts.
• Chapter 8: AML-CDD Policy Manager – Describes how to set up and activate user-defined
policy rules for the Policy Types that are delivered with the Actimize AML-CDD solution.
• Chapter 9: Risk Factor Specifications – Provides a list of risk factors used in the Actimize
AML-CDD solution, as well as their specifications.
This document may describe features and capabilities that require a separate license and are not
covered by the standard license. For information about licensing please contact your Actimize
representative.
Examples included in this document are for the purpose of illustration and reference only.
Screenshots may look different from the screens in your solution, depending on your solution’s
configuration and the browser that is used.
Actimize AML-CDD Solution Guide Page 1
About Customer Due Diligence
Related Documents
The following documents are related to the Actimize AML Customer Due Diligence (CDD)
Solution Guide:
• Actimize AML Customer Due Diligence (CDD) Installation Guide
• Actimize AML Customer Due Diligence (CDD) Implementer’s Guide
• Actimize AML Foreign Account Tax Compliance Act (FATCA) Solution Guide
• Actimize AML Foreign Account Tax Compliance Act (FATCA) Web Services Guide
• Actimize AML Foreign Account Tax Compliance Act (FATCA) On-Boarding User’s Guide
• Actimize Risk Case Manager (RCM) Installation Guide
• Actimize Risk Case Manager (RCM) Reference Guide
• Actimize Visual Modeler & AIS Server Installation and Configuration Guide
1.2 About Customer Due Diligence

Since the USA PATRIOT Act was signed into law in 2001, financial institutions have given
increased attention to customer due diligence (CDD). US financial institutions are required to
conduct due diligence on all new customers, while non-US financial institutions have adopted
their own customer due diligence programs, mainly using the industry-accepted standard
provided by the Basel Committee on Banking Supervision.
The customer due diligence process ensures that a customer’s identity is known to the financial
institution and identifies whether a customer is on any government watch lists. The importance of
customer due diligence is emphasized by the Federal Financial Institutions Examination Council
(FFIEC) Bank Secrecy Act/Anti-Money Laundering Examination Manual: “the cornerstone of a
strong BSA/AML compliance program is the adoption and implementation of comprehensive CDD
policies, procedures, and processes for all customers, particularly those that present a high risk
for money laundering and terrorist financing.”
Financial institutions are also required to implement a Know Your Customer (KYC) process,
which collects sufficient information to determine the level of Anti-Money Laundering (AML) risk
each customer poses. Know Your Customer processes are becoming increasingly important
globally to prevent identity theft, financial fraud, and money laundering. Institutions must further
conduct Enhanced Due Diligence (EDD) on those customers who are potentially high risk given
the institution’s overall AML risk assessment.
1.3 About the Actimize AML-CDD Solution

Customer Due Diligence (CDD) is a key component of the Actimize Anti-Money Laundering
(AML) suite. Using a risk-based approach of scores and alerts, the Actimize AML-CDD solution
allows financial organizations to efficiently pinpoint and evaluate those entities that potentially
pose the greatest threat in money laundering and terrorist financing.
Providing end-to-end customer life cycle risk management, the Actimize AML-CDD solution
collects customer information (KYC/CIP), automatically verifies customer identity, assesses the
risks associated with each customer, and enables Enhanced Due Diligence for high-risk
customers.
The Actimize AML-CDD solution is implemented within the Actimize platform, which comprises:
• Analytics Intelligence Server (AIS) – Distributes alerts and initiates actions upon detecting
high-risk customers
• Actimize Risk Case Manager (RCM) – Enables organizations to efficiently investigate and
manage cases.
Overview
1.3.1 Main Features of the Actimize AML-CDD Solution

• A Customer Centric Approach – The Actimize AML-CDD solution is focused on the
customer, and provides a full, consolidated customer view, including the Customer
Identification Program (CIP), Know Your Customer (KYC), risk factors, documentation,
identity verification, customer relationships, and history.
• Complete Life Cycle Customer Due Diligence – The solution includes an interactive risk-
based account opening process (on-boarding), real time identity verification, watch list
screening and risk rating, and ongoing monitoring based on risk or account changes.
• Comprehensive Risk Rating – Actimize analyzes a wide variety of data elements and risk
factors to assign a score to each customer, thereby identifying the highest risks and enabling
an enterprise risk-based approach.
• Analytical Risk Models – Risk models analyze each customer’s profile and identify different
types of risks associated with the customer, generating alerts and highlighting those
customers that may pose a risk to the organization.
• Advanced CDD Workflow – Provides robust and efficient management of high-risk
customers, and can be easily customized to support each organization’s policies and
procedures, including alert and case management, investigation, resolution, reporting and an
audit trail.
1.3.2 Key Objectives of the Actimize AML-CDD Solution

The key objectives of the Actimize AML-CDD solution are:
• External Data Gathering and Integration – Accessing needed data to properly ‘Know Your
Customer,’ and performing various levels of system data integration including:
 Risk based dynamic interviewing (an optional feature)
 Client data integration
 Integration of data from external risk monitoring applications
• Dynamic Interviewing – The out-of-the-box ability to conduct tailored customer interviews
dynamically, based on the risk indicated through analysis of customer responses.
• Effective Risk Scoring and Identification – The ability to consistently and objectively
calculate the customer risk rate automatically.
• Data Retention and Auditing
• High Risk Customer Management
 Alert and Case Management
 Notifications and Investigation Workflow
 Enhanced Due Diligence
 Unified Single Customer View
1.4 What’s New in This Version

The Actimize AML-CDD 2.0.8 solution includes the following enhancements:
• Restricted on-boarding and customer search – Financial institutions can restrict the
results of both customer and on-boarding searches to authorized users only. The displayed
results of searches are restricted, based on the business unit(s) assigned to the user
performing the search, as well as the business unit of the returned party. For more
information, see Section 5.3 Search Restrictions According to Business Unit.
• Web services that leverage on-boarding capabilities – Financial institutions using third-
party on-boarding systems can leverage Actimize’s on-boarding capabilities with the new
What’s New in This Version
Search, Fetch, Get On-Boarding Party Data, and Update On-Boarding Party Data web
services. For more information, see Section 2.3 Actimize AML-CDD Web Services.
• Transient web service – Actimize customers can assess the risk level of a potential party by
calculating a hypothetical risk score, and without saving data in the database. For more
information, see Section 2.3 Actimize AML-CDD Web Services.
• Beneficial Ownership Records – The Beneficial Ownership tab in the customer record
details the ownership structure of the party. If the party is owned by other entities or
individuals, this tab shows the related information; such as the name, relationship type, and
the percentage of ownership. For more information, see Section 6.2.12 Reviewing Beneficial
Ownership Records.
Chapter 2: Solution Summary
This chapter describes the solution methodology, solution flow, and web services for the Actimize
AML-CDD solution.
2.1 Actimize AML-CDD Solution Methodology

The following schematic diagram presents an overview of the methodology used by the AML-
CDD solution:
2.1.1 Input Sources

The solution receives input data from various client and external sources such as:
• Client reference data files, customer records, etc.
• Watch or safe lists
• Identity verification applications and services
• External risk analysis and detection applications (e.g., Actimize AML Suspicious Activity
Monitoring solution)
• Answers to questions supplied during on-boarding process
The solution then performs data integration by mapping all input data to the solution’s logical data
structure.
Actimize AML-CDD Solution Methodology
2.1.2 Customer Record

Once all input data is integrated into the system, the Actimize AML-CDD solution analyzes the
input data for each customer and creates a detailed and thorough record per customer.
The customer record includes:

• Customer profile – Provides detailed information about the customer such as full name,
primary and additional addresses, transactional activity, and business information (see
Section 6.2.4: Reviewing the Customer Profile, page 59).
• Account profile – Provides customer account related data for the customer, such as account
details, account peer group profile data, and a history of monthly transactions (see
Section 6.2.5: Reviewing Account Profile, page 59).
• CIP Record (Customer Identification Program) – Includes all CIP records received for this
customer (see Section 6.2.6: Reviewing CIP Records, page 60).
• Risk Scoring – Provides the risk score calculation for the customer, based on the client’s risk
factors and reference risk scoring tables, as well as a history of the risk score (see
Section 6.2.7: Reviewing Customer Risk Scores, page 60).
• On-boarding Questions – Includes a summary of a questionnaire presented to the party by
the client representative during the on-boarding process (see Section 6.2.8: Reviewing On-
boarding Questions, page 61).
• Relations Diagram – Presents a diagram that displays customer accounts and all related
accounts (see Section 6.2.9 Reviewing a Relation Diagram, page 62).
• Audit Information – Provides a detailed history of all changes made to a customer record,
for example any adjustments to the customer risk score or additions of comments (see
Section 6.2.10: Reviewing Audit History, page 62).
• Related Docs – Provides an option to view documentation available for this customer (see
Section 6.2.11: Reviewing Related Documentation, page 62).
Solution Summary
A record is created for all customers, regardless of whether there are alerts associated with this
customer or not.
2.1.3 Calculation of Risk Factor Scores

The Actimize AML-CDD solution includes a set of Risk Factors that are appropriate for the
organization’s needs. This includes both pre-defined risk factors that are delivered as an integral
part of the solution, as well as custom risk factors that can be defined by the solution’s
implementers. These risk factors are used for creating the comprehensive customer record. Each
risk factor runs an algorithm that is specific to that factor and assigns a Risk Factor Score per
customer. All customers are rated by all of the solution’s risk factors, and the resulting scores are
displayed within the Customer Record.
Based on the risk score assigned to each customer, the solution generates a risk profile and can
then distribute an alert, recommend a compliance workflow, or simply draw attention to those
customers who may pose a risk to the organization. For more information about Risk Factor
Scoring, see Chapter 3: Customer Risk Scoring, page 12.
2.1.4 Determination of Risk Levels

Authorized users can define risk levels that classify customers based on the customer score.
These levels are used by some of the Actimize AML-CDD detection models, and are displayed in
the Customer Profile. The levels are defined based on the organization’s needs; for example, the
levels can be defined as High, Medium, and Low. For each level the user assigns a range of
scores; for example, the High level can be assigned scores from 100 and above. The business
user also defines, for each risk level, the required number of days for periodic review that are
used by the Periodic Review Model (CDD-PRE).
NOTE:
There can be any number of tiered risk levels as long as they are numbered consecutively.
2.1.5 Detection and Alert Generation

Actimize AML-CDD detection models analyze the customer profile and risk factors, highlight high-
risk customers and, when appropriate, generate alerts. The solution includes detection models
that analyze each customer’s profile and identify CDD risk-related issues.
Detection Model Description

High Risk The High Risk Customer model calculates customer risk factor
Customer scores for each new customer and generates an alert when a
(CDD-HRC) customer score exceeds a threshold.
For more information about this model, see Section 4.1: High
Risk Customer (CDD-HRB), page 19.
Change in The Change in Customer Risk model monitors each customer for
Customer Risk changes to the customer profile or associated risks. When a
(CDD-INR) change is detected, the model checks whether the customer
score changed significantly from the previous risk score.
For more information about this model, see Section 4.2: Change
in Customer Risk (CDD-INR), page 20.
Actimize AML-CDD Solution Methodology

Identity Verification The Identity Verification Issues model aggregates and displays
Issues (CDD-CIP) information about parties that are connected with a discrepancy
violation, such as a discrepancy between provided identification
and missing documentation.
The model evaluates client-provided data on a daily basis and
generates alerts per party for each day.
The model checks for consistency regarding party information
such as:
• Customer name
• ID number
• ID type (when more than one type of ID is allowed)
• Date of birth
• Customer address
For more information about this model, see Section 4.3: Identity
Verification Issues (CDD-CIP) page 22.
Documentary The Documentary Tracking model tracks the status of the
Tracking (CDD- customer’s documentation, including identity and certification
DOC) documents, and detects any incomplete or insufficient
documentation, ensuring compliance with the organization’s
policies.
For more information about this model, see Section 4.4:
Documentary Tracking (CDD-DOC) page 24.
Periodic Review The Periodic Review model ensures that reviews are conducted
(CDD-PRE) in a timely manner. The model calculates the date of the next
required review for each customer, based on the last review date
and the customer’s risk level.
For more information about this model, see Section 4.5: Periodic
Review (CDD-PRE), page 27.
Expected Behavior The Expected Behavior Deviation model compares actual
Deviation transactional activity against expected activity and generates
(CDD-EBD) alerts for exceptions.
For more information about this model, see Section 4.6:
Expected Behavior Deviation (CDD-EBD), page 28.
The detection models usually run on a daily basis, updating the relevant customer profiles and,
when required, re-calculating their risk score. When model analytics identify CDD issues based
on the new profile, an alert is generated in the RCM Alerts tab.
2.1.6 CDD Review and Investigation

Risk based score values and generated alerts are distributed to the Actimize Risk Case
Manager (RCM), together with additional historical information such as related prior alerts, CIP
records, and other relevant customer related information.
The RCM is a web-based portal for streamlining investigation and reporting. The RCM controls
the organizational workflow for internal review and analysis of the customer records and review of
alerts generated by the Actimize detection models. AML analysts, and other designated
personnel, receive prioritized and filtered notification of anomalous behavior with supporting case
information. Users who want to gain further context can easily drill down into suspicious activity
Solution Summary
data, find information on related events, and obtain detailed profiles for all accounts and
individuals involved.
Depending on the users’ roles and level of authority, they can reassign, escalate, or process
alerts from a personalized list, or a common (departmental) queue. Case Manager review
features enable users to modify the status and score of an alert, attach notes and other
documentation, and determine resolutions to alerts. The user can note and describe the
disposition of resolved alerts, and can optionally assign alerts to cases for a more focused review.
RCM provides the AML-CDD analyst with the tools to investigate customer records and any
customer-related alerts.
Authorized users can configure questions and answers that can then be used to on-board parties
to become new customers of the institution, and to create relationships between these customers.
Authorized users are also able to manually mark customers or accounts that should be removed
the next time a purge process is run by the solution. The purge actions are registered in an
appropriate audit trail log, including user comments explaining why a customer or account was
purged. By default, the solution regularly performs a cleanup process that purges old or obsolete
customers or accounts from the AML-CDD solution database (see Section 2.1.8 Solution
Cleanup, below).
In addition, the RCM Work Items module includes a list of all documents maintained within the
system. Each document is an instance of a supported document form such as OFAC License
Documents, FinCEN Registration Documents, etc. Authorized users can create new instances of
document forms or edit existing documents.
2.1.7 Risk-Based Dynamic Interviewing

For any standard procedure conducted by representatives of the financial institution, such as
opening an account, the solution offers a dynamic interview that includes questions derived from
customer information and previous responses by the customer. The questions and appropriate
responses are configured by authorized users via the AML-CDD solution’s GUI. The dynamic
interviewing process is initiated from the On-Boarding tab.
All questions and answers are recorded by the system for further consideration. Analysts use the
On-boarding Questions page of the AML-CDD Customer record to evaluate all questions that
were presented to the customer and their responses.
2.1.8 Solution Cleanup

The solution includes a Purge of Old Records model that is designed to purge old or obsolete
records from the solution’s database. This model provides the facilities for organizations to define
a policy for cleaning customer and account records that are considered inactive. The model
monitors for customer or account records that have been inactive for a period of time and
implements either a full or partial purging process based on the financial institution’s
requirements.
The solution includes one maintenance model that identifies and purges old customer and
account records.

Purge of Old The Purge of Old Records model identifies customer and
Records (CDD- account records that are considered by the financial institution to
PRG) be old and removes them from the solution database.
For more information about this model, see Chapter 7: CDD
Maintenance Model, page 70.
Overview of the Solution Flow
2.2 Overview of the Solution Flow

The following schematic diagram shows all stages that comprise the full flow of the Actimize
AML-CDD solution.
2.3 Actimize AML-CDD Web Services

Actimize AML-CDD web services enable users to screen new and ongoing individual and entity
customers on demand, activate the onboarding process, and mitigate possible operational risks.
In addition, financial institutions using third-party on-boarding systems can use CDD web services
in order to leverage Actimize’s on-boarding capabilities.
Solution Summary
The Actimize AML-CDD solution leverages the following web services:

• Data Service Entity to Database – Creates and stores a new customer in the CDD Profiles
database by adding, updating and deleting draft and real-time customer records.
• Evaluate CIP Store Score Event – Provides initial and successive questions, depending on
the answers supplied to previous questions. The web service also returns the customer’s up-
to-date risk score based on existing information.
• File Upload –Uploads customer files to the Actimize CDD Profiles database.
• Search – Allows customers to search customer data through a web service. Prior to the
Actimize AML-CDD version 2.0.8 solution, users could search customer data only through the
solution search interface. The Search web service enables financial institutions which on-
board customers through a third-party interface to check if the customer already exists in the
Actimize internal database.
• Fetch – Allows users to retrieve additional information about a party after viewing the results
of the Search web service. In addition, the Fetch web service allows Actimize customers who
on-board their clients through a third-party (non-Actimize) system interface to search the
potential client’s data in the internal Actimize CDD database.
• Report All Questions – A configurable web service that returns all questions that exist within
the database.
• Report All Questions by Requesting Code – A configurable web service that returns all
questions that exist within the database for a given line of business (as designated by the
requesting code).
• Report by Party Key – A configurable web service that returns a full question and answer
log (both historical and current answers) that exist within the database for a specified party
key (party or customer).
• Report Update Answers – A configurable web service that enables the client application to
update answers for a specific party within the party profile database.
• Get On-Boarding Party Data – Allows customers using third-party on-boarding systems to
leverage Actimize’s on-boarding capabilities by creating their own user interface. The Get On-
Boarding Party Data Web service retrieves the current on-boarding state of a particular party.
• Update On-Boarding Party Data – Allows customers using third-party on-boarding systems
to leverage Actimize’s on-boarding capabilities by creating their own user interface. The
Update On-Boarding Party Data web service saves new or modified answers, performs risk
scoring (if required), and re-calculates the visibility of question sets (based on the answers
provided to answered questions and the EDD flag).
• Transient – Enhances the capabilities of the Evaluate CIP Store Score Event web service by
allowing Actimize customers to assess the risk level of a potential party without saving the
data in the database. The risk assessment is based on the data that was provided as an input
to the web service, and not on the party data that may exist in Actimize’s CDD internal
solution database. A hypothetical risk score is calculated based on the web service input.
Chapter 3: Customer Risk Scoring
The Actimize AML-CDD solution comes with default out-of-the-box risk factors. Each organization
can select the relevant risk factors and define appropriate risk scoring scales according to its risk
assessment and policies.
3.1 About Risk Factors and Scoring Scales

Risk factors are the basic building blocks of the customer risk score logic. Each risk factor is
defined by a risk factor value and scoring scale.
The following example shows the scoring scales used for the Account Value risk factor, which
assigns a risk score based on the customer’s account end of month balance:
Risk Factor: Account Value
Value: Account end of month balance
Scoring Scale:
Account end of month balance Score

$ 0-9,999 0
$ 10,000-99,999 10
$ 100,000-999,999 20
$ 1,000,000 30
3.2 Risk Factor Score Calculation

A risk factor is calculated for a specific entity such as a customer, an account, or a product.
When a risk factor is evaluated for an entity other than the customer (e.g., at the account level),
there may be multiple entities with different scores associated with the same customer.
In order to calculate the risk factor score at the customer level, the risk factor scores of the
various entities are aggregated at the customer level.
There are two possible options for the aggregation: SUM and MAX. The aggregation option is
defined for each score factor.
Example:
Customer X has 4 accounts: 1111, 2222, 3333, and 4444
Account # Balance Score

1111 $ 5,500 0
2222 $ 99,000 10
3333 $ 8,000 0
4444 $ 250,000 20
• If the Account Value risk factor is calculated by MAX aggregation, then:
Customer Risk Scoring
Customer Risk Score (X, Account Value) = MAX (0, 10, 0, 20) = 20
• If the Account Value risk factor is calculated by SUM aggregation, then:
Customer Risk Score (X, Account Value) = SUM (0, 10, 0, 20) = 30
• The total Customer Risk Score is the sum of all Customer Risk Factor scores.
• Customer Risk Score = SUM (Customer Risk Factors Score)
Example:
The following risk factor scores are assigned for Customer X.
Risk Factor Score

Account Value 20
Customer Type 10
MSB 40
Address Type 0
In this example, the Customer Risk Score = 20 + 10 + 40 + 0 = 70
3.3 List of Solution Risk Factors

The following risk factors are delivered as an integral part of the Actimize AML-CDD solution and
are used when calculating customer risk scores:
Risk Factor Name Description

Address in High Risk Geography A score is given based on the country score
CDD-RSK-001-GEO-ADR listed within the solution’s Countries list for the
country within the customer’s primary address. If
there is more than one country, the solution
takes the riskiest.
Foreign Individual A score is given based on the level of risk
CDD-RSK-002-GEO-IND associated with the geographic location of the
customer and his CIP (Customer Identification
Program) information.
Political Exposure A score is given if the party is defined as a
CDD-RSK-003-PTY-PEP Politically Exposed Person.
Foreign Corporate Entity A score is given based on the level of risk

CDD-RSK-004-GEO-CRP associated with the geographic location of
corporate entity and related accounts.
Foreign Trading Area A score is given based on the level of risk
CDD-RSK-005-GEO-TRA associated with the geographic location of
foreign trading countries according to customer
CIP (Customer Identification Program)
information.
Embassies & Foreign Consulates A score is given if the customer business
CDD-RSK-006-GEO-EMB address is an embassy or foreign consulate.
List of Solution Risk Factors

Client with SARs A score is given based on the level of risk
CDD-RSK-007-PTY-SAR associated with the number of customer's SAR
reports.
Customers Under Suspicion A score is given if a hit resulted for this customer
CDD-RSK-008-PTY-SUS when screened against watch lists by the
Customer Watch List Filtering model.
Customers under Subpoena A score is given based on the number of
CDD-RSK-009-PTY-SBP subpoenas received by the customer.
Mail Code A score is given based on the risk calculated for

CDD-RSK-010-ACT-MAL a given address type. Certain mail codes may
indicate a concealed address or an attempt to
conceal an address.
Account Type A score is given based on the account type of
CDD-RSK-011-ACT-TPY the customer, such as Private Banking,
Managed Account, etc.
This score is based on all accounts related to
the customer.
Collateral Type A score is given based on the level of risk
CDD-RSK-012-LON-CLT associated with the customer’s collateral type.
Employee Status A score is given if the customer is an employee

CDD-RSK-013-EMP-STS of the financial institution. The score is based on
the fact that an employee has more potential
opportunities to perform suspicious activities.
High Risk Businesses A score is assigned based on the risk
CDD-RSK-014-PTY-BSN determined for the line of business of the
customer. Some businesses are considered
potentially riskier than others, such as services
connected with Money Transfers, Check
Cashing, etc.
Money Service Business A score is given if the business is a money
CDD-RSK-015-PTY-MSB transfer service that includes payments and
collections.
Client Segment A score is given based on the risk determined
CDD-RSK-016-PTY-SGM for the party segment or classification type of the
customer such as SME, Corporate etc.
Channel of Account Opening A score is given based on the channel of
CDD-RSK-017-ACT-OCH account opening, for example whether it is a
face-to-face mode or a non face-to-face mode
(which is considered riskier).
Occupation A score is given based on the level of risk
CDD-RSK-018-PTY-OCP associated with the customer’s occupation code.
Initial Source of Funds A score is given based on the level of risk

CDD-RSK-019-ACT-ISC associated with the customer’s initial source of
funds.

Ongoing Source of Funds A score is given based on the level of risk
CDD-RSK-020-ACT-OSC associated with the customer’s ongoing source
of funds.
Relationship to Higher Risk Entity A score is given if a client is related by link
CDD-RSK-021-PTY-REL analysis to another high-risk entity.
Service Type A score is given based on the risk determined

CDD-RSK-025-PTY-SRV for all services related to the customer.
Behavioral Trends A score is given based on the level of risk

CDD-RSK-026-PTY-BHT associated with the customer’s suspicious
behavioral trends, such as alerts from other
systems.
Client Net Worth A score is given based on the level of risk
CDD-RSK-027-PTY-NWT associated with the customer’s net worth.
3.4 Custom Risk Factors

Implementers can define custom risk factors, based on a client’s business requirements. The
scoring logic for a custom risk factor can be built by using any of the following information:
• Full customer profile data (e.g., parties, accounts, and related entities)
• Customer historical profile data
• RCM alerts, cases, and FIU Reports (e.g., SAR or CTR reports), including attributes such as
date, alert status, etc.
• AML-SAM transactional profile data
• Data resulting from customer investigation, e.g., risk adjustments, customer status change,
audit trail information
Custom risk factors are displayed within the customer profile together with the solution’s pre-
defined risk factors.
Any predefined or custom risk factor can be activated or de-activated by the implementer.
3.5 Risk Factor Score Reference Tables

The risk score reference tables enable organizations to populate their own values for each risk
factor. Clients adjust the scores based on the local regulations and other localization factors.
3.5.1 Countries
The Country List should include all relevant country ISO codes and a score allocated to each
country. The score value varies based on the client’s requirements.
The following is an example of a Country List
Country Name ISO Score

(Example list) (Example score values)
Brunei BN 20
Kazakhstan KZ 20
Czech Republic CZ 15
Risk Factor Score Reference Tables
Country Name ISO Score

Serbia & Montenegro CS 15

Romania RO 15
etc. ….. …..
3.5.2 Mail Code

This is a list of typical client mailing methods and correspondence with the financial organization.
The list score allocations vary based on the client’s requirements.
The following is an example of a Mail Codes List
Code Mailing Method Score

H Hold 30
U Undeliverable Address 30
B PO Box 10
O Others 0
3.5.3 Account Opening Channel

This list includes typical financial organization account opening channels. The score values vary
based on the client’s requirements.
The following is an example of an Account Opening Channel List
Code Account Opening Channel Score

1 Face-to-Face 0
2 Non Face-to-Face 50
3 Other 20
3.5.4 Client Segment

This is a list of typical financial organization customer segment types. The score values vary
The following is an example of a Segment Type List

Code Segment Type Score
1 Core Bank 10
6 Private Banking 60
11 Wealth Management 90
16 Corporate 10
17 Commercial 20
18 Small Business 20
20 Top Core 10
25 Other 0
3.5.5 Account Classification

This list includes typical financial organization account classifications. The score values vary
The following is an example of an Account Classification List
Code Account Classification Score

1 Managed Account -30
2 Private banking 20
3 Retail Account - Checking 50
4 Retail Account - Saving 20
5 Wealth Management / investments 50
6 Anonymous ("numbered") 100
7 Margin Accounts 70
8 Certification Of Deposit Account (CD) 70
9 Other 0
3.5.6 Service Type

This list includes typical financial organization service types. The score values vary based on the
client’s requirements.
The following is an example of a Service Type List
Code Service Type Score

1 Money Transfer 30
2 Online Banking 20
3 Checking 30
4 Security Dealing 50
5 Direct Deposit Account 70
6 Debit Card 20
7 Others 0
3.5.7 Employee Type

This list includes codes for each employee type and indicates whether or not the customer is an
employee of the bank. The score values vary based on the client’s requirements.
The following is an example of an Employee Type List
Code Non-Employee- Employee Type Score
Flag (Example list) (Example score values)
M 0 Management 0
S 0 Staff 30
N 1 Non-Staff 20
3.5.8 Account Relation Type

This list includes typical financial organization relation types between customers and accounts.
The score values vary based on the client’s requirements.
Risk Factor Score Reference Tables
The following is an example of a Relation Type List

Code Relation Type Score
1 Owner 0
2 Beneficiary 20
3 Spouse 0
4 Co-Signer 20
7 Others 0
3.5.9 Risk Adjustments

This list enables implementers to enter manual risk factor values to be used for adjusting client
risk scores. This list should include additional categories for risk adjustment based on the needs
of the organization.
The following is an example of a Risk Adjustment List
Code Relation Type Score
1 High Risk Geography 100
2 Foreign Individual 30
3 Politically Exposed Person 100
4 Customer Under Suspicion 100
5 Customer under Subpoena 100
6 Other Types 100
Chapter 4: CDD Detection Models
Each model identifies specific types of issues and generates alerts if the issues are detected.
The Actimize AML-CDD solution includes the following models:
• High Risk Customer
• Change in Customer Risk
• Identity Verification Issues
• Documentary Tracking
• Periodic Review
• Expected Behavior Deviation
4.1 High Risk Customer (CDD-HRB)

This detection model calculates all risk factor scores for each new customer (i.e., a customer who
was never previously scored) and then checks whether the customer score is greater than or
equal to a configurable threshold. If the score exceeds the threshold, the model generates an
alert.
Since each customer may belong to more than one line of business, corresponding to RCM
Business Units (BUs), a different threshold can be defined and alerts can be generated per line of
business.
The following is an example of multiple alerts per line of business:

A customer is associated with the following lines of business: retail, insurance and
credit cards.
This customer has a risk score of 120.
The following thresholds have been defined for this model:
• A threshold of 110 is assigned for retail businesses
• A threshold of 80 is assigned for the credit card industry
• A default threshold of 250 is assigned for this model
In this example the following alerts would be generated for this customer:
• An alert is generated for the retail line of business (since the risk score is
greater than the specific business threshold).
• An alert is generated for the credit card industry for this customer (since
the risk score is greater than the specific business threshold).
Since there is no threshold specified for insurance, the solution uses the default
threshold for this line of business. In this case no alert is generated for insurance
since the customer risk score is less than the default threshold.
A total of two alerts would be assigned for this customer.
Each customer-risk score is based on risk factor scores assigned by this model (see Section 3.1:
About Risk Factors and Scoring Scales, page 12). In addition, AML-CDD analysts can fine-tune a
score manually by adding risk adjustments.
Change in Customer Risk (CDD-INR)
When an alert is generated for this alert type, analysts can view the alert within the main Alert List
and can directly access, from the alert, the relevant customer’s Risk Factor Scores (see
Detection Logic
1. For each new detected customer that is active:
a. Calculate Risk Score for all active Risk Factors.
b. Calculate Total Score by aggregating the Risk Scores.
2. For each detected customer that is not active:
a. Assign a Total Score of 0.
3. Generate an alert for each customer BU:
a. If a Minimum Score threshold exists for the customer BU and the Total Score ≥ BU
Minimum Score threshold.
b. If no threshold exists for the customer BU and the Total Score ≥ Minimum Score
threshold.
NOTE:
Risk Factors can be activated or de-activated by the implementer or authorized users using the RCM
Settings. Only active risk factors appear in the Customer Profile.
Thresholds
The business analyst is able to adjust the following threshold value using options available within
the Actimize Risk Case Manager:
Threshold Name Description Default

Value
Minimum score Sets the default minimum total score above 250
which an alert is generated.
It is possible to define a minimal score
threshold per Business Unit using the Edit
Business Unit Thresholds link available
within the Minimal score threshold row.
Scoring
Scores are calculated based on active risk factors. For more information about Risk Factors see
Section 3.2: Risk Factor Score Calculation, page 12.
4.2 Change in Customer Risk (CDD-INR)

The Change in Customer Risk detection model monitors each customer for changes to the
customer profile or associated risks. When a change is detected, the model re-calculates the
score and checks whether the customer score significantly changed from the previous risk score.
A change can be either an increase or a decrease in the customer's score. The change can
deviate from the previous score based on one or more of the following factors:
• Number of points – For example, if the customer risk score increased by 10 points or
decreased by 20 points, then the model generates an alert.
• Percentage from previous score – For example, if the customer risk score increased by
10% or decreased by 20%, then the model generates an alert.
CDD Detection Models
• Number of risk levels – For example, if the risk level increased by 1 level or decreased by 2
levels, then the model generates an alert.
A risk level depends on the customer risk scores. The following table shows an example of
risk levels:
Risk Level Risk Level Name From Score

1 Low risk 0-99
2 Medium risk 100-199
3 High risk 200-299
4 Very high risk ≥ 300
Optionally the Change in Customer Risk detection model can be run in No Threshold mode, in
which case an alert is generated regardless of any threshold values that are defined. This allows
the model to be run more than once a day on the same data.
When an alert is generated for this alert type, analysts can view the alert within the main Alert List
and can directly access, from the alert, the relevant customer’s Risk Factor Scores (see
Each customer-risk score is based on risk factor scores assigned by the High Risk Customer
model (CDD-HRB) (see Section 4.1: High Risk Customer (CDD-HRB), page 19).
Detection Logic
1. Retrieve the latest customer total risk score that was calculated by the CDD-HRB model (see
above), or by the CDD-INR model.
2. Calculate a new customer total risk score.
3. Retrieve risk levels for the previous and current risk scores.
4. If running in No Threshold mode, generate an alert for each scanned customer.
OR
5. If running in regular mode, generate an alert if:
 Risk level increased by at least No. of Risk Levels Increased threshold levels since last
scoring
OR
 Risk level decreased by at least No. of Risk Levels Decreased threshold levels since
last scoring
OR
 Risk score increased by at least Points of Risk Score Increased threshold points since
last scoring
OR
 Risk score decreased by at least Points of Risk Score Decreased threshold points
since last scoring
OR
 Risk score increased by at least Percentage of Risk Score Increased threshold
percentage since last scoring
OR
Identity Verification Issues (CDD-CIP)
 Risk score decreased by at least Percentage of Risk Score Decreased threshold

percentage since last scoring.
Thresholds
The business analyst is able to adjust the following threshold values using options available
within the Actimize Risk Case Manager:

Value
No. of Risk Levels Sets the minimum number of levels between the 1
Increased previous and current risk levels (that the level
increased) from which an alert is generated.
No. of Risk Levels Sets the minimum number of levels between the 2
Decreased current and previous risk levels (that the level
decreased) from which an alert is generated.
Points of Risk Score Sets the minimum number of points between the 10
Increased previous and current risk scores (that the score
increased) from which an alert is generated.
Points of Risk Score Sets the minimum number of points between the 20
Decreased current and previous risk scores (that the score
decreased) from which an alert is generated
Percentage of Risk Sets the minimum percentage of risk score 10
Score Increased increase between the previous and current risk
scores from which an alert is generated.
Percentage of Risk Sets the minimum percentage of risk score 20
Score Decreased decrease between the current and previous risk
scores from which an alert is generated.
Scoring
Scores are calculated based on active risk factors. For more information about Risk Factors see
Section 3.2: Risk Factor Score Calculation, page 12.
4.3 Identity Verification Issues (CDD-CIP)

The Identity Verification Issues (CDD-CIP) model is run in conjunction with the financial
institution’s existing Customer Identification Program. The program is responsible for collecting
identification details from the customer, based on the requirements of the local regulations, and
for verifying the customer’s identity.
There may be more than one CIP record per customer. For example, if the customer has multiple
accounts there may be a CIP record for each account, or if there were changes made to a CIP
record over time there will be additional records as changes were made, or if there were
corrections made to a CIP record, etc.
There are two standard methods for conducting identity verification: documentary and non-
documentary. An organization can deploy either method or a combination of both, depending on
the local regulations and the organization’s policies.
Documentary identity verification means that the customer has to present certain identification
documentation (e.g. national identity card, driver’s license, passport, bill, etc.). Non-documentary
identity verification means that the financial institution collects the mandatory CIP information
from the customer and verifies identity using identity verification applications or services. Identity
verification applications typically have access to confidential databases and can confirm whether
the details supplied match the government data (e.g. does the name associated with the ID
number match the name in the government records).
The Identity Verification Issues model tracks an institution’s documentary and non-documentary
customer information, and disseminates alerts upon detection of missing or incomplete
information, based on the Customer Identification Program requirements. This model assists the
financial institution to meet the mandates of the regulations, which require identification of key
information such as:
• Customer Name
• ID number
• ID type (when more than one type of ID is allowed)
• Date of birth
• Customer address
When an alert is generated for this alert type, analysts can view the alert within the main Work
Items Alert List and can directly access, from the alert, the relevant customer’s CIP records. For
more information about Customer’s CIP Records, see Section 6.2.6: Reviewing CIP Records,
page 60.
Detection Logic
1. Read all new discrepancy records from a discrepancy report (supplied by the client).
NOTE:
Each time CIP data is analyzed and a discrepancy is found, a new record is created.
2. Aggregate all new discrepancy records, per customer.
3. Generate an alert for each customer with new aggregated discrepancy records.
Scoring
The business analyst is able to adjust the following default score value using options available
Score Factor Name Description Default

Value
Default Score for Sets the default score assigned for each 100
Discrepancy Alerts CDD-CIP alert.
Documentary Tracking (CDD-DOC)
4.4 Documentary Tracking (CDD-DOC)

The Documentary Tracking model tracks the status of the customer’s documentation, including
identity and certification documents, and detects any incomplete or insufficient documentation,
ensuring compliance with the organization’s policies.
This model looks for the following issues:
• Mandatory documents that are incomplete (i.e., missing or late)
• Mandatory documents that are past their due date
• Renewable documents that have expired
• Renewable documents that are about to expire
The model generates an alert when an issue is found in connection with any of the client’s
documentation. It continues to generate reminders (in the form of alerts) until the documentary
issue is resolved, based on a configurable reminder schedule. The frequency of reminders
depends on the type of document and the organization’s documentary requirements.
The following is an example of a reminder schedule:
Document From Frequency Period

Requirement Code (days) (days)
SAR MSB -60 30
SAR MSB -30 15
In the above example a SAR MSB (Suspicious Activity Report by Money

Services Business) certification will trigger an alert 60 days before the renewal
date. The above schedule will then trigger an additional alert (reminder) 30
days before the renewal date and every 15 days until the renewal date is reset
or the document is no longer required for the customer.
This model can also track the status of documents that are created within the RCM Work Items
module and can generate alerts if incomplete or insufficient documentation is detected (see
Section 6.3.3: Document Management, page 64).
Documents can be categorized into different document groups, thereby enabling the solution to
distribute separate alerts per document group. Each document group can be configured to
include one or more document type. For example: If one business group within the organization is
investigating SARs and another business group is investigating a different type of document, then
the model distributes alerts with the appropriate data to each of the appropriate business group of
users.
When a document type is associated with more than one document group, multiple alerts are
generated, one for each document group, including the relevant document type.
The following is an example of alert distribution to multiple document groups:

The Documentary Tracking model detected issues associated with 2 different
document types for the same customer. Each document type is associated
with a document group. In this case, multiple alerts are generated for the same
customer on the same day to different document groups.
Document ID Document Type Document Group

111 SAR FIU
222 CTR FIU
333 OFAC Default
In the above example, a total of two alerts would be assigned for this
customer: one alert would be distributed to the ‘FIU’ Document Group, and a
separate alert would be distributed to the Default Document Group.
If different business groups are not defined for different document types, then
there would be only one alert for the customer for detected issues that refer to
all document types.
Detection Logic
1. For each customer document that was updated since the last time the model ran:
 If Requirement Priority Code is on the Mandatory Documentary Requirements list,
then the Document is Mandatory.
 If the Document Status Code is on Incomplete Document Status list, then the
Document is Incomplete.
 If the Document Requirement Code is on Renewable Documents list, then the
Document is Renewable.
2. If the Document Requirement Code is within the Incomplete Document Reminder
Schedule list, then retrieve the appropriate Document Due Date from the client data and
perform the following:
a. Calculate Difference value = Document Due Date - Current Date.
b. If Difference Value ≤ ABS (From value in days), then the Document Is Relevant for
Incomplete Document Review.
c. Retrieve the Frequency Period associated with the From value within the Incomplete
Document Reminder Schedule list. If Difference Value ≤ ABS (From value) for more
than one From value, take the MIN(ABS (From value in days) for retrieving the
frequency.
3. If the Document Requirement Code is within the Document Renewal Reminder Schedule
list, then retrieve the appropriate Document Expiration/Renewal Date from the client data
and perform the following:
a. Calculate Expiration Difference value = Document Expiration/Renewal Date - Current
Date.
b. If Expiration Difference value ≤ ABS (From value in days) then Document Is Relevant
For Renewable Document Review.
c. Retrieve the Frequency Period associated with the From value within the Document
Renewal Reminder Schedule list.
If Expiration Difference value ≤ ABS (From value) for more than one From value, take
the MIN(ABS (From value in days)) for retrieving the frequency
4. Generate alert if:
Document is Mandatory and Document is Incomplete and Document Is Relevant for
Incomplete Document Review and no alert was created in the current Frequency Period,
based on the Incomplete Document Reminder Schedule.
OR
Documentary Tracking (CDD-DOC)
Document Is Mandatory and Document Is Renewable and Document Is Relevant for

Renewable Document Review and no alert was created in the current Frequency Period,
based on the Document Renewal Reminder Schedule.
NOTE:
All documentary issues are consolidated into a single alert per document group on the customer level.
Lists
The business analyst must populate the relevant lists using options available within the Actimize
Risk Case Manager:
List Name Description

Mandatory Documentary A list that enables the user to enter the
Requirements document’s Requirement Priority Code that
indicates which documents are evaluated by the
model.
Incomplete Document Status A list that enables the user to enter the Document
Status Code that indicates that the document is
incomplete.
Incomplete Document Reminder A scheduler which enables the user to enter the
Schedule Document Requirement Code, the ‘From’ value
and the ‘Frequency’ for generating reminders (see
example in the Model Description above).
Renewable Documents A list that enables the user to enter the Document
Requirement Code that indicates that the
document is renewable.
Document Renewal Reminder A scheduler which enables the user to enter the
Schedule Document Requirement Code, the ‘From’ value
and the ‘Frequency’ for generating renewal
reminders (see example in the Model Description
above).
Scoring

Value
Default Score for Document Sets the default score assigned for 100
Tracking Alerts each CDD-DOC alert.
4.5 Periodic Review (CDD-PRE)

The Periodic Review (CDD-PRE) model helps organizations maintain a risk based periodic
review process for customers, and ensures that reviews are conducted in a timely manner.
The model calculates the date of the next required review for each customer, based on the last
review date and the customer’s risk level. The review period is based on a configurable review
schedule, which can be adjusted to the organization’s policy.
For example:
Risk Level Risk Level Name From Score Periodic Review (Days)
1 Low risk 0-99 -
2 Medium risk 100-199 365
3 High risk 200-299 180
4 Very high risk ≥300 90
When calculating the next review date, the model also takes into account reviews that were
conducted outside of the normal review schedule, for example due to some other CDD issues
identified by the system.
When the customer is due for a review, the CDD-PRE model automatically generates an alert into
a special work queue to notify the relevant team that a review should be conducted, thereby
ensuring that periodic review policies and procedures are applied without fail.
The following is a business example of Periodic Review alerts:

A new customer opened an account on January 9, and was identified as high
risk. As a result an initial EDD review was conducted at account opening, and
completed on January 14. According to the organization’s policies, a periodic
review of high-risk customers should be conducted every 6 months, so the
next review date was automatically set to July 14.
On February 23, an alert was generated for this customer due to expired
certification. In addition to collecting the required documentation, the analyst
conducted a second review of the customer, and determined that the
customer’s risk level should be increased to Very High Risk. This review was
completed on February 27, and the adjusted risk level required a review every
3 months, so the next review date was re-set to May 23.
On May 23 a Periodic Review alert was generated. The analyst reviewed the
customer and their activities since opening the account, determined that no
unusual activity has been conducted, and closed the alert on May 25. The next
review date was automatically set to August 25.
Detection Logic
1. Determine the Review Period based on the customer risk level (see Section 2.1.5: Detection
and Alert Generation, page 7).
2. For each customer related alert retrieve Related Cases.
3. Calculate Customer Last Review Date = the latest of:
a. Last review date from Party Table.
b. Last date the customer was reviewed based on the customer status. A customer is
considered reviewed if the customer status is on the Customer Reviewed Status list.
Expected Behavior Deviation (CDD-EBD)
c. Last date the customer alerts were reviewed based on Alert Type and Alert Status. An
alert is considered reviewed if the alert status is on the Customer Reviewed Alert
Status list and the Alert Type is on the Customer Reviewed Alert Type list.
d. Last date the Related Cases were reviewed based on Case Type and Case Status. A
case is considered reviewed if the case status is on the Customer Reviewed Case
Status list and the Case Type is in the Customer Reviewed Case Type list.
4. Generate alert if: Customer Last Review Date + Review Period is before or on the current
date then customer is relevant for review.
Lists
Risk Case Manager:

Customer Reviewed Statuses A list that that indicates which customer
statuses should be reviewed. The user enters
values for the relevant customer statuses in
the list.
Customer Reviewed Alert Statuses A list that indicates which alert steps should
be reviewed. The user enters values for the
relevant alert statuses in the list.
Customer Reviewed Alert Types A list that indicates which alert types should
relevant alert types in the list.
Customer Reviewed Case Types A list that indicates which case types should
relevant case types in the list.
Customer Reviewed Case Statuses A list that indicates which case statuses
should be reviewed. The user enters values
for the relevant case statuses in the list.
Scoring

Value
Default Score for Sets the default score assigned for each 100
Periodic Review Alerts CDD-PRE alert.
4.6 Expected Behavior Deviation (CDD-EBD)

The Expected Behavior Deviation (CDD-EBD) model helps organizations monitor a customer’s
on-going activities compared to that customer’s expected activity, based on customer
declarations. Any major deviation will result in an alert. This helps to ensure that any significant
deviation between a customer’s financial activities and anticipated activity receives attention for
additional scrutiny.
On a monthly basis the model performs activity comparisons for a customer and a customer’s
accounts. The model looks at the total volume and value of transactions for that month and if the
activity exceeds the anticipated (i.e., previously declared) monthly activity by a pre-defined
percentage, then an alert is triggered.
The financial institution can configure which related account activity should contribute to the
monthly sum of activities. The model can retrieve profile data for an account or customer from a
variety of sources, including Actimize AML-SAM or other data sources.
The following is a business example of an Expected Behavior Deviation alert:

A new customer opened an account on January 1 and indicated, in a
declaration, that the monthly value of deposit activities would be around
US$50,000.
The financial institution determines that activities in excess of 15% of the
anticipated activities should trigger an alert.
In the month of January, the customer’s account shows US$54,000 in
deposits, which does not trigger an alert.
In the month of February the customer’s account shows a total of US$58,000
in deposits. This does trigger an alert since the sum of the deposits for
February exceeds the anticipated monthly deposit activities of US$50,000 by
more than 15%.
Detection Logic
1. Calculate Sum of Customer Activity for the previous month based on Transaction Type
Codes for Monthly Activity list.
If customer activity is calculated based on related accounts, then identify customer related
accounts based on the Relation Types list and calculate activity as sum of related account
activity.
2. If Sum of Customer Activity ≥ Minimal Monthly Activity threshold
Then
a. For each service type, retrieve Account Expected Monthly Value
b. For each service type, retrieve Account Expected Monthly Volume
c. For each service type, retrieve or calculate Customer Expected Monthly Value
d. For each service type retrieve or calculate Customer Expected Monthly Volume
e. For each service type, calculate the Account Profile Monthly Value
f. For each service type, calculate the Account Profile Monthly Volume
g. For each service type, calculate the Customer Profile Monthly Value
h. For each service type, calculate the Customer Profile Monthly Volume
3. Generate alert if, for one or more service types:
o Account Profile Monthly Value exceeds Account Expected Monthly Value by at
least Percentage Exceeds Expected Account Monthly Value threshold.
OR
o Account Profile Monthly Volume exceeds Account Expected Monthly Volume by
at least Percentage Exceeds Expected Account Monthly Volume threshold.
OR
o Customer Profile Monthly Value exceeds Customer Expected Monthly Value by
at least Percentage Exceeds Expected Customer Monthly Value threshold.
OR
Expected Behavior Deviation (CDD-EBD)
o Customer Profile Monthly Volume exceeds Customer Expected Monthly Volume

by at least Percentage Exceeds Expected Customer Monthly Volume threshold.
Thresholds and Settings


Value
Minimal Monthly Sets the minimum amount of monthly activity 5,000
Activity that is considered of interest for this model.
Percentage exceeds Sets the percentage that the actual account 15%
Expected Account value exceeds expected value, from which an
Monthly Value alert is generated
Percentage exceeds Sets the percentage that the actual volume of 15%
Expected Account activity for the account exceeds expected
Monthly Volume volume, from which an alert is generated
Percentage exceeds Sets the percentage that the actual value of 15%
Expected Customer customer activity exceeds expected value,
Monthly Value from which an alert is generated
Percentage exceeds Sets the percentage that the actual volume of 15%
Expected Customer activity for the customer exceeds expected
Monthly Volume volume, from which an alert is generated
Scoring

Value
Default score for EBD Sets the default score assigned for each 100
alerts CDD-EBD alert.
Lists
Risk Case Manager:

Transaction Type Codes The user populates this list with the codes of transaction
for Monthly Activity types that are used for calculation of monthly activity.
Relation Types A list that enables the user to enter the relation types
between customers and related accounts (e.g. owner,
beneficiary etc). These relations are used for calculating
related account activity. If this list is left empty, all relation
types are used.
4.7 Trigger Events

CDD models are run when specific trigger events occur. The models are part of an end of day
process that collects all the trigger events of that day and determines the customer population
that is impacted by these events.
The relevant customers’ profiles are updated and their risk score is re-calculated. Then model
analytics identify CDD issues based on the new profile.
The following events are CDD triggers:
Event Impacted customer population

New customer opens account All new customers from the current business
day
Existing customer opens new account All customers related to accounts opened on
the current business day
Customer details changed All customers who had a change of details
made on the current business day
Customer score changed by risk All customers for whom a risk adjustment
adjustment change was made during the current
business day
Watch list is updated All customers
Implementation specific event. The impacted customers depend on the
The solution provides implementers specific logic implemented
with the ability to define criteria for
triggering events.
Chapter 5: On-Boarding Parties
The Actimize AML-CDD solution enables representatives of the financial institution to on-board
new parties, or entities, via a coordinated series of pre-defined questions that are presented in
the On-Boarding tab. For each new customer, an on-boarding client alert is generated, and a
customer record is created. Users can view and process on-boarding client alerts like other alert
types (as explained in Chapter 6: Review and Investigation, page 56).
5.1 Overview
The on-boarding procedure is fully configurable. First, business analysts need to define a
question flow for different party types that will be on-boarded via the normal on-boarding forms or
web services. This analytical process of defining a question flow consists of:
• Creating questions
• Defining possible answers
• Organizing questions into sets
• Determining the flow of questions (when to ask certain sets of questions).
After defining the question flow, authorized implementers can configure the on-boarding process
by performing the following:
• Creating party types – Different types of parties can be defined for on-boarding, and each
party is presented with its own set of questions during the on-boarding process.
• Organizing question sets into tabs – A series of predefined questions is presented to the
prospective Financial Institution officer user (typically the on-boarding Relationship Manager).
Questions and answers are recorded by the Actimize AML-CDD solution for risk scoring.
High-risk customers may need to answer enhanced due diligence (EDD) questions that are
displayed in the EDD tab.
• Defining Next Set expressions – Supplementary questions may be presented to the
customer based upon answers already provided. Dynamic on-boarding forms are created
automatically based on available data in the Q&A engine. When data in the Q&A engine is
updated, the forms are automatically updated.
Authorized users can configure the on-boarding process via the following options:
• On-Boarding Config tab
• Settings > References > On-Boarding action menu
• Questions & Answers option of the Settings > References > CDD action menu
See the Actimize AML-CDD Implementer’s Guide for more information about configuration.
In order to perform on-boarding of new parties, the user (typically the on-boarding Relationship
Manager) must be assigned special permission.
The workflow may have been configured according to your business policy to approve or reject
submitted parties. By default, such workflow steps are not configured, but may have been
provided by Actimize Professional Services as a special customization.
On-Boarding Parties
5.2 Locking Mechanism and Auto-Expiry

In general, when an on-boarding record is being created, the logged-on RCM user becomes the
owner of the new party record, and automatically locks the record. Only the owner can modify,
save, or submit the party record.
Other users who try to open the party record see a message that the record is locked, but can
open a read-only version instead.
The lock is removed when:
• The on-boarding record is submitted and accepted.
• A configurable auto-expiry period has elapsed.
Authorized users can configure the duration of this auto-expiry mechanism via Settings >
References > CDD > Technical Parameters > On-boarding Lock Expiry in Minutes.
5.3 Search Restrictions According to Business Unit

The Actimize AML-CDD solution enables financial institutions to restrict the results of both on-
boarding and customer searches to authorized users only. To enable the search restriction
function, authorized implementers need to follow the procedure described in the Actimize AML-
CDD Implementer’s Guide.
The restriction of search results is based on both the:
• Business unit of the business user who initiated the search, assuming that the business unit
belongs to a predefined hierarchy, and
• Business unit of the party that met the search criteria (a party can have one or more business
units).
Authorized business users who are assigned a super user role can view the results of all
searches without restrictions.
NOTE:
If a party does not have any business unit assigned to it, it is displayed in the search results only
to super users.
The following diagram illustrates a hierarchy of business units. Business users can belong to any
business unit of the hierarchy:
On-Boarding a New Party
Based on the above diagram, if a user belongs to the business unit called BU_B, which appears
as a sub-business unit for BU_A, then the user is exposed to the data of parties that are
associated with the following business units: BU_B, BU_D, and BU_E.
NOTE:
If a business unit belongs to more than one hierarchy, then users who are assigned to this
business unit might be exposed to customer data pertaining to all hierarchies, based on the
above logic.
5.4 On-Boarding a New Party

This section describes how to initiate, validate, and submit the on-boarding process in order to
create an On-Boarding Client alert and new customer record.
The On-Boarding process involves the following steps:
 In the On-boarding tab, click the Party Type link to open an onboarding questionnaire.
 Enter the party details in each tab.
 Save to add the new onboarding customer record.
 Navigate to the Summary tab to review.
 Validate for the AML-CDD solution to verify entered details.
 Fix any issues until all entered details are valid.
 Submit; the On-boarding Client alert is then investigated.
 The new party is accepted or rejected through the On-boarding Client alert actions.
5.4.1 Initiating the On-Boarding Process

To perform on-boarding of a new party:
1. Select the On-Boarding tab at the top of the RCM application.
2. When the forced on-boarding search mechanism is turned off (default setting), you can
either search for an existing party, or start on-boarding a new party (links displayed in red in
screenshot above).
3. When the forced on-boarding search mechanism is turned on (configurable), you must first
check whether a customer already exists (the new on-boarding links are not displayed in the
screenshot above). The AML-CDD solution does not allow you to on-board a new party
without first searching if the customer already exists, in order to prevent on-boarding
of existing parties. Use the Basic Search fields at the top of the tab to check if a party
On-Boarding Parties
already exists in the Actimize AML-CDD database. This applies to both Advanced and
Related searches.
NOTE:
The new on-boarding links are only displayed after performing a search, and verifying that the
customer does not exist in the Actimize AML-CDD database.
 If the customer already exists in the Actimize AML-CDD database, you can view, and
optionally modify, an existing on-boarding questionnaire for a party who is either in the
On-boarding or Approved state.
 If the customer does not exist in the Actimize AML-CDD database, the message “No
results were found with the search criteria” appears and the new on-boarding links are
displayed. You can then proceed to on-board the new party.
For information on how to configure the forced on-boarding search mechanism, refer to the
Actimize AML-CDD Implementer’s Guide.
4. Click the relevant party type link to begin on-boarding a new party. Party types depend on
how your deployment has been configured, but might typically include Individual and
Organization.
The relevant party type questionnaire opens. Questions are organized in several tabs,
according to the configuration that has been created for the chosen party type.
NOTE:
Different party types may be used to distinguish between parties for different lines of
business (e.g. mortgage – account opening, loans – guarantees, etc.).
If you leave all search fields blank when you perform the search, all the on-boarding records
will be displayed.
5. Enter the details into the On-Boarding Questionnaire page. As you enter the party’s
responses to these questions in the Questionnaire page, a read-only summary of details that
have been entered is added to the Summary tab on the right of the page.
6. Click Save at any stage of the on-boarding process to save your input.
A new on-boarding party record is added, and the Party Information Highlight bar appears at
the top of the window. The on-boarding party is not added to the Customers list until it is
accepted.
NOTE:
At any stage during the on-boarding process you can quit by clicking the Cancel button. A
message appears warning you that you will lose any information you have not yet saved.
In general, when completing an on-boarding record:
 Mandatory fields marked with an asterisk (*) – You will not be able to submit the new
record unless these fields contain verifiable data.
 Online help fields followed by a question mark ( ) – By hovering your cursor over this
mark you invoke a tooltip containing any description of the field that was included when it
was configured (if applicable). By clicking the mark you will invoke a new window
containing the page of online help that was associated with the field when it was
configured (if applicable).
7. Select each tab in the On-Boarding Questionnaire page to bring it forward and continue
entering party details.
Typical tabs in the On-Boarding Questionnaire page might appear as follows:
On-Boarding Parties
Question Types
A question that is configured to be dynamic depends on the answer already supplied to another
question. For example, selecting “USA” as the country of residence may populate a drop-down
list of appropriate states:
In another example, when you select a certain answer to one question, a set of applicable follow-
up questions may be displayed, which were not applicable (and hidden) if you had chosen a
different answer.
In the example below, if “None Available” is selected for the Identification Number Type, then the
“Please Explain” field appears prompting the user to provide an explanation.
A multiple-type question permits users to select more than one answer from a list:
8. Click Save at any stage to add a new customer record on the database.
When you save the record for the first time, the Party Information Highlight section is
added at the top of the page as shown in the following example.
The fields displayed here are configurable for your deployment, and you can collapse the
section if you want.
At this stage, the customer record’s status is On-Boarding.
At any stage, saving the record applies a data integrity check on answers entered so far and
any syntax errors will be reported. Each subsequent save, validate, or submit operation will
update the customer record.
An alert of the On-boarding Client type is generated, which can be viewed in the RCM
Workbench > Work Items list. At this stage, the alert’s status is Still in On-Boarding process,
and no customer details are presented.
9. When you are satisfied with the answers entered in all tabs of the On-Boarding Questionnaire
page, navigate to the Summary tab to review the questions and answers supplied.
The Summary tab includes basic details of the party record, the user who created it and
expandable sections for each of the tabs of the On-Boarding Questionnaire page.
10. Click Validate. The solution verifies the input details.
 If any fields do not contain input, these are highlighted on the Summary tab.
 If any mandatory fields do not contain verifiable input, a warning message is displayed.
11. Return to previous tabs of the On-Boarding Questionnaire page to complete missing details
as necessary.
12. When all required details have been entered, click Save and then return to the Summary tab.
 Click Validate. If all mandatory fields are validated, the solution performs a basic risk
scoring check and presents the results in the Summary tab. If the calculated risk level
exceeds the configured threshold, an additional set of Enhanced Due Diligence (EDD)
questions is added to the On-Boarding Questionnaire page. For information on how to
complete the EDD tab, see Section 5.4.2 Enhanced Due Diligence (EDD) Tab.
On-Boarding Parties
 If the calculated risk level is below the configured threshold, a message is displayed
confirming the successful validation. Click Submit in the Summary tab to complete the
process. A message is displayed confirming the successful submission.
On-Boarding Under Review

After submitting a customer for on-boarding, the On-boarding Client alert is updated to include all
new party details, risk score, and a calculation of the party’s risk level. The party record’s status is
updated to On-boarding under review.
Depending on configuration, party data can be sent to external bank systems upon submit.
While the record is in On-boarding under review status, the party’s profile is frozen, and an on-
boarding client alert is generated.
The on-boarding entry is locked for editing until the party is accepted as a client. Any user with
access to the On-Boarding tab can search for the party, and open the party’s On-Boarding
Questionnaire page in read-only form. In this form all the entry fields are grayed out, and no Save
or Submit buttons appear at the bottom of the page.
When in On-boarding under review status, the party record can be modified only by the RCM
owner. The party record can be exported to PDF.
NOTE:
A user who is not assigned the OB_EditAllowed role will always see a read-only version of an
on-boarding record.
5.4.2 Enhanced Due Diligence (EDD) Tab

If the initial risk score exceeds a configured threshold when validating a customer, an enhanced
due diligence (EDD) process is usually initiated.
The Enhanced Due Diligence tab can be configured by implementers to behave as follows:
• Default – High-risk customers must answer the additional EDD questions in order to create
an on-boarding record. The EDD tab is usually hidden, and appears only after validation if the
score threshold is exceeded (after answering all questions). Implementers need to define the
risk score threshold for displaying the EDD tab.
NOTE:
Once the EDD tab becomes applicable, it remains displayed even if answers are changed
during the on-boarding process, and a risk score below the defined EDD threshold is
obtained.
• Configurable – Depending on your configuration, certified implementers can define custom
business rules to initiate the Enhanced Due Diligence (EDD) process from the beginning of
the on-boarding questionnaire. The EDD tab is displayed from the beginning of the on-
boarding questionnaire throughout the process.
An example of pre-empting Enhanced Due Diligence questions is for US lines of business
that serve a non-US party. Once the user selects “US PFS” LOB and “Non-US Citizen,” and
clicks Save, the EDD tab is displayed. In this case, the user can ask the prospective
customer EDD questions before completing the rest of the mandatory questions.
To complete the Enhanced Due Diligence (EDD) form:

1. Navigate to the appropriate tab (e.g. the EDD tab, depending on your configuration) and
answer the additional questions.
If an EDD tab contains no currently applicable questions for the record, an appropriate
message is displayed. Note that further questions may be displayed depending on answers
you enter after saving.
2. When the EDD questions have been answered, return to the Summary tab and click Save
and Validate until no errors are detected.
The AML-CDD solution repeats the basic risk scoring check and presents the results in the
Summary tab.
3. Only when no validation errors are detected, click Submit in the Summary tab to complete
the process. A message is displayed confirming the successful submission.
On-Boarding Parties
On-Boarding Risk Level for Enhanced Due Diligence

You can control the thresholds used to determine whether EDD questions should be answered
via Settings > Thresholds > On-Boarding > Risk Level Threshold and Risk Score
Threshold.
5.4.3 Summary Tab in On-Boarding Record

The Summary tab displays the following buttons:
• Clone – Creates a copy of the existing record, including all questions that were configured as
clonable. This feature allows you to clone a party from the party itself.
• Generate PDF – Enables you to create a printable hard copy of the questions and answers
for the current party.
• Save – Saves the on-boarding information to the AML-CDD database.
• Cancel – Quits the on-boarding process. A message appears warning you that you will lose
any information you have not yet saved.
• Validate – Checks that there are no errors in the on-boarding data and displays a list of
validation errors, if there are any.
• Submit – Only displayed when no errors are detected.
5.5 Viewing the On-Boarding Client Alert

An On-Boarding Client alert is created as soon as the on-boarding record is submitted.
On-boarding Client alerts can be viewed by selecting RCM Workbench > Work Items, optionally
filtering by the alert type.
Workflow definition and additional customization enables authorized users to do the following:
• Accept or reject the submitted party.
• Further investigate the On-boarding Client alert.
• Cancel the process.
Viewing the On-Boarding Client Alert
See Chapter 6: Review and Investigation, page 56 for more information about alerts.
An alert is created for a new on-boarding record the first time the user clicks the Save button.
Until the new party record has been submitted the alert’s Party Name column will be blank and
you will not be able to view any details within it.
If you click the link in the Item ID column a message is displayed as follows:
When the party record is submitted, the Party Name column will be completed and you can view
details by clicking the link in the Item ID column. The alert captures a read-only snapshot of the
party’s profile.
The Customer Highlights section at the top of the alert displays the party’s name, customer key,
score, risk level and alert status. The details that were displayed in the Summary tab of the On-
Boarding Questionnaire page are also displayed on the On-boarding Questionnaire tab of the
alert.
On-Boarding Parties
Other details may be displayed in the Customer Profile tab, depending on how the questions are
configured. The Risk Scoring tab, which is displayed by default, may enable an authorized user to
decide whether or not to accept the on-boarding party as a customer of the institution.
5.5.1 View Party History

The View Party History option displays an audit of all changes made to parties during the on-
boarding process.
To display the party’s history during the on-boarding process:

1. Select RCM Workbench > Work Items, and select the Onboarding Client alert item by
marking the checkbox on the left side.
2. In the Actions menu, click the View Party History link.

3. Alternatively, click the View Party History link from the Alert Details page. The Party History
screen opens, as shown below:
Relating a New Party to the Current Party
A list of all the actions performed on the alert is displayed, including answers to on-boarding
questions, and any updates to those answers that may have been entered.
5.6 Relating a New Party to the Current Party

Depending on your configuration, the On-Boarding Questionnaire page allows you to add a party
who is related to the party currently being on-boarded during the on-boarding process. The
related party may already exist in your system database, or may need to be added as a new
record.
This feature depends on the On-Boarding Questionnaire page having been configured with a tab
for entering related parties. You must also have clicked Save to create a customer record for the
parent party (the party currently being on-boarded).
5.6.1 Searching for an Existing Related Party

The Actimize AML-CDD solution is delivered with a configurable forced on-boarding search
mechanism, which mandates users to search for an existing related party in the database when
adding a related party. By default, the forced on-boarding search mechanism is turned off, but it
should be turned on in order to prevent users from creating a new related party that already exists
in the database.
For information on how to configure the forced on-boarding search mechanism for advanced and
related searches, refer to the Actimize AML-CDD Implementer’s Guide.
To search for an existing related party when on-boarding a new party:

1. Navigate to the appropriate tab of the On-Boarding Questionnaire page (e.g. Related
Parties).
On-Boarding Parties
2. Click the Search Existing link to open the Related Party Search window. If the forced on-
boarding search mechanism for related parties is turned on, you must first search for an
existing party in the AML-CDD database. This mechanism prevents the user from creating a
new related party that already exists in the database.
A new window opens containing the following fields enabling you to search for the relevant
party. The available search fields depend on your configuration.
The above search options are the defaults, but your deployment may have been customized
to use other search fields, or to allow selection from drop-down lists. When the search is of
the exact or partial match type, it is also configurable per field.
4. Enter the relevant details and click Search.
The results of any party records matching the search are displayed, as shown in the example
below.
If more than 1000 party records match the search criteria, a message is displayed asking you
to enter further search values so as to narrow the search. If your user permissions deny you
access to any of the parties that would have been returned by the search, a message is
displayed to notify you accordingly.
5. Click the link in the CSN column of the search results to select the party as the basis for the
new on-boarding related party.
The new party is entered in the Related Parties tab of the current party. The details of the
related party are not editable within the Related Parties tab.
6. Proceed to Section 5.6.3 Adding a Related Party to the Current Party to add the selected
related party to the current party being on-boarded.
5.6.2 Selecting a Related Party

There are two ways of selecting a related party, depending if your AML-CDD solution is
configured to use the forced on-boarding search mechanism or not:
• By default, the configurable forced on-boarding search mechanism is turned off, so that
related party links are displayed in the Related Party Search window. The user can choose to
either search for an existing related party, or select a new related party (as shown in the
screenshot below).
• If the configurable forced on-boarding search mechanism is turned on, users must first
search for an existing related party in the database when adding a related party. If the related
party does not exist in the database, only then are the new related party links displayed (as
shown in the screenshot below):
To select a new related party:

1. Click the relevant Select a Related Party link in the lower part of the screen.
On-Boarding Parties
A version of the On-Boarding Questionnaire page is displayed in the window with appropriate
entry fields and options enabling you to identify the party.
entering the party’s details as usual.
4. Save the new on-boarding record.
A message appears in the Related Parties tab of the “parent” party indicating that the party
relationship has been recorded and the highlights of the related party will be shown when you
click Save. The details of the related party are not editable within the Related Parties tab.
NOTE:
The related party record is added to the party profile as a new party.
5. Proceed to step 2 in Section 5.6.3 Adding a Related Party to the Current Party to add the
selected related party to the current party being on-boarded.
5.6.3 Adding a Related Party to the Current Party

To add a selected related party to the current party:
1. Once you identify the related party you should save, but not submit it. Submitting the current
party includes the details of any other parties that are related to it.
Once you select the required related party, a line is added at the top of the Related Parties
tab showing basic highlights of the chosen party. The fields that appear here are configurable
for your deployment.
2. From the Relationship Type drop-down list, select an option to indicate how this party is
related to the current party, such as “Is the Spouse of” or “Company Director.”
This field is mandatory and if you forget it your related party may become an orphan (see
Section 5.6.4 Orphan Related Parties).
3. Click Save to save the update to the current party record.
Additional links appear as follows:
• Remove – Enables you to remove the party-party relationship. A message appears
reminding you to save the record to confirm this action. Note that this does not delete the
related party’s source record, which remains active on the system.
• Show Details – Enables you to open a Related Party Details window to confirm you chose
the correct related party.
• Add – Enables you to add a new box containing a set of links to define another related party
by either of the methods described above (create new or search existing). The following
screenshot shows two related party boxes:
4. When you finish adding party-party relationships, you can click Save and validate the record.
5.6.4 Orphan Related Parties

When continuing, if you forget to choose a relationship from the mandatory Relationship Type
drop-down list, an error will be displayed when you validate the record. However, the newly
created related party will have been added to the system as an orphan. In this case you should
search for the orphan as explained in Section 5.6.1 Searching for an Existing Related Party rather
than create it again.
On-Boarding Parties
5.7 Cloning an On-Boarding Record

A party can be cloned to create a record with details that partially match those of the existing
party.
You can either create a clone either from the:
• Summary tab – Create a clone from a new party.
• Search results – Create a clone from one of the records displayed in the party search
results.
A clone is a copy of the existing record, and includes all responses entered during the on-
boarding process to questions that were configured as Clonable.
See the Actimize AML-CDD Implementer’s Guide for more about configuring questions.
5.7.1 Cloning from the Summary Tab

When on-boarding a new party in the Actimize AML-CDD solution, you can create a clone from it
in the Summary tab.
The existing party’s record may not have been reviewed yet, but as a minimum requirement you
must click Save to create a customer record for it.
To create a clone from an existing party in the Summary tab:

1. When on-boarding a new party in the Actimize AML-CDD solution, click Clone in the
Summary tab to clone a party from the party itself.
The cloned party’s type defaults from the source party.

2. If the cloned party has any related parties saved, or requires EDD information, the following
screen appears:
Cloning an On-Boarding Record
3. Select the relevant checkboxes to clone the information from the Related Parties and
Enhanced Due Diligence (EDD) tabs.
If the original party only has related parties, or only EDD information, then only the relevant
checkbox is displayed. If the original user has neither, then this screen is skipped entirely,
and the cloned party is displayed.
NOTE:
If the user selects to clone EDD information from a specific party, then the cloned party is set
to EDD Required, and the EDD tab is visible. The EDD tab behaves in the same way as if it
would be required due to high risk scoring, although no scoring has yet been done. Whether
the individual answers are also cloned depends on the setting of the clonable flag for those
questions.
4. Click Submit to display the new cloned party with the related party and EDD information.
5. The fields are already populated from the original party record. You can edit the fields as
required to create a version of the selected record.
entering the party’s details as usual.
7. For any questions where answers have defaulted from the source, you can choose
replacement values as required.
8. Save, validate and submit the new on-boarding record to complete the process. The same
messages are displayed to the screen as when creating any other on-boarding record and
you may be expected to fix syntax errors or answer enhanced due diligence (EDD) questions.
 If an On-boarding Client alert already exists for the party, then it is updated.
 If no On-boarding Client alert exists for the party, then an alert is generated.
5.7.2 Cloning from the Search Results

You can create a clone from one of the records displayed in the party search results. For
example, if you wish to create a record whose details partially match those of an existing party,
such as that party’s spouse.
To create a clone by searching for the party:

1. Select the On-Boarding tab at the top of the RCM application.
On-Boarding Parties
2. In the Basic Search fields at the top of the page, enter sufficient details to identify the existing
party you are interested in.
The Basic Search options may have been customized for your deployment to use different
search fields, or to allow selection from drop-down lists. Each field can also be configured to
determine whether the search is of the exact or partial match type.
3. Click Search to perform the search, and then continue from step 6 below.
4. If you don’t see the search category you need in the entry fields at the top of the page, click
the Advanced Search button to display the Advanced Search window:
Cloning an On-Boarding Record
5. Enter the required search values in the following fields:
Field Description
Account Number The number of an account owned by the party.
CSN The identification number of the party.
First Name The party’s forename.
Last Name The party’s surname.
Doc number The number of the party’s primary identification document, e.g.
passport number.
RM Manager The party’s relationship manager, as identified during the on-
boarding process. When a record is successfully validated, the user
who performed that action is identified as the relationship manager.
Creator The username of the user who was logged on when the party
record was created.
Address Line 1 The first line of the address provided when the party was recorded.
Address Line 2 The second line of the address provided when the party was
recorded.
City The city part of the address provided when the party was recorded.
State/Province The state/province part of the address provided when the party was
recorded.
PO Box The PO Box part of the address provided when the party was
recorded, if applicable.
Zip Code The zip or postal code part of the address provided when the party
was recorded.
Party Status The status of the party record, such as On-boarding, or On-boarding
waiting for review.
On-Boarding Parties
The above Advanced Search options are the defaults, but your deployment may have been
customized to use other search fields, or to allow selection from drop-down lists. When the
search is of the exact or partial match type is also configurable per field. Click Search at the
bottom of the Advanced Search window to perform the search.
The results of any party records matching the search are displayed.
6. Select the option button at the left end of the required row of party search results to identify
the source record.
7. Optionally you can click the View Details link in the Details column of the search results to
open the Party Details window to help your selection:
Changing the Party Type of an On-Boarding Record
8. Click Clone at the bottom of the search results window.

Fields will already be populated from the party record you selected from the search results.
You can edit any fields as required to create a version of the selected record.
The cloned party’s type will default from the source party.
9. To complete the cloning process, follow steps 2–8 in Section 5.7.1 Cloning from the
Summary Tab.
5.8 Changing the Party Type of an On-Boarding Record

When a table of party search results is displayed, you can change a record’s party type as
follows:
1. Select the option button at the left end of the required row of party search results to choose
the record you want to change.
The party’s current type will be identified in the Type column of the search results.
On-Boarding Parties
2. Click Convert Party at the bottom of the window.

The following page appears enabling you to identify the new party’s type.
3. Select a party type from the drop-down list.

4. Click Continue On-boarding to advance to the next part of the procedure.
The relevant version of the On-Boarding Questionnaire page is displayed, including values in
any clonable fields from the source record.
5. Continue as when creating a new on-boarding record.
For any questions where answers have defaulted from the source, you can choose
replacement values as required.
6. Save, validate and submit the new on-boarding record to complete the process. The same
messages are displayed to the screen as when creating any other on-boarding record and
you may be expected to fix syntax errors or answer enhanced due diligence (EDD) questions.
The party’s On-boarding Client alert is updated.
If you search again for the same party, you will see that the party type has been updated.
Chapter 6: Review and Investigation
6.1 Overview
The Actimize Risk Case Manager includes options and features that enable authorized users to
investigate customer records, all alerts generated as a result of CDD issues and any documents
associated with customers.
The user can review and investigate any selected customer record from the ‘Customer Module’ of
the RCM. In addition, the RCM user can easily access and investigate all alerts related to the
customer.
From the Customer Module the AML-CDD analyst can perform the following tasks:
• Search for a required customer
• Review a customer record, including customer profile, account profile, customer account
relations, related documents etc.
• Jump to alerts related to the customer
• Manage all customer documents
• Add notes to a record
• Adjust risk factor scores
• Audit the history of any updates made, or comments/documents added, to a customer record
From the ‘Work Items’ module the AML-CDD analyst can perform the following tasks:
• Review all alerts detected by the solution, based on the ‘alert type’
• Review all customer documents
• Create a new customer document based on available document forms
6.2 Workflow for Reviewing a Customer Record

This section describes the graphic interface via which users can review customer-related
information.
6.2.1 Searching for a Customer

Authorized users can leverage Actimize’s KYC (Know Your Customer) capabilities by searching
for a specific customer from the Customer tab in RCM.
To search for a customer, users can enter:
• CSN ID or the Customer Name; or
• Relevant attributes in the available entry boxes.
All customers who match the search parameters appear within the resulting list, regardless of
whether an alert was generated for the customer or not.
Review and Investigation
Users can then click on the Customer Name link within the resulting list of customers and view
the related CDD information pertaining to that customer.
6.2.2 About the Customer Record

The customer record includes all related details and calculated risks as of a specified date and
includes the following options and features:
Workflow for Reviewing a Customer Record
1. Header Information and Action Buttons – This pane includes information that is relevant
for the current record and basic actions that can be performed on the customer record such
as jump to the customer's alerts, manage customer documents, view all customer profiles or
add notes.
2. Customer Highlights – This pane provides highlights of the customer details, including the
current risk score record information and main customer attributes.
3. Customer Record Tabs – The tabs within a CDD customer record are:
 Customer Profile – With customer level information
 Account Profile – With account level information
 CIP Record – With ‘Customer Identification Program’ information
 Risk Scoring – With all risk factor scores assigned for the customer
 Onboarding Questions – With a summary of questions presented to the party and
answers given by the party during the on-boarding process
 Relation Diagram – Displaying a link analysis with all related customer accounts
 Audit – Providing a full audit trail on user actions
 Related Docs – With documents related to the customer, which may be uploaded by the
user or via a web service
 Beneficial Ownership – Details the ownership structure of the party. If the party is
owned by other entities or individuals, this tab shows the related information; such as the
name, relationship type, and the percentage of ownership.
6.2.3 Header Information and Action Buttons

The following table presents the information fields and action buttons that may appear within this
area.
Field/Option Description
Displays the customer record ID.
Displays the date and time at which the

information within the record was updated. ‘As
of Now’ indicates that this customer record is
the most updated record for this customer.
Clicking this button opens a page with a list of
all Profiles that exist in the system for this
customer.
The user can select any instance within the
resulting history in order to view the customer
profile at the date and time specified for the
selected instance.
Field/Option Description
Opens the ‘Workbench – Work Items’ module
and displays all alerts related to this customer.
Opens the ‘Add Note’ window that enables the
user to add a note to a selected customer
record. This action is recorded within the ‘Audit
History’ of the customer record.
Authorized Users can change the status of the
customer. This action updates the customer’s
status within the customer’s profile.
Authorized users can use this button to open
the ‘Workbench – Work Items’ module and
display all documents related to this customer.
6.2.4 Reviewing the Customer Profile

The Customer Profile tab presents detailed information about the selected customer, such as:
• A full list of customer details
• The ‘Historical Profile’ of the customer’s transactions for the past month
• A list of customer flags such as “Is the customer a Politically Exposed Person”, “Is the
customer associated with an NGO (non-governmental organization)”, etc.
6.2.5 Reviewing Account Profile

The Account Profile tab presents detailed information about the selected customer’s accounts,
such as:
• Account details
• ‘Historical Profile’ of the customer’s account
6.2.6 Reviewing CIP Records

The CIP tab displays all CIP records for the customer. Each CIP record appears as an
expandable section containing the CIP record information. In addition, the tab includes a section
that provides identity verification discrepancies and the type of discrepancy (e.g., name, ID,
address etc).
Once a CIP record is received, any ID changes result in a new CIP record that is not considered
part of the existing CIP record.
6.2.7 Reviewing Customer Risk Scores

The Risk Scoring tab presents the full list of all solution risk factors and the score that is currently
assigned for each factor for the current customer. In the User Defined Policy section the tab
shows details of active Policy Manager rules, provided that module is available. This tab also
enables analysts to make adjustments to the risk level or risk scores, and to view the history of
previous risk scoring.
6.2.8 Reviewing On-Boarding Questions

This tab is populated for alerts of the On-boarding Client type only. On-boarding a new party
based on a questionnaire is explained in Chapter 5: On-Boarding Parties, page 32.
When a questionnaire is used as part of any of the financial organization’s procedures (e.g.
prospective customer opening an account), this tab displays a read-only summary of the
questions that the representative presented to the party, together with the party’s responses.
6.2.9 Reviewing a Relation Diagram

The Relation Diagram tab provides a diagram that shows all customer account relations. Users
can determine the level at which they want to view the depth of account relations within the
diagram.
The screen is divided into two sections:

• The left side of the tab presents a diagram of the relevant accounts with relations indicated by
connecting lines. The objects within this diagram are color coded as follows:
 The blue rectangle represents the customer under review
 Red rectangles represent high risk accounts that are related to the customer
 Grey rectangles represent any customer-related accounts that are not high risk
• The right side of the screen is used for additional details. The details that appear within this
section depend on what the user selects within the diagram:
 When the user clicks on one of the entities in the diagram (either customer or account),
the details of that selected entity appear on the right side of the page.
 When the user clicks on one of the relational connections in the diagram, the details of
the relevant relations appear on the right side of the page.
The additional details that appear on the screen are tuned according to the organization’s
requirements and data availability and therefore may appear differently for different organizations.
6.2.10 Reviewing Audit History

The Audit tab shows a history of all actions performed by the RCM user with regard to the
Customer record. In the above screen capture the user made an adjustment to the risk score.
6.2.11 Reviewing Related Documentation

The Related Docs tab shows documents that were attached to the customer record. Users can
view the available related documents and their details. Authorized users can upload new
documents (up to 50MB in size) and deleted existing documents. All such changes are saved and
can be reviewed on the Audit tab.
6.2.12 Reviewing Beneficial Ownership Records

The Beneficial Ownership tab details the ownership structure of the party. If the party is owned by
other entities or individuals, this tab shows the related information; such as the name, relationship
type, and the percentage of ownership.
6.3 Options for Reviewing AML-CDD Items and Item Details

This section describes the main list of work items, solution alert types, and document
management options in the Actimize AML-CDD solution.
6.3.1 About the Main List of Work Items

The main RCM Workbench > Work Items screen displays different views of alerts or documents
that the user has permission to view, and enables the user to select an item for further
investigation.
Options for Reviewing AML-CDD Items and Item Details
The main areas of the Workbench are described below:

1. Tabs – Enable users to switch between different main tasks such as viewing alerts or other
work items, managing settings for thresholds, scores and rule related lists, and viewing
customer records in the Customer’s tab.
2. Buttons – Allow users to initiate frequently performed tasks, such as Change Step, Assign,
Add Note, Add Attachment, Print List, Export, and View History.
3. Activity Bars – Each bar contains different actions that can be performed for the selected
tab.
4. List Area – Includes items according to the currently selected task. The checkboxes let you
select one (or more) item in the list. Links within the list jump to details related to the
corresponding item.
The columns that appear on the screen are based on the organization’s requirements and data
availability and therefore may appear differently for different organizations.
Each row represents an item that corresponds to the selected ‘View’ type, for example a row may
represent an alert that corresponds to a selected alert type view or a document corresponding to
the ‘Documents’ view. Each item row contains at least one field that appears as a link. For
example, in the screen capture shown above the ‘Item ID’ is a link. These links take you to the
appropriate details for the corresponding item. For example a link within an alert takes you to the
Customer Record.
6.3.2 Solution Alert Types

The solution alert types are:
• High Risk Client Alerts– Alerts resulting from high risk factor score(s) for a customer.
(See Chapter 3: Customer Risk Scoring, page 12, for more information about the solution risk
factors, and Section 4.1: High Risk Customer (CDD-HRB), page 19, Section 4.2, Change in
Customer Risk (CDD-INR) on page 20 and Section 6.2.7: Reviewing Customer Risk Scores,
page 60.)
• Discrepancy Alerts – Alerts resulting from a detected discrepancy in customer identification
information, or due to a lack of documentary evidence for determining customer identification.
(See Section 4.3: Identity Verification Issues (CDD-CIP), page 22 and Section 6.2.6:
Reviewing CIP Records, page 60.)
• Documentary Tracking Alerts – Alerts resulting from documentary tracking issues such as
missing documentation, expired documentation etc. (See Section 4.4: Documentary Tracking
(CDD-DOC) page 24 and Section 6.2.7: Reviewing Customer Risk Scores, page 60.)
• Periodic Review Alerts – Alerts resulting from customer periodic review. (See Section 4.5:
Periodic Review (CDD-PRE), page 27 and Section 6.2.7: Reviewing Customer Risk Scores,
page 60.)
• Expected Behavior Deviation – Alerts resulting from detected discrepancies between actual
activity and expected activity. (See Section 4.6: Expected Behavior Deviation (CDD-EBD),
page 28.)
• On-boarding Client Alerts – Alerts resulting from a new party record created through the
On-boarding process. (See Chapter 5: On-Boarding Parties, page 32).
6.3.3 Document Management

The Actimize AML-CDD solution is delivered with a library of supported document forms that
enable authorized users to create or modify specific document instances for relevant customers.
All documents can be viewed within the RCM Work Items module and the documents that are
related to a customer can be accessed from that customer’s record.
To create or edit documents:

Users can use a New Item wizard to select a document form and fill in the form with the required
document details. Once all data is entered the user can add their notes to the document, print the
document, add an attachment, etc.
Once the document is saved it appears under the Summary tab of the relevant customer record.
Users can manage all customer documents from the customer record by selecting the Manage
Documents button at the top of the window.
After reviewing or editing the required documents within the Work Items page the user can return
to the customer record using a ‘Back to Customer’ option. The documents remain active until they
expire and then appear within the Summary sub tab as expired.
Documents that are created within the RCM can be checked by the CDD Documentary Tracking
(CDD-DOC) detection model which tracks the status of customer documentation. The model, for
example, can check the documentation expiration date and can distribute an alert if an issue is
detected.
For more information about the Documentary Tracking model see Section 4.4: Documentary
Tracking (CDD-DOC), page 24.
Adjusting Thresholds and Scoring Scales
6.4 Adjusting Thresholds and Scoring Scales
Thresholds are upper and lower limits that are used by the solution logic when assigning scores.
In some cases the thresholds are predefined and cannot be adjusted. However, in many cases
the user has the ability to adjust these upper and lower limits in order to fine-tune the number of
alerts that are generated.
The scoring scales define different segmentation levels for each risk factor and the score values
that are associated with each segment. These values are used, each time the corresponding risk
factor is activated, in order to assign the appropriate score.
6.4.1 Thresholds
Clicking the Threshold link enables the user to view default values for all thresholds that are
available for adjustment. When required, users can enter user-defined values in order to fine-tune
the process to suit their immediate tasks and needs.
For example, the user could select the ‘Days to expiration’ threshold within the list and use the
available Edit button at the top of the page to modify the value for this threshold, as shown in the
example below:
6.4.2 Scoring Scales
Clicking the Scoring link enables the user to view default values for all scoring scales that are
used to determine the assignment of score values. When required, the user can enter user-
defined values in order to fine-tune the process to suit their immediate tasks and needs.
Viewing and Managing Solution Lists
Each risk factor has a scoring scale that defines the different segmentation levels for that score
factor and score values that are associated with each segment. These values are used each time
the corresponding risk factor is activated.
6.5 Viewing and Managing Solution Lists

Analysts can use the Lists module to maintain lists that are used by the system during score
calculation and generation of alerts. Each list that is used by the solution includes links that
enable you to view default list members (when available). It is also possible to enter user-defined
members for some of the lists, if required.
The example shown below is the list of risk factors that is referenced when the solution evaluates
the risk level of a customer. This list includes all risk factors and an indication of whether the
factor is currently active.
When a user score value is entered for a list member, this value is used instead of the default
value. The user can return to the default values at any time by removing the user-defined values.
Chapter 7: CDD Maintenance Model
The solution includes a ‘Purge of Old Records’ model that is designed to purge old or obsolete
records from the solution’s database. This model provides the facilities by which organizations
can define a policy for cleaning customer and account records that are considered inactive. The
model monitors for customer or account records that have been inactive for a period of time and
implements either a full or partial purging process based on the financial institution’s
requirements.
The financial institution can ensure that the CDD database is synchronized with the banking
systems, maintain updated information about customers and accounts within the AML-CDD
solution, and remove outdated records.
During the implementation stage, a purge policy for ‘inactive’ customers and accounts is defined
based on the financial institutions requirements. The solution runs separate logic to determine
which customers to delete and which accounts to delete. The reason for this is:
• An account may be connected to multiple customers and some of these customers could still
be active
• A current (active) customer can have old accounts that should be deleted
7.1 Old Customer Purge

The financial institution defines what constitutes an ‘old’ customer. For example, an institution
could define an ‘old’ customer as follows:
• All the related accounts have been inactive for a certain number of days
• The customer does not have any alerts that are in ‘active’ status
• The customer does not have any cases that are in ‘active’ status
If these parameters are met, then the financial institution will have the option to either perform a
full purge or a partial purge:
• Full purge (default) removes from the system all objects related to the customer, including
related accounts, alerts, audit trail, history, etc. The result of this type of purge is as if the
customer never existed in the system.
• Partial purge removes only customer details, related accounts, and old profiles that are not
associated with any alerts. Workflow items, such as alerts, old profiles related to those alerts,
cases, and related audit trail, are retained within the system. This maintains a paper trail of
AML activities for these old customers.
• Authorized users also have the ability to manually flag a customer to be purged the next time
the model is run. The authorized user can add comments that will not be deleted and will stay
as part of the audit trail.
7.2 Old Account Purge

The financial institution defines what constitutes an ‘old’ account. For example, an institution
could define an ‘old’ account as follows:
• The account has been inactive for a certain number of days.
When the specified condition(s) are met and an account is identified as ‘old’, the system performs
the following:
CDD Maintenance Model
• The ‘old’ account is deleted from the current profile of any related customers. Historical
snapshots of those related customers and other related items, such as related customers or
workflow items, are not deleted.
• Once an account is purged, the related customers’ profiles are updated, i.e., new profile
records are created, while previous ones are stored in the respective history.
Authorized users also have the ability to manually flag an account to be purged the next time the
purge process runs. The authorized user can add comments that will not be deleted and will stay
as part of the audit trail.
The following is an example of a purge process for old records:

The financial institution’s ‘old records’ policy is defined as follows:
• Any customer that has had:
 No activity in all related accounts for the last 1,826 days (roughly
translates to 5 years)
 No “active” alerts for the account
 No “active” cases for the account
• Any account that has had:
 No activity for the last 1,826 days
Old customer records undergo the partial purge.
Scenario 1: Jane Doe has the following accounts with the financial institution.
Account Account Date of Account’s “Active” “Active”
Identifier Opening Date Last Activity Alert? Case?
Account A 1 January 2001 3 May 2003 No No
Account B 4 June 2002 14 September 2006 No No
If today is 31 December 2008, only account A will be identified for old records purge,
since the last activity occurred over 1,826 days ago, and the account does not have any
active alerts or cases. Since account B has had activity within the last 1,826 days,
profiles associated with Jane Doe and account B will not be deleted.
Scenario 2: John Smith has the following accounts with the financial institution.
Account Account Opening Date of Account’s “Active” “Active”
Identifier Date Last Activity Alert? Case?
Account D 10 February 1983 24 November 1990 No No
Account E 31 December 1992 18 July 2003 No No
If today is 31 December 2008, the customer profile and details of accounts D and E will
be identified for old records purge, since both accounts have no active alerts or cases
and the last activities occurred over 1,826 days ago. Since the financial institution’s
policy is for partial purge for customer profiles, the details of the customer and accounts
D and E will be deleted. Alerts, cases, and other workflow items associated with John
Smith and his two accounts will not be deleted.
Detection Logic for Account Purge:

1. Identify ‘old accounts’ based on the organization’s policy definition.
By default, the solution policy is as follows:
 Old Account = Account that is “inactive” for more than Inactive Number Of Days Of
Account threshold.
Old Account Purge
2. Retrieve manually entered inactive accounts from the Manual Account Purge list.
3. Purge accounts if account is old or was manually marked to be purged.
Detection Logic for Customer Purge:

1. Identify ‘old customers’ based on the organization’s policy definition.
By default, the solution policy is as follows:
a. Old customer = customer where all the accounts related to that customer are ‘inactive’ for
more than Inactive Number Of Days Of Party threshold.
AND
b. There are no alerts for this customer that are of an active alert type with an active status,
based on the Active Alert Types list and the Active Alert Statuses list.
AND
c. There are no cases, which include this customer, of an active case type with an active
status, based on the Active Case Types list and the Active Case Statuses list.
2. Retrieve manually entered inactive customers from the Manual Party Purge list.
3. Purge customers if customer is old or was manually marked to be purged.
Customers can be purged in one of the following ways:
 Full purge (default) – Delete all objects related to this customer from the system (as if it
never existed). E.g. related accounts, alerts, audit trail, history etc.
 Partial purge – Delete the customer, related accounts, and old profiles that are not
associated with any alerts, but keep workflow items – alerts, ‘old profiles’ related to those
alerts, cases, related audit trail etc.
Flexibility:
Thresholds and Settings:

Value
Inactive Number Of Sets the number of days over which an 2,000
Days Of Account account is considered inactive. (~ 5.5 years)
Inactive Number Of Sets the number of days over which 2,000
Days Of Party customer related accounts are considered (~ 5.5 years)
inactive.
Lists:
Risk Case Manager:

Manual Account Purge The user populates this list with account keys for all
accounts that should be purged from the solution
database the next time the model is run.
Active Alert Types The user populates this list with all Alert Types that are
considered relevant for the purge process.
CDD Maintenance Model

Active Alert Statuses The user populates this list with the codes of all Alert
statuses (steps) that are considered active (e.g., In
progress).
Active Case Types The user populates this list with all Case Types that are
considered relevant for the purge process.
Active Case Statuses The user populates this list with all Case statuses that are
considered active.
Manual Party Purge The user populates this list with customer (party) keys for
all customers that should be purged from the solution
database the next time the model is run.
Chapter 8: AML-CDD Policy Manager
The license for the AML-CDD Policy Manager module is purchased separately.
8.1 Overview
Authorized users can set up and activate a policy of rules for the Policy Type that is delivered with
the AML-CDD solution. Rules created in the Policy Manager are used to define risk factors.
Active rules are evaluated when the customer risk score is checked as part of the risk scoring
process. If conditions defined within the rules are met, the relevant risk factor is used to adjust the
score assigned to any affected party. If the total score of the rules exceed the minimum alert
score then an alert will be generated for this party.
The policy can be made up of one or more rules that determine the response to the rule’s
conditions.
Risk score and level are determined by a combination of a default out-of-the-box value, a custom
value, if set, and an adjustment if rule criteria are met.
When a rule includes an action to adjust the risk level, AML-CDD will choose the highest risk level
from the default, custom and rule-determined levels.
For example:
The following risk levels are applicable:
Risk Score Risk Level

0-99 Low
100-199 Medium
200 and above High
• The default risk score for parties where Occupation = “terrorist”, add 100 points
• The custom risk score for parties where Party Color = “green”, add 100 points
• The following policy rules are active:
 If Party Color =! “blue”, add 100 points
 If Occupation = “banker”, set risk level = Low
 If Occupation = “singer”, set risk level = High
Policy Manager Rules
Then the following risk score will apply for Party A, Party B and Party C:
Party A: A red engineer
The party’s occupation does not cause the default risk score to apply (+0); the party’s color does
not cause the custom risk score to apply (+0); but the first policy rule does apply (+100).
Risk Score = 100, therefore Risk Level = Medium
Party B: A green banker

The party’s occupation does not cause the default risk score to apply (+0); but the party’s color
does cause the custom risk score to apply (+100); the first and second policy rules both apply
(+100 + risk level = Low).
Risk Score = 200 or Low, whichever is higher, therefore Risk Level = High
Party C: A blue singer

The party’s occupation does not cause the default risk score to apply (+0); the party’s color does
not cause the custom risk score to apply (+0); but the third policy rule does apply (risk level =
High).
Risk Score = 0 or High, whichever is higher, therefore Risk Level = High
8.2 Policy Manager Rules

• A policy can include one or more rules. The following example shows a Draft Policy with three
rules that are defined for the available Policy Type.
Policy Manager Rules
• Clicking the Rule Name link displays the criteria for the rule:
• This example includes only one condition, but more complex rules can be defined if required.
• Once conditions are defined, select a value for the ‘Adjust Risk Level’ action and/or the
‘Adjust Score’ action.
 Adjust Risk Level – Select the risk level value to which the party should be set when the
criteria for the rule are true.
 Adjust Score – Select a negative value to reduce the risk score if the rule criteria are true,
or select a positive value to increase the risk score. Available score values are as follows:
Examples of User-Defined Policies
• Users can define multiple rules for a Policy Type, and then activate only a sub-group of all the
rules. The solution executes only the active rules.
8.3 Examples of User-Defined Policies

The following example shows the three rules and how the solution reads these rules.
In the example presented above, the following actions were defined for the rules:
• Example Rule 1 – When the party’s Active Date is within three months prior to today’s date,
then increase the risk score by 50.
Examples of User-Defined Policies
• Example Rule 2 – When the party’s Occupation is “BANKER”, then set the risk level to
“Low”.
• Example Rule 3 – When the party’s Occupation is “SINGER”, then set the risk level to
“High”.
Chapter 9: Risk Factor Specifications
The Actimize AML-CDD solution analyzes a wide variety of data elements and risk factors to
assign a score to each customer. The risk score calculation is based on the client’s risk factors
and reference risk scoring tables, as well as a history of the risk score.
This section provides a list of risk factors used in the Actimize AML-CDD solution, as well as their
specifications.
9.1 List of Risk Factors

The following risk factors are delivered as an integral part of the CDD-RSK Customer Risk
Scoring model and are used when calculating customer risk scores:

Address in High Risk Geography A score is given, based on the country score listed
CDD-RSK-001-GEO-ADR within the Solution’s ‘Countries list’, for the country
within the customer’s primary address. If there is
more than one country, the solution takes the riskiest.
See Address in High Risk Geography, page 82.
Foreign Individual A score is given, based on the level of risk associated
CDD-RSK-002-GEO-IND with the geographic location of a customer and the
associated CIP (Customer Identification Program)
information.
See Foreign Individual, page 84.
Political Exposure A score is given if the customer is defined as a
CDD-RSK-003-PTY-PEP Politically Exposed Person.
See Political Exposure, page 86.
Foreign Corporate Entity A score is given based on the level of risk associated
CDD-RSK-004-GEO-CRP with the geographic location of corporate entity and
related accounts.
See Foreign Corporate Entity, page 87.
Foreign Trading Area A score is given based on the level of risk associated
CDD-RSK-005-GEO-TRA with the geographic location of foreign trading
countries based on the customer CIP (Customer
Identification Program) information.
See Foreign Trading Area, page 89.
Embassies & Foreign Consulates A score is given if the customer business address is
CDD-RSK-006-GEO-EMB an embassy or foreign consulate.
See Embassies and Foreign Consulates, page 90.
Client with SARs A score is given based on the level of risk associated
CDD-RSK-007-PTY-SAR with the number of the customer's SAR reports.
See Client with SAR reports, page 91.
Customers Under Suspicion A score is given if a hit resulted for this customer
CDD-RSK-008-PTY-SUS when screened against watch lists by the Customer
Watch List Filtering model.
See Customer Under Suspicion, page 92.
List of Risk Factors

Customers under Subpoena A score is given based on the number of subpoenas
CDD-RSK-009-PTY-SBP received by the customer.
See Customer Under Subpoena, page 93.
Mail Code A score is given based on the risk calculated for a
CDD-RSK-010-ACT-MAL given address type. Certain mail codes may indicate
a concealed address or an attempt to conceal an
address.
See Mail Code, page 94.
Account Type A score is given based on the account type of the
CDD-RSK-011-ACT-TPY customer such as Private Banking, Managed
Account, etc.
This score is based on all accounts related to the
customer.
See Account Type, page 95.
Collateral Type A score is given based on the level of risk associated
CDD-RSK-012-LON-CLT with customer's collateral type.
See Collateral Type, page 96.
Employee Status A score is given if the customer is an employee of the
CDD-RSK-013-EMP-STS financial institution. The score is based on the fact
that an employee has more potential opportunities to
perform suspicious activities.
See Employee Status, page 97.
High Risk Businesses A score is assigned based on the risk determined for
CDD-RSK-014-PTY-BSN the line of business of the customer. Some
businesses are considered potentially riskier than
others, such as services connected with Money
Transfers, Check Cashing etc.
See High Risk Businesses, page 98.
Money Service Business A score is given if the business is a money transfer
CDD-RSK-015-PTY-MSB service that includes payments and collections.
See Money Service Business, page 100.
Client Segment A score is given based on the risk determined for the
CDD-RSK-016-PTY-SGM party segment/classification type of the customer
such as SME, Corporate etc.
See Client Segment, page 101.
Channel of Account Opening A score is given based on the channel of account
CDD-RSK-017-ACT-OCH opening, for example whether it is a face-to-face
mode or a non-face-to-face mode (which is
considered riskier).
See Channel of Account Opening, page 102.
Occupation A score is given based on the level of risk associated
CDD-RSK-018-PTY-OCP with the customer’s occupation code.
See Occupation, page 103.
CDD-RSK Risk Factor Specifications

Initial Source of Funds A score is given based on the level of risk associated
CDD-RSK-019-ACT-ISC with the customer’s initial source of funds.
See Initial Source of Funds, page 104.
Ongoing Source of Funds A score is given based on the level of risk associated
CDD-RSK-020-ACT-OSC with the customer’s ongoing source of funds.
See Ongoing Source of Funds, page 105.
Relationship to Higher Risk Entity A score is given if a client is related by link analysis to
CDD-RSK-021-PTY-REL another high-risk entity.
See Relationship to Higher Risk Entity, page 106.
Service Type A score is given based on the risk determined for all
CDD-RSK-025-PTY-SRV services related to the customer.
See Service Type, page 109.
Behavioral Trends A score is given based on the level of risk associated
CDD-RSK-026-PTY-BHT with the customer’s suspicious behavioral trends,
such as alerts from other systems.
See Behavioral Trends, page 110.
Client Net Worth A score is given based on the level of risk associated
CDD-RSK-026-PTY-BHT with the customer’s net worth.
See Client Net Worth, page 111.
9.2 CDD-RSK Risk Factor Specifications

The risk factor specifications may include the following information:
• Model name and ID
• Description of the risk factor
• Risk factor ID
• Risk factor display name
• Scoring algorithm
• Scoring calculations
• Default values
• Scoring scales
Each risk factor includes a scoring algorithm that provides the high level logic for the risk factor.
All bolded terms within the scoring algorithm represent scoring calculations that are presented in
detail immediately following the algorithm.
All terms that appear, within the algorithm or the calculations, in blue text represent default
configurations or scoring scales that are delivered with the package. The default values are
presented within the appropriate sections immediately following the calculations.
The scoring scales present all scoring scales used by the risk factor.
9.2.1 Address in High Risk Geography

Model CDD-RSK [ Customer Risk Scoring ]
Risk Factor Calculates the level of risk associated with the geographic location of
Description customer and related accounts.
Risk Factor ID CDD-RSK-001-GEO-ADR
Risk Factor Name Address in High Risk Geography
(display)
Scoring Algorithm IF
COUNTRY RISK score <> NULL
THEN
Score = COUNTRY RISK score
ELSE
IF
ZIP RISK score <> NULL
THEN
Score = ZIP RISK score
ELSE
Score = HOLD MAIL RISK score
Scoring Calculations COUNTRY RISK score =
MAX (
Score (
All Party Address Countries
Excluding LOCAL COUNTRY
AND
All related Account Address Countries
)
Based on COUNTRY SCALE scoring scale
)
ZIP RISK score =

IF
All Party Addresses (
Country = NULL
OR
Country = LOCAL COUNTRY
)
AND
All related Account Addresses (
Country = NULL
OR
Country = LOCAL COUNTRY
)
THEN
MAX (
Score (
All Party ‘Address Zip Codes’
AND
All related Account ‘Address Zip Codes’
)
Based on ZIP SCALE scoring scale
)
HOLD MAIL RISK score =

IF
Exists related ‘Accounts Mail Code’ = HOLD MAIL
THEN
DEFAULT SCORE
ELSE
Score = 0
Default Values LOCAL COUNTRY = ‘US’
HOLD MAIL = ‘H’
DEFAULT SCORE = 100
Scoring Scales COUNTRY SCALE [based on the reference table for country scales]
ZIP SCALE [based on the reference table for zip scales]
9.2.2 Foreign Individual

Risk Factor Calculates the level of risk associated with the geographic
Description location of the customer and their CIP information (Customer
Identification Program).
Risk Factor ID CDD-RSK-002-GEO-IND
Risk Factor Name Foreign Individual
(display)
Party Type = INDIVIDUAL PARTY AND
CITIZENSHIP_COUNTRY <> LOCAL_COUNTRY
THEN
IF
THEN
Score = COUNTRY RISK score
ELSE
IF
TAX LEVEL RISK score <> NULL
THEN
Score = TAX LEVEL RISK score
ELSE
Score = 0
ELSE
Score = 0
Scoring Calculations COUNTRY RISK score =
IF
CITIZENSHIP COUNTRY RISK score <> NULL
THEN
CITIZENSHIP COUNTRY RISK score
ELSE
IF
Exists ‘Foreign Individual Document’
AND
ISSUE COUNTRY RISK score <> NULL
THEN
ISSUE COUNTRY RISK score
ELSE
IF
Exists ‘Foreign Individual Document’
AND
All Issued Countries of Party Documents = NULL
THEN
DEFAULT SCORE
CITIZENSHIP COUNTRY RISK score =
IF
Party Citizenship Country <> LOCAL COUNTRY
THEN
Score based on COUNTRY SCALE scoring scale
ISSUE COUNTRY RISK score =
MAX (
Score (
All Issued Countries of Party Documents
)
)
TAX LEVEL RISK score =

MAX (
Score (
All related ‘Account Tax Levels’
)
Based on TAX LEVEL SCALE scoring scale
)

INDIVIDUAL PARTY = ‘P’
DEFAULT SCORE = 100
Scoring Scales COUNTRY SCALE [based on the reference table of country
scales]
TAX LEVEL SCALE [based on the reference table of federal tax
scales]
9.2.3 Political Exposure

Risk Factor Calculates the level of risk associated with political exposure.
Description
Risk Factor ID CDD-RSK-003-PTY-PEP
Risk Factor Name Political Exposure
(display)
Party Is Politically Exposed
THEN
Score = DEFAULT SCORE
ELSE
IF
Exists ‘PEP Document’
AND
Party Type = INDIVIDUAL PARTY
THEN
ELSE
Score = 0
Default Values INDIVIDUAL PARTY = ‘P’
DEFAULT SCORE = 100
9.2.4 Foreign Corporate Entity

Risk Factor Calculates the level of risk associated with the geographic
Description location of the customer and related accounts.
Risk Factor ID CDD-RSK-004-GEO-CRP
Risk Factor Name Foreign Corporate Entity
(display)
ORGANIZATION TYPE RISK score <> NULL
THEN
Score = ORGANIZATION TYPE RISK score
ELSE
Score = 0
IF
THEN
Score = Score + COUNTRY RISK score
ELSE
IF
CORPORATE RISK score <> NULL
THEN
Score = Score + CORPORATE RISK score
Scoring Calculations ORGANIZATION TYPE RISK score =
Score Based on ORGANIZATION TYPE SCALE
COUNTRY RISK score =
IF
Party Citizenship Country <> LOCAL COUNTRY
AND
CITIZENSHIP COUNTRY RISK score <> NULL
THEN
CITIZENSHIP COUNTRY RISK score
ELSE
IF
Exists ‘Foreign Corporation Document’
AND
ISSUE COUNTRY RISK score <> NULL
THEN
ISSUE COUNTRY RISK score
ELSE
IF
Exists ‘Foreign Corporation Document’
AND
All Issued Countries of Party Documents = NULL

THEN
DEFAULT SCORE
CITIZENSHIP COUNTRY RISK score =
Score based on COUNTRY SCALE scoring scale
ISSUE COUNTRY RISK score =
MAX (
Score (
All Issued Countries of Party Documents
)
)
CORPORATE RISK score =
IF
Party Type = CORPORATE PARTY
THEN
MAX (
Score (
All 'Party Address Countries'
AND
All related 'Account Address Countries'
)
)
CORPORATE PARTY = ‘B’
DEFAULT SCORE = 100
Scoring Scales COUNTRY SCALE [based on the reference table for county
scales]
ORGANIZATION TYPE SCALE [based on the reference table
for organization type scales]
9.2.5 Foreign Trading Area

Risk Factor Calculates the level of risk associated with the geographic location
Description of foreign trading countries according to customer CIP information
(Customer Identification Program). This risk factor is enabled for
online risk scoring only.
Risk Factor ID CDD-RSK-005-GEO-TRA
Risk Factor Name Foreign Trading Area
(display)
Scoring Algorithm Score Trading Area Country
Scoring Scales COUNTRY SCALE [based on the reference table for country
scales]
Scoring Logic The Foreign Trading Area risk factor is calculated based on the
TRADING_AREA field in the PARTY table. This field is expected
to contain the name of a country. This country name is matched to
a list of counties and their risk scores, which are configured by the
user in RCM > Settings > Lists > High Risk Client > Country. If
no country is provided, then the risk score is 0.
9.2.6 Embassies and Foreign Consulates

Risk Factor Calculates the level of risk associated with the embassies and
Description foreign consulates.
Risk Factor ID CDD-RSK-006-GEO-EMB
Risk Factor Name Embassies and Foreign Consulates
(display)
AND
Exists ‘Foreign Embassy’ or ‘Consulate’ Document
THEN
ELSE
IF
Party Type <> CORPORATE PARTY
AND
(Party Is Foreign Embassy
OR
Party Is Consulate)
THEN
Default Values CORPORATE PARTY = ‘B’
DEFAULT SCORE = 100
9.2.7 Client with SAR reports

Risk Factor Calculates the level of risk associated with number of customer's
Description SAR reports.
Risk Factor ID CDD-RSK-007-PTY-SAR
Risk Factor Name Client with SAR reports
(display)
Scoring Algorithm Score (
Count Number of Party SAR reports
)
Based on SAR REPORTS SCALE scoring scale
Scoring Scales SAR REPORTS SCALE
Number of SAR reports Score
0 0
1 100
2 150
6 250
9.2.8 Customer Under Suspicion

Risk Factor Calculates the level of risk associated with customer watch list
Description hits.
Risk Factor ID CDD-RSK-008-PTY-SUS
Risk Factor Name Customer Under Suspicion
(display)
Party Exists in ‘Watch List Hits’
THEN
ELSE
Score = 0
Default Values DEFAULT SCORE = 150
9.2.9 Customer Under Subpoena

Risk Factor Calculates the level of risk associated with the number of
Description customer's subpoenas.
Risk Factor ID CDD-RSK-009-PTY-SBP
Risk Factor Name Customer Under Subpoena
(display)
Scoring Algorithm Score (
Count Number of Party Subpoenas
)
Based on SUBPOENAS SCALE scoring scale
Scoring Scales SUBPOENAS SCALE
Number of Subpoenas Score
0 0
1 100
2 150
6 250
9.2.10 Mail Code

Risk Factor Calculates the level of risk associated with related accounts mail
Description code.
Risk Factor ID CDD-RSK-010-ACT-MAL
Risk Factor Name Mail Code
(display)
Scoring Algorithm SUM (
All related ‘Account Mail Codes’
IF
MAIL RISK score <> NULL
THEN
Score = MAIL RISK score
ELSE
)
Scoring Calculations MAIL RISK score =
Score based on MAIL SCALE scoring scale

Scoring Scales MAIL SCALE [ based on mail scales reference table ]
9.2.11 Account Type

Risk Factor Calculates the level of risk associated with customer's account
Description type.
Risk Factor ID CDD-RSK-011-ACT-TPY
Risk Factor Name Account Type
(display)
THEN
Score = MIN (
ACCOUNT CLASSIFICATION score,
MAX SCORE
)
ELSE
IF
Party Is Priority Party
THEN
Score = ACCOUNT CLASSIFICATION score * REDUCE
RATIO
ELSE
ACCOUNT CLASSIFICATION score
+
IF
Party Is Correspondent Bank
THEN
ELSE
Score = 0
Scoring Calculations ACCOUNT CLASSIFICATION score =
SUM (
All related ‘Account Classification Codes’
Score based on ACCOUNT CLASSIFICATION SCALE
scoring scale
)

MAX SCORE = 150
REDUCE RATIO = 0.5
DEFAULT SCORE = 50
Scoring Scales ACCOUNT CLASSIFICATION SCALE [based on ‘account
classification’ reference table]
9.2.12 Collateral Type

Risk Factor Calculates the level of risk associated with customer's collateral
Description type.
Risk Factor ID CDD-RSK-012-LON-CLT
Risk Factor Name Collateral Type
(display)
THEN
Score = MIN(
COLLATERAL score,
MAX SCORE
)
ELSE
IF
Party Is Priority Party
THEN
Score = COLLATERAL score * REDUCE RATIO
ELSE
Score = COLLATERAL score
Scoring Calculations COLLATERAL score =
SUM (
All related Collateral Type Code
IF
Score based on COLLATERAL SCALE <> NULL
THEN
Score based on COLLATERAL SCALE scoring scale
ELSE
DEFAULT SCORE
)

DEFAULT SCORE = 10
MAX SCORE = 150
REDUCE RATIO = 0.5
Scoring Scales COLLATERAL SCALE [based on collateral reference table]
9.2.13 Employee Status

Risk Factor Calculates the level of risk associated with employee status.
Description
Risk Factor ID CDD-RSK-013-EMP-STS
Risk Factor Name Employee Status
(display)
Scoring Algorithm Score Employee Type
Based on EMPLOYEE SCALE scoring scale
Scoring Scales EMPLOYEE SCALE [based on the reference table for employee
type scales]
9.2.14 High Risk Businesses

Risk Factor Calculates the level of risk associated with the customer's
Description business type.
Risk Factor ID CDD-RSK-014-PTY-BSN
Risk Factor Name High Risk Businesses
(display)
Scoring Algorithm Score = 0
IF
Party Is NBFI [non-bank financial institution]
THEN
Score = Score + DEFAULT NBFI SCORE
IF
Party Is PSP [professional services provider]
THEN
Score = Score + DEFAULT PSP SCORE
IF
Party Is NGO [non-governmental organization]
THEN
Score = Score + DEFAULT NGO SCORE
IF
Party Is CIB [cash intensive business]
THEN
Score = Score + DEFAULT CIB SCORE
IF
Party Is TPPP [third party payment processor]
THEN
Score = Score + DEFAULT TPPP SCORE
IF
Party Is POATM [privately owned ATM operator]
THEN
Score = Score + DEFAULT POATM SCORE
IF
Score = 0
THEN
Score = NAICS RISK score
Scoring Calculations NAICS RISK score
Score based on NAICS SCALE scoring scale
Default Values DEFAULT NBFI SCORE = 50
DEFAULT PSP SCORE = 50
DEFAULT NGO SCORE = 100
DEFAULT CIB SCORE = 50
DEFAULT TPPP SCORE = 50

DEFAULT POATM SCORE = 50
Scoring Scales NAICS SCALE [based on NAICS scales reference table ]
9.2.15 Money Service Business

Risk Factor Calculates the level of risk associated with the Money Service
Description Bureau.
Risk Factor ID CDD-RSK-015-PTY-MSB
Risk Factor Name Money Service Business
(display)
Party Is MSB
THEN
ELSE
Score = 0
9.2.16 Client Segment

Risk Factor Calculate the level of risk associated with the customer’s
Description segment code.
Risk Factor ID CDD-RSK-016-PTY-SGM
Risk Factor Name Client Segment
(display)
CLASSIFICATION score <> NULL
THEN
Score = CLASSIFICATION score
ELSE
Score = 0
Scoring Calculations CLASSIFICATION score =
Score based on CLASSIFICATION SCALE
Scoring Scales CLASSIFICATION SCALE [ based on the reference table for
party segment scales]
9.2.17 Channel of Account Opening

Risk Factor Calculates the level of risk associated with the account opening
Description channel.
Risk Factor ID CDD-RSK-017-ACT-OCH
Risk Factor Name Channel of Account Opening
(display)
All related 'Channels of Account Openings'
IF
CHANNEL OF ACCOUNT OPENING score <> NULL
THEN
Score = CHANNEL OF ACCOUNT OPENING score
ELSE
)
Scoring CHANNEL OF ACCOUNT OPENING score =
Calculations Score based on CHANNEL OF ACCOUNT OPENING SCALE
scoring scale

Scoring Scales CHANNEL OF ACCOUNT OPENING SCALE [based on the
reference table for channel of account opening code scales]
9.2.18 Occupation
Risk Factor Calculates the level of risk associated with the customer’s
Description occupation code.
Risk Factor ID CDD-RSK-018-PTY-OCP
Risk Factor Name Occupation
(display)
Occupation Code <> NULL
THEN
Score = OCCUPATION score
ELSE
Scoring OCCUPATION score =
Calculations Score based on OCCUPATION SCALE
Scoring Scales OCCUPATION SCALE [ based on the reference table for
occupation code scales]
9.2.19 Initial Source of Funds

Risk Factor Calculates the level of risk associated with the customer’s initial
Description source of funds.
Risk Factor ID CDD-RSK-019-ACT-ISC
Risk Factor Name Initial Source of Funds
(display)
All related 'Initial Source of Funds'
IF
INITIAL SOURCE OF FUNDS score <> NULL
THEN
Score = INITIAL SOURCE OF FUNDS score
ELSE
)
Scoring INITIAL SOURCE OF FUNDS score =
Calculations Score based on SOURCE OF FUNDS SCALE scoring scale
Scoring Scales SOURCE OF FUNDS SCALE [based on the reference table for
source of funds code scales]
9.2.20 Ongoing Source of Funds

Risk Factor Calculate SOURCE OF FUNDS scoring scale as the level of risk
Description associated with the customer’s ongoing source of funds.
Risk Factor ID CDD-RSK-020-ACT-OSC
Risk Factor Name Ongoing Source of Funds
(display)
All related 'Ongoing Source of Funds'
IF
ONGOING SOURCE OF FUNDS score <> NULL
THEN
Score = ONGOING SOURCE OF FUNDS score
ELSE
)
Scoring ONGOING SOURCE OF FUNDS score =
Calculations Score based on SOURCE OF FUNDS SCALE scoring scale
Scoring Scales SOURCE OF FUNDS SCALE [based on the reference table for
source of funds code scales]
9.2.21 Relationship to Higher Risk Entity

Risk Factor Calculate the level of risk associated with a customer’s relationship to
Description other high risk entities
Risk Factor ID CDD-RSK-021-PTY-REL
Risk Factor Name Relationship to Higher Risk Entity
(display)
HIGHEST PARTY BASE RISK score >= CDD-HRB MIN SCORE
THEN
Score = (
MAX (all relationships between monitored party to highest risk
party RELATIONSHIP PREMIUM score)
[Clarification: if more than one path between the parties exists,
calculate the score for each path by taking the relationship
score and multiplying by the premium weight of the related
party’s risk level. Choose the maximum score]
)
ELSE
Score = 0
Scoring Calculations HIGHEST PARTY BASE RISK score =
MAX (
All relationship scores of related parties multiplied by the premium
weight of their defined risk levels.
)
RELATIONSHIP PREMIUM score =
IF
Party  Account  Party Relationship
THEN
MONITORED PARTY to ACCOUNT RELATION score
*
ACCOUNT to HIGHEST PARTY RELATION score
*
RISK LEVEL PREMIUM score
/
100
ELSE IF
Party  Party Relationship
THEN
PARTY to PARTY RELATION score
*
RISK LEVEL PREMIUM score

/
100
MONITORED PARTY to ACCOUNT RELATION score =

IF
IGNORE_MONITORED_PARTY_RELATION = 1 [default=0]
THEN
1
ELSE
Score based on RELATION SCALE between the monitored party
and the account related to the highest risk party
ACCOUNT to HIGHEST PARTY RELATION score =

IF
IGNORE_HIGHEST_PARTY_RELATION = 1 [default=0]
THEN
1
ELSE
Score based on RELATION SCALE between the monitored
related account to the highest risk party
PARTY to PARTY RELATION score =
Score based on RELATION SCALE between the monitored party
to the highest risk party
RISK LEVEL PREMIUM score =
Score based on RISK LEVEL PREMIUM SCALE for the risk level
of the highest risk party [default=1 for every risk level]
Parties related
to the Accounts
HRB Score = 30
Related Accounts P2
HRB Score = 60
A1
Monitored Party P3
HRB Score = 150
HRB Score = 300

A2
P1 X - Relation score P4
A3
P5
Y- Relation score
X = MONITORED PARTY to ACCOUNT RELATION score

Y = ACCOUNT to HIGHEST PARTY RELATION score
Default Values CDD-HRB MIN SCORE = 250

Scoring Scales RELATION SCALE [based on relation type scales reference table]
RISK LEVEL PREMIUM SCALE [based on risk level premium scales,
risk levels settings]
9.2.22 Service Type

Risk Factor Calculates the level of risk associated with the customer’s service
Description type.
Risk Factor ID CDD-RSK-025-PTY-SRV
Risk Factor Name Service Type
(display)
THEN
Score = MIN (
SERVICE TYPE score,
MAX SCORE
)
ELSE
IF
Party Type = INDIVIDUAL PARTY
THEN
Score = SERVICE TYPE score * REDUCE RATIO
ELSE
Score = 0
Scoring SERVICE TYPE score =
Calculations SUM (
Score(
All related Service Code
)
Based on SERVICE TYPE SCALE scoring scale
)
INDIVIDUAL PARTY = ‘P’
MAX SCORE = 150
REDUCE RATIO = 0.5
Scoring Scales SERVICE TYPE SCALE [based on services reference table]
9.2.23 Behavioral Trends

Model CDD-RSK [Customer Risk Scoring]
Risk Factor Calculates the level of risk associated with the customer’s
Description suspicious behavioral trends, such as alerts from other systems.
Risk Factor ID CDD-RSK-026-PTY-BHT
Risk Factor Name Behavioral Trends
(display)
Party Behavioral Trends <> NULL
THEN
Score(
related Behavioral Trends Code
)
Based on BEHAVIORAL TRENDS SCALE scoring scale
ELSE
Score = 0
Scoring Scales BEHAVIORAL TRENDS SCALE [based on behavior trends
reference table]
9.2.24 Client Net Worth

Model CDD-RSK [Customer Risk Scoring]
Risk Factor Calculates the level of risk associated with the customer’s net
Description worth.
Risk Factor ID CDD-RSK-027-PTY-NWT
Risk Factor Name Client Net Worth
(display)
Client Net Worth <> NULL
THEN
Score = CLIENT NET WORTH score
ELSE
Score = 0
Scoring CLIENT NET WORTH score =
Calculations Score based on CLIENT NET WORTH SCALE scoring scale
Scoring Scales CLIENT NET WORTH SCALE [based on rule scoring scale]
About NICE Actimize
NICE Actimize is the largest and broadest provider of financial crime, risk and compliance solutions for
regional and global financial institutions, as well as government regulators. Consistently ranked as number
one in the space, NICE Actimize experts apply innovative technology to protect institutions and safeguard
consumers and investors assets by identifying financial crime, preventing fraud and providing regulatory
compliance. The company provides real-time, cross-channel fraud prevention, anti-money laundering
detection, and trading surveillance solutions that address such concerns as payment fraud, cybercrime,
sanctions monitoring, market abuse, customer due diligence and insider trading.
NICEACTIMIZE.COM INFO@NICEACTIMIZE.COM NICEACTIMIZE.COM/BLOG @NICE_ACTIMIZE LINKEDIN.COM/COMPANY/ACTIMIZE

Actimize AML-CDD 2 0 8 Solution Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Actimize AML-CDD 2 0 8 Solution Guide

Uploaded by

Copyright:

Available Formats

Actimize Anti-Money Laundering

Document Version: 2.0.8.6

Chapter 2: Solution Summary ................................................................................................. 5

Chapter 3: Customer Risk Scoring ........................................................................................ 12

Chapter 4: CDD Detection Models ........................................................................................ 19

4.4 Documentary Tracking (CDD-DOC) .......................................................................................... 24

Chapter 5: On-Boarding Parties ............................................................................................ 32

Chapter 6: Review and Investigation .................................................................................... 56

6.3.3 Document Management ............................................................................................... 64

Chapter 7: CDD Maintenance Model .................................................................................... 70

Chapter 8: AML-CDD Policy Manager .................................................................................. 74

Chapter 9: Risk Factor Specifications ................................................................................... 79

1.1 About this Guide

1.2 About Customer Due Diligence

1.3 About the Actimize AML-CDD Solution

1.3.1 Main Features of the Actimize AML-CDD Solution

1.3.2 Key Objectives of the Actimize AML-CDD Solution

1.4 What’s New in This Version

2.1 Actimize AML-CDD Solution Methodology

2.1.1 Input Sources

2.1.2 Customer Record

The customer record includes:

2.1.3 Calculation of Risk Factor Scores

2.1.4 Determination of Risk Levels

2.1.5 Detection and Alert Generation

Detection Model Description

Detection Model Description

2.1.6 CDD Review and Investigation

2.1.7 Risk-Based Dynamic Interviewing

2.1.8 Solution Cleanup

Detection Model Description

2.2 Overview of the Solution Flow

2.3 Actimize AML-CDD Web Services

The Actimize AML-CDD solution leverages the following web services:

3.1 About Risk Factors and Scoring Scales

Account end of month balance Score

3.2 Risk Factor Score Calculation

Account # Balance Score

• If the Account Value risk factor is calculated by MAX aggregation, then:

Risk Factor Score

In this example, the Customer Risk Score = 20 + 10 + 40 + 0 = 70

3.3 List of Solution Risk Factors

Risk Factor Name Description

Foreign Corporate Entity A score is given based on the level of risk

Risk Factor Name Description

Mail Code A score is given based on the risk calculated for

Employee Status A score is given if the customer is an employee

Initial Source of Funds A score is given based on the level of risk

Risk Factor Name Description

Service Type A score is given based on the risk determined

Behavioral Trends A score is given based on the level of risk

3.4 Custom Risk Factors

3.5 Risk Factor Score Reference Tables

The following is an example of a Country List

Country Name ISO Score

Country Name ISO Score

Serbia & Montenegro CS 15

3.5.2 Mail Code

The following is an example of a Mail Codes List

Code Mailing Method Score

3.5.3 Account Opening Channel

The following is an example of an Account Opening Channel List

Code Account Opening Channel Score

3.5.4 Client Segment