FCM Services Features

FCM Services Suite Features :
Screening, Profiling, KC+
Information in this document is subject to change without notice.
No part of this document may be reproduced or transmitted in any form or by any means, for any purpose,
without the express written permission of TEMENOS HEADQUARTERS SA.
COPYRIGHT 2007 - 2016 TEMENOS HEADQUARTERS SA. All rights reserved.

Document History
Version Date Author Comments / Change Description

0.1 FCM team First draft
0.2 Gaetan Deblaere Review and update
0.3 Vincent Dupuis Clarifications and amplifications
Added missing sections
0.4 Vincent Dupuis Corrections and amplifications
0.5 Vincent Dupuis Change description of KC+ functionality
0.6 Marlène Meli Review and proposed updates

Add section about Security, Reporting Framework,
System administration and releases.
0.8 Vincent Dupuis Slight Structure change to improve legibility
0.10 Gaetan Deblaere Update changes for release 201610
Information in this document is subject to change without notice.
No part of this document may be reproduced or transmitted in any form or by any means, for any purpose,
without the express written permission of TEMENOS HEADQUARTERS SA.
COPYRIGHT 2007 - 2016 TEMENOS HEADQUARTERS SA. All rights reserved.

FCM Services
User Guide for Business Functions
Table of Contents
Table of Contents
1. Introduction ............................................................................................................................................6
2. FCM Screen: Sanctions screening ........................................................................................................7
2.1 Support of public lists, data provider supplied lists and bank’s private lists ................................7
2.1.1 Watch Lists data separation per business unit ........................................................................7
2.1.2 Public lists supported: OFAC, EU, UN .....................................................................................7
2.1.3 Data providers supported lists: WorldCheck, Factiva / DowJones, Accuity ............................7
2.1.4 Private Lists .............................................................................................................................8
2.2 List management .........................................................................................................................9
2.2.1 Data imported from the lists .....................................................................................................9
2.2.2 Enrichment of data from the lists: permutations and variations ............................................ 11
2.3 Transactions screening and Customers screening .................................................................. 15
2.3.1 Transaction screening........................................................................................................... 15
2.3.2 Customer Information screening at on boarding time........................................................... 15
2.3.3 Ad Hoc Customer Information screening .............................................................................. 16
2.3.4 Customer Information database screening on a daily basis ................................................. 16
2.4 Scanning methods .................................................................................................................... 16
2.4.1 Normalization to compare apples to apples.......................................................................... 16
2.4.2 Exact match or literal scan .................................................................................................... 18
2.4.3 Approximate match or Relaxed Pattern Matching ................................................................ 19
2.4.4 Enhanced Recognition Module ERM .................................................................................... 23
2.4.5 Detect Banks, Cities and Countries aliases and identifiers .................................................. 23
2.4.6 Bank/City/Country Data Update Service ............................................................................... 26
2.4.7 Match Chinese Commercial Codes (CCC) to Pinyin name .................................................. 27
2.4.8 FATF R16 Scanning ............................................................................................................. 28
2.5 Reducing the number of false alerts ......................................................................................... 28
2.5.1 CRS (reducing number of false alerts based on the text morphology) ................................. 28
2.5.2 CSF (reducing number of alerts using entity types) ............................................................. 30
2.5.3 Reduction of Alerts on transactions: creating SKIPs that prevent recurrent alerts to be raised
on the same text against the same black listed entity ......................................................................... 30
2.5.4 CIF (Customer Information File) Screening .......................................................................... 31
2.6 Screen User Interfaces ............................................................................................................. 31
2.6.1 Alert Manager ....................................................................................................................... 31
2.6.2 Screen Watch List Manager ................................................................................................. 35
2.6.3 Reporting for FCM Screen .................................................................................................... 35
2.7 Case management: 2 eyes or 4 eyes principle ........................................................................ 38
2.7.1 Alert Manager ....................................................................................................................... 38
2.7.2 Flush operations ................................................................................................................... 38
FCM Services Version 0.9
3
FCM Services
2.7.3 Watch List Manager: ............................................................................................................. 38

2.7.4 Using the 2 or 4 eyes principle examples ............................................................................. 38
2.8 Mapping Interface for any XML message into FCM XML ........................................................ 39
3. FCM Profile: Behaviour analysis ........................................................................................................ 40
3.1 Detect suspicious activity by grouping transactions and using compare rules ........................ 40
3.1.1 General concept .................................................................................................................... 40
3.1.2 Transactions are grouped in aggregates (AKA profiles)....................................................... 40
3.1.3 What is a comparison rule? .................................................................................................. 43
3.1.4 A rule on a profile can be applied on .................................................................................... 49
3.1.5 A rule on a transaction can be applied on ............................................................................ 51
3.1.6 Handle complex requirements by linking rules together ....................................................... 53
3.1.7 Increase rule relevance by defining threshold ...................................................................... 53
3.1.8 Ignore bank holidays ............................................................................................................. 53
3.1.9 Scoping: Include/exclude entities and select pre-defined filters ........................................... 54
3.1.10 Peer Groups: Detect deviating behaviour of customers ....................................................... 54
3.1.11 When the condition is met, an alert is generated ................................................................. 55
3.2 Profiling Alerts management .................................................................................................... 55
3.2.1 Alert on transaction amount .................................................................................................. 57
3.2.2 Alert on profile rules .............................................................................................................. 59
3.3 Case management : 2 eyes or 4 eyes principle ....................................................................... 60
3.4 Data imported ........................................................................................................................... 61
3.4.1 Customer data imported ....................................................................................................... 61
3.4.2 Account data imported .......................................................................................................... 65
3.4.3 Transaction data imported .................................................................................................... 68
4. FCM Know Customer plus (KC+): Customer risk calculation ............................................................ 73
4.1 Customer Risk Calculation ....................................................................................................... 73
4.1.1 Calculator .............................................................................................................................. 73
4.1.2 Calculate Risk for many customers ...................................................................................... 74
4.2 Supported Factors and Attributes for risk calcuation ............................................................... 74
4.2.1 Customer............................................................................................................................... 74
4.2.2 Checks .................................................................................................................................. 77
4.2.3 Assessments ......................................................................................................................... 77
4.2.4 Account ................................................................................................................................. 77
4.2.5 Meaningful Functions ............................................................................................................ 77
4.3 CIF Dynamic Fields: ability to add new fields on the fly ........................................................... 78
5. FCM Security ...................................................................................................................................... 79
5.1 Authentication ........................................................................................................................... 79
5.1.1 Build-in authentication module .............................................................................................. 79
5.1.2 Authentication handles by application server ....................................................................... 79
5.2 Authorisation module: FCM Rule Manager .............................................................................. 79
4
FCM Services
5.2.1 Mandators: how to handle multiples companies, subsidiaries or business units within a
single FCM Screen instance ............................................................................................................... 79
5.2.2 Users belong to profiles giving access to a configured list of features in a configured list of
modules 80
5.2.3 The access to FCM Screen application modules is governed by rules ................................ 80
6. FCM Reporting: the Reporting Framework ........................................................................................ 82
6.1 Browsing tables ........................................................................................................................ 82
6.2 Filter .......................................................................................................................................... 82
6.2.1 Simple filter ........................................................................................................................... 82
6.2.2 Filter based on joint tables .................................................................................................... 82
6.3 Count statistics ......................................................................................................................... 82
6.4 Dashboards .............................................................................................................................. 82
6.5 Report generator ...................................................................................................................... 82
6.6 Report Scheduler ...................................................................................................................... 82
7. System administration ........................................................................................................................ 84
7.1 Screen parameter wizard ......................................................................................................... 84
8. FCM Integration with other systems ................................................................................................... 85
8.1 Screen Integration .................................................................................................................... 85
8.1.1 Transaction screening........................................................................................................... 85
8.1.2 Customer Information File (CIF) screening........................................................................... 85
8.2 Profile Integration ..................................................................................................................... 85
8.3 Out of the bow integration with T24 .......................................................................................... 85
9. What feature available form what release? ........................................................................................ 86
9.1 R201604 ................................................................................................................................... 86
9.2 R201607 ................................................................................................................................... 86
5
FCM Services
1. Introduction
This document describes the set of the Standard Features available with the Financial Crime Mitigation
(FCM) Suite software:
The features can be regrouped as follow:
• the 3 main FCM modules
o FCM Screen
o FCM Profile
o FCM KC+
• The 3 common modules
o FCM Reporting Framework
o FCM Security module for authorisation
o FCM System administration module
Extended Features of FCM Suite are also available as chargeable options. These are described in
separate documents, each describing the features of a given module.
This document also describes
• The integration options
• The features and the releases
6
FCM Services
2. FCM Screen: Sanctions screening

The FCM Sanctions Screening system consists in an integrated Application Suite that covers the
following functionality:
- Watch Lists Management
- Interfacing with the Back-Office Systems
o Web Service in SOA mode
o Using message Queues
o By files extraction and import
- Screening Engine
- Alert Management
- Reporting
Each of these functionalities are supported by a specific module and are described hereafter..
2.1 Support of public lists, data provider supplied lists and bank’s
private lists
2.1.1 Watch Lists data separation per business unit
FCM Suite is architected in the way that a single instance of the system can support multiple legal
entities, or within a legal entity multiple business units. Each such unit is called “mandator”.
It’s the bank’s decision on how its business is logically divided; a mandator can be a branch, an office,
a group of clients, a region, a country, and so on.
Each mandator has its own set of Watch Lists. Watch Lists can be grouped in 3 types: 1. public lists
(e.g. OFAC, EU, UN), 2. Global lists (bank’s own globally applicable names lists) and 3. Private lists
(mandator specific names lists). Global lists are applicable to all mandators, but private lists are only
applicable to a particular mandator.
2.1.2 Public lists supported: OFAC, EU, UN

The Supported Public lists are available either:
- directly from the regulatory authorities for free (OFAC, EU, UN)
- from commercial data suppliers (WorldCheck, World Compliance, Factiva/Dow Jones, Accuity)
2.1.3 Data providers supported lists: WorldCheck, Factiva / DowJones, Accuity
2.1.3.1 WorldCheck
World-Check (http://www.world-check.com) offer services focused on several regulatory aspects..
This file integrates PEP and sanctioned entities records. WorldCheck is a subsidiary of the
Thomson Reuters company.
The WorldCheck data can be obtained in the “normal” format or in the “premium” format. The
premium format contains more detailed information and columns.
A record of the WorldCheck file represents an entity – a sanctioned entity, a PEP or another type
of entity. Such an entity can belong to several sanctions lists: e.g. a given entity can exist in the
OFAC, EU, US Treasury, Canadian sanctions lists. We therefore call the WorldCheck file a
7
FCM Services
“grouped entity” file, whereas some other supplier’s files would provide a separate record for each
occurrence of the entity in a sanctions list.
Because of the file size, FCM Screen supports the import of the WorldCheck file in “delta” mode.
In this mode, a comparison is made between the current and the previous WorldCheck files, and
only the records where there is a difference or when there is no match are taken into
consideration. (While WorldCheck also publishes deltas, these specific files are not supported.)
2.1.3.2 Factiva / DowJones

Factiva is now integrated in the Dow Jones company. It provides information databases focused
on regulatory aspects.
FCM Screen is able to integrate the lists published under the name DowJones Watchlist.
2.1.3.3 Accuity
The Accuity file is published by Accuity a member of the Reed Elsevier Group. This company
is specialized in Data management for financial institutions. They are also delivering the well-
known Bankers Almanac. In the context of the compliance business, Accuity issues the
“Global Watch List” (http://www.accuity.com/compliance/global-watchlist/).
Accuity provides the lists in either the “single entity” or in the “grouped entity” formats.
In the case of “grouped entity” format, such an entity can belong to several discrete sanctions
lists: e.g. a given entity can exist in the OFAC, EU, US Treasury or Canadian sanctions lists.
In the case of “single entity” format, each record represents a sanctions list entry.
FCM Screen supports the Accuity provided files formats:
- PIDGWL “single entity” Global Watch List
- PIDETCGWL “grouped entity” Global Watch List
1
- UPIDGWL “single entity” Global Watch List using the UTF-8 character set
Accuity provides the PEP information in either the PIDGWL or the UPIDGWL format. FCM
Screen handles both sanctions lists and PEP lists in the same database.
The files are published every day. FCM Screen supports the import of the Accuity file in “delta”
mode. In this mode, a comparison is made between the current and the previous Accuity files, and
only the records where there is a difference or when there is no match are taken into
consideration.
2.1.3.4 WorldCompliance
The FCM Screen support the World compliance list format
2.1.4 Private Lists

Besides the public lists used by the bank, FCM Screen provides support of private lists that contain bank
managed and owned search names.
Private lists can have a global scope – Private Global Lists - or a scope limited to a given “mandator” –
Private Lists.
The Private Global Lists are applicable, like the Public Lists for the whole system, i.e. all mandators. The
Private Lists are only applicable for the business unit represented by the mandator code.
1
In this format, an additional column is provided with the names expressed in native characters.
8
FCM Services
2.1.4.1 Private Lists Import in fixed or delimited format

It is possible to import a list maintained by the bank externally to FCM Screen. This is also known
as a ‘private import’.
There are two supported formats: fixed length and delimited fields. In the delimited fields format–
also called “character separated” format - the separator character can be chosen. The system
supports the escaped fields: e.g. if the separator character is the comma, it is possible to put a
coma inside the data by enclosing the content of the field between ” (the double quote character,
e.g. “apples, carrots, oranges”).
2.1.4.2 Private Lists Import supported character set

This import supports the UTF-8 and the ISO-8859-x character sets.
The bank should ensure that the character set used corresponds to that of the original imported
data.
2.1.4.3 Private Lists Import required fields and field mapping

With the private lists import, you can upload, the name, surname of the entity, the aliases, the
addresses, the passport number, the social security number and the birth date.
The fields Address, Alias, Birth date, Passport and social security number can contain multiple
values. Each instance of an alias is separated from the next by a character that must be different
from the character used for the separation of the fields. This is configured with a data transformer.
It is possible to link an entry to several lists. This is also configured with a data transformer.
Data transformers are code that implements the support of data mapping and optional
transformation so that an external format can be understood by the Private Lists import program.
2.2 List management

2.2.1 Data imported from the lists
The following data is imported from the sanction list file into the FCM database. This allows to
enhance and manage data in a controlled manner
• name,
• given name,
• type (Individual, Bank, Vessel,…),
• list name
• ID,
• honorific(s),
• alias(s),
• address(s),
• birth date(s),
• decease date(s),
• IDs (passport, national id,…),
• further information (sanction program, remarks,…)
Note that the specialised import for OFAC, EU, UN, WorldCheck, Factiva / Dow Jones and
Accuity supports the same type of data:
• Name of the entity
• Titles and honorific
2
• Events
• Addresses
2
Date of birth, Death date, Incorporation date, …
9
FCM Services
• Aliases
3
• Identifiers of this entity
• Additional information
• Associations
Besides these data provided directly from imported file, the application maintains automatically
generated data and user-modified data.
Automatically generated data includes
• Permutations (alterations based on names and aliases using a set of algorithms
depending on the entity type – individual, company, organisation, …)
• Variations (alterations of people's names based on a set of algorithms taking usual name
usage into consideration, e.g. nicknames, abbreviations, language specific spelling
variations…)
Sometimes the data from the official list can be amended and adapted to the situation of the
bank. This can be done manually:
• Deactivation of aliases, permutations, variations
• Addition of SKIPs
• Additional private aliases, addresses, events, identifiers.
All the dependant information (title, date of birth, address, alias, identifier, further info) are linked
to the main entry in a 1 to n relationship; for one entity entry, there are several possible titles,
addresses, aliases, dates of birth, identifiers and additional information.
The name of the entity refers to the principal name of the person, organisation or company. If the
entity is known under other names, these are stored as aliases.
Events (like the date of birth) also include the place at which the event occurred. When several
places for the same event are mentioned in the input file, and if there is no direct link between the
place and the date, the locations are concatenated and associated with each date.
Sometimes, the date of an event is incomplete (month or day) but can still be parsed by the
import; the date will be flagged as “Approximate”. If the format of the date cannot be parsed, the
date is flagged as “Unparsed”.
The address needs to contain at least one of the components: address line, city, zip code, state,
country.
Aliases are a list of equivalent names provided for an entity. They are not generated
automatically.
Identifiers are attributed by official administrations: passport numbers, social security numbers,
driver licenses, VAT numbers, SWIFT codes, Clearing House Codes, …
Additional information contains references to the legal decisions, in text or via an URL. We can
also find Web links to external web-sites containing information related to an entry.
Associations are links between entities. An association is either a family link or a business link.
From one entity you can get the list of the linked entities. Currently, it is not possible to browse
the database links from one entity to another.
Note: Details about technical references and data attributes can be found in the Appendix in
chapter 6.
3
Social security number, passport numbers, …
10
FCM Services
2.2.2 Enrichment of data from the lists: permutations and variations

To enhance and complement the detection features of the scanning engines, alterations of the
4
names of each entry are generated and added every time a name is added/modified in the
database. The purpose of such alterations is to increase true hit detection without the need to
reduce RPM threshold.
Note: More details to computed data enrichments are described in the appendix.
2.2.2.1 Variations
Variations are generated using the existing names and Temenos proprietary algorithms. The
generated alterations are based on statistically likely variants of the name components (e.g. a
variation of Robert Deblaere could be Bob Deblaere). Such additional variations allow to keep
a higher RPM (Relaxed Pattern Matching) threshold and hence reduce false hits but still be
able to detect potentially true hits.
2.2.2.2 Permutations
Permutations are generated using the existing names and Temenos proprietary algorithms. It
is possible to add the Variations to the set of permutations input data. The generated
alterations are permutations of the name and given name, valid initials, removal of
parentheses and company markers.. Based on the bank’s specific risk based approach and
screening requirements additional permutations types can be added to the lists entries.
2.2.2.3 Smart Variations Module SVM

The Smart Variations Module is a new GUI that allows educated users to manage and
configure various additional permutations. These permutations enrich FCM Screen’s
knowledge base containing all interdict data used for screening. SVM allows further to use the
additional permutations selectively, e.g. for specific mandators, for entries in some of the lists,
for some transactions, depending on the bank’s specific requirements and risk appetite (see
also chapter 2.8.1 Screen administration “Mandators”).
1. Last Names only: This feature generates permutations (under conditions) consisting in
only last names without first names and is only applicable to individuals entity types.
Conditions refer to minimum_word_count, minimum_word_size and minimum_size in
order to prevent permutations on too short names with too many false hits.
Examples:
Entry / Alias Permutation: Last name only
GRAJALES LONDONO, JUAN RAUL GRAJALES LONDONO
CAICEDO VERGARA, NOEMY CAICEDO VERGARA
L EMIR N/A (conditions not met, too short)
2. Given names only: Technically the same feature as before with same (or even more
restrictive) conditions but only for first names applied.
Examples:
Entry / Alias Permutation: Given name only
GRAJALES LONDONO, JUAN RAUL JUAN RAUL
CAICEDO VERGARA, NOEMY N/A (too short, conditions not met)
CAZARES SALAZAR, BLANCA MARIA BLANCA MARIA
3. Glued entries: This feature generates permutations of names and aliases with any
spaces in between removed and allows to cope with cases where voluntary blanks
and spaces have been removed in transactions. Conditions refer to list name (e.g.
only for OFAC list) and minimum_size.
4
Standard names and aliases.
11
FCM Services
Examples:
Entry / Alias Permutation: Glued
GRAJALES LONDONO, JUAN RAUL GRAJALESLONDONOJUANRAUL
4. Partial Names (Tokens_and_Clique): This feature generates permutations of sub-

parts of names, both first and last names. Conditions refer again to minimum_size,
minimum_word_size, minimum_word_count, list name, entry types,
maximum_front_names, maximum_back_names and maximum_given_names.
Examples:
Entry / Alias Tokens and Cliques
NOURY, JEAN STEPHANE PAUL NOURY JEAN, NOURY STEPHANE
DUPONT LAJOIE, ANDRE DUPON ANDRE, LAJOIE ANDRE
In addition there is the table of given name cliques with additional variations of first
names, e.g. William, Guillermo, Bill.
Examples:
fr: GUILLAUME
en: WILLIAM, BILL, WILL, BILLIE, BILLY, LIAM, WILLY
es: GUILLERMO
5. Ordinals: This feature generates permutations for names that contain an ordinal value
in numerical (10th) or alphabetical order (tenth). Conditions refer again to list name,
minimum_size, minimum_word_size, minimum_word_count and entry type.
Examples:
Entry / Alias Permutation: Ordinal
8TH IMAM INDUSTRIES GROUP EIGHTH IMAM INDUSTRIES GROUP
RESISTANCE GROUP FIRST OCTOBER RESISTANCE GROUP 1ST OCTOBER
6. Main URL component: This features generates aliases extracted from main
components of URLs mentioned as aliases in interdict lists like OFAC. Conditions
refer to list name, minimum_word_size and minimum_word_count.
Examples:
Entry / Alias Permutation: Main URL component
www.no.gocubaplus.com GOCUBAPLUS
www.nuevocontinente.com.pe NUEVOCONTINENTE
www.kahanetzadak.com KAHANETZADAK
7. Segment Slice: This feature generates permutations by decomposing some words into
separate words when the systems considers the name was concatenated from 2
words, one of which with a frequent business-related suffix or prefix. Conditions refer
to entry type, list name and miminum sizes and word counts. The default set of values
contains INVEST, EXPORT, BANK, COMPANY, CORP
Examples:
Entry / Alias Permutation: Segment slice
BARAKAAT GLOBETELCOMPANY BARAKAAT GLOBETEL COMPANY
DISTRIEXPORT DISTRI EXPORT
8. Abbreviation swap: This feature generates permutations for a standard set of

commercial abbreviations such as CO: COMPANY, CORP: CORPORATION, INC:
INCORPORATED, HOLD: HOLDING, IMPEX: IMPORT EXPORT, DEPT:
DEPARTMENT, GRP: GROUP, SHPG: SHIPPING, FRT: FREIGHT. Conditions refer
to entry types, list name and minimum sizes and word counts.
12
FCM Services
Examples:
Entry / Alias Permutation: Abbreviation swap
EURO COMPANY EURO CO
DISTRI IMPORT EXPORT DISTRI IMPEX
DISTRIBUTION SHPG DISTRIBUTION SHIPPING
9. Singleton Expand: This feature is a combination of Segment slice (see 7.) and
Abbreviation swap (see 8.) but works with single words only. Default set of values are
CO: COMPANY, EX: EXPORT, HOLD: HOLDING, INC: INCORPORATED; INVE:
INVESTMENT. Conditions refer to entry type, list name, suffixes, miminum sizes for
prefix, word and word count.
Examples:
Entry / Alias Permutation: Singleton expand
SCOTRACO SCOTRA CO, SCOTRA COMPANY
BELMEX BELM EXPORT, BELM EX
10. Alternation Symbol “/”: This feature generates permutations by extracting aliases
having the symbol. “/” in the name and is only applied to non-individual type entries.
Conditions refer to entry type, list name, minimum sizes for word and word count.
Examples:
Entry / Alias Permutation: Alternation name
7TH OF TIR ISFAHAN/ESFAHAN 7TH TIR ISFAHAN, 7TH TIR ESFAHAN
11. Person Initials: This feature splits standard person permutation generation in 2 parts
and is mainly applied to entry type individuals or similar. The system combines the
name and each given name of a person and generates permutations with the initials.
Conditions refer to entry type, minimum sizes for word and word count.
Examples:
Entry / Alias
CAZARES SALAZAR, BLANCA MARIA
Permutation: Person initials

B CAZARES SALAZAR, B M CAZARES SALAZAR, M CAZARES SALAZAR,
CAZARES SALAZAR B, CAZARES SALAZAR B M, CAZARES SALAZAR M
12. Person Name: This features splits the standard person permutation generation in 2
parts. It combines the name and each given name of a person and creates
permutations but no new initials other than those present in source lists. Conditions
refer to list name, entry type, minimum sizes for word and word count.
Examples:
Entry / Alias
Permutation: Person name

BLANCA CAZARES SALAZAR, BLANCA MARIA CAZARES SALAZAR, MARIA
CAZARES SALAZAR
CAZARES SALAZAR BLANCA, CAZARES SALAZAR BLANCA MARIA, CAZARES
SALAZAR MARIA
13. Standard Person: This features generates permutations for individuals by combining
name and given names of a person including initials. Conditions refer to entry types,
list name and minimum sizes for word and word count.
13
FCM Services
Examples:
Entry / Alias
Permutation: Standard person

B CAZARES SALAZAR
BLANCA CAZARES SALAZAR
B M CAZARES SALAZAR
BLANCA MARIA CAZARES SALAZAR
MARIA CAZARES SALAZAR
M CAZARES SALAZAR
CAZARES SALAZAR BLANCA
CAZARES SALAZAR B
CAZARES SALAZAR BLANCA MARIA
CAZARES SALAZAR B M
CAZARES SALAZAR MARIA
CAZARES SALAZAR M
14. Company marker: This feature generate permutations for companies by removing
some frequent legal suffixes that are not always present in a screened transaction.
Conditions refer to entry types, list name, semicolon separated list of values for
suffixes, prefixes and infixes, minimum sizes for words and word count.
Examples with suffixes = S. A., S. A. DE C. V., PLC:

Entry / alias: Permutation: Company marker:
IMMOBILIARIA LA PROVINCIA S A DE C V IMMOBILIARIA LA PROVINCIA
MELFI MARINE S.A. MELFI MARINE
MELLI BANK PLC. MELLI BANK
15. Possessive Mark, Remove Dot, Remove Parenthesis, Short Word: These features
normalize list entries and text in transactions for screening in order to make them
“similar” for screening.
Examples:
Entry / alias: Mohammed’s Army
Permutations Possessive Mark: MOHAMMED’S ARMY, MOHAMMEDS ARMY,
MOHAMMED ARMY
Entry / alias: I. B. M.
Permutations Remove Dot: IBM
16. Advanced Configuration: The Pipeline allows to configure a sequence in which the
various permutations are generated. It allows also to perform several rounds with
different so called permutations producers to generate permutations. The pipeline
stores in the generation path which smart variation led to a given result. Below is an
th
example of such a sequence with different rounds with interdict entry 7 OF TIR
INDUSTRIES OF ISFAHAN/ESFAHAN
Interdict entry: Generation Path
7TH OF TIR INDUSTRIES OF ESFAHAN Alternation_symbol

TH
7 OF TIR INDUSTRIES OF ISFAHAN Alternation_symbol
7THTIROFINDUSTRIESOFESFAHAN Alternation_symbol + glue
7THTIROFINDUSTRIESOFISFAHAN Alternation_symbol + glue
14
FCM Services
7THTIROFINDUSTRIESOFISFAHANESFAHAN glue
SEVENTH OF TIR INDUSTRIES OF ordinal

ISFAHAN/ESFAHAN
SEVENTH OF TIR INDUSTRIES OF ISFAHAN Ordinal + alternation_symbol
SEVENTH OF TIR INDUSTRIES OF ESFAHAN Ordinal + alternation_symbol
SEVENTHOFTIRINDUSTRIESOFISFAHAN Ordinal + alternation_symbol + glue
SEVENTHOFTIRINDUSTRIESOFESFAHAN Ordinal + alternation_symbol + glue
SEVENTHOFTIRINDUSTRIESOFISFAHANESFAHAN Ordinal + glue
17. List of removable company markers and legal suffixes
2.3 Transactions screening and Customers screening

2.3.1 Transaction screening
FCM Screen can check the content of each field of a transaction (e.g. a payment instruction) in order
to make sure that none of the parties involved is sanctioned.
This is a real time process.
This screening process takes place in the flow of transaction processing and stops the flow in case
the transaction contains a sanctioned party (i.e. a search name or interdict in one or several lists),
that generated a compliance Alert. The transaction flow can resume after the Alert evaluation
“approves” the transaction, or be ended if the Alert evaluation “cancels” the transaction. In both
cases, approved or cancelled transaction, a respective status information will be sent back to the
transaction delivering application.
2.3.2 Customer Information screening at on boarding time

FCM Screen can check, at on boarding time, if the customer is on a sanction list.
15
FCM Services
This screening process takes place in the flow of the on boarding process. The customer on
boarding will be influenced by the result of the screening.
Besides checking for sanctioned entities, the Customer screening can check at the same time if the
customer is a Politically Exposed Person (PEP) or any other unwanted/no longer wanted banking
client relationship (e.g. name added in bank’s global list or mandator specific private list). This can
thereafter be flagged in the bank’s customer database.
The feature of CIF Dynamic Fields, as described in 4.3 CIF Dynamic Fields can also be used at
customer onboarding.
2.3.3 Ad Hoc Customer Information screening

The Web Inquiry Tool (WIT) of FCM Screen can be used to perform ad hoc screening of customer
names, checking that it is not on a sanctions list.
This allows compliance operators or branch employees to do some preliminary checks or
verifications when needed.
2.3.4 Customer Information database screening on a daily basis

FCM Screen can check the entire customer database to find sanctioned customers.
This is a batch process, usually run once a day. As the same process is used in FCM Profiling and
FCM KC+ you can find more information in this chapter 3.4.1 Customer data imported
Besides checking for sanctioned entities, the Customer screening can check at the same time if the
customer is a Politically Exposed Person (PEP) or any other unwanted/no longer wanted banking
client relationship (e.g. name added in bank’s global list or mandator specific private list). This can
thereafter be flagged in the bank’s customer database.
2.4 Scanning methods

The screening engine part of the solution is designed to detect and report alerts against interdict
entries if they are found in the submitted text (transactions, customer record, etc.). The scanning
engine compares two strings, string 1 and string 2, where string 1 represents the text being screened
(e.g. transaction, CIF record or financial message) and string 2 represents a watch list entry. Then
string 1 and string 2 are compared character by character in order to determine how syntactically close
the 2 strings are. As string 1 and string 2 can be different the screening engine uses besides exact
match also several algorithms that can accommodate the most frequent exceptions and/or alterations
that are likely to be encountered in the comparison, e.g. typos, misspellings, transposed letters or
name variations.
The screening engine first parses and splits the submitted text into separate sub-elements (fields) and
then screens these fields for the possible presence of an interdict entity, possibly more than a single
one. Several scanning methods or algorithms are applied to the relevant fields, depending on their
nature, possible content, semantics and so on. This chapter gives a comprehensive description of
these methods and a detailed explanation on how they proceed.
It is important to note though that a combination of enriched data together with scanning methods
allow for most accurate hit detection and low false hits rate.
2.4.1 Normalization to compare apples to apples

Normalization of strings is the key to compare apples with apples. Prior to screening and
independently of the scanning method, the data content to be screened (string 1) and that of interdict
16
FCM Services
entries (string 2) to be screened against are normalized to handle variations such as letter case,
presence of punctuations, initials, name and given name order, meaningless words (so called noise
words) and consistent handling of characters with diacritical signs. More details regarding data
enrichments, permutations and variations added to interdict entries that support hit detection can be
found in chapter Error! Reference source not found.
2.4.1.1 Case tolerance, punctuations, special characters

Letter Case tolerance as well as special characters handling is achieved by replacing when
possible each character by the uppercase equivalent without diacritics where appropriate:
“a = A, b = B, é = E, etc.”.
Handling of punctuations is achieved by replacing any non-alphanumeric character or sign by
a space character. When multiple spaces are present, these are compressed into a single
one.
Examples:
"Robert Smith" => "ROBERT SMITH"
"Robert+Smith/" => "ROBERT SMITH"
"Robert Smith" => "ROBERT SMITH"
"Röbert Smîth" => "ROBERT SMITH"
The same principle applies in the same manner for non-latin scripts:
“клмф” => “КЛМФ”
2.4.1.2 Tolerance to names and initials

For individuals, the engine takes advantage of permutations and initials, computed as
described in Error! Reference source not found..
Example:
Interdict entry: ”GAETAN ABRIEL DEBLAERE”
Permutations and initials:
“GAETAN ABRIEL DEBLAERE”
“DEBLAERE GAETAN ABRIEL”
“GAETAN DEBLAERE”
“DEBLAERE GAETAN”
“GAETAN A DEBLAERE”
“DEBLAERE GAETAN A”
“G A DEBLAERE”
“DEBLAERE G A”
Any of the above listed texts will be used as search name in transaction screening.
2.4.1.3 Variations on names with quote

One character has a special status when present in interdict entries: the single quote
character (‘). This character is sometimes present in names, like in: “Brian O’Reilly”. For the
entries containing this character, one additional variation is generated to give the screening
engine more chance to trigger an alert against the common variation which would not contain
this sign.
Example:
“O’Reilly” will be used to create both “O REILLY” and “OREILLY”.
17
FCM Services
2.4.1.4 Remove Noise Words

Entries or text can contain words that are not adding sense or value. In FCM Screen these
meaningless words are called “Noise Words”. These can prevent an alert from being triggered.
For example, it is legitimate to trigger an alert on text “HOLA SUN HOLIDAYS” against an
interdict entry “HOLA SUN HOLIDAYS LIMITED”, because the word “LIMITED” is a noise
word in this context.
Noise words can appear anywhere in the interdict entry: at the beginning, at the end or in the
middle:
Examples:
“THE MODERN LAUNDRY BLUE FACTORY”
“T AND M GROUP DECORATION CENTRE”
“TEAM WORK INTERNATIONAL COMPANY”
The screening engine includes a standard feature to handle these noise words to increase the
potential for interdict entries detection. The principle is to allow an alert to be reported even if:
• noise words are present in the interdict entry but not in the screened text
• noise words are present in the screened text but not in the interdict entry
• extra or different noise words are present in the text the be screened
The technical implementation simply consists in removing these noise words in both interdict
entry and text to screen, when present.
Remark on noise words clean-up in interdict entries: a sanity check is performed for interdict
entries to ensure that the remaining text contains at least two words and that the total length is
at least 5 characters. This will prevent short patterns to be added as interdict which could lead
to undesired false positives (abnormally high number of alerts reported).
The noise words list is the following:
LIMITED LE CENTER CENTRAL
LTD LES INTERNATIONAL PARTY
LTDA DU GROUP WORLD
INC LA ORGANIZATION ARMY
INCORPORATED DES ESTABLISHMENT NATIONAL
BROTHERS IN SOCIETY CONSTRUCTION
SA DA TRADING SERVICES
COMPANY FOR CORPORATION SERVICE
ET POUR AIR BUILDING
AND FOUNDATION COMMERCIAL BUSINESS
THE FONDATION INVESTMENTS INDUSTRIES
OF FUND SYSTEMS ENTERPRISE
DE FOND AGENCY GENERAL
This list is based on statistical analysis of interdict entries from public lists, as well as on
statistical analysis of huge sets of real-life transactions. This list cannot be modified.
2.4.2 Exact match or literal scan

This is the simplest scanning method. This method is also called “Literal Scanning”
Literal scanning will trigger an alert when the content to be screened contains one or more interdict
entries, written in the same way (after the normalization described in 2.4.1).
Example:
18
FCM Services
Interdict entry “JOHN DOE” will be detected in text to screen: “MR JOHN DOE”
Interdict entry “BAD GUYS COMPANY” will be detected in text to screen: “BAD GUYS”
Interdict entry “ARMY REVOLUTION” will be detected in text to screen: “ARMY OF
REVOLUTION”
2.4.3 Approximate match or Relaxed Pattern Matching

Approximate Match is also known as Relaxed Pattern Matching or simply RPM. RPM is the term
which will be used in this chapter.
As opposed to the literal screening [designed for exact match], the Relaxed Pattern Matching (RPM)
is an additional feature that will allow handling of:
• Misspellings and typos
• One or more characters missing
• Letters permutations
• Additional characters
• Missing words
• Wrong words separation
• Other similar situations
In addition to the detection itself, this method provides an indication regarding the “quality” of the
alerts detected, in the form of a score. Keeping or rejecting the detected alert can be decided based
on this score. The score is a number between 0 and 100.
The only configurable parameter is the score threshold: this is the minimum score considered as
meaningful for a detection to be reported. The meaningful values for the thresholds range from 90 to
100. As a low threshold can lead to an undesirable number of spurious alerts, it is recommended for
the bank to model the effect of the threshold and to set the value accordingly.
The detection of misspelled patterns (interdict entities) is done as follows:
• Selection of potential entity comparison candidates using a sound proximity algorithm
(Temenos proprietary algorithm, making use of the Soundex Method, but adapted to fit the FCM
Screen requirements). The same algorithm is applied to the text to be scanned to identify the
corresponding comparison candidates.
• Comparison of the text with all the corresponding candidates using a Temenos Fault
Tolerant Pattern Matching Algorithm. This results in a comparison score.
• Selection of the candidates based on their comparison score and the specified threshold.
RPM only applies for entities that after semantic normalization have a length greater than 5
characters (that is 6 characters or more).
Example:
“OMAR” will never match with “UMAR”, “OMIR”, “OMAC”, etc.
“ABDUL” will never match with “ABDEL”, “ABDIL”, etc.
The reason is that allowing approximate pattern matching on short entities always leads to an
unacceptable false positive rate.
For a given entry against a given candidate, the score, representing the syntactic and semantic
proximity, is calculated using several factors:
• Comparison of lengths (text pattern vs candidate)
• Number and nature of faults
• Nature of faults
19
FCM Services
All these numbers are combined together with several weights to compute a global score.
Note that the same number and nature of faults in two entries with different length will give totally
different scores: the price for one single fault in a 7 characters string is much higher than in a 20
characters string. Due to rounding, it may happen that a RPM hit will have a 100% score.
RPM Detection Examples, score=99:

Text Content Interdict entity Score
CAROLINE CAROLINA 99
CHAN WEI CHEN WEI 99
ENRICA INRICA 99
FRANCESCO FRANCISCO 99
GERMAN QERMAN 99
IMPRESA IMPRISA 99
KAROLINA CAROLINA 99
MOHSIN MOHSEN 99
SANIBEL SANIBAL 99
SERENA SIRENA 99
SERGEI SERGEY 99
VALENTINA VALENTINE 99

BARZAN BARSAM 98
CASPER KASPAR 98
CHAN WEI CHEN WAI 98
CHIN MENG CHEN MING 98
HESSEN HASSAN 98
HOUTEN HOOTAN 98
KANAKO GANEKO 98
MONICA MUNECA 98
NICHIDO NACHITO 98
PATRYCJA PATRICIA 98
RIBA AL RABI AL 98
TELEBEN TALEBAN 98

CHAN WEI KHIN WAI 97

FREDERIC FREDERICO 96
ROADTRANSPORT ROAD TRANSPORT ENTERPRISE 96
VALENTIN VALENTINE 96

A DOCTOR AL DOCTOR 95
ABDULAZIZ ABDUL AZIZ 95
AL SHAMIA AL-SHAMI A 95
ALFRED ALFREDO 95
ANIBAL SANIBAL 95
BOLSA S A BOLSAK S.A. 95
20
FCM Services
CATALIN CATALINA 95
GRENOBLE GRANOBLES 95
HERMAN HERMANN 95
UMBERTO HUMBERTO 95

A RATA A R ATA 94
ARMADA PARMIDA 94
BELSTR BELSTAR 94
COLORS COLORES 94
CONTROLS KONTROLES 94
DELOS REYES DELOS REYES U 94
E CABELLO EL CABALLO 94
ELSTER BELSTAR 94
HARMAN HERMANN 94
HASAN KHASAN 94
IND SAN SINT SAN 94
IRENE EIRENE 94
KATALIN CATALINA 94
MOHAMED MOHAMMED 94
OP DEN TOP DIN 94
PALMER PALMARY 94
PATTERSON FR PATTERSON FARM 94
ROMAN ROMANA 94
SERGE SERGEY 94
STAR SHIPPING KASPAR SHIPPING CO 94

A DOCTOR EL DOCTOR 93
ANKER ANKARA 93
BE CH TE CHU 93
BOSNIA AND HERZEGOVINA RIHS-BOSNIA AND HERZEGOVINA 93
CHIN MENG KHING MING 93
DE ESPANA DESPINA 93
DI ROMA RM DI ROMA R 93
ELECTRONICS
CORPORATION ELECTRONIC INDUSTRIAL COMPANY 93
ELECTRONICS ELECTRONIC INDUSTRIES
CORPORATION ORGANIZATION 93
ELECTRONICS GMBH ELECTRONIC INDUSTRIAL COMPANY 93
ELECTRONICS LIMITED ELECTRONIC INDUSTRIAL COMPANY 93
ELECTRONIC INDUSTRIES
ELECTRONICS LIMITED ORGANIZATION 93
FRANK FRENKI 93
HAMBLE HAMBALI 93
ISTVAN ESTEVAN 93
JELITO JULITO 93
KARLIN GARLAND 93
LE MANS LA MINSA 93
LEONARDO DA LEONARDO DIAS 93
21
FCM Services

AG FINANCIAL ZB FINANCIAL HOLDINGS LTD 92
AGATA IGATHA 92
AL SEER AL-SHAER 92
ALIAN ALI AL 92
BANCO PANCHO 92
BARRO BERRIO 92
CHANG CHUN CHANG CHEN 92
CHILE CHI LI 92
CHUNG HSIN HONG HSIN 92
DI ROMA A DI ROMA 92
DIMEN DEIMAN 92
FANTON SAN TUN 92
GUBIN CUBANA 92
HAAS ELECTRONIC SHIRAZ ELECTRONIC INDUSTRIES 92

ALBANIA EL BENJA 91
ALEGRE AL-AGRA 91
ALICAN ALICANTE 91
AND ENGINEERING MAY ENGINEERING COMPANY 91
AND ENGINEERING TMG ENGINEERING LIMITED 91
CHANG CHUN CHEN CHUN 91
CHANG CHUN CHENG CHEN 91
CHANGNING KHING MING 91
COMMODITIES RWR INTERNATIONAL COMMODITIES 91
COMMUNICATIONS IRAN COMMUNICATIONS INDUSTRIES 91
CONSTRUCTION MAX CONSTRUCTION CO LTD 91
CONTR CONDOR 91
CONTROL KONTROLES 91
EMAIL ISMAIL 91
ENGINEERING MAY ENGINEERING COMPANY 91
ENGINEERING TMG ENGINEERING LIMITED 91
ESPADA GONZALEZ E ESTRADA GONZALEZ 91
ET ARMAND TINET ARMAND 91
FINANCIAL ZB FINANCIAL HOLDINGS LTD 91
FOR TELECOMMUNICATION SUDAN TELECOMMUNICATION CO. LTD. 91
FRANCES FRANCISCO 91
FUNDS MANAGEMENT S A NADA MANAGEMENT ORGANISATION SA 91
GERRY CHERRY 91
GMBH COMMUNICATION IRAN COMMUNICATION INDUSTRIES 91
IBRAHIMA IBRAHIM 91
Remarks
The number of reported alerts depends on the threshold. The lower the threshold is, the higher the
number of reported hits is. Hence, it is recommended to use a phased and iterative approach to
determine the right RPM threshold. The function is not linear but more likely an exponential:
22
FCM Services
2.4.4 Enhanced Recognition Module ERM

ERM consists of an additional set of detection and scoring mechanisms and is from a functional
perspective an extension of RPM. Hence, the condition to call ERM functions is that RPM scanning
method is defined. ERM is designed to perform more specific and more focused string comparisons
to deal with “extreme” or exceptional cases that otherwise could only be detected with a lower RPM
threshold.
ERM produces scores like RPM. When ERM is activated, ERM scores supersede RPM score and
are used instead, but the final decision whether to report a hit or not based on the score remains
unchanged, meaning the ERM computed score is compared with the RPM_THRESHOLD.
2.4.5 Detect Banks, Cities and Countries aliases and identifiers

The lexical match uses bank and city-/country lexicons to detect hits on sanctioned banks and countries
even if the respective name variation is not present in the watch lists. FCM provides a standard lexicon as
part of the knowledge base (KB) containing all countries and related cities as well as bank identifiers like
BIC and IBAN. For special needs an enhanced version of bank lexicons is available containing more bank
identifiers for local clearing systems.
2.4.5.1 Bank detection based on bank alias and bank identifiers like BIC, National Ids, IBAN
Banks can be identified by name, alias and bank identifiers such as BIC, National Ids or IBAN. The
interdict lists can contain financial institutions or banks, but will hardly ever contain all kind of
identifiers to detect an interdict bank in a transaction or financial message. The Knowledge Base
(KB) contains lexicons with Bank names and identifiers which will be used by the screening engine to
perform intelligent bank detections, based on names or identifiers.
An interdict bank can be detected by:
• Its name, as written in the interdict list or as one of the existing synonym (in the KB)
• One of its BIC or SWIFT codes
• One of its National Identifier, when preceded by a valid NATID marker
• One of its CHIPS code, when preceded by a CHIPS marker
• The presence of an IBAN which relates to this bank
CHIPS Markers are words, which must precede a CHIPS code for it to be identified. These markers
are industry standard. The following are valid CHIPS markers:
"CHIPS UID NO" "CHIPS U.I.D. NO" "CHIPS ID. NO."
"UID NO" "U.I.D. NO" "CHIPS UID." "CHIPS U.I.D."
"CH" "CHIPS" "UID" "U.I.D."
23
FCM Services
NATID Markers are words, which must precede a NATID code for it to be identified. These markers
are industry standard. The following are valid NATID markers:
"BANKLEITZAHL" "BLZ" "B L Z" "BLZ NO" "HU" "LI" "PL" "BG" "AT" "BL" "PT" "RU" "CHAPS"
"BRANCH SORT CODE" "BANK SORT CODE" "SORT CODE" "SORTCODE" "YOUR SORT
CODE"
"S. CODE" "SCODE" "SORT" "CODE SORT" "NSC" "SORTING" "SORTING CODE" "GG" "GI" "IM"
"JE"
"BSB" "BSB NO" "AU" "HK" "IE" "IL" "NZ" "SC" "ZA" "CC" "REG NO" "DENMARK CODE NO"
"FEDERAL RESERVE ROUTING NUMBER" "FEDERAL RESERVE NO." "FED WIRE ROUTING
NO." "FEDWIRE ROUTING NO." "FEDWIRE" "FED. WIRE." "FED WIRE NO." "FEDWIRE NO."
"ABA ROUTING NO." "ROUTING NO." "ROUTING" "CA"
"FW NO." "ABA" "ABA NO." "ABA CODE" "CHIPS ABA" "ABA NO" "ROUTING ABA NO" "WIRE"
"BANK ROUTING NUMBER" "FW" "FR" "GR" "IN" "IT" "SIC" "SIC NO" "SW" "ES"
"ABI" "BANK" "BANK CODE" "BANKCODE" "BK CODE" "BANK PICASSENT" "BANQUE"
"CODE" "CODE NR" "CODE NO" "CODE NUMBER" "CODIGO" "CB" "C.B." "CBQUE" "C.BANQUE"
"CDE BANQUE" "CODE BANQUE" "BC" "CODE BANK" "COD. BANCA" "BANK NUMBER" "BANK
NO"
"ECO" "ENT" "ENTIDAD" "ENTIDAT" "ENTITAT" "ENTITE" "ENTITY" "ETAB" "CODE ETABL"
"ROUTING" "RTG" "BS" "BANK SORT CODE" "BRANCH CODE" "BRANCH NO" "BR NO" "NSC"
"SC"
"BANQ" "BQUE" "ET" "ETABLISSEMENT" "ETABL" "ETABLIS" "ETABLISS" "CODE BANQ" "CODE
ET"
"CODE ETABLISSEMENT" "CODE ETABLIS" "CODE ETABLISS"
"C. BANQ" "C. BQUE" "C. ET" "C. ETABLISSEMENT" "C. ETABL" "C. ETABLIS" "C. ETABLISS"
"C BANQ" "C BQUE" "C ET" "C ETABLISSEMENT" "C ETABL" "C ETABLIS" "C ETABLISS"
"NO. BANQ" "NO. ET" "NO. ETABLISSEMENT" "NO. ETABL" "NO. ETABLIS" "NO. ETABLISS"
"NO BANQ" "NO ET" "NO ETABLISSEMENT" "NO ETABL" "NO ETABLIS" "NO ETABLISS"
"NUMERO BANQ" "NUMERO ET" "NUMERO ETABLISSEMENT" "NUMERO ETABL" "NUMERO
ETABLIS" "NUMERO ETABLISS"
"NUM. BANQ" "NUM. ET" "NUM. ETABLISSEMENT" "NUM. ETABL" "NUM. ETABLIS" "NUM.
ETABLISS" "NUM BANQ" "NUM ET" "NUM ETABLISSEMENT" "NUM ETABL" "NUM ETABLIS"
"NUM ETABLISS"
"BANK NUM" "INSTITUTE NO" "INSTITUTION NO" "INSTITUTION NUMBER" "BRANCH"
"AG" "AGENCE" "AGENCIA" "AGENCY" "BRANCH" "BRANCH CODE" "BRANCH NO" "BRANCH
NUMBER" "BR NO" "CAB" "CDE" "CODE" "CODIGO" "CDE OFICINA" "CODE OFICINA" "CODICE
AVVIAMENTO BANCARIO"
"CG" "C.GUICHET" "CDE GUICHET" "CODE GUICHET" "FILIALE" "GUICHET"
"OF" "OFF" "OFC" "OFIC" "OFFIC" "OFICE" "OFFICE" "OFICINA" "OFFICINA"
"SUC" "SUCURSAL" "VENT" "GHT" "GUI" "GUICH"
"CODE GHT" "CODE GUI" "CODE GUICH" "CDE GHT" "CDE GUI" "CDE GUICH"
"C. GHT" "C. GUI" "C. GUICH" "C GHT" "C GUI" "C GUICH" "NO. GHT" "NO. GUI" "NO. GUICH"
"NO GHT" "NO GUI" "NO GUICH" "NUMERO GHT" "NUMERO GUI" "NUMERO GUICH"
"NUM. GHT" "NUM. GUI" "NUM. GUICH" "NUM GHT" "NUM GUI" "NUM GUICH"
"TRANSIT" "BANK CODE TRANSIT" "TRANSIT CODE" "TRANSIT NO" "TRANSIT NUMBER"
"BANK TRANSIT NUMBER" "BRANCH TRANSIT"
24
FCM Services
Note on IBAN detection: IBANs are detected based on their format and then validated using their
check digit. Once the validation has been successfully performed, the “bank identifier” part of the
IBAN is extracted (according to Swift IBAN structure) and the knowledge base is used to identify the
corresponding bank.
Example Bank Synonym DETECTION:
Interdict Entry: “DEXIA BANK”
Field content: “BELFIUS BANK” will trigger an alert based on synonym bank name.
Example BIC DETECTION:

Interdict Entry: “TIRANA BANK”
Field content: “TIRBALTRXXX” will trigger an alert based on BIC code.
Example NATID DETECTION:

Interdict Entry: “COMMERZBANK AG”
Field content: “BL 70220900” will trigger an alert based on NATID code.
Example CHIPS DETECTION:

Interdict Entry: “LLOYDS TSB BANK PLC”
Field content: “CH 13886” will trigger an alert based on CHIPS code.
Example IBAN DETECTION:

Interdict Entry: “BANCA INTESA SAN PAOLO”
Field content: “IT98K0306914800100000006347” will trigger an alert based on IBAN.
2.4.5.2 Country detection based on country alias and on cities

There are 3 ways of detecting an interdict country: by its name, by derivation from a city name or via
ISO Country Code in a BIC
The detection by name will be able to detect an interdict country by its name as mentioned in the
interdict list or by any available synonym from the KB.
Example:
If the country “DEMOCRATIC PEOPLE'S REPUBLIC OF KOREA” is an interdict in one of the list, then the
screening engine will be able to trigger an alert against text “COREE DU NORD”, thanks to the use of
the synonyms information present in the KB.
The “city to country” derivation uses the so called “city-country” database, included in the KB. The
KB contains a large number of city country associations, such as “RANGOON/BURMA”,
“BRUSSELS/BELGIUM” and so on. If a given country is an interdict entry, then the screening engine
will trigger an alert based on a city name present in the text, assuming this particular city is present in
the field.
Example:
If the country “BELGIUM” is an interdict entry, then the screening engine will trigger an alert on text
“BRUSSELS”, “BRUXELLES”, etc.
25
FCM Services
2.4.5.3 Country detection based on BIC, via the ISO Country Code in BIC
A BIC or Swift Code has the following structure: AAAACCBBDDD, where “CC” is an ISO Country
Code. When a valid BIC is present in one field, the Iso Country Code part is extracted, derived into a
country name and then can be used to detect an interdict country.
Example:
Interdict Entry: “IRAN”
Field content: “MELIIRTHXXX”
“MELIIRTHXXX” is a valid BIC, hence the ISO Country code is extracted (“IR”), derived into
a country name (IRAN). Then, an alert would be generated against this Country via the BIC.
2.4.6 Bank/City/Country Data Update Service

The screening engine offers advanced detection methods using a “Knowledge Base”, or simply KB
supporting exact, approximate and lexical match. The KB is a file, generated by Temenos and
provided to the customers on a regular basis, via the standard Temenos service named “Data
Update Service”. The Knowledge Base contains a selection of bank names and synonyms, city
names and synonyms, country names and synonyms. It also contains large lists of CITY to
COUNTRY associations.
On top of that, the KB also includes Financial Identifiers from the SWIFT Directory, including BIC
Codes (SWIFT codes), Bank National Identifiers and CHIPS codes.
Example of Bank Names with synonyms:

STANGVIK SPAREBANK
SURNADAL AND STANGVIK SPAREBANK
SURNADAL SPAREBANK
BANK KARGOSHAEE
BANK MELLI IRAN INVESTMENT COMPANY (BMIIC)
FIRST USA BANK

JP MORGAN
MORGAN JP
Example of City Names with synonyms:

ABOU DHABI
ABU DHABI
ABU ZABI
DHABI / ABU
BRUESSELS
BRUSELAS
BRUSSEL
BRUSSELS
BRUXELLES
Example of Country Names with synonyms:

COREA DEL NORD
CHOSON MINJUJUUI IN'MIN KONGHWAGUK
COREA, REPUBBLICA POPOLARE DEMOCRATICA
COREE (REPUBLIQUE POPULAIRE DEMOCRATIQUE
26
FCM Services
DE)
COREE DU NORD
DAVVI-KOREA
DEMIRGAZYK KOREYA
DEMOCRATIC PEOPLE'S REPUBLIC OF KOREA
DEMOKRATISCHE VOLKSREPUBLIK KOREA
SJEVERNA KOREJA
ZIEMELKOREJA
SCHWEDEN
SUECIA
SUEDE
SUEDSKO
SVERIGE
SWEDEN
SWEEDEN
ZWEDEN
Example of SWIFT Bank Identifiers:

BIC CHIPS NAT-ID BANK NAME CITY COUNTRY
BACAADADXXX 036733 ANDORRA BANC AGRICOL REIG S.A. LES ESCALDES ANDORRA
BINAADADXXX 070755 00070014 MORA BANC GRUP SA ANDORRA LA VELLA ANDORRA
CRDAADADXXX 016179 00030001 CREDIT ANDORRA ANDORRA LA VELLA ANDORRA
AAISALTRXXX 20311003 UNITED BANK OF ALBANIA SH.A TIRANA ALBANIA
NCBAALTXXXX 346433 20511007 BANKA KOMBETARE TREGTARE SH.A. TIRANA ALBANIA
Example of CITY-COUNTRY associations in the City-Country Database:

ISO-CC COUNTRY NAME CITY
GB UNITED KINGDOM BELFAST
BE BELGIUM BRUSSELS
RO ROMANIA BUCHAREST
FR FRANCE RENNES
Note: there is no guarantee that ALL possible city/country pairs will be present in the KB database.
This database contains city-country associations for the main cities and countries in the world but
does not pretend to be exhaustive. However, Temenos customers using the KB database provide
input with new, renamed or additional city/country pairs that helps to constantly enhance the content
of the database for the benefit of all users.
2.4.7 Match Chinese Commercial Codes (CCC) to Pinyin name

Chinese Commercial Codes or Chinese Telegraphic Codes are widely used to encode Chinese
characters in such a way that they are usable in electronic messages supporting only Latin character
set, e.g. SWIFT Each CCC is composed of a 4 digits decimal code.
Example: The CCC 0006 represents the character 上 = shang, i.e. the pinyin translation from
Chinese characters into Latin characters
The mapping table, containing the CCC to Chinese characters mapping is provided with the
screening engine. Note that the provided table only corresponds to one of the possible flavours of
CCC: the CCC are not necessarily the same in all the Chinese regions. However, customers are free
to update this table (plain text file) so that it fits their needs.
27
FCM Services
Conversion table extract and example:

<conversion language="chinese">
<entries type="single-character">
<entry numeric-code="0001" unicode="U+4E00" text="yi"/>
<entry numeric-code="0002" unicode="U+4E01" text="ding"/>
<entry numeric-code="0003" unicode="U+4E03" text="qi"/>
<entry numeric-code="0004" unicode="U+4E08" text="zhang"/>
The engine will first scan the field content without translation and then will translate the CCC
according to the list for each group of 4 numerical digits as soon as there are at least 2 contiguous
groups. The engine will then scan a second time the translated field content, where CCC codes have
been replaced by their pinyin translation, according to the provided mapping table. Note that after
CCC replacements, all the defined screening methods are applied on the transformed text.
Example of field content with CCC:

“PAYMENT FOR 0015 0004 TO BE DONE FOR 0004 0015”
CCC codes will be replaced by their pinyin translation, leading to:
“PAYMENT FOR CHENG ZHANG TO BE DONE FOR ZHANG CHENG”
Additional screening: CCC scan conjugated with UTF-8 support

A third scan is executed. This third scan is performed on a content where the CCC codes are
translated in their corresponding UTF-8 character (i.e. native Chinese Character).
Example:
The field contains the following text
“PAYMENT FOR 0015 0004 TO BE DONE FOR 0004 0015”
Is converted in:
“PAYMENT FOR 丞丈 TO BE DONE FOR 丈丞”
2.4.8 FATF R16 Scanning

th
The 4 EU Anti-Money Laundering Directive 4AMLD based on the FATF R16 Wire Transfers require
financial institutions to detect and report incomplete payer and payee information in payment transactions
and messages throughout the whole payment chain.
The FATF scanning raises alerts in cases where the account number line and/or payer and/or payee
names and/or addresses are missing, incomplete or containing dubious information. This feature contains
a couple of sub-rules allowing banks to customize the scanning method to their specific requirements.
2.5 Reducing the number of false alerts

2.5.1 CRS (reducing number of false alerts based on the text morphology)
CRS (Contextual/Customer Restricted Screening) is an optional parameter which is defined on a
field by field basis to potentially reduce the number of spurious alerts based on the text morphology.
28
FCM Services
It is not a scanning method but it automatically discards certain alerts if they are based just on a little
part of the entire field. As such CRS is used to prevent spurious hits on short search patterns.
The principle is to allow an alert to be reported if and only if the text triggering the alert is big enough
in size when compared to the entire field content. In other words, CRS is designed to ensure that the
detected text is a significant part of the whole text content.
CRS is only applicable in well-known fields, where one can guarantee that the field will only contain
one unique type of information, e.g. names only. Typically, CRS will be used in fields containing
ONLY an individual or company designation and nothing else, for example no additional information
such as an address or any additional free text. Under these conditions, CRS is useful and can safely
be used.
Note that CRS is a special filter which applies to all screening methods defined for a field.
Example:
“BIN” is an alias for an interdict company.
Without CRS, the text “MOHAMMED BIN RABAH” would trigger a hit against “BIN”. With CRS
activated, “BIN” will not trigger a hit, because the selected text “BIN” is too little in size compared to
the entire text provided.
From a technical perspective, the CRS mechanism is implemented as a “CRS score” comparison.
The CRS score is a number between 0 and 100. The score depends on the alert size compared to
the field size and also depends on the morphology of the alert compared to the morphology of the
field content, morphology being approximated by the count of words. The score is compared to a
threshold and the alert is reported if the computed score is bigger than a predefined (not modifiable)
internal threshold.
The choice for CRS value depends on the bank’s risk appetite. It also depends on the data, on how
“clean” and regular the data are.
The CRS default value for CRS_THRESHOLD is 75 (75%). Values between 65 and 75 are suitable.
Note: the lower the RPM_THRESHOLD and the CRS_THRESHOLD the more false hits are
generated.
Examples:
CRS
Interdict entry Text in field Score
ABDELLAH
X ABDELLAH 89
X ABDELLAH X 82
BIN ABDELLAH 73
MOHAMMED ABDELLAH BIN TAYEB 53
JACQUES
BROUGERE
JACQUES BROUGERE DUPONT 79
ABDELRAHMMAN
MOKTAR ABDELRAHMMAN 72
29
FCM Services
2.5.2 CSF (reducing number of alerts using entity types)

CSF (the acronym for Contextual and Semantic Filtering) is a filter that uses entity types, defined on
a field by field basis, to determine which kind of alerts are plausible in a given context.
All interdict entries have an entity type: INDIVIDUAL, COMPANY, BANK, COUNTRY, POLITICAL
ORGANIZATION, VESSEL, etc.
In a lot of cases, the nature (hence the semantic) of a given field is well-known; from this information,
one can easily derive which kind of entity types are plausible (likely to occur) and more importantly,
which ones are not.
Use Cases – Scenarios:

In a payment message, the text/content in the field for “ordering customer” is likely to be an individual
or a company, but it is extremely unlikely to be a vessel. This means that any alert for an interdict
with entity type = VESSEL in this particular field is a false alert. Especially in the light of the fact that
many vessels have commonly used western first names, which will simply cause undesired noise
and lead to spurious, extra work for reviewers.
In the same manner, a field dedicated to the “Ordering Financial Institution” is by definition supposed
to contain the name of a bank, with possibly also its location (city, country). This field will then
certainly never contain the name of an individual neither the name of a vessel. Hence, if an alert is
detected having type “INDIVIDUAL” or “VESSEL”, it can safely be ignored and not reported at all.
Note: The bank’s risk appetite determines in which fields CSF will be used and for which entity types.
2.5.3 Reduction of Alerts on transactions: creating SKIPs that prevent recurrent

alerts to be raised on the same text against the same black listed entity
Some blacklisted interdict entries present text patterns that, for any reason, occur very frequently in
transaction texts. As a consequence, the number of false alerts for these patterns can rise to a level
which is detrimental to the efficiency of the compliance department. To prevent the generation of
these false alerts, the customer can define SKIPs, special text patterns linked to a blacklisted entity.
Whenever an entity is the source of an alert, if one of its SKIPs is found, the alert is recorded but not
presented by the system for human evaluation. This mechanism has proven its efficiency as it
allows maintaining the number of false alerts at a manageable level not impacting the detection rate
of the scanning engine.
Each SKIP is linked to a single mandator and a single interdict entry. This means that if a message
for a mandator XXX triggers an alert for an entry, the SKIPs defined on that entry for another
mandator YYY will not be used to silence the alert.
There are two possibilities to create Skips:
1. Skips proposed in Alert Manager during hit review
2. Skips proposed directly in Watch List Manager
SKIPs can be proposed through the Alert Manager interface , when a user reviews and evaluates a
message and directly sees which text or part of text could be used as an appropriate SKIP. SKIPs
proposed through this interface are flagged with a special "Proposed" status and will not impact the
scanning engine until they are reviewed and approved by another authorized user.
Skips can be entered directly in the Watch List Manager in the same way as other data (i.e.
addresses, aliases). Depending on the defined workflow such directly added skips are immediately
active or need another user for approval.
Note: Skips are only used to ignore a hit if they exactly match with the string in the screened text
(see examples below).
Skip value Interdict entry Screened text Ignored y/n
30
FCM Services
Robert Mugabe Flower Street Robert Mugabe Robert Mugabe Hyde Park N
Robert Mugabe Flower Street Robert Mugabe Robert Mugabe Flower Street Y
2.5.4 CIF (Customer Information File) Screening

Alerts generated by the CIF Loader or the CIF Scan modules are never repeated.
Alerts that result from a detection of the possible match between a customer record and an interdict
entry on a watch list are first stored for review and evaluation. This specific alert will not be raised
again by a new screening run.
Once a CIF alert is evaluated, its status for the customer record is changed to ALLOW or CANCEL
and the alert record(s) is/are moved to the statistics database together with their evaluation history.
The specific evaluated alert will not be raised again by further screening runs.
2.6 Screen User Interfaces

Details how to work with the Alert Manager can be found the respective user guide.
2.6.1 Alert Manager
2.6.1.1 Alert on transactions screening

The user interface is split into the following main components:
• Transactions list
• Alert Evaluation
• User Preferences
• Filter management
• Flush management
2.6.1.1.1 Transactions List

This page is split into 3 sections
• Message Overview: in this area, the user can see the current number of messages at
each stage of the workflow that has been defined for the evaluation of screening alerts.
This allows high level users to get a quick impression of "how well" the evaluation
process is going, to quickly spot possible bottlenecks.
• View Preferences: in this area, the user can modify
which data of the messages is displayed in the message list (amount, currency,
mandator, …)
the sort order (by default older messages are displayed first but any message
property can be used for sorting)
the messages to be listed (the user can use a simple filter or define a complex
advanced filter based on any combination of message properties)
• Messages List: in this area, the user will see a list of messages, complying with his
current filter definition. The display depends on the selection made in the View
Preferences. From this list, a user can view the details of the alerts on a message or open
it for evaluation (one user can only have one message open at a time). If a message was
31
FCM Services
opened by another user, the user can force open it, reassigning it to himself, provided the
rules engine allows that operation.
The actions available to the user depend on the set-up of the rules engine, his role, and the
state of the messages. It is possible to limit the actions of a user using any property of a
message (e.g. the customer could limit the high value transactions to a sub-set of users).
2.6.1.1.2 Alert Evaluation

This is divided into the following areas
• Message header: this area displays the properties/metadata of the message being
reviewed. Those comprise:
o Message id
o Transaction number
o Current state
o Message type and sub-type
o Message format
o Mandator
o Priority
o Gateway
o Currency
o Amount
o Direction
o Sender and country
o Receiver and country
• Payload: this area displays the actual content of the message, formatted for readability.
Various formats are supported (SIC, FED, CHIPS, SWIFT, EGAV, EZAG, LSVP, BFA,
BOJNET, SIT, XML, ZENGIN, PACS). Support for other formats is easy to add. The parts
of the message which triggered the alerts are highlighted to allow the user to directly
focus on them.
• Alert navigation: this area displays all the hits detected by the Scanning engine in the
message and allows the user to switch the focus between them.
• Alert evaluation: this area displays the properties of the currently selected alert and
allows the user to make an evaluation of the alert, choose a pre-defined reason code and
add a manual comment. This area also contains the following sub-sections:
Skip proposal: if the user deems it appropriate, he may make a skip proposal which
will be reviewed later in the Watch List Management module by an authorized user.
Evaluation history: provided the user has the proper access rights, he is able to
see the evaluation of the alert made by the previous users (in a multi-level workflow)
Blacklisted entries: this section displays all the details of the blacklisted entries
linked to the alert (entry name, aliases, permutations, addresses, identifiers, …) that
will allow the user to make an informed decision concerning the alert.
• Message evaluation: this area allows the user to make a global evaluation for the
message (as a message could have triggered multiple alerts), choose a pre-defined
reason code and add a manual comment.
• Message Evaluation history: provided the user has the proper access rights, he is able
to see the evaluation of the message made by the previous users (in a multi-level
workflow)
• Evaluation Documents: provided the user has the proper access rights, he is able to
upload/attach external documents to his evaluation. These documents can be viewed by
later reviewers, provided they have the appropriate access rights.
32
FCM Services
When the user has finished his evaluations, he can commit his work. The message will then be
released or will be kept for further evaluation according to the specified workflow. If the user has
insufficient information to complete work on the current message, he can reserve the message
("hold for investigation") in order to save his work, thus preventing other users from evaluating
that message.
2.6.1.1.3 User Preferences

In this section, the user can:
• Change the number of messages per page
• Change the number of alerts per page (when viewing a message)
• Toggle On/Off the auto-refresh of the message list
• Hide/Show some optional panels
2.6.1.1.4 Filter Management

In this section, the user can define and save for later use complex messages selection
filters,that are combining multiple conditions, to address required business needs. The saved
filters can be invoked by a simple selection in a dropdown in the View Preferences panel of the
Messages List page.
2.6.1.1.5 Flush Management

Flush is a process by which messages are released with a special evaluation, directly bypassing
the standard workflow. This is an action which is only authorised to high-level users, and should
only be used in very specific operations or emergency cases.
Two types of flush are available in the system:
• Standard Flush
• Flush for Rescan
Standard Flush will evaluate messages to the FLUSH status. They will be saved in statistical
tables and FLUSH notifications will be sent back to the Message Broker.
Flush for Rescan acts as Standard Flush, but it will send RESCAN notifications to the Message
Broker. Messages will be evaluated with RESCAN status and saved in statistical tables as usual.
The Message Broker will then resend the same message again with a new id.
Flush Suspect Messages page lists all message types for which the user is privileged to flush
messages.
The main page is the same for all messages and hit types. It consists of the following areas:
• Messages: this section looks and behaves exactly as the list of messages on the
Message Evaluation page, but the only action allowed is View.
• Flush Categories: this section allows the user to select the type of flush, extra filtering
options and to explain the reason behind the flush.
Flush is an asynchronous process which will start when the user confirms his request. This
process will release all messages complying with the filter defined by the user until there are no
such messages anymore.
Depending on the configuration of the system, a Flush operation can be triggered by one user
with special privileges, or may require an additional approval (4-eyes principle) before being run.
If this configuration is enabled, an extra section is available: Pending Requests where a user
33
FCM Services
with the appropriate access rights can review, accept or reject Flush requests issued by other
users.
2.6.1.1.6 Reason Codes

Reason Codes allow for a standardized alert evaluation and reporting. Such reason codes can be defined
on alert level or on transaction / message level. There are out-of-the-box reason codes available but
these can be adapted and/or enhanced to meet the bank’s specific requirements.
2.6.1.1.7 Expand, collapse or move Sections

The 2 main pages in Alert Manager, i.e. Alert Overview and Alert Evaluation, allow the users for each
section to expand or collapse. In addition a bank may want to benefit from the option to move up/down
some of the sections in order to allow the users to configure the user interface to their individual comfort.
2.6.1.1.8 Frequent Action Buttons

This feature allows fast evaluation of alert transactions or messages with many false alerts within the
transaction or message. By adding frequent action buttons in the Alert Evaluation page a user can set all
alerts of a transaction or message to false and apply the respective reason code by one click on the
frequent action button. This is of specific interest for large banks with hundreds of alert transactions or
messages each day to increase operational efficiency.
It goes without saying that such frequent actions buttons require well trained and experienced staff.
2.6.1.2 Alert on customer on boarding

The Web Inquiry Tool is a component which can be used at customer on-boarding to check the
identity of a customer against the watch lists.
The user can enter the following properties of the customer:
• Customer name
• Date of birth
• Identity document
• Free text
Once this is done, a request is sent to the scanning engine which will return a simple result: NO
HIT or HIT.
When the result is HIT, a detailed page can be opened, containing all the details of the blacklisted
entries (entry name, aliases, permutations, addresses, identifiers, …) related to the hit, which the
user can then use to assess whether the customer is blacklisted or not.
The tool is for consultation purposes only; nothing is persisted in the database.
2.6.1.3 Alert on customer base (CIF Screening)

The FCM Screen system also generates alerts on the customer base, i.e. in CIF (Customer
Information File). This happens through the execution of batch scripts against the customer base
on a regular basis.
The system remembers past evaluations to avoid generating the same alerts over and over again
for the same sanctioned entity.
34
FCM Services
From the user perspective, handling alerts on customers follows the same principles as for
handling alerts on transactions. The user interface is similar and the possible actions are the
same.
The main differences are:
• No Message Overview panel in the main page
• No SKIP Proposal panel in the evaluation page – as this is not necessary here
• No Flush – as the reference data is the Customer database itself
When reviewing alerts on a customer record, the user will see:

• Customer Id
• Name
• Given Name
• Address
• City
• State
• Zip Code
• Country
• Fiscal Country
• Nationality Country
• National Id
• Birth date
• Birth City
• Birth Country
• Passport Number
• Social Security Number
• Social Security Country
• Bank Id
2.6.2 Screen Watch List Manager

. The Watch List Manager provides insight into the contents of public lists, banks’ own global and
private lists. A user can upload, add, change, activate, inactivate or delete watch list interdict entries,
including associated aliases and permutations, depending on the individual user access rights.
The Watch List Manager user interface is split in the following pages, displayed as tags at the top of the
main page:
• Lists (views available on public or provider supplied lists and private local lists)
• Advanced Search (search for specific interdict entries, aliases, permutations)
• Skips Proposal Review (review and accept or reject skips proposals)
• Import Management (accept or reject records of imported public or provider supplied lists
• Batch Management (view status on import, acceptance and export of batch processes)
Note: More information on possible and allowed user actions in Watch List Manager can be found in the
appendix.
2.6.3 Reporting for FCM Screen

The Screen Reports display all checks performed against a given message, a complete history of the
review process and all transactions that provide details about true/false hits.
35
FCM Services
The Reports application runs on a set of the statistics collected during the FCM Screen operation. The
statistical data include customer or transactions data as well as the different user actions that have been
exercised with the Alert Manager, Watch List Manager, Watch Batch processes, Rules Manager and
Security modules.
The Reports application consist in the following:
- Message Investigation Report

In-depth investigation of a specific message that has been processed by the FCM solution from
the complete set of related data.
- CIF Investigation Report

In-depth investigation of a specific customer information messages that have been processed by
the FCM solution.
- Audit Analysis Report

Provides detailed reports on all the actions carried out by the users or by the applications within
different components of the FCM solution.
- Statistical Analysis Report

Statistical information on the messages that have been processed by the FCM solution by
statuses.
- CIF Statistical Report

The user can input criteria in order to produce a report to analyse the CIF records statistics.
- Hit Statistics Report

Displays the top "internal match/interdict entries" and the number of occurrences of "internal
match/interdict entry" association and the number of messages including these items.
The reports can be exported in PDF or CSV format. Where applicable, reports are exportable in CSV
format, for use in other analysis tools, such as Microsoft Excel.
2.6.3.1 Message Investigation Report

This report can be run to analyse in details all the data pertinent to a given message, i.e. a transaction or
a customer record out of the on boarding process.
For messages having been screened for the “Compliance Filter” (COFI) risk type, the Message
Investigation Report can be run an authorised user for the purpose of operational control or auditing
The user can use a set of criteria for collecting messages: start date, end date, name of the user who
performed the last evaluation action, currency, transaction number, sender, receiver, direction, mandator,
gateways, Message Broker Reference, additional sender countries and additional receiver countries. The
user can also specify the amount to filter on.
Note: Start date and End date are obtained from the PAYSCAN_UTC containing the timestamp of the
Screening Engine passage.
The Message Status field can have the following values:
No Hits
Skipped (all hits detected were skipped by SKIPs)
No Hits NOR Skipped
Bypassed (the message has been ‘flushed’)
36
FCM Services
Allowed (all hits were evaluated to false hits)

Cancelled (at least one hit has been evaluated to true)
Allowed OR Cancelled
The statistical reports can be generated as a summary or full report, both reports in PDF or CSV format.
Below are a couple of use cases for the Message Investigation Report:
• Investigate a specific message evaluated as ALLOW (all hits were evaluated as false)
• Investigate a specific message evaluated as CANCEL (at least one hit was evaluated to true)
• Investigate a specific message that was flushed / flushed for rescan
• Investigate a specific customer record from the customer database
2.6.3.2 Statistical Analysis Report on transactions screening

By selecting a time interval and report format, CSV or PDF, the Message Statistical Report provides hit
transactions grouped by mandator (if applicable) and Dataset. For each dataset line the report displays
the total quantity and % of transactions with status HIT, OK (without hit), SKIP and final hit decision
(allowed, cancelled, bypassed, rescanned, discarded).
2.6.3.3 Statistical Analysis Report on customer screening

By selecting a time interval and report format the CIF Statistical report displays the customer information
grouped by Data Sources and Data Set. For each Data Set line the report displays: Total number of
customers, numbers of customers evaluated as Allow, numbers of customers evaluated as Cancel.
2.6.3.4 Report the most frequent alerts

By selecting a time interval and report format (CSV or PDF) the report displays the most frequent alerts,
grouped by interdict entry. Additional fields can be used for the selection filter: currency, direction,
message type, mandator, gateway. All these information allow the bank to assess whether hit reduction
measures are needed.
2.6.3.5 Audit Report

The report provides details on all the actions carried out by the applications or by the users using the
different components of the FCM solution. A detailed breakdown of action performed can be analysed.
Below are a couple of uses cases for the Audit Report:

• Report on all the actions performed by the operators of the Watch List Manager
• Report on all the actions performed by the operators of the Alert Manager
• Report on all the actions performed by the operators of the Security application
• Report on all the actions performed by the operators of the Reports application itself
• Report on the actions performed by the operators of the Rule Manager
37
FCM Services
2.7 Case management: 2 eyes or 4 eyes principle

Case management in Alert Manager and Watch List Manager can be configured to as many
levels of review as required. The standard principle is 2 eyes for obviously false alerts and 4 eyes
for review by an expert user or escalation to a compliance user. Obviously the 4 eyes principle
involves 2 different users and respective actions cannot be performed by the same person Case
management is defined and maintained in the FCM Rule Manager (see chapter 5).
2.7.1 Alert Manager

• when Evaluating suspicious messages under Compliance Filtering (COFI)
• when Evaluating suspicious customers (CIF)
In both cases above, this refers to the way an alert evaluation is confirmed:
• 2 eyes evaluation: one user is completely evaluating the alert (close or follow-up). The
alert is evaluated by a single user .
• 4 eyes evaluation: 2 users evaluate the alert. In this case, the second evaluation is
st
required after the first one and the respective user can have another role than the 1
evaluating user, e.g. an Expert or Compliance role.
Note: The specific evaluation process is defined with the Rules Manager application with a
specific workflow.
2.7.2 Flush operations

• Depending on the configuration of the system, a Flush operation can be triggered by one
user with special privileges, or may require an additional approval (4-eyes principle)
before being run.
• If this configuration is enabled, an extra section is available: Pending Requests where an
user with the appropriate access rights can review, accept or reject Flush requests issued
by other users.
2.7.3 Watch List Manager:

Watch List Manager has an implemented but optional mechanism, 4-eyes Validation, which
prevents a single user from changing the database. Each requested change needs to be
approved by a different user before it is considered active.
2.7.4 Using the 2 or 4 eyes principle examples

This section outlines examples of how the principle is applied in several components.
2.7.4.1 Manage message alerts in Alert Manager with the 4 eyes principle
This situation occurs when the workflow is designed in such a manner that there are several
consecutive states, so that a first evaluation triggers a transition to a different state (that depends
on the first user decision: ALLOW or CANCEL). The second user has the final decision.
38
FCM Services
2.7.4.2 Manage customer information alerts in Alert Manager with 4 eyes principle
In CIF screening, if the workflow is designed with several consecutive states, so that a second
evaluation is necessary, the final result will be given by a second user.
2.7.4.3 Flush one message in Alert Manager with 4 eyes principle

The asynchronous flush process needs confirmation from a second user. The request by the first
user will be waiting for the second user’s decision: accept or reject the request.
2.7.4.4 Manage transaction alerts in Profiling with 2 eyes principle

This approach is the simplest: the alert evaluation by one user doesn’t need any further
confirmation.
2.7.4.5 Manage profile alerts in Profiling with 4 eyes principle

By contrast with the above solution, the first level alerts need to be confirmed by a second user;
he/she can accept or reject the examined alert.
2.7.4.6 Manage modifications/additions in Watch List Manager with 2 eyes principle

This approach doesn’t need the approval by a second user of any
addition/suppression/modification of an entry and/or of a subcomponent of an entry.
2.7.4.7 Manage modifications/additions in Watch List Manager with 4 eyes eyes principle
By contrast with the above solution, any addition/suppression/modification becomes a proposal
which needs the confirmation of a second user; he/she can accept or reject the proposal.
2.8 Screen technical interface

2.8.1 Mapping Interface for any XML message into FCM XML
rd
This feature allows to map any online received message in XML format from any 3 party system into a
single XML format known by the Screening Engine.
All the XML files coming from a 3rd party system, online or through a file, are converted into an FCM XML
conform to the FCM XSD. The message decoder from the Screening Engine will decode only FCM XML
messages.
2.8.2 Additional info in immediate respons

This feature allow to configure the addition of information in the screening response. The default
immediate response is OK or NOT OK. This response can be enhances with date like hit type or number
of hits
39
FCM Services
3. FCM Profile: Behaviour analysis

3.1 Detect suspicious activity by grouping transactions and using
compare rules
3.1.1 General concept
One of the key features of the FCM Profiling solution is to inform the bank when the activity of a customer,
a group of customers or on account is being suspicious. In order to perform this, FCM Profile can
maintain the summary of the operations done and use it when checking profiling rules.
Examples:
• Raise an alert if the sum of the amounts of the cash transaction done by a customer during the
last five days is higher than 10.000€
By monitoring the cash activity of the customers on a daily basis
• Raise an alert if a customer did more credit operations yesterday than during 20 days before
By monitoring the credit activity of the customers on a daily basis
3.1.2 Transactions are grouped in aggregates (AKA profiles)

The profiles aggregate a defined set of operations. Based on their operation code, operations are
aggregated for accounts, customers or groups of customers.
Four types of profiles can be calculated: CUSTOMER, ACCOUNT, GROUP and Peer Group. A profile
can be generic (valid for all the entities of the same type) or non-generic (valid only for a certain entity).
The profiles are calculated every time a payments file is processed. In a second step, the rules can be set
on these profiles to look for suspicious transactions.
40
FCM Services
For example, the bank may want to be informed if the sum of all amounts received by a customer on the
last 5 days is bigger than 5000 USD. In order to do this, a profile summing all the incoming daily
transactions for the customers can be created.
3.1.2.1 A profile is a set of 4 values

A profile contains a set of 4 values
• The count of operations
• The total operation amount
• The average operation amount
• The maximum operation amount
These values are calculated per:
• type of operation (one operation code or a group of operation codes)
• type of entity (account, customer or group of customers)
The value calculated is available to be used by profiling rules and highlight suspicious behaviours.
3.1.2.1.1 The count of operations

Each transaction processed on the defined entity (account, customer or group of customer) will be
counted and stored in the profile.
This allows FCM Profile to remember for example that 3 operations have been done by a customer during
the last day.
3.1.2.1.2 The total operation amount

The sum of all transactions processed on the defined entity (account, customer or group of customer) will
be calculated and stored in the profile.
This allows FCM Profile to remember for example that a total of 5000 USD has been deposited on an
account during the last month.
3.1.2.1.3 The average operation amount

The average transaction amount on the defined entity (account, customer or group of customer) will be
calculated and stored in the profile.
41
FCM Services
This allows FCM Profile to remember for example that during the last 6 month, a customer made in
average of 300 USD per ATM withdrawal.
3.1.2.1.4 The maximum operation amount

The maximum transaction amount on the defined entity (account, customer or group of customer) will be
calculated and stored in the profile.
This allows FCM Profile to remember for example that the maximum amount debited from an account
during the last 7 days was 2500 USD.
3.1.2.2 An aggregate is calculated for a set of operations code(s)

Each operation (cash in, cash out, wired in, wired out, ATM withdrawal, currency deposit, etc.) has a
specific code assigned, depending on the bank’s configuration.
Those operation codes are used to create profiles for a chosen type of activity such as:
• All cash debit operations (cash deposit, ATM withdrawals, currency deposits...)
• All credit operations (cash in, wired in...)
• All ATM withdrawals
• ...
3.1.2.3 A profile can be calculated for

A profile can calculate the activity of different types of entities.
3.1.2.3.1 An account
A profile on an account will calculate the 4 values described above for the transactions done on an
account. It can be calculated
• for each account meaning that each account known by FCM Profile will have its own profile
summarizing its activity;
• for a defined single account meaning that the profile will be calculated only for the chosen
account.
3.1.2.3.2 A customer
A profile on a customer will calculate the 4 values described above for the transactions done by a
customer. It can be calculated
• for each customer meaning that each customer known by FCM Profile will have its own profile
summarizing its activity;
• for a defined single customer meaning that the profile will be calculated only for the chosen
customer.
3.1.2.3.3 A group of customers

FCM Profile allows the manual creation of groups of customers. A group is an entity with a defined name
that contains a set of customers.
For example, the group “John Smith’s family” containing John Smith’s, his wife and his son can be
created. Another example is the Peer Group
42
FCM Services
A profile on a group of customers will calculate the 4 values described above for the transactions done by
all the members of the group. It can be calculated
• for each group of customers meaning that each group of customers defined in FCM Profile will
have its own profile summarizing its activity;
• for a defined single group of customers meaning that the profile will be calculated only for the
chosen group of customers.
3.1.2.4 A profile can be calculated on a daily or a monthly basis

A profile can cover the activity for a single day or a single month. Those will be respectively used to check
the daily or monthly activity.
A rule checking the short term activity will use daily profiles:
Alert if a customer makes more than 2000 USD of cash withdrawals during the last 5 days
A rule checking the long term activity will use monthly profiles:
Alert if a customer received more money during the last month than he did during the 6
months before
3.1.3 What is a comparison rule?

A comparison rule compares a transaction amount or a value calculated from profile(s) against a
reference value or a value calculated from a profile(s).
A rule is a condition made of
• The left part of the condition – comparing what
• The right part of the condition – comparing against what
• A comparator
3.1.3.1 Comparing what

Two types of rules can be defined:
• Rules on transaction. Those rules are checked on a transaction basis and are comparing the
transaction amount against a reference value or a value calculated from one or more profiles.
• Rules on profile. Those rules are checked on a daily basis to compare a value calculated from
profile(s) against a reference value or a value calculated from or more profiles.
3.1.3.1.1 Transaction amount

The rules on transactions compare a transaction amount against a reference value or a value calculated
from one or more profiles.
Examples:
• If an ATM withdrawal is higher than 5000 USD
• If a wired out transaction is at least twice higher than the maximum wired out amount done by the
customer during the last 6 month
• If a wired in transaction is higher than the total deposit on the account for the last 2 months
3.1.3.1.2 Value coming from a profile
43
FCM Services
The rules on profiles compare a value calculated on one or more profiles against a reference value or a
value calculated from one or more profiles.
There are three types of profiles: ACCOUNT, CUSTOMER and GROUP. A profile rule will match one of
the types of the profile definition.
The source value is an aggregated value which can calculate: AVERAGE, COUNT, MAX, SUM.
3.1.3.1.2.1 Average
i) Case = Average
The application calculates the average (sum of all transactions divided by the number of transactions).
The interval is calculated as:
Source = Σ (SUMk / COUNTk) / PERIOD, k= 1 to PERIOD
ii) Case = Sum
The application calculates the sum of all transactions, and divides it by the number of all transactions. The
interval is calculated as:
Source = (ΣSUMk) / (ΣCOUNTk ) , k= 1 to PERIOD
Example:
You want to be alerted if a specific customer receives an average amount per day bigger than 500
USD on the last 3 days.
You will have to create a daily behaviour for that specific customer that will calculate the average of
all the incoming transactions for each day for all the customer’s accounts.
From here, you can create a rule that will calculate the average of the average of each day or you can
create a rule to calculate the sum of the average of each day.
Let’s suppose we have the following transactions:
• Day 1 – incoming amount 100
The behaviour will calculate:

• Profile amount is (100 + 300)/2 = 200 EUR for day 1
• Profile amount is (200 + 150 + 250) / 3 = 200 EUR for day 2
• Profile amount is (400 + 600)/ 2 = 500 EUR for day 3
44
FCM Services
If the rule calculates the average of the averages for each day, then it will calculate
(200 + 200 + 500) / 3 = 300. No alert will be raised
If the rule calculates the sum of the averages for each day, then it will calculate
200 + 200 + 500 = 900. The result is bigger than 500, so an alert will be generated.
3.1.3.1.2.2 Count
i) Case = Average
The application counts the number of all transactions, and divides the result by the number of periods
specified in the Period text box. The interval is calculated as:
Source = (ΣCOUNTk) / PERIOD, k= 1 to PERIOD
ii) Case = Sum
The application counts the number of all transactions. The interval is calculated as:
Source = ΣCOUNTk , k= 1 to PERIOD
Example:
You want to be alerted if a specific customer receives more than 3 transactions on his account on the
last 3 days.
You will have to create a daily behaviour for that specific customer that will calculate the number of all
the incoming transactions for each day for all the customer’s accounts.
From here, you can create a rule that will calculate the average of the number of transactions each
day or you can create a rule to calculate the sum of the number of transactions.

• Behaviour calculates 1 transactions for day 1
If the rule calculates the average of the number of transaction, then it will calculate
(1+ 3+ 2) / 3 = 2. No alert will be raised
If the rule calculates the sum of the number of transactions, then it will calculate
45
FCM Services
1+ 3+ 2 = 6. The result is bigger than 3, so an alert will be generated.
3.1.3.1.2.3 Maximum
i) Case = Average
The application adds the maximum amount of each profile, and divides the result by the number of
periods specified in the Period text box. The interval is calculated as:
Source = (ΣMAXk) / PERIOD, k= 1 to PERIOD
ii) Case = Sum
The source is the maximum amount of all profiles specified in the Period text box. The interval is
calculated as:
Source = MAX (MAXk), k= 1 to PERIOD
Example:
You want to be alerted if a specific customer receives a transaction bigger than 2000 USD on the last
3 days.
You will have to create a daily behaviour for that specific customer that will calculate the maximum of
all the incoming transactions for each day for all the customer’s accounts.
From here, you can create a rule that will calculate the average of the maximum amount of
transactions for each day or you can create a rule to calculate the sum of the maximum amounts of
each day.

• Behaviour calculates 1100 for day 1
If the rule calculates the average of the maximum of the transaction, then it will calculate
If the rule calculates the sum of the maximum of the amount of transactions, then it will calculate
46
FCM Services
3.1.3.1.2.4 Sum
i) Case = Average
The application adds the sum of each profile, and divides the result by the number of periods specified in
the Period text box. The interval is calculated as:
Source = (ΣSUMk) / PERIOD, k= 1 to PERIOD
ii) Case = Sum
The application adds the sum of each profile. The interval is calculated as:
Source = ΣSUMk, k= 1 to PERIOD
Example:
You want to be alerted if a specific customer receives an amount bigger than 2000 USD on the last 3
days.
You will have to create a daily behaviour for that specific customer that will calculate the sum of all
the incoming transactions for each day for all the customer’s accounts.
From here, you can create a rule that will calculate the average of the amounts for each day or you
can create a rule to calculate the sum of all amounts for all 3 days.

If the rule calculates the average of the maximum of the transaction, then it will calculate
If the rule calculates the sum of all amounts of transactions, then it will calculate
47
FCM Services
3.1.3.2 Comparing against what

This section describes the four possible values that can be used for the right side of the condition.
3.1.3.2.1 Reference value
The source value is compared with the reference fixed value.
Example:
• If the cash deposit is higher than 1000 EUR
• If the customer income for the last week is higher than 20.000 EUR
3.1.3.2.2 Profile Value

A value calculated from a profile can also be used in the right side of the condition.
There are three types of profiles: ACCOUNT, CUSTOMER and GROUP. The source value is an
aggregated value which can calculate: AVERAGE, COUNT, MAX and SUM as described in section
3.1.3.1.2 Value coming from a profile.
On top of the functions defined for the calculation, three other parameters can be used:
• The weight allows multiplying the value calculated by factor.
Example:
o Compare against twice the total income of the last month
o Compare against half the maximum transaction amount for the last week
• The shift allows ignoring one or several days in a calculation. It is especially useful when
comparing the same type of operation on different periods
Example:
o If the income during last month is higher than the income during the last 6 months except
the last month. In this case, the shift will be 1.
• The reference minimum is used as a threshold mechanism for a rule to apply and as such allows
ignoring values below a given amount. This is especially useful to avoid non-relevant.
3.1.3.2.3 Rounded value
To test if the amount is a round number, the amount of the transaction is divided by the multiple of 10
defined in Rounded selection list. The comparator is not used in this case. In this example the amount
must be divisible to 100.
Possible values are
• 1
48
FCM Services
• 10
• 100
• 1000
• 10.000
• 100.000
3.1.3.2.4 Value defined for the customer segment

The activity of a individual employee or of a corporate is not the same. This application allows the same
condition to apply differently based on the customer segment by defining different threshold values for
each segment.
Example:
• If the income over 1 month is higher than
o 10.000 for an employee
o 10.000.000 for a corporate
3.1.3.3 Type of comparators: >, >=, <, <=, =

The Comparator taken from the selection list will be used in comparing the source value against the
reference value.
The comparators are as follows:

a. ‘= - EQUAL’ – the source value must be equal with the reference value in order to generate an
alert
b. ‘< - LOWER’ – the source value must be smaller than the reference value in order to generate an
alert
c. ‘> - GREATER’ – the source value must be greater than the reference value in order to generate
an alert
d. ‘<= LOWER OR EQUAL’ – the source value must be smaller or equal with the reference value in
order to generate an alert
e. ‘>= - GREATER or EQUAL’ – the source value must be greater or equal with the reference value
in order to generate an alert
3.1.4 A rule on a profile can be applied on

A rule on profile can apply based on the:
• customer activity
• group of customers activity
• account activity.
49
FCM Services
On top of this, the application allows to define on which set of customers, groups of customers or
accounts the rule will be applied.
3.1.4.1 Customer
3.1.4.1.1 Each customers

A rule on profile can apply to every customer.
3.1.4.1.2 A specific customer

A rule on profile can apply only to a specific customer. The customer is identified by its customer ID.
Example:
“This rule applies only to the customer John Smith”
3.1.4.1.3 Each customers of a given segment

A rule on profile can apply to every customer of a specific segment. The segment is identified by its
segment ID.
Example:
“This rule applies only to employees”
3.1.4.1.4 High risk customers

FCM Profile can receive and associate a risk rate for each customer. This risk rate is a number between
‘0’ (lowest risk) and 100 (highest risk). The risk rate can be either:
• Imported with the customer file
• Computed by the FCM KC+ module described in 4. FCM Know Customer plus (KC+)
By default, the risk rate is split in three categories:
• LOW: from 0 to 49
• MEDIUM: from 50 to 99
• HIGH: 100
This can be parameterized as per bank requirements.
A rule on profile can apply to every customer having a risk rate higher or equals than a defined value.
Example:
“This rule applies only to medium and high risk customers”
This risk factor can be applied on top of the preview scopes defined.
Examples:
“This rule applies to all customers with medium and high risk”
“This rule applies to all employees with medium and high risk”
50
FCM Services
3.1.4.2 Account
3.1.4.2.1 Each accounts

A rule on profile can apply to every account.
3.1.4.2.2 A specific account

A rule on profile can apply only to a specific account. The account is identified by its account ID.
Example:
“This rule applies only on the account 112233”
3.1.4.3 Group of customers

FCM Profile allows the manual creation of groups of customers. A group is an entity with a defined name
that contains a set of customers.
For example, the group “John Smith’s family” containing John Smith’s, his wife and his son can be
created.
3.1.4.3.1 Each groups of customers

A rule on profile can apply to every group of customers.
3.1.4.3.2 A specific group of customer

A rule on profile can apply only to a specific group of customers. The group of customer is identified by
its ID.
Example:
“This rule applies only on the group “John Smith’s family””
3.1.5 A rule on a transaction can be applied on

A rule on transaction will always apply for the transactions of a given type identified by the transaction
code. The rule editor interface provides facilities to duplicate a rule for all required transaction codes.
On top of the transaction code, other criteria’s can be defined to distinguish more specifically to which
transactions the rule must apply.
3.1.5.1 Each transactions with a specific operation code

A rule on transaction applies to a defined type of transaction identified by it transaction type.
Example:
“This rule applies only on the cash deposit transactions identified par the transaction code 111”
3.1.5.2 Transactions with a specific operation code belonging to
3.1.5.2.1 A specific account
51
FCM Services
A rule on transaction can apply only on the transactions done on specific account identified by its account
ID.
Example:
“This rule applies only on the cash deposit transactions done on the account 112233”
3.1.5.2.2 A specific customer

A rule on transaction can apply only on the transactions done by a specific customer identified by its
customer ID.
Example:
“This rule applies only on the cash deposit transactions done by the customer John Smith”
3.1.5.2.3 A specific group of customer

A rule on transaction can apply only on the transactions done by a member of a specific group of
customers. The group of customer is identified by its ID.
Example:
“This rule applies only on the cash deposit transactions done by a member of the group “John
Smith’s family””
3.1.5.2.4 A specific segment

A rule on transaction can apply only on the transactions done by a customer part of a defined segment.
The segment is identified by its ID.
Example:
“This rule applies only on the cash deposit transactions done an employee”
3.1.5.2.5 High risk country

FCM Profile provides an interface allowing the classification of the countries in 5 risk categories:
• Risk 0: Used to be set with the bank domestic country
• Risk 10: Low risk
• Risk 20: Medium low risk
• Risk 30: Medium risk
• Risk 40: Medium high risk
• Risk 50: High risk
A rule on transaction can apply only on the transactions coming from or going to countries with a risk level
higher or equals than a defined value. The transaction country will be picked up from the transaction
external party country containing the Iso Country Code of the external party.
Example:
“This rule applies only on the wired out to countries with a medium or higher risk”
“This rule applies only on the wired in coming from foreign countries”
52
FCM Services
3.1.6 Handle complex requirements by linking rules together

Complex FCM requirements may not be covered by a single rule. FCM Profile allows then linking several
rules together with a ‘AND’ condition in such context.
For example:
Bank wants to be informed if a customer splits a big amount in several small amounts in order to keep
below the regulatory threshold (Max 10.000 in a single operation).
This can be implemented with the two following rules linked together. In this case, bank will be informed
only if the two conditions are met:
• Rule 1: If the total cash deposit during the last 3 days is higher than 10.000
• Rule 2: If the maximum cash deposit transaction during the last 3 days is lower than 10.000
3.1.7 Increase rule relevance by defining threshold

A rule comparing against a value from a profile may by default raise non relevant alerts.
Examples:
• If a customer does a cash deposit twice higher than the maximum cash deposit of the last 2
months
If the customer doesn’t do any cash deposit during the last 2 months and does a 10 EUR
cash deposit, the condition will be met
To prevent this, FCM Profile provides the threshold mechanism allowing defining a minimum value for the
rule to apply. For such scenario, the threshold could be for example set to 750 EUR.
• If a customer does a cash deposit of at least 750 EUR and twice higher than the maximum cash
deposit of the last 2 months
3.1.8 Ignore bank holidays

For the rules applying on daily profiles and/or against daily profiles, the choice to ignore or not bank
holidays is provided.
• By default, the bank holidays are not ignored. This means that the number of calendar days will
be considered
• If the bank holidays are ignored, it means that only the working days will be considered. Working
days are all days but
o Week-ends (Saturday and Sunday)
o Additional days defined in the calendar. FCM Profile provides an interface allowing the
manual definition of the additional bank holidays.
Example :
• Rule : If a customer does more than 5000 EUR outcome during the last 7 days
nd
• Context: Let’s say it’s Friday 2 of May 2014
o Don’t ignore bank holidays : then the customer outcome from Saturday 26th of April to
nd
Friday 2 of May will considered
o Ignore bank holidays : then the customer outcome for the following days will be
considered
nd
1 - Friday 2 of May
53
FCM Services
st
Thursday 1 of May (If defined as such in the calendar)
th th
2 4 – from Monday 28 April to Wednesday 30 April
th
Saturday 26th April and Sunday 27 April
rd th h
5->7 – from Wednesday 23 April to Friday 25 April
3.1.9 Scoping: Include/exclude entities and select pre-defined filters

This feature allows defining more granular and specific rules taking into consideration possible deviations
within a peer group, a segment or transaction type. It allows further to define a list of filters and values
which can be used for other and/or new rules.
• Each rule has a scope.
• The scope defines for which entities the rule is triggered.
• The user can select to which type of entity the rule will apply. The entities types are Customer,
Account, Group or Segment (also called Peer).
• The user can select an attribute and provide a value for which the rule will be triggered. Based on
the selected entity type the available attributes are different.
The attribute can be a core attribute or one provided through dynamic fields.
Note: the scope limitation based on attributes applies only for customers and accounts.
Examples of scoping a rule:

• Limit the scope of a rule to PEPs only.
• Limit the scope of a rule to a risk level range.
• Limit the scope of a rule based on account attributes.
• Add a list of customers to the scope of a rule.
• Exclude a list of customers from the scope of a rule.
3.1.10 Reverse transaction handling

A reverse transaction is a transaction that indicates to Profile that the calling system want to cancel a
previous transaction. Cancelling a transaction means that the impact of that transaction, in the history and
for eventually generated alerts, need to be null.
When Profile receives a reverse instruction it will
• remove the targeted transaction from the history
• make that alerts generated based on this transaction obsolete
3.1.11 Peer Groups: Detect deviating behaviour of customers

This feature allows to detect customer behaviour not matching the behaviour of the other customers from
the same peer group.
A peer group represents a business activity, this means that customers who are members of the same
peer group are having the same type of business activity, and hence the evolution of their business
should be similar.
The term “peer group” is synonym of the term “segment” used elsewhere in the product descriptions.
(A customer can only belong to a single segment or peer group. Other types of grouping are also
available and are discussed elsewhere.)
54
FCM Services
Examples:
• Have an alert if a flower reseller sells less the 14th of Feb as the system sees that other flower
resellers obviously sell more.
• Having an alert on employees that get more incoming cash transactions that the other
employees.
• Not having an alert when an employee gets paid his end of year bonus, where everyone else also
has
3.1.12 When the condition is met, an alert is generated

Each rule is attached to a single alert code. And an alert code is the combination of
• A code. This is a numeric value (max 5 digits) uniquely identifying the alert.
For example ‘001’
• A description. This is a string of characters (max 50 characters) describing the alert.
For example “High ATM withdrawals”
• A weight. This is a numeric value (between 0 and 100 inclusive) identifying the alert severity.
For example ‘90’ (high severity)
An alert code is a separated entity and can be used by several rules.
When the rule is met the associated alert is raised.
3.1.12.1 Alert goes in the Alert Manager

By default the alert will be raised in the alert manager to be reviewed by one or several evaluators.
3.1.12.2 Alert goes directly in the statistics

At the rule definition level an authorized user can define whether an alert is for reporting only,. In such
case, the alert won’t have to be evaluated but will be accessible via the profile reporting tool.
3.2 Profiling Alerts management

The alerts generated are managed using the Profiling Evaluation user inter face. The main page is
structured in 3 main sections:
1. Dashboard for a quick overview of workload
2. View Preferences to organize workload by filtering and ordering messages
3. Messages to action on alert messages
The Dashboard delivers a graphical summary of the risks detected by score, type, volume, status, and a
number of other configurable criteria as shown in the picture below.
55
FCM Services
The View Preference section provides 4 tabs for filtering:

1. Simple Filter that allows to display a subset of messages in the messages list
2. Advanced Filter that allows to perform complex filtering of messages in the messages list
3. Order Filter that allows to sort the message list by a certain filed in ascending/descending order
4. Columns that allow to specify the fields/information displayed in the message list and its order
Operational efficiency may require to filter and order the messages list for resource allocation. In the View
Preferences a user can organize own workload in order to meet operational needs and priorities but also
to support personal efficiency and performance. Following fields are available in the Simple Filter:
• The Entity Name – the name for the entity who generated the alert
• The Entity Type – the type of the entity for which the alert was generated: CUSTOMER,
ACCOUNT, GROUP, EXTERNAL
• The Entity Code – the customer id
• The Alert Code – a code for alert type, defined by the bank
• The Score – the severity of the alert
• The period : From Date / To Date
• Branch – the bank branch were the alert was generated
Using the Advanced Filter allows for more complex filter rules with the use of operators and values and by
linking rules.
The Messages List can be also ordered by the selected fields in ascending or descending order, or can
be customized by selecting the fields to be displayeThe Columns filter is used to define the information to
be displayed and its order.The arrows indicate the sequence of the columns from the left to the right, i.e.
moving up means to the left, moving down means to the right.
The Messages List section shows the list of transactions which generated the alerts.Note: The alert type
"OPERATION"is an alert on transaction, whereas "PROFILE"refers to behaviour (profile).
An alert can be viewed or opened. Viewing an alert means that all the information is only read, and
cannot be modified. If the alert is opened, then it can be followed up or closed. .
56
FCM Services
In certain cases, it may be necessary to force open an alert. Only a user with the appropriate
authorization can force open it, and the original user is not able to complete the evaluation. An error
message is displayed to the original user, issuing a warning when he tries to commit.
3.2.1 Alert on transaction amount

An alert on transaction is an alert generated from a transaction rule.
When an alert was generated on transaction amount this means that the rule was checking the amount of
the transaction against a reference value, the value coming from a profile, a rounded value, or a value
defined for the customer segment (see chapter 3.1.3.2).
Evaluating an alert on transaction gives information about past alerts, past transactions, daily profiles,
monthly profiles, all the rules applied, plus account details and the transaction details.
Once a user started with alert investigation he/she can decide whether an alert can be set as completed,
closed without saving or must be hold for investigation.
57
FCM Services
If the alert is considered false, then the user selects a "reason code" and clicks on “Evaluation Complete”,
and the alert will be out of the list.
In case 2 users need to evaluate the alert (it’s working on the 4 eyes principle. See chapter 3.3Case
management : 2 eyes or 4 eyes principle), the first user should hold the alert for more investigation, in
order to let the second one also evaluate the alert.
58
FCM Services
If the user clicks on “Close” then the alert remains in initial state and can be evaluated by another user
and the user is back on the Messages List.
When evaluating alerts, users can attach related documents to justify an action. Attachments remain in
the DB when the message goes to output, and can be linked to the statistics tables. Another user can
view the attachments, as long as he/she can view the state of message evaluation history the
attachments are linked to.
The following rules apply:

• The maximum number of attachments uploaded by an user, for a single message state, is 50;
• The maximum attachment size is 5 MB;
• An attachment is not compressed (it is saved in the database as it is);
• No restriction is available.
3.2.2 Alert on profile rules

When evaluating a profile alert, the user has information about past alerts, past transactions, daily
profiles, monthly profiles and all the rules applied.
Once a user started with aler evaluation, he/she can decide whether an alert can be set as completed,
closed without saving or it must be hold for investigation.
59
FCM Services
If the alert is considered false, the user set it as completed and the alert will be out of the list. In case of a
second user need to evaluate the alert, the first user should hold the alert for investigation in order to let
the second one also to evaluate the alert.
Here can also be attached documents, the same as described in the previous subchapter.
3.3 Case management : 2 eyes or 4 eyes principle

This principle refers to the way an alert is evaluated.
2 eyes means only one user is evaluating the alert (close or follow-up). So the alert is evaluated once and
exits the Profiling Evaluation to go to Statistics.
4 eyes principle means 2 users are needed for the process. In this case, the second evaluation is
required regardless of the final decision of the first one. A choice can be made in configuration whether to
use one or the other principle.
After the first evaluation the alert goes to another stage (configurable) and it needs to be reviewed by
another evaluator than the one who did the first evaluation. Once the second evaluation is done, the alert
60
FCM Services
exits the Profiling Evaluation to go to Statistics. The 2nd evaluator has access to the first evaluation
details.
It is important to mention that the 2 users are different and they must be logged into the application
separately. While the user evaluates an alert, this is no longer accessible by the others. Also, after the
first user evaluates an alert, he will no longer see it in the list. If he decides that Evaluation is completed,
no other user can see it anymore, but if he decides it should be followed up, only the other users are able
to see it and evaluate it.
3.4 Data imported

• The FCM Profiling software aims to highlight the suspicious transactions or suspicious activity of the
bank’s customers or on the customer’s accounts. To do such, it needs to be fed with the customers,
accounts and transactions information.
• This section details the type of information that can be managed, provides an overview of their usage
within the application and explains the way they must be provided. For T24 customers, it will also be
described the default mapping from T24 to FCM profiling.
3.4.1 Customer data imported

The customer is a person or a company that is making transactions through the bank.
The payments system is responsible of giving this information to the FCM Profiling system, which imports
the file of customers received. This file should contain all the necessary data in the profiling application.
The file can be:
• Delimited – the fields are delimited by a delimiter character (e.g. , ~ ‘)
00110114~ AC~ ACCOUNT NAME~ 1000 494~ CUSTOMER NAME~ 100000OSCAR ARTURO LLO~ 00000020130905~ 19000101~ 0000002709982
• Fixed length – the fields have a fixed length

00110114 AC ACCOUNT NAME 1000 494 CUSTOMER NAME 100000OSCAR ARTURO LLO 00000020130905
19000101 0000002709982
To define the fields’ format a mapping file is used to specify field length, position in the file or, if it’s the
case, the delimiter used.
Note: Import of Customer data, also known as FCM CIF Loader, as a batch process is also used in FCM
Screen for CIF Screening and in FCM KC+ for customer risk rating.
61
FCM Services
3.4.1.1 Data used for processing: ID, Segment, company

A customer has an ID which uniquely identifies the customer in a bank. The bank is identified by an
unique ID in the system set in the field company.
The bank can define segments of customers, based on a specific logic, and in this case each customer
that is belonging to the segment receives this information in the customers file exported by the payments
system.
The customers can be grouped in a group of customers, where specific customers are added by name or
by id, or in a segment conform to the customers file.
3.4.1.2 Data used for information: Given name, Address (Address line 1, Address line 2,
City, zipcode, State, country), Social security number, Social security country,
Passport number, Birth date, Birth country, Birth city, Fiscal country, Country of
nationality, Entity type (Individual, company, bank,…)
The information that is needed for a customer is:

• Name and family name
• The address : address lines, city, zip code, state, country
• The social security number and social security country
• Passport number
• Birth information : birth date, birth city, birth country
• The country where payments are made by the customer: fiscal country
• Country of nationality
• Entity type
3.4.1.3 Data format
Fields Data type Length Mandatory
Customer ID String 64 Yes
Name String 254 Yes
FirstName String 254 No
AddressLine String 254 No
City String 254 No
State String 64 No
ZipCode String 32 No
Country String 2 No
FiscalCountry String 2 No
62
FCM Services
BirthDate Date No
BirthCity String 254 No
BirthCountry String 2 No
PassportNumber String 32 No
NatCountry String 2 No
SocialSecurityNumber String 32 No
SsnCountry String 2 No
Segment String 32 No
Entity Type Numeric 5 Yes
The Entity type can have one of the values (the left side represents source file entity type and right side
the corresponding VWatch value)
0=BANK
1=COMPANY
2=GOVERNMENT/COUNTRY
3=INDIVIDUAL
4=MINISTER/GOVERNMENT OFFICIAL
5=OTHER
6=POLITICAL/RELIGIOUS ORGANIZATION
7=PRINCIPAL CITY
8=VESSEL
3.4.1.4 CIF Dynamic Fields

Any attribute of a customer can be used to define a Profiling rule. These attributes are directly linked to
the CIF_RECORD. The CIF_RECORD fields are a very small subset of fields that exist in a core banking
system (i.e. T24).
The feature of CIF Dynamic Fields allows the bank to define which of the customer attributes, available in
the core banking system (e.g. T24), should be used in the customer data import into Profiling.
More information about the detailed functions can be found in 4.3 CIF Dynamic Fields.
3.4.1.5 Methods to handle fields

For double, float, date or integer fields, special methods can be used in order to calculate, convert or
parse them:
• double, float, int; GetMinDouble, GetMaxDouble, GetMinFloat, GetMaxFloat, GetMinInt,
GetMaxInt
• date: GetMinDate, GetMaxDate
63
FCM Services
• string: GetMinString, GetMaxString, Concatenate, Substring, LowerCase, UpperCase.
3.4.1.6 From T24 to FCM Profile
3.4.1.6.1 The correlation with the fields from T24 R11 version
The values extracted from T24 from CUSTOMER table are as follows:
FCM Profile fields T24 R11 fields

CUST_ID Account.Number>Account>Customer
NAME Short.Name
FIRST_NAME Name.1
TITLE Title
ADDRESS1 Street
ADDRESS2 Address
CITY Town.Country
STATE Country
ZIPCODE Post.Code
COUNTRY Residence
FISCAL_COUNTRY Residence
TELNO_FIX
TELNO_MOB Phone.1
BIRTH_DATE Date.of.birth
BIRTH_CITY
BIRTH_COUNTRY Country
PASSPORT_NR
NAT_COUNTRY Nationality
NAT_ID
SSN_ID
SSN_COUNTRY
OCCUPATION Occupation
PEP
CAREOF Mail.Domicile
RISK_LEVEL
SEGMENT_ID Sector
ONBOARDING_DATE
MANAGER Account.Officer>Dept.Acct.Officer>Name
BRANCH Account.Number>Account>Co.Code>Company>Sub.Division.Cod
e
COMPANY
3.4.1.6.2 The correlation with the fields from T24 R12 version or higher
The values extracted from T24 from CUSTOMER table are as follows:
CUST_ID ACCOUNT.NUMBER>ACCOUNT>CUSTOMER
NAME Short.Name
64
FCM Services
FIRST_NAME Name.1
TITLE Title
ADDRESS1 Street
ADDRESS2 Address
CITY Town.Country
STATE Country
ZIPCODE Post.Code
COUNTRY Residence
FISCAL_COUNTRY Residence
ENTITY_TYPE
TELNO_FIX
TELNO_MOB Phone.1
BIRTH_DATE Date.of.birth
BIRTH_CITY
BIRTH_COUNTRY Country
PASSPORT_NR
NAT_COUNTRY Nationlaity
NAT_ID
SSN_ID
SSN_COUNTRY
OCCUPATION Occupation
PEP
CAREOF Mail.Domicile
RISK_LEVEL
SEGMENT_ID Sector
ONBOARDING_DATE
MANAGER ACCOUNT.NUMBER>ACCOUNT>ACCOUNT.OFFICER
BRANCH Account.Number>Account>Co.Code>Company>Sub.Division.Code
COMPANY
3.4.2 Account data imported

The account is the bank account of a customer. Only one customer is the owner of the account, but more
customers can be joint holders of the same account.
A customer can have 1 or more accounts in the same bank.
the file of accounts received. This file should contain all the necessary data in the profiling application.
The file can be:
• Delimited – the fields are delimited by a delimiter character (e.g. , ~ ‘)
00110114~ AC~ ACCOUNT NAME~ 1000 494~ CUSTOMER NAME~ 100000OSCAR ARTURO LLO~ 00000020130905~ 19000101~ 0000002709982

00110114 AC ACCOUNT NAME 1000 494 CUSTOMER NAME 100000OSCAR ARTURO LLO 00000020130905
19000101 0000002709982
65
FCM Services
To define the fields’ format, a mapping file is used to specify field length, position in the file, or the
delimiter used if it’s the case.
3.4.2.1 Data used for processing: Account number, customer ID

An account is uniquely identified in a bank by its account number.
An account belongs to a customer which is identified by the customer ID.
Both values are mandatory when specifying the account.
3.4.2.2 Data used for information: Account name, Account currency, Opening date,
Closure date, Last operation date, Balance
The information needed for an account is:
• Account name - The name of the account
• Account currency - Currency of the account
• Opening date is the date when the account was created
• Closure date is the date when the account was closed
• Last operation date is the date when the last operation was executed on that account
• Balance is the current amount of the account
• Category code is the code of the application that is exporting the accounts
3.4.2.3 Data format
Fields Datatype Length Mandatory
AccountNumber String 34 Yes
Account Name String 50 Yes
OpeningDate Date No
ClosureDate Date No
LastOperationDate Date No
WorkingBalance Numeric 18 No
CategoryCode String 50 No
AccountCurrency String 3 No
The date fields may specify their own format, e.g. dd-MM-yyyy:
<delimitedField name="openingDate" index="81" type="date" format="dd-MM-
yyyy"/>
66
FCM Services
If no format is specified, the default one is used yyyyMMdd (this is stored into database as a preference
and can be changed if needed):
<delimitedField name="openingDate" index="81" type="date"/> (no format at all)
is the same with:
<delimitedField name="openingDate" index="81" type="date" format="yyyyMMdd"/>
Also the double fields may specify their own format, e.g. #.##:
<delimitedField name="amount" index="23" type="double" format="#.##"/>
If no format is specified, the default number of decimals is used: 3 (this is stored into database as a
preference and can be changed if needed), which is equivalent to #.### format:
<delimitedField name="amount" index="23" type="double"/>
Is the same with:
<delimitedField name="amount" index="23" type="double" format="#.###"/>
For each source field you can have type and format, only one of them or even none. Depending on the
destination field which refers the source, the implicit format can be yyyyMMdd for date, or #.### for duble.

parse them:
GetMaxInt

COMPANY Co.code
ACCOUNT_CODE Account.Number
ACCOUNT_NAME Account.Title.1
OPEN_DATE
CLOSE_DATE Format.Closure.Date
LASTOP_DATE Trans.Last.Check
BALANCE Get.Working.Balance
PRODUCT_CODE
CURRENCY
67
FCM Services
The values extracted from T24 from ACCOUNT table are as follows:
COMPANY Co.code
ACCOUNT_CODE Account.Number
ACCOUNT_NAME Account.Title.1
OPEN_DATE Opening.Date
CLOSE_DATE Closure.Date
LASTOP_DATE Date.Last.Update
BALANCE Working.Balance
PRODUCT_CODE
CURRENCY Currency
3.4.3 Transaction data imported

The transaction, also named operation in the profiling application, is the banking transaction whereby a
customer is sending/receiving money from another customer of the same bank or from another bank.
the file of transactions received. This file should contain all the necessary data in the profiling application.
The file can be:
• Delimited – the fields are delimited by a delimiter character, like , ~ ‘
1~1.67832E+14~FT~ BANK NAME~~1003~OFFICE NAME~213~20130704~EUR~~-10.15~1.1E+11~~CUSTOMER NAME~101010~Leto II Atreides

0002 FT1324610702-1128-0200100112816 FTACCRA MAIN - T24 213 213 120130903
GHC0000000001000 0000000001000 0200100112816 FTANTHONIO VIDA MISS 1128
CUSTOMER_NAME 900
To define the fields’ format, a mapping file is used to specify field length, position in the file, or the
delimiter used if it’s the case.
The transactions are checked against the operation rules in order to find out if any of them should raise
an alert. The rules are defined by the bank.
3.4.3.1 Data used for processing: Transaction ID, amount converted in the reference
currency, operation code, customer ID, account ID, external party ID, External
party ISO Country Code
A transaction is uniquely identified in a bank by the transaction ID. The transaction amount is the amount
sent/ received by the customer.
The transaction can be made using a different currency than the account currency, and in this case the
transaction will have a value specifying the amount in the currency used when the transaction was made,
and another value for the amount converted in the reference account currency.
A transaction is described by an operation code (also the name “transaction code” is used) that is
specifying the type of the operation: WIRED IN, WIRED OUT, CASH IN, CASH OUT, etc.
68
FCM Services
A transaction is made for a customer that is specified by a customer ID and in the account specified by
the account ID.
The external party is a customer from another bank that is sending/ receiving money to/from a customer
of the bank that registered this operation. This external party is uniquely identified by the external party
ID, and his country is specified by the external party ISO country code.
3.4.3.2 Data used for information: Currency, amount, operation date, customer name,
customer segment, External party name, External party account ID, external
party address (Address line 1, Address line 2, country), External party BIC
The file can also contain the data used to describe the transaction, as follows:
• Currency used for the transaction
• The amount of money transferred in the current transaction on the specified currency
• Operation date –the date when the transaction was made
• Customer name – the name of the customer
• Customer segment – the segment to which the customer belongs to
Some other fields that can be filled in for an external party are the following:
• External party name – the name
• External party account id – the identifier of the external party’s account
• External address: address line 1, address line2, country
• External BIC – the code of the third party bank that is implied in the transaction
3.4.3.3 Data format
Fields Datatype Length Format Mandatory
TransactionId String 34 Yes
OperationCode String 10 Yes
OperationDate Date yyyyMMdd (default format) Yes
Currency String 3 No
“xxxxxxyyy” representing a
AmountCurrency Numeric 18 floating point value as No
“xxxxxx.yyy”
“xxxxxxyyy” representing a
AmountRefCurrency Numeric 18 floating point value as Yes
“xxxxxx.yyy”
ApplicationId String 32 No
ExternalPartyId String 32 No
69
FCM Services
ExternalPartyName String 50 No
ExternalPartyAddress String 50 No
ExternalPartyCountry String 2 No
AccountId String 32 Yes
CustomerId String 64 Yes
The date fields may specify their own format, e.g. dd-MM-yyyy:
<delimitedField name="openingDate" index="81" type="date" format="dd-MM-
yyyy"/>
If no format is specified, the default one is used yyyyMMdd (this is stored into database as a preference
and can be changed if needed):
<delimitedField name="openingDate" index="81" type="date"/> (no format at all)
is the same with:
<delimitedField name="openingDate" index="81" type="date" format="yyyyMMdd"/>
Also the double fields may specify their own format, e.g. #.##:
<delimitedField name="amount" index="23" type="double" format="#.##"/>
If no format is specified, the default number of decimals is used: 3 (this is stored into database as a
preference and can be changed if needed), which is equivalent to #.### format:
<delimitedField name="amount" index="23" type="double"/>
Is the same with:
<delimitedField name="amount" index="23" type="double" format="#.###"/>
For each source field you can have type and format, only one of them or even none. Depending on the
destination field which refers the source, the implicit format can be yyyyMMdd for date, or #.### for duble.

parse them:
GetMaxInt
70
FCM Services
The values extracted from T24 from STMT table are as follows:
COMPANY
BRANCH Account.Number>Account>Co.Code>Company>Sub.Division.Code
OPERATION_CORE_ID Get.Trans.Ref.Num
PRODUCT_ID System.ID
OPERATION_CODE Transaction.Code
OPERATION_DATE Value.Date
CURRENCY Currency
CURRENCY_AMOUNT Get.Txn.Amt.Ccy
AMOUNT Get.Lccy.Amt
MANAGER
ACCOUNT_ID Account.Number
CUST_ID Account.Number>Account>Customer
EXTERNAL_ID Get.Third.Party.Dets
EXTERNAL_NAME
EXTERNAL_BIC
EXTERNAL_ADDRESS1
EXTERNAL_ADDRESS2
EXTERNAL_COUNTRY
The values extracted from T24 from STMT table are as follows:
COMPANY ACCOUNT.NUMBER>ACCOUNT>CO.CODE
BRANCH ACCOUNT.NUMBER>ACCOUNT>CO.CODE>COMPANY>SUB.DI
VISION.CODE
OPERATION_CORE_ID STMT.NO
PRODUCT_ID SYSTEM.ID
OPERATION_CODE TRANSACTION.CODE
OPERATION_DATE VALUE.DATE
71
FCM Services
CURRENCY CURRENCY
CURRENCY_AMOUNT AMOUNT.FCY
AMOUNT AMOUNT.LCY
MANAGER Account.number>Account>Account.Officer>Dept.Acct.Officer>Nam
e
ACCOUNT_ID
CUST_ID
EXTERNAL_ID
EXTERNAL_NAME ORD.CUST.ACCT>ACCOUNT>CUSTOMER>CUSTOMER>SHOR
T.NAME
EXTERNAL_BIC
EXTERNAL_ADDRESS1 ORD.CUST.ACCT>ACCOUNT>CUSTOMER>CUSTOMER>STRE
ET
EXTERNAL_ADDRESS2 ORD.CUST.ACCT>ACCOUNT>CUSTOMER>CUSTOMER>ADDR
ESS
EXTERNAL_COUNTRY ORD.CUST.ACCT>ACCOUNT>CUSTOMER>CUSTOMER>COUN
TRY
72
FCM Services
4. FCM Know Customer plus (KC+): Customer risk

calculation
The Know your Customer Plus (KC+) module allows the bank to formalise the information obtained from
its customers.
First, the customer characteristics that are relevant for the evaluation of their associated risks need to be
identified. To each such characteristic, a risk weighing factor can then be assigned, defining for the
customers a “risk matrix”. Each characteristic is stored in a “field” or “attribute”.
The fields are imported into KC+ from the core banking system. They can be considered to have been
verified using the core banking system and following the bank’s procedures. Alternatively, “checks” or
“assessments” can be defined in KC+.
Checks are flagged with their current status: outstanding, investigating, OK or Not OK, with a risk weight
being associated with each of the statuses.
Assessments are questions about the customer for which several answers are possible, each with an
associated risk weight (e.g. expected earning scale of individuals).
Furthermore, “functions” can be defined to obtain a grouped risk weight based on several independent
fields.
KC+ can be used standalone (independently from any of the other FCM Suite modules) or in combination
with the other modules. In particular, when the application is installed with the FCM Profile module, the
risk score calculated for each customer can be used, as part of the monitoring rules.
For its operation, the KC+ application needs the following FCM Suite modules:
- FCM Suite Database
- FCM Suite Rules Manager
- FCM Suite Security
- FCM CIF Loader
4.1 Customer Risk Calculation

In order to allow monitoring and progress tracking of the Risk Calculation the Process Runs section
provides an overview of all processes with process name, status, start and end time, user and message
(in case of an error).
4.1.1 Calculator
The calculation procedure loops through all the functions of the active risk matrix and checks if the
function matches to the type of the customer.
For each function that applies to the customer, the procedure loops through its definitions and checks
whether the definition is satisfied. If a definition is indeed satisfied then it would add the weight of the
definition to the total weight of the calculation.
In order to determine if a definition is satisfied, the appropriate value for the attribute is extracted and
compared to the value of the definition. Depending on the comparison operator, the definition is satisfied if
they match or not.
The total weight calculated for each function is factored using the weight of each function (called the
function’s factored weight).
The factored weights of all the functions that apply are then added together to calculate the risk level for
the customer.
73
FCM Services
4.1.2 Calculate Risk for many customers

This is how the Risk Calculation is done for many customers.
It first registers the start of the process, and then tries to locate an active Risk Matrix. If it finds one it
loops though the Customers, calculates a risk and then checks to see if the customer status must be
updated as a result and whether the calculation should be saved.
4.2 Supported Factors and Attributes for risk calcuation

The following attribute groups have to be set-up before the risk calculation can be defined. For each of
the attributes the bank can define the values. A set of out-of-the-box values is available.
• Customer segments
• Customer occupation
• Industry sector
• Risk countries
• Assessment questions
• Compliance checks
Note: Management of attributes and associated values is provided in the KC+ Base Data Management
area.
4.2.1 Customer
4.2.1.1 Birth Country

It is possible to add a value, operator and weight that will be compared with the customer’s birth country.
Example: if Customer.BirthCountry = Cuba then add 20
4.2.1.2 Birth Country Weight

It is possible to add a weight that will be used to factor the weight assigned to the country equal to the
customer’s birth country.
Example: Add the value of the Country’s weight that is equal to Customer.BirthCountry factored by 100
4.2.1.3 Country
It is possible to add a value, operator and weight that will be compared with the Customer’s country.
Example: if Customer. Country = Cuba then add 10
4.2.1.4 Country Weight

customer’s country.
Example: Add the value of the Country’s weight that is equal to Customer.Country factored by 100
74
FCM Services
4.2.1.5 Fiscal Country

It is possible to add a value, operator and weight that will be compared with the customer’s fiscal country.
Example: if Customer.FiscalCountry = Cuba then add 15
4.2.1.6 Fiscal Country Weight

customer’s fiscal country.
Example: Add the value of the Country’s weight that is equal to Customer.FiscalCountry factored by 100
4.2.1.7 National Country

It is possible to add a value, operator and weight that will be compared with the customer’s social security
country.
Example: if Customer.NationalCountry = Cuba then add 30
4.2.1.8 National Country Weight

customer’s national country.
Example: Add the value of the Country’s weight that is equal to Customer.NationalCountry factored by
100
4.2.1.9 Number Of SAR Filed

It is possible to add a value, operator and weight that will be compared with the number of suspicious
reports filed for the customer. This depends on the SAR filing feature being used by the bank..
Example: if Customer.NumberOfSARsFiled< 5 then add 90
Note: the risk calculator ensures that if there are more than of these definition then the one with the
highest value is checked first and if it is satisfied then the other are ignored.
4.2.1.10 Occupation
It is possible to add a value, operator and weight that will be compared with the customer’s occupation.
Example: if Customer.Occupation = Lawyer then add 15
4.2.1.11 Occupation Group

It is possible to add a wild carded value, operator and weight that will be compared with the customer’s
occupation.
Example: if Customer.OccupationGroup = Law% then add 15
4.2.1.12 Pep
It is possible to add a value, operator and weight that will be compared based on the customer’s PEP
status.
Example: if Customer.isPep = yes then add 30
75
FCM Services
4.2.1.13 Required Field Empty

It is possible to add a field, operator and weight that can be checked if it is empty or not.
Example: if Customer.City = empty then add 100
4.2.1.14 Sector
It is possible to add a value, operator and weight that will be compared with the customer’s occupation.
Example: if Customer.Sector = Farming then add 20
4.2.1.15 Sector Group

It is possible to add a wild carded value, operator and weight that will be compared with the customer’s
occupation.
Example: if Customer.SectorGroup = Farm% then add 20
4.2.1.16 Segment
It is possible to add a value, operator and weight that will be compared with the customer’s segment
(using the Customer.BankId1 field).
Example: if Customer.BankId1 = Individual then add 2
4.2.1.17 Social Security Country

It is possible to add a value, operator and weight that will be compared with the customer’s social security
country.
Example: if Customer.SocialSecurityCountry = Cuba then add 25
4.2.1.18 Social Security Country Weight

customer’s social security country.
Example: Add the value of the Country’s weight that is equal to Customer.SocialSecurityCountry factored
by 100
4.2.1.19 Years SinceOn Boarding

It is possible to add a value, operator and weight that will be compared with the number of years since the
customer came on board. This depends on the on boarding value being fed from the core banking
application.
Example: if Customer.YearsSinceOnBoarding < 1then add 45
Note: the risk calculator ensures that if there are more than of these definition then the one with the
lowest value is checked first and if it is satisfied then the other are ignored.
76
FCM Services
4.2.2 Checks
It is possible to use the status of a check when calculating the risk level for a customer.
The options are:
• Check.NotOk
• Check.Outstanding
• Check.Investigating
• Check.Ok
Examples:
If “Identification Verification” equals “Outstanding” then add 10
If “Information Discrepancy” equals “NotOk” then add 100
4.2.3 Assessments
4.2.3.1 Selection
It is possible to add a weight for any assessment selection.
Example: Assessment.Selection = “Account Type.Credit Card” add 10
4.2.4 Account
4.2.4.1 ProductCode
It is possible to add a weight for a product code.
Example: Account.ProductCode = ABCD add 5
4.2.4.2 AccountName
It is possible to add a weight for a product code.
Example: Account.AccountName = Loan add 5
4.2.5 Meaningful Functions

Using the functions mechanism and the fact that each function can have its own weight it implies that
meaningful functions can be made to group similar risk definitions together.
Example 1:
Name: Geographical
Type: Individuals
Weight: 25
Definitions:
1. Customer.Country = CUBA add 10
2. Customer.NationalCountry = CUBA add 10
3. Customer.BirthCountry = CUBA add 10
Example 2:
Name: Compliance Checks
77
FCM Services
Type: Individuals
Weight: 50
Definitions:
1. If “Identification Verification” equals “Outstanding” then add 10
2. If “Information Discrepancy” equals “NotOk” then add 100
In the above two examples, example 1’s first definition has a weight of 10 and example 2’s first definition
has a weight of 10. However the fact that the two functions have different overall weights (25 and 50)
implies that the end value that contribute to the overall risk level are different.
4.3 CIF Dynamic Fields: ability to add new fields on the fly
Any attribute of a customer can be used to assign a risk against or to define a Profiling rule. These
attributes are directly linked to the CIF_RECORD. The CIF_RECORD fields are a very small subset of
fields that exist in a core banking system (i.e. T24).
The feature of CIF Dynamic Fields allows the bank to be able to assign risk against ANY field available in
the core banking system. These additional fields’ values can be used in future for the Link Analysis in
Profiling.
The main functions of this feature are:
• The bank defines and configures what fields should be persisted for a customer
• There isn’t any restriction to the amount of fields that can be persisted for a customer.
• It allows to save additional field values during all stages of a customer lifecycle.
• It allows to import multiple values for a field.
• It allows to keep the history (insert, update, delete) of any dynamic CIF field.
• It allows to configure options of a dynamic field, e.g. to assign weights against certain values for a
customer’s field.
• It allows to assign weights for certain values for a dynamic field
78
FCM Services
5. FCM Security
5.1 Authentication
5.1.1 Build-in authentication module
The FCM suite has a build in authentication module.
This module has the following characteristics
• User name and password are stored in the database
• The password is encrypted
• The user can change the password via a dedicated interface
5.1.2 Authentication handles by application server

The FCM suite can use the application server to do the authentication.
In this case the application sever connect to an external authentication module to validate the credentials.
For more details please refer to your application server documentation.
5.2 Authorisation module: FCM Rule Manager

In FCM Rule Manager offers the ability to:
• Define access to the various FCM Modules
• Define the workflows within the Modules
5.2.1 Mandators: how to handle multiples companies, subsidiaries or business

units within a single FCM Screen instance
An instance of FCM Screen can be implemented to run on behalf of multiple “business units”, be them
companies, subsidiaries or branch offices. Business Units are identified by a “mandator” code.
Technically, “mandator” is an identifier. A special one is ALL, which covers all business units managed by
the FCM Screen instance. In other words, ALL applies to the scope of the whole business.
The mandator concept allow for sharing all common resources and common data by all business units,
while segregating mandator specific data in separate “data silos” or even allowing specific processes.
The mandator concept is used in all FCM Screen applications mostly as a filter, enabling authorised users
access to mandator specific actions or data, specific rules, specific amount of information displayed, etc..
In Watch List Manager (WLM), the interdict entries imported from official providers (as public lists), are
associated with the ALL mandator. The entries of private global and private local lists are the bank’s
responsibility; private local lists are associated with different mandators.
At new entries import/acceptance, WLM generates permutations and variations (depending on some
specific settings). Another WLM feature is the possibility to define/add new aliases (perhaps with a limited
scope, i.e. for a specific mandator). For the mentioned sub-components (permutations, variations,
aliases), WLM also offers the possibility to deactivate the selected element for a particular mandator.
The same flexibility is available also for the SKIPs:
- a skip can be defined/added for the mandator ALL;
- one can define/add a new skip for a particular mandator only;
- the skip’s mandator can be modified.
The mandator concept is taken into account in the Rule Manager: rules may be mandator dependent.
79
FCM Services
The Reports application uses the mandator as a main criterion in filtering the source information used to
generate the report(s).
KC+ operates with context mandator, which enables the user to focus on a specific business division.
The Web Inquiry Tool limits the investigations to a particular mandator.
The Security application enables the bank to manage the access rights to various FCM Screen
applications and one of the key elements managed is the mandators (see below).
5.2.2 Users belong to profiles giving access to a configured list of features in a

configured list of modules
In order to manage the controlled access to various modules and/or features of FCM Screen, the users
are given sets of privileges and access rights. The basic concepts are:
• Role a capability to access a feature; examples:
o COMPLIANCE allow the access to Alert Manager and give the primary
evaluation
o REVIEW allow the access to Alert Manager and give the final
evaluation
o SECURITY_ADMIN allow the access to Security module
• Mandator a “business scope”, a means to logically divide the business (in
branches, companies, regions, groups of countries …); examples:
o ALL all business flow
o 001 a (local) division of business
o GB business flow to/from Great Britain
• Profile a collection of (role, mandator) tuples; examples:
o Superuser
o Reviewer
o Reports
• User an authentication identity belonging to one and only one profile;
examples:
o Fict_001
o Fict_002
The Security module is the FCM Screen application which offers the means to manage the Users,
Profiles, Roles and Mandators. The Rule Manager uses the mentioned elements to create and modify
rules that govern the access to various FCM Screen modules.
5.2.3 The access to FCM Screen application modules is governed by rules
A rule is a logical expression operating with roles and various elements of the entity to control.
Rules are organized in rule bases associated with each application. The Rule Manager is the
specialized application which allows creating, modifying, exporting and importing the rule bases.
Depending of the application structure, in a rule base there are interface rules, action rules and transition
rules.
In workflow management is possible to define/eliminate states (referred in transition rules).
80
FCM Services
The rules allow a fine tuning of accesses permitted to different user categories to FCM Screen application
modules. The rules makes intensive use of roles; as users are associated with profiles, which pair roles
with mandators, an effective access control is obtained.
The 4-eyes paradigm ensures that a change is approved/rejected by a second user which appropriate
privileges.
81
FCM Services
6. FCM Reporting: the Reporting Framework

The FCM Reporting Framework allows users to have access that all data of the database.
6.1 Browsing tables

The FCM Reporting Framework offers the ability to browse through the FCM database without the need
to have an in-depth knowledge of the data model.
The tables are labelled with a business name and the links between the tables are show in a simplified
graphical way.
6.2 Filter
6.2.1 Simple filter
The user can apply filters on a single table.
6.2.2 Filter based on joint tables

The user can apply filters on tables that are linked to the main table.
Example:
This 2 tables, the table customer are the table alerts are linked. The filtering functionality allows to apply a
filter to retrieve only the customers with have alerts.
6.3 Count statistics

The count statistics functionality allows to quickly count data.
The count statistics can work together with the filter functionality.
Example:
This 2 tables, the table customer are the table alerts are linked. The filtering functionality allows to apply a
filter to retrieve only the customers with have alerts. The count functionality counts how many customer
have alerts.
6.4 Dashboards
The dashboards functionality allows to have on a single page different view based on filter and count
statistics.
6.5 Report generator

This functionality allows to extract data from the system without in-depth knowledge of the data model.
The extraction can be automatically repeated by using the Report Scheduler
6.6 Report Scheduler

The FCM suite has a build-in scheduler that allow to automatically generate reports on a regular basis.
82
FCM Services
6.1 Email notifications

The FCM suite has a build-in notification geneator that allow to automatically generate email notifications
based on configurable criteria.
83
FCM Services
7. System administration
The FCM suite offers and build in module to manage different aspect of the configuration.
7.1 Screen parameter wizard

The parameter wizard allow to update the following configuration items:
• Update the main FCM Screen engine parameter files
o The Deffile
o The parmdyn
o The DSL/DSR
• Add a new watch lists in the database
• Update the system preferences
84
FCM Services
8. FCM Integration with other systems

The FCM modules can easily be integrated with other systems.
Below are describe the most common way the FCM suite integrates with other systems. Nevertheless
more integration option are available, these options can be discussed with the FCM Service team.
Also for more details about the integration and the system architecture please refer to the FCM
architecture document.
8.1 Screen Integration

8.1.1 Transaction screening
The transaction screening is done online.
The FCM Screen integration for transactions screening happens via one of these ways:
• Integration via queues
• Integration via web service
When the input message is in XML format it can be mapped via XSLT configuration to a format supported
by FCM Screen.
8.1.2 Customer Information File (CIF) screening

The CIF screening is done in batch mode.
The FCM Screen integration for customer screening happens via export and import of the Customer
database.
8.2 Profile Integration

The profile integration is done in batch mode via export and import of transactions, customers and
accounts
8.3 Out of the box integration with T24

The integration of the FCM suite with T24 happens out of the box.
For more details please refer to the installation guide.
85
FCM Services
9. What feature available form what release?

In this section we find what feature appears in what release.
Note that the below list starts from release R201604, for information about earlier releases please contact
the FCM service team.
9.1 R201604
• Profile: Scoping, Include/exclude entities and select pre-defined filters
• Profile: Peer Groups: Detect deviating behaviour of customers
• New module: the Reporting Framework
• Screen integration -> Transaction Screening: the input message can be mapped via XSLT
9.2 R201607
• Reporting framework: Dashboards
• Reporting framework: Exportable reports on risk
• Reporting framework: Report Scheduler
• FCM Screen -> Data providers supported lists: Support of WorldCompliance
9.3 R201610
• New look and feel
• Screen: Screening for dynamic CIF fields
• Screen: additional info returned in the immediate Screen response.
• Profile: handling of reverse transactions
• Reporting framework: Email notification
86

FCM Services Features

Uploaded by

Copyright:

Available Formats

FCM Services Features

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

FCM Services Features

Uploaded by

Copyright:

Available Formats

FCM Services Suite Features :

Screening, Profiling, KC+

Information in this document is subject to change without notice.

COPYRIGHT 2007 - 2016 TEMENOS HEADQUARTERS SA. All rights reserved.

Version Date Author Comments / Change Description

0.5 Vincent Dupuis Change description of KC+ functionality

0.6 Marlène Meli Review and proposed updates

0.7 Gaetan Deblaere Review and update

0.8 Vincent Dupuis Slight Structure change to improve legibility

0.9 Gaetan Deblaere Review and update

0.10 Gaetan Deblaere Update changes for release 201610

Information in this document is subject to change without notice.

COPYRIGHT 2007 - 2016 TEMENOS HEADQUARTERS SA. All rights reserved.

FCM Services Version 0.9

2.7.3 Watch List Manager: ............................................................................................................. 38

FCM Services Version 0.9

FCM Services Version 0.9

FCM Services Version 0.9

2. FCM Screen: Sanctions screening

2.1.2 Public lists supported: OFAC, EU, UN

2.1.3 Data providers supported lists: WorldCheck, Factiva / DowJones, Accuity

FCM Services Version 0.9

2.1.3.2 Factiva / DowJones

2.1.4 Private Lists

FCM Services Version 0.9

2.1.4.1 Private Lists Import in fixed or delimited format

2.1.4.2 Private Lists Import supported character set

2.1.4.3 Private Lists Import required fields and field mapping

2.2 List management

FCM Services Version 0.9

FCM Services Version 0.9

2.2.2 Enrichment of data from the lists: permutations and variations

2.2.2.3 Smart Variations Module SVM

FCM Services Version 0.9

4. Partial Names (Tokens_and_Clique): This feature generates permutations of sub-

8. Abbreviation swap: This feature generates permutations for a standard set of

FCM Services Version 0.9

Permutation: Person initials

Permutation: Person name

FCM Services Version 0.9

Permutation: Standard person

Examples with suffixes = S. A., S. A. DE C. V., PLC:

Interdict entry: Generation Path

7TH OF TIR INDUSTRIES OF ESFAHAN Alternation_symbol

7THTIROFINDUSTRIESOFESFAHAN Alternation_symbol + glue

7THTIROFINDUSTRIESOFISFAHAN Alternation_symbol + glue

FCM Services Version 0.9

SEVENTH OF TIR INDUSTRIES OF ordinal

SEVENTH OF TIR INDUSTRIES OF ISFAHAN Ordinal + alternation_symbol

SEVENTH OF TIR INDUSTRIES OF ESFAHAN Ordinal + alternation_symbol

SEVENTHOFTIRINDUSTRIESOFISFAHAN Ordinal + alternation_symbol + glue

SEVENTHOFTIRINDUSTRIESOFESFAHAN Ordinal + alternation_symbol + glue

SEVENTHOFTIRINDUSTRIESOFISFAHANESFAHAN Ordinal + glue

17. List of removable company markers and legal suffixes

2.3 Transactions screening and Customers screening

2.3.2 Customer Information screening at on boarding time

FCM Services Version 0.9

2.3.3 Ad Hoc Customer Information screening

2.3.4 Customer Information database screening on a daily basis

2.4 Scanning methods