Anti-Money Laundering - User Guide

Release - R18AMR
May 2018

©2018 Temenos Headquarters SA - All rights reserved.

Warning: This document is protected by copyright law and international treaties. Unauthorised reproduction of this document, or any portion of it, may result in severe
and criminal penalties, and will be prosecuted to the maximum extent possible under law.
Table of Contents

Introduction 3
Purpose of this Guide 3
Intended Audience 3
Anti-Money Laundering Profile 4
Configuration 4
Anti-Money Laundering Screen 9
Configuration 9

Anti-Money Laundering - R18AMR - Page 2 of 10

 Introduction
Purpose of this Guide
This user guide describes the products such as Anti-Money Laundering screen and Anti-Money Laun-
dering profile which perform online as well as offline screening of customer transactions. Financial
institutions use these products to detect and prevent money laundering.

Intended Audience
This user guide is intended for the use of Internal Temenos users and Clients.

Anti-Money Laundering - R18AMR - Page 3 of 10

 Anti-Money Laundering Profile
Configuration
The following Parameter files are required for configuration before entries can be made:

ACCOUNT.PARAMETER
A default filter subroutine AML.ENT.FILTER.RTN to select STMT.ENTRY for capturing transaction
details has been introduced in ACCOUNT.PARAMETER > ACCOUNTING.SUBR field.

AML.ENT.FILTER.RTN is a hook routine to be attached in ACCOUNT.PARAMETER. This will update the

concat file AML.TXN.ENTRY. The ID of the file will be <APPLICATION>-<TXN.ID>.
The record contains the dump of the following:
First line will have application record, Second line will have debit side STMT.ENTRY and Third line will
have credit side STMT.ENTRY.
An extract on how F.AML.TXN.ENTRY will look like would be as below :

Note: AML.TXN.ENTRY is a file maintained in the backend.

Anti-Money Laundering - R18AMR - Page 4 of 10

AML.TXN.PARAMETER
This is the AML parameter file which is used to specify the application that will be picked up for cap-
turing of data.

The parameter need not be set for CUSTOMER and ACCOUNT application as these are included by
default.

AML.EXTRACT.MAPPING
For each application specified in the AML.TXN.PARAMETER this table will specify the fields to be
mapped to AML transaction profiling (.csv) file. Individual setup is needed for both legs of the trans-
action,i.e. Debit and Credit sides.

Anti-Money Laundering - R18AMR - Page 5 of 10

 Note: DEBIT/CREDIT should need not be suffixed for STMT.ENTRY application.

DEAL.PROCESSING
The setup and workflow for AML profile is defined in the chart below:

Anti-Money Laundering - R18AMR - Page 6 of 10

Anti-Money Laundering - R18AMR - Page 7 of 10
The routine AML.PROCESS.DATA reads the concat file F.AML.TXN.ENTRY and builds the csv file.
Please refer to the "How to" guides for further setup and processing related to DW module and extract
of CSV file.

Anti-Money Laundering - R18AMR - Page 8 of 10

 Anti-Money Laundering Screen
Configuration
The actual configuration for AML Screen lies with configuring via Integration Studio (Integration
Framework).
IF (Integration Framework) is asynchronous and is a simple, efficient tool to transmit messages to
other systems. IF is designed to handle high volumes and comes with 2 components:
Design time ‘Integration Studio’ where the versions, applications and component operations for which
events need to be triggered can be mentioned. The message content that is sent to other system can
also be configured here.
Run time component which captures the exit points (versions/application + input/auth stage) and
depending on the pre-defined flow schema, prepares messages and transmits (through ‘Integration Ser-
vice’) to other system
The AML engine will check if a message is on a blacklist and returns hit/miss. A full review facility is
provided in AML screen for a compliance officer to manually check.
In Integration Studio you define an event and choose the exit point. The exit point can be the version of
an application. For example: FUNDS.TRANSFER,. An override is defined in the IF event and DISPO pro-
cessing is triggered based on it. Upon authorisation of the transaction input using the version linked in
the IF event, the status of the transaction goes to INAO.
Upon receipt of a miss or hit response from the AML Engine the underlying transaction gets authorised
or deleted.
The workflow for AML Screen is as per diagram shown below:

Anti-Money Laundering - R18AMR - Page 9 of 10

Please refer to the "How to" guide for further setup information.

Anti-Money Laundering - R18AMR - Page 10 of 10