1 Version 2.1

goAML Web – Manual

Customization by MROS

2 Version 2.1

1 Version Control Version When What Who 1.0 22.03.2018 Creation of first version

MROS

1.1 16.07.2018 Content re-write MROS

2.0 21.01.2019 The main changes are: - New entrance portal (chapter 6 and 7) - Definition of password rules (chapter

7.2) - Recommended order by entering

reported subjects, accounts or entities (chapter 9.4.1)

- Several changes in chapter 9.4.2 (esp. logic behind «my client» vs. «not my client», max. count of transactions per transmission, attachments, location of cash-transactions, automatic transaction number generator)

- Data-entry of entities in the «Person» mask, but only when certain conditions apply (chapter 9.4.2.1.1 to 9.4.2.1.3)

- Procedure when entering «Alias»-identities (chapter 9.4.2.1.1)

- Revaluated importance of MultiParty-«transactions»/-functionalities (chapter 9.4.2.2)

- Procedure when entering a report without transactions (chapter 9.5)

- Data-entry of Trust structures (chapter 9.7)

- Reporting by leasing institutes, casinos, life insurance providers (chapter 9.8)

- Requests based on article 11a AMLA (chapter 10)

- Terms for automated deletion of information in goAML Web (chapter 13)

MROS

2.1 16.04.2019 - Change of the title of chapter 10 to «Additional-Information (AIF)- und Additional-Information-with-Transaction (AIFT) – Reports»

- Adding chapter 10.2 «Reports with more than 5’000 Transactions »

- Adding chapter 10.3 «Reporting of additional Information »

MROS

3 Version 2.1

2 Table of Contents 1 Version Control ............................................................................................................ 2

2 Table of Contents ......................................................................................................... 3

3 Introduction .................................................................................................................. 6

4 goAML IT Architecture ................................................................................................. 6

5 Field labelling syntax ................................................................................................... 8

6 The entrance portal of the goAML Web application ................................................... 9

7 Registration .................................................................................................................10

7.1 Registering as a new Reporting Entity ..................................................................10

7.2 Registering the first Person during the Reporting Entity Registration Process 12

7.3 Registering as a new Person for an existing Reporting Entity ............................13

8 Login and Logout ........................................................................................................15

8.1 Logging in to goAML Web ......................................................................................15

8.2 Logout from goAML Web .......................................................................................17

9 New Reports ................................................................................................................17

9.1 Report compilation methods ..................................................................................17

9.2 XML File Upload ......................................................................................................17

9.3 The starting Web report screen .............................................................................20

9.3.1 The field “Report with transaction?” ..............................................................22

9.3.2 The section “Report type / suspected predicate offense(s) / factor(s) arousing suspicion / type of attachments” ...............................................................23

9.4 Manually created web reports incl. transaction ....................................................24

9.4.1 The recommended order by entering reported subjects, accounts or entities 24

9.4.2 Transactions .....................................................................................................24

9.4.2.1 BiParty Transactions ..............................................................................27

9.4.2.1.1 Person..................................................................................................31

9.4.2.1.2 Account ...............................................................................................33

9.4.2.1.3 Entity ....................................................................................................35

9.4.2.2 MultiParty Functionality ..........................................................................36

9.4.2.3 Goods and Services reported by merchants ........................................39

9.5 Manually created web reports without transactions ............................................39

9.6 Attachments to the Report and Submission .........................................................41

9.7 The data entry of Trust structures in goAML ........................................................43

9.8 Reports which are made by leasing institutions, casinos or providers of life insurance policies ...................................................................................................45

9.9 Report status during the reporting process ..........................................................46

10 Additional-Information (AIF)- und Additional-Information-with-Transaction (AIFT) – Reports................................................................................................................................47

4 Version 2.1

10.1 Requests based on Article 11a para. 1 and 3 of the Money Laundering Act (AMLA) or Article 11a para. 2 and 3 AMLA ............................................................47

10.2 Reports with more than 5’000 Transactions .........................................................48

10.3 Reporting of additional Information.......................................................................48

11 Drafted Reports ...........................................................................................................49

11.1 Current Report ........................................................................................................49

11.2 Not Submitted Web Reports ...................................................................................49

12 Submitted Reports ......................................................................................................52

13 Automated deletion terms for reports and data within goAML Web........................53

14 Message Board ............................................................................................................53

15 My goAML ....................................................................................................................55

15.1 Change password ...................................................................................................55

15.2 Forgotten password instructions ..........................................................................55

15.3 Change My User / My Organization Details ...........................................................56

16 Administration .............................................................................................................56

16.1 Role Management ...................................................................................................57

16.2 User-Role Management ..........................................................................................58

16.3 User Request Management ....................................................................................59

16.4 Overview Users .......................................................................................................60

16.5 Org Request Management ......................................................................................60

16.6 Overview Organizations .........................................................................................60

16.7 Statistics ..................................................................................................................61

17 Application Support and System Maintenance .........................................................62

18 Glossary .......................................................................................................................62

19 Appendix ......................................................................................................................64

19.1 Screen „Report Type“ .............................................................................................64

19.2 Screen „Address“ ...................................................................................................65

19.3 Screen „Indicators“ ................................................................................................66

19.4 Screen „Transaction “ ............................................................................................67

19.5 Screen „Good or Service” ......................................................................................71

19.6 Screen „Transaction Currency “ ............................................................................72

19.7 Screen „Person“ .....................................................................................................73

19.8 Screen „Phone“ ......................................................................................................75

19.9 Screen „Identification“ ...........................................................................................76

19.10 Screen „Email“ ........................................................................................76

19.11 Screen „Account“ ...................................................................................77

19.12 Screen „Entity“ .......................................................................................79

5 Version 2.1

19.13 Screen „Contracting party / Beneficial owner(s) / Power of attorney/Signator(ies) “ ..........................................................................................80

19.14 Screen „Report Party“ ............................................................................81

20 Disclaimer ....................................................................................................................82

6 Version 2.1

3 Introduction The goAML application is a fully integrated software solution developed specifically for use by Financial Intelligence Units (FIUs) and is one of UNODC's strategic responses to financial crime, including money-laundering and terrorist financing. goAML is specifically designed to meet the data collection, workflow management, analytical and statistical needs of FIUs. FIUs play a key role in the fight against money laundering and terrorist financing as they are the central reception point for receiving, processing and analyzing reports compiled by reporting entities1 in compliance with their country’s anti-money laundering and counter-terrorist financing legislation. This document aims at giving an overview of the goAML IT architecture and at providing an in-depth view into the use of the goAML Web application. The order of the various chapters reflects the user needs in chronological order when compiling a suspicious activity report, starting from the registration steps into goAML until the report is submitted. The chapters are named after the various goAML Web functionalities. In order to best meet the various requirements of the Swiss Anti-Money Laundering Act (AMLA), the various goAML Web system functionalities presented in this document include the specific customization changes introduced into the system by MROS.

4 goAML IT Architecture The goAML system consists of two applications: • the “external” Web application, which is accessible to all reporting entities, and • the “internal” MROS main application (so-called “client application”), which is accessible

to MROS personnel only. The goAML Web application provides a secure web based interface between MROS and the reporting entities. Its main purpose is to provide a platform of communication between the FIU and the reporting entities, allowing the submission of reports and other information to MROS by XML file upload or by filling in manually the online reporting forms. Currently, the system does not provide any semi-automated report compilation functionality. IMPORTANT: It is emphasized that the submitted information is kept in Switzerland and that UNODC does not have access to the data processed and stored within the goAML system. The following picture gives an overview of the goAML IT architecture applied in Switzerland:

1 The term “reporting entity” is applied throughout this document and is a standard within goAML to define any financial intermediary or merchant authorized to submit suspicious activity reports in Switzerland based on the Anti-Money Laundering Act (AMLA).

7 Version 2.1

The required data format when submitting reports is XML, which is an IT language that allows to structure complex sets of data, such as suspicious activity reports. When a report is being compiled manually via web form, the data is transferred via secure HTTPS internet connection to the DMZ (demilitarized zone). The DMZ is located outside the Swiss Federal IT Network and corresponds to a secure IT environment. In the DMZ the data is protected by the following data security measures: • firewall; • encrypted communication; • Two-factor user authentication measures2; • antivirus software; • data deletion mechanisms within DMZ If, for example, a reporting entity takes several days to finish its manual report compilation process and, while working during those days, saves the preliminary data set in the goAML form, this data set is stored in the DMZ and is therefore protected by the security measures mentioned above3. If the reporting entity decides to upload the data via automated XML file, this data is stored temporarily in the DMZ as well. Once the report has been completed and submitted to MROS, its content is then validated by the goAML web application to check whether it is consistent to the data structure defined by MROS. 2 The two-factor user authentication has not yet gone live at the time of publication of this document. However, this additional protection mechanism will be activated in the coming months. 3 Despite this high protection level, in order to minimize any potential data risk, it is suggested to finish the manual report compilation process and its submission to MROS in the shortest possible time frame.

8 Version 2.1

If the data validation checks are successful, the data set remains on the goAML web database server within the DMZ until it is permanently deleted by the mechanism illustrated in chapter “Automated deletion terms for reports and data within goAML Web”. A pull mechanism ensures that the data is uploaded timely into the Swiss Federal IT Network, which is protected by enhanced Swiss Federal IT security guidelines. In a scenario where the data validation checks are not successful, meaning the report submitted by the reporting entity is not complete or incorrect, this data set is automatically routed back by the goAML Web application to the reporting entity. The reporting entity then receives an automated e-mail by the system explaining the rejection reason(s), without any client data. This allows the reporting entity to correct the report and to resubmit it to MROS. Once the data is resubmitted, the process explained above restarts.

5 Field labelling syntax The following syntax applies throughout the goAML system and aims at further specifying the label of the corresponding field in goAML as follows: Syntax Explanation {word}* The asterisk after a word means that this particular field must be filled in

mandatorily, else the report will not be accepted for submission.

Inactive (n/a) All fields marked with “Inactive (n/a)” have been technically blocked by MROS preventing entering any data. If the reporting entity wishes to submit information for which there is no adequate place in goAML, please do contact MROS to agree on the most suitable solution.

The “+”-symbol indicates that a separate section is accessible. To do so, the user selects the “+”-sign and a new screen with additional fields opens up.

9 Version 2.1

6 The entrance portal of the goAML Web application The Web application by MROS can be accessed via following link: https://www.gewawebintg.fedpol.admin.ch

The entrance portal is available in English only. After choosing one of the following buttons, the user can select its preferred language (DE, FR, IT or EN) in the upcoming screen by selecting the abbreviation of the chosen language on the top right corner of the screen: • “Login” (to the system) • “Register a new Organisation” • “Register a new Person” Moreover, the entrance portal offers the possibility to access all goAML-related documents published by MROS, including the date of its last updating, and discloses the MROS contact information.

10 Version 2.1

7 Registration During the coming months, the security related to the access of goAML Web will be increased by introducing a two-factor user authentication functionality. With this new functionality, a code sent via SMS will be required in addition to the user name and password for a successful login to the system. Two-factor user authentication is not yet included in the following explanations and will only be introduced and explained in detail when it is established. Note: The first person who registers on behalf of one entity will automatically be assigned administrator rights on behalf of that entity and, for example, is also to approve any user access request submitted on behalf of the reporting entity it represents. The administrator role can be changed later, however, in the interest of efficiency, an appropriate person should be the first person to register on behalf of the entity.

7.1 Registering as a new Reporting Entity All reporting entities must first register with the FIU before they can fully access goAML Web. This section provides guidance on how reporting entities can first register as a user of goAML Web. To apply for a goAML user account perform the following steps: • Access the entrance portal for the goAML Web application as explained in chapter “The

entrance portal of the goAML Web application” and select “Register a new Organisation”:

• At the top select “Reporting Entity”, “Swiss Authority / Foreign FIU” or “Supervisory body”

depending on the type of institution attempting to register to goAML. In order to decide which category your institution belongs to, please use the definitions explained in the chapter “Glossary” of this document.

• Fill in the fields of the form with your institutions’ data. Selected fields are to be completed by using the drop down arrow and then selecting the most appropriate category:

11 Version 2.1

• Note: the field „BIC“ is only addressed to banks and is to be filled in by them mandatorily with the requested information. Non-banks are kindly asked to select “No” in the field “Financial sector?” above, which allows them to skip the field “BIC”.

• Field “Group Email”: Please note that e.g. notification emails informing that there is an unread item on the message board or notifications related to entity change requests will be sent to this group e-mail address registered for the “Organisation”. Considering these type of notifications are not meant to be for individuals, this field must contain a group e-mail address. Hence, this address is to be distinguished from the one being registered later on for the “user” (see chapter “Message Board” for additional details).

• The system also requires the entity’s phone number and physical address. It is

mandatory to provide this information. To access these fields click on . Please note

that after having added the first phone number or address the sign is still active, meaning the user can add multiple phone numbers or addresses:

Should the user want to delete a data set, please select the cross-sign on the right of the screen.

• Once all entities fields have been completed, the registering person will have to apply for access request (see next chapter).

12 Version 2.1

7.2 Registering the first Person during the Reporting Entity Registration Process

As already mentioned above, reporting entities should note that the first person who registers on behalf of that entity will automatically be assigned administrator rights on behalf of the entity. This administrator role can be changed later, however, in the interest of efficiency, an appropriate person be the first person to register on behalf of the entity. • Continue by scrolling down on the same screen illustrated in chapter 7.1 and fill in the

fields of the form as required:

• Field “User Name”: This information is required any time the user logs into goAML.

Please note that the User Name must be unique across all registered goAML users and cannot be equal to any previously registered user name.

• Field “Email”: Enter the personal work e-mail address. The acceptance notice of the registration will be sent to this address (see chapter “Message Board” for additional details).

• Field “Password”: A strong password containing between 8 and 20 characters and fulfilling the following conditions is to be set: It must contain at least one lower case letter [a-z], at least one upper case letter [A-Z], at least one digit [0-9] and at least one of the following special characters: "~`!@€#$%£ç^&*()-+={}.,[]\;:/? The password must be kept confidential and should be changed every 365 days.

• Fields “First Name” and “Last Name”: These fields are required by the system. However, if the registering person does not want to disclose his/her first and last name to MROS, he/she is authorized to use an alias name instead (e.g. first name = United ; last name = Bank).

• Section “Phones”: This is the place where the registering person must fill in his/her direct phone number. Once a suspicious activity report has been submitted, this phone number allows MROS to contact the relevant person in case of questions.

• MROS does not require any attachments when registering to the system. • Once all data is completed, enter the security code (captcha) displayed on the screen into

the field at the bottom of the form and select “Submit Request”:

13 Version 2.1

The captcha ensures that you are not a robot. If the entry is incorrect, the registrations process is aborted.

• The registering person will now receive an automated email notification with a reference number.

• As soon as the request has been approved by MROS, the registering person will receive another automated confirmation email from MROS.

7.3 Registering as a new Person for an existing Reporting Entity If a reporting entity is already registered in goAML and additional users working for this entity are to be registered, the procedure is as follows:

• Access the entrance portal for the goAML Web application as explained in chapter “The entrance portal of the goAML Web application” and select “Register a new Person”:

14 Version 2.1

• The registering screen is loaded:

• Field “Reporting Entity ID”: Enter the entity number assigned to your organization by

goAML at the time the entity was registered in the system according to chapters 7.1 and 7.2.

• Field “User Name”: This information is required any time the user logs into goAML. Please note that the User Name must be unique across all goAML users and cannot be equal to any previously registered user name.

• Field “Email”: The user enters the personal work e-mail address. • Fields “First Name” and “Last Name”: These fields are required by the system. However,

if the registering person does not want to disclose his/her first and last name to MROS, he/she is authorized to use an alias name instead (e.g. first name = United ; last name = Bank).

• Section “Phones”: This is the place where the registering person must fill in his/her direct phone number. Once a suspicious activity report has been submitted, this phone number allows MROS to contact the relevant person in case of questions.

• For an explanation of the remaining registration fields and steps, please refer to the explanations provided above.

Note: goAML administrators of a reporting entity are required to approve goAML access requests submitted by new users of the same reporting entity.

15 Version 2.1

8 Login and Logout 8.1 Logging in to goAML Web

To log into goAML Web, the user needs to be registered and have chosen a user name and password. He/she will not be able to use goAML Web until his access request has been approved as detailed in the previous sections. The access security to the goAML web application will be further enhanced in the coming months with two-factor user authentication. With this new functionality, a code sent via SMS will be required in addition to the user name and password for a successful login to the system. Two-factor user authentication is not yet included in the following explanations and will only be introduced and explained in detail when it is established. To access the goAML Web application of MROS enter the URL mentioned in the chapter “Registration”. For logging into the system perform the following steps: • Select “Login” at the top of the Web application starting screen: •

16 Version 2.1

• Enter User Name and password, then select “Log In”:

• After having successfully logged into the system, the goAML home page is displayed:

The menu bar of the goAML Web user interface allows the user to navigate to the various goAML Web functions. Hovering with the mouse pointer over a link in the menu bar displays the functions it contains. Note: The availability of menu functions depends on your access permissions.

17 Version 2.1

8.2 Logout from goAML Web To log off from goAML Web, click “Logout” in the menu bar:

• Your goAML session is terminated. Note: MROS strongly advices users to frequently save reports being drafted. In fact, you will

be logged out automatically after some time of inactivity. The following message warns you that in case of a log off all changes will be lost.

9 New Reports 9.1 Report compilation methods

Reporting entities can compile their reports either by • XML file upload or by • filling in manually the online reporting form. While the XML file upload functionality is suggested in instances where high volume reports are submitted to MROS regularly, the manual report compilation process is rather recommended for low volume reports. Currently the system does not provide any semi-automated report compilation functionality.

9.2 XML File Upload When using the XML file upload process, the suspicious activity report has to be produced in XML format outside goAML, hence the XML file needs to be created by the reporting entity within its internal IT environment. For this purpose, the reporting entity needs to build an XML interface connecting its internal systems to a new IT application: • On one hand, this new IT application would be used, e.g. by compliance departments, to

manually enter in a GUI (Graphical User Interface) information that is not stored in internal RE systems (e.g. descriptions of facts, reason of suspicion).

• On the other hand, after having specified the necessary criteria, the new IT application will automatically fetch information from RE-internal systems (e.g. the compliance officer will

18 Version 2.1

enter the client ID number and requires the new application to automatically fetch the clients / reported subjects first name, last name, birth date, address etc.).

The required information that this internal application must fetch from the internal systems in order to create a proper suspicious activity report, is defined within the XML scheme (required fields, whether they are mandatory or not, formats and data logics). MROS has published the requirements of the XML scheme in a document called “Standard XML Reporting – Instructions and Specifications for goAML”. This document can be accessed from the MROS internet site through the following link: https://www.fedpol.admin.ch/fedpol/en/home/kriminalitaet/geldwaescherei/meldung.html . Once the new in-house application has grabbed all required information from the internal systems of the reporting entity, this information must be converted by the application into an XML file. Structured in a technical language, this XML file now corresponds to the suspicious activity report that the reporting entity will submit to MROS. Detailed XML process description from the perspective of a compliance officer In the following example, a compliance officer aims at compiling a suspicious activity report by using the XML file upload functionality. For this purpose the officer performs the following steps:

a) The compliance officer opens the GUI (graphical user interface) developed internally within

the RE for the purpose of creating suspicious activity reports. b) A suspicious activity report consists of information stored in internal RE systems (e.g.

client-, account- and transaction-related data), but also of information that most probably is not available in internal systems (e.g. descriptions of facts, reason of suspicion etc.).

c) All information that is not automatically available from internal RE-systems is entered manually in the GUI by the compliance officer.

d) After having completed the manual information, in the GUI the compliance officer fills in all criteria that is required by the new functionality to automatically fetch e.g. client-, account- and transaction-related data from internal RE-systems. Specifically, the compliance officer enters e.g. the client nr. and the dates of the suspected time period in the GUI, so that the

19 Version 2.1

new interface can then fetch all client related details (e.g. first name, last name, address, birth date, nationality etc.) and all required account- and transaction-related information (e.g. account balances, transactions etc.) automatically.

e) Once the manual and automated information has been collected, the compliance officer reviews all information in the GUI. If changes are necessary, the relevant amendments are directly made via GUI.

f) After the quality review is completed, the compliance officer uses the GUI to produce an XML file containing all information previously collected.

g) In order to submit this XML file to MROS, the compliance officer then logs into goAML and uploads this XML file manually to goAML by executing the following steps:

1) Select “New Reports” and then “XML Upload” from the menu bar of goAML:

2) The respective screen to upload XML files and attachments is displayed.

3) In the section XML- or ZIP-file Upload, click “Browse” and select the XML file to be

uploaded. You can select either a plain XML file or a zipped file containing the XML file and attachments related to the report. Warning: Every report corresponds to 1 XML file incl. multiple attachments. In case the XML file is uploaded as a Zip file, this Zip file can only contain 1 XML file (but multiple attachments). However, multiple XML files may not be sent simultaneously. The maximum size of the XML file must not exceed 300 MB.

4) In case the report attachments are not part of the XML Zip file, these documents must be added in the separate section and attached before uploading the XML Zip file.

Warning: the maximum size of each attachment is 20 MB. The number of attachments is not limited.

5) Not before the user has selected both XML file and attachments, the file should be transmitted be pressing the button “Submission of complete report (XML file and attachments)”. The data is now being uploaded to the goAML database and undergoes several data validation checks (please refer to the chapter “Report status during the reporting process” below).

20 Version 2.1

6) By selecting “Drafted Reports” or “Submitted Reports” in the menu bar, the reporting entity can check for the report status at any point in time (see corresponding chapters below for further information).

Note: There is no automated upload of data from the internal systems of the reporting entity

to goAML directly. Hence, the automation is only between the internal systems of the reporting entity and the new application that has to be created in-house by the reporting entity.

9.3 The starting Web report screen

The aim of this chapter is to present the logic and connections of the various screens needed to compile a manual Web report, including an in-depth explanation of key fields that are not self-explanatory. For additional information related to all other fields not explained in this chapter, please refer to the appendix. The manual report compilation process is launched by selecting “New Reports” and then choosing “Web Reports” from the menu bar:

• The form for creating a new manual report is loaded and displayed:

This screen is used to enter basic data of the report. Specifically, it is used to collect information regarding the reporting entity and its contact person as well as information

21 Version 2.1

regarding the specific case to be reported (description of facts, reason for suspicion and steps taken by the reporting entity).

• Note 1: The name of the reporting entity is automatically filled in and cannot be changed. • Note 2: It is mandatory to fill in the “Reporting Entity Reference”. This is the reference

number attributed by the reporting entity to the underlying suspicious activity report. The reporting entity is free to decide on its structure. This number may be useful to quickly identify the relevant case.

• Note 3: If the contact person details displayed on the screen do not correspond to the details of the current user, this information can be replaced by the current user’s details, if necessary. This is done by clicking on the “refresh” icon on the right of the “contact person” title.

• Note 4: The two text fields «Description of facts» and «Reason for suspicion / what steps have been taken?» hold a maximum of 8’000 characters. In case the to be entered text exceeds this limit, please get in contact with MROS, in order to discuss what should be done in this specific case.

The above screen additionally contains the following key parts: 1. The field “Report with transaction?” 2. The section “Report type / suspected predicate offense(s) / factor(s) arousing

suspicion / type of attachments”

22 Version 2.1

9.3.1 The field “Report with transaction?” The question “Report with transaction?” is crucial for the forthcoming report compilation process, because depending on the value selected from the drop-down list, the required fields in the page are adjusted accordingly. For example: if from the drop-down the user selects “Yes”, the section at the bottom corresponds to “Transactions”; by choosing “No”, the same section corresponds to “Activity”. It is important to carefully read the tooltip linked to the field “Report with transaction?” which is shown by hoovering with the mouse pointer over the field name. If you use Microsoft Internet Explorer, the tooltip will disappear after a few seconds. Mozilla Firefox users will notice that the tooltip will stay as long as the mouse pointer is placed on the desired field. The tooltip explains the drop-down list as follows: • “If the business relationship subject to this report contains transactions, select “Yes”, else

select “No””.

• Note: It is important to notice, that this question is not about whether the reporting entity wishes to declare selected transactions, but rather if the client being reported has ever carried out any transaction on the concerned business relationship. The intent of MROS is that if a business relationship contains transactions and is subject of a report to MROS, then the report must contain all transactions executed during the suspicious time period. In other words: MROS will reject every report, if no transactions were included, although the concerned business relationship contains indeed at least one transaction.

• Remark: If the report contains more than 5’000 transactions, please follow the

procedures explained in chapter 10.2 «Reports with more than 5’000 Transactions». Must suspicious transactions only, or all transactions carried out in a specific time period be reported? There is no change to existing reporting practices. All transactions involving the reported subject(s) during the suspicious time period and allowing MROS to make its analysis, will have to be reported. Furthermore, in order to complete the suspicious activity report, MROS is at any time entitled to make use of its legal right to ask for additional information according to Art. 11a para. 1 AMLA. Transactions requested according to this article will also have to be transmitted to MROS via goAML.

• The text in the tooltip continues as follows: “If you are submitting additional information belonging to a report submitted to MROS in the past, select “AIF” (if no transactions are going to be reported) or “AIFT” (if transactions are going to be reported).”

• Note: If the reporting entity is asked by MROS to submit information as part of an

official request for information according to article 11a para. 1 and 3 of the Anti-Money Laundering Act (AMLA) or article 11a para. 2 and 3 of the AMLA, the reporting entity should select AIF or AIFT from the drop-down list (please see chapter Requests according to Article 11a para. 1 and 3 of the Money Laundering Act (AMLA) or Article 11a para. 2 and 3 AMLA”).

• The last part of the text in the tooltip specifies the following: “For any questions or spontaneous information disclosure, foreign FIUs select IRI (Incoming Request for Information – International), while domestic authorities select IRD (Incoming Request for Information – Domestic).”

23 Version 2.1

• These selections should be used for questions and spontaneous information

disclosures that foreign FIUs or Swiss authorities would like to address to MROS. They are not relevant for financial intermediaries and merchants.

9.3.2 The section “Report type / suspected predicate offense(s) / factor(s) arousing suspicion / type of attachments”

By selecting the next to the title of this section a new screen opens, which contains a selection list split in 4 categories (please note that the 2 columns of the displayed screen can be sorted by clicking on the column header):

The various categories can be differentiated by the code and its purpose as follows: Codes ending with M

The reporting entity selects the Swiss legal article it wishes to apply when transmitting its suspicious activity report to MROS. It is mandatory to choose one field from this list only.

Codes ending with V

This list shows all predicate offenses to money laundering defined by the Swiss law. If necessary, the reporting entity can select more than one suspected predicate offense. It is mandatory to choose at least one.

Codes ending with G

This category shows a list of factors arousing suspicion that prompted this report. If necessary, the reporting entity can select more than one factor. It is mandatory to choose at least one.

Codes ending with B

This category shows a list of attachments, which may be necessary for completing the documentation requirements. Please note that MROS will reject every report, if necessary attachments will be missing.

Notes: • If the reporting entity is not able to determine a predicate offense, “not classifiable” can be

selected.

24 Version 2.1

• If the number of reported transactions exceeds the limit of 5’000, it is mandatory to attach an account transaction statement to the report (please see chapter “Attachments to the report and Submission”.

• Every category contains the items “Art. 11a para. 1 and 3 AMLA” and “Art. 11a para. 2 and 3 AMLA”. One of these items is to be chosen whenever the reporting entity submits additional information to MROS based on Art. 11a AMLA, but has no predicate offense, factor arousing suspicion etc. to report since the reporting entity is not submitting a suspicious activity report.

• In addition to the above mentioned items “Art. 11a para. 1 and 3 AMLA” and “Art. 11a para. 2 and 3 AMLA”, in the category “factors arousing suspicion” the item “MROS-Info (Art. 11a para. 2 AMLA)” is listed. MROS-Info (Art. 11a para. 2 AMLA)” is to be chosen whenever the reporting entity replies to a request for additional information by submitting a suspicious activity report to MROS.

9.4 Manually created web reports incl. transaction 9.4.1 The recommended order by entering reported subjects, accounts or

entities Once the introducing Web mask has been filled, it has to be decided in what order the reported persons, entities and accounts are entered in the system. This concerns both reports with or without transactions. So as not to lose track of the wealth of information, MROS suggests when having to enter reported persons, accounts and entities, to start with the reported accounts.

The reason for this procedure is that the system logic of goAML guides the user in the downstream process to automatically enter persons and entities belonging to the reported account. This minimizes the risk that required information is not entered and the report is rejected by the system.

9.4.2 Transactions Please note that a report can contain a maximum of 5’000 transactions. This means, that due to system capacities, when exceeding 5’000 transactions, the remaining transactions have to be reported with a separate report (with a maximum of 5’000 each) of report type AIFT. We refer to chapter 10.2 «Reports with more than 5’000 Transactions». In such a case, it is wise to get in contact with MROS prior to the transmitting the information. In case you selected the dropdown option “Yes” in the field “Report with transaction?” in the lower part of the screen, the transaction knot will appear. In the bottom section of the report cover, the user can add transactions to the Web report.

25 Version 2.1

• Select to add transactions. The following screen appears:

• It is mandatory to assign a transaction number to every transaction. The reporting entity

should choose, whenever possible, to provide its in-house transaction number. by clicking on the icon displayed on the right of the field, an automated

transaction number is generated and assigned to that transaction. This automatic transaction generator can only be used in the so-called multiparty-dummy-transactions (see chapter MultiParty-Functionality)

• It is also possible to enter an additional in-house transaction number in the field “Internal Reference Number”,

• If in the field transaction type, the values “ATM” or Counter (Cash)” are selected, it is mandatory to insert in the field «location» at least city and country of where the transaction took place. If this information is not available to you, please insert the value «n/a».

• For every transaction, it is also mandatory to fill in the payment reason. The system requires to fill any transaction-specific comment provided by the transaction initiator into the field “Payment reason”. If the transaction initiator didn’t provide any transaction-specific comment, then “n/a” is to be entered into this field.

• Any other comment related to this particular transaction that the reporting entity may want to provide to MROS, can be registered into the field “Transaction comments”.

26 Version 2.1

From the screen “Transactions” the user can access the BiParty or MultiParty functionality as follows:

Important: • The name «Reported subject» contains all main subjects, which are part of the report

created by the reporting entity. In contrast, the terms «Counterparty» and «Involved Subjects» are subjects, which are within the report, counterparties in a transaction or additionally involved subjects outside of a transaction.

• BiParty transactions: MROS requires ALL transactions be registered as BiParty.

BiParty transactions correspond to commonly-known transactions, where two parties are involved (the sender and the receiver of funds). Hence, BiParty transactions are composed of a source (“From”) and destination (“To”). The source and destination may be either a reported person, account or entity, or an external counterparty.

• MultiParty transactions: MultiParty transactions, although defined as “transactions”

in the goAML system functionality, in reality do not correspond to transactions as per commonly-known terminology. The MultiParty functionality in goAML must only be used in case the reporting entity would like to report to MROS additional subjects involved in the underlying report (please see chapter “Data-entry of Trust structures in goAML). Due to this, it is not allowed to enter the reported subjects using the MultiParty-functionality (please see the graph above “Do not use”). The involved subjects can be either persons, accounts or entities, each with a specific role in the underlying report. They do not necessarily have to be directly involved in a transaction. Example: if the boss of a criminal organization is not directly involved in any transaction, this person would not be reported to MROS. Hence, considering the most-probably high relevance of this person in a specific case, the reporting entity could decide to register this person in goAML as additional involved subject by using the MultiParty functionality. In the MultiParty functionality it is crucial to register the “Role” that is assigned to every involved party.

27 Version 2.1

9.4.2.1 BiParty Transactions

In a BiParty transaction the sender and the receiver of the money are registered via separate screens (“From Party” vs “To Party”), where both screens contain the same fields to be filled in: • For account deposits, the source is a person and the destination is an account (from

PERSON to ACCOUNT). • For account withdrawals, the source is an account and the destination is a person (from

ACCOUNT to PERSON). • For money remittances, there are person to person transactions (from PERSON to

PERSON). • For account- / money transfers, there are account to account transactions (from

ACCOUNT to ACCOUNT). • For security transactions the user has to register the money flow related to the buy or sell

of the underlying security (using the transaction type category “Securities”). If the involvement of a particular security is an important reason for the suspect being reported (e.g. when the suspect is insider trading or in case of fraudulent securities delivery / extradition), then the reporting entity is not only required to report the related money flow, but also to clearly describe the role of the involved security as fact in the starting web

28 Version 2.1

report screen of the underlying report and to attach to the report a security transaction list/inventory in Excel format.

The system logics of goAML demand that, if available, the reporting entity always provides the account of the reported party and at least enters the contracting party and the beneficial owner to said account. For reporting entities that do not have money accounts (e.g. lawyers and notaries, casinos, currency exchange dealers, fiduciaries, merchants, money transmitters, self-regulatory organizations (SRO)) these rules do not apply. When entering a transaction, it is mandatory to enter a transaction type for both sides of the transaction, meaning from the point of view of the sender («From») and the receiver («To»). The same screen logic applies to both screens («From») and («To»).

The transaction type has to be the same for both sides of the transaction and also for the main transaction screen. In a BiParty transaction, at least one of the parties must be the reported subject of the reporting entity. The “Reported subject” registering screen is similar to the “Counterparty” screen, with the only difference that the “Reported subject” screen contains more mandatory fields to be filled in compared to the “Counterparty” screen. This is because reporting entities do not have the same amount of information for counterparties as they do for the reported subjects. For counterparties, reporting entities usually only have the information provided through transaction/payment systems. Based on international payment standards (e.g. SWIFT) the first and last name of counterparties involved in transactions do not have to be registered in separate fields. Hence, reporting entities may most probably not be in a position to distinguish between first and last names of counterparties involved in transactions, nor will they be able to automatically determine whether these counterparties are persons or entities. To overcome this deficiency, the following transaction registering logic must be followed in goAML:

29 Version 2.1

The above transaction scheme shows, that for counterparties reporting entities do not have to distinguish between person and entity, nor do they have to fill the first and last name in separate fields of goAML. Instead, the name of the subjects (these are probably the account

30 Version 2.1

holders), including their address if available, must all be registered mandatorily in the field “additional comments” displayed in the screen “account”. In the section “Transaction Currency” of the screens “From” and “To” the user must specify the currency details of the underlying transaction. This has to be done for any transaction, independently whether this is a CHF or foreign currency transaction.

• When clicking on the “+”-sign next to the description “Transaction Currency”, the opening

window allows to report the “Currency Code” and the “Amount” of the transaction in original currency (CHF or foreign currency depending on the transaction):

• Note: The field “Exchange Rate” is not in use, but can’t be deactivated. It is therefore

mandatory to always enter the number 1 into this field.

Once the user has filled in the fields of the “Transaction currency” screen, he/she can select the “Add” button below to return to the “From Party” screen. As a next step, the user now needs to, by selecting the appropriate option, indicate whether the relevant party is a person, an account or an entity.

31 Version 2.1

9.4.2.1.1 Person The details of the person are entered in the screen „Person”. As explained above, the number of mandatory fields varies between „Reported subject“ and “Counterparty”. The following screenshot has been taken from the “Person – reported subject” node:

32 Version 2.1

• If the person to be registered has already been entered in goAML during the current report compilation process, the user can click on the icon “Use an existing Person”. A new window listing the existing persons appears. This new window allows the user to select the desired person. Note: Reporting entities can only access the persons which were registered by themselves

during the current report compilation process. Important:

• It is important to notice that the person registering screen includes 3 fields asking for PEP-related information. When deciding whether a PEP is involved or not, the user must rely on Swiss law (Art. 2a AMLA) and not on internal classifications of client profiles. If the user selects “Yes”, the system forces the user to add additional information related to the PEP, namely the function/term of office and the country in which the PEP has carried out his function. The item “No” is to be selected also in all cases, where the PEP status is unknown.

• Input box «Address(es)»: There is the possibility to enter multiple addresses. For example it is possible to enter also old addresses or addresses of third parties who might handle the mail of the subject.

• Input box "Alias/Pseudonym": In the case of an alias person, the user should enter the name "MultiParty" in this field and then enter the details of the additional identity using the "MULTIPARTY Dummy" transaction in a separate goAML person mask (see chapter "MultiParty functionality"). In addition, the user must indicate to MROS in the field "Description of facts" of the web input mask what the presumably connected identities are called. This allows MROS analysts to link these two personal data sets during case processing in goAML, after receiving the message.

• At this point it is important to note that legal entities can also be entered in the "Person" input mask. However, this is only permitted if, when entering accounts (see next chapter), either several legal entities have a role in the corresponding account (in terms of the system, only one legal entity and only as a contracting party can be entered in the "Legal entity as contracting party" selection node provided for this purpose) or if, although only one legal entity appears in connection with the account, it does not have the role of a contracting party. • The following fields have therefore been renamed in the person mask to such an extent

that they can be used for both natural and legal subjects: • “Gender / Entity": If a natural person is entered, their gender should be selected. If

a legal person is entered, "Entity" should be selected. • “First name or see tooltip”: For natural persons the first name should be entered.

If a legal entity is entered, "n/a" should be entered in this field. • “Name": The surname should be entered for natural persons and the name for

legal persons. • “Date of birth / Reg. date": For natural persons the date of birth should be entered.

If a legal entity is entered, the date of the commercial register entry should be entered here.

• Node "Identification", field "ID-No.": For natural persons, the number of the passport or any other officially valid identity document should be entered. If a legal entity is entered, the commercial register number should be entered here (e.g. enter UID for Swiss companies).

• The other fields are not explained separately here because it is either clear that they apply only to natural persons (e.g. the fields "Social Security No.", "PEP" or "Occupation") or that their purpose is the same for natural and legal persons (e.g. the node "Address").

33 Version 2.1

9.4.2.1.2 Account The screen „Account“ is used to specify the involved account details by registering account-related information. At least one of the registered accounts must be an account of the reported subject. The “Reported subject” account screen is similar to the “Counterparty” screen, with the only difference that the “Reported subject” screen contains more mandatory fields to be filled in compared to the “Counterparty” screen. The following screenshot has been taken from the “Account – Reported subject” node:

• In the field “Account- / IBAN-Number” the user can choose whether he/she wants to report

the account or IBAN number. If both are available, MROS prefers receiving IBAN numbers. The field “IBAN” shown separately is mandatory for clients of the reporting entity, but as explained above is optional for non-clients. • The field “BIC” is dynamic, meaning that on the right you will see “BIC” or “n/a”

depending on the selection on the left. At this point, however, MROS only allows the entry of the BIC.

• It is important to report the account balances as follows: o If it is a foreign currency account, please report the foreign currency balance in the

field “Balance in foreign currency” by indicating its currency in the field “Account currency” to the left. In addition, please convert this balance in CHF and report the CHF

34 Version 2.1

balance in the field “Balance in CHF” below. The field “Balance in CHF” is accessed by the selecting “Yes” next to the field “Balance in CHF?”.

o If it is a CHF account, leave the field “Balance in foreign currency” blank and select “Yes” next to the field “Balance in CHF?” in order to report the CHF balance in the field “Balance in CHF” below. On its right please indicate the “Date of Balance” as well.

• As explained in chapter (“BiParty transactions”) above, in the “Account – counterparty” screen, the field “additional comments” is to be filled in mandatorily for registering the name of the counterparties (these are most probably the account holders), including their address if available.

The user is obliged to ensure that all subjects of a business relationship with the corresponding roles are registered in the nodes "Entity as contracting party" and/or "Contracting party / Beneficial owner(s) / Power of attorney/Signator(ies)". If, for example, a business relationship has each two contracting parties and beneficial owners, four subjects must be registered at this point. Otherwise, MROS will reject the submitted report. • node " Entity as contracting party " of screen "Account":

The node “Entity as contracting party” should be filled in whenever the contracting party of an account is a legal entity. Technically, however, only one legal entity can be entered here. This means that in all constellations where several legal entities play a role in the corresponding account or where only one legal entity is connected to the account but does not carry the role of the contracting party, the legal entities that cannot be entered at this point of the system must be entered using the node "Contracting party / Beneficial owner(s) / Power of attorney/Signator(ies)" of the screen template "Account".

Since the input mask for the node " Contracting party / Beneficial owner(s) / Power of attorney/Signator(ies)" in goAML corresponds to that of a natural person, it may occur that legal entities are also entered in the input mask for natural persons (see also previous chapter "Person"). This will mainly be the case where multiple reported entities have a role in a reported account or where an entity has a role in the account but not that of the contracting party. In such a case the entity has to be entered using the node "Contracting party / Beneficial owner(s) / Power of attorney/Signator(ies)". According to the explanations under 9.4.2.1, “Counterparties” do not have to be entered in the same manner as these fields are optional and do not have to be filled mandatorily.

• Node "Contracting Party / Beneficial owner / Power of Attorney/Signator(ies)" of

screen "Account": For the registration of natural persons or, according to the preceding explanations (see chapter "person"), entities that have a role in connection with the account in question, the "Account" screen contains the " Contracting party / Beneficial owner(s) / Power of attorney/Signator(ies)" node. By clicking on this node, the following screen appears in which the role of the various subjects in connection with the corresponding account must be selected as follows:

35 Version 2.1

• Field "Is contracting party?": If the subject is a natural person who is also a contracting party of the account, "Yes" must be selected. Otherwise, "No" must be selected. The selection "Yes" may only be selected once per account.

• The selectable roles are as follows: Contracting party Beneficial owner Control owner / Controller Power of attorney / Authorised signatory Contracting party & Beneficial owner Contracting party & Control owner / Controller Contracting party & Power of attorney / Authorised signatory Beneficial owner & Power of attorney / Authorised signatory Control owner / Controller& Power of attorney / Authorised signatory Contracting party r & Beneficial owner & Power of attorney / Authorised signatory Contracting party & Control owner / Controller & Power of attorney / Authorised

signatory Addressee Other (please explain) Sender of funds (only for counterparties) Receiver of funds (only for counterparties) Notice: • Since it is not technically possible to register several roles separately for each subject

(e.g. contracting party and beneficial owner), the dropdown list also provides selection options where several roles are listed together in the same selection.

• The selection "Other" must be explained in the input field "Comments", which is available in the subject mask appearing after clicking "Save".

Due to the explanations in chapter “BiParty Transactions”, the entry of non-reported subjects, i.e. counterparties, in the "entities as contracting party" node or in the "Contracting party & Control owner / Controller & Power of attorney / Authorised signatory" node of the "Account" screen mask is not mandatory.

9.4.2.1.3 Entity The screen „Entity“ is used whenever the subject to be reported is an organization. The following screenshot has been taken from the “Entity – Reported subject” node:

36 Version 2.1

• Input field "Address(es)": Several addresses can be entered. In this field for example older addresses of the subject as well as addresses of third parties can be registered, which receive the mail for the subject (in the field "Comments" explain accordingly).

9.4.2.2 MultiParty Functionality The MultiParty functionality in goAML may only be used for the registration of natural or legal persons as well as accounts in the following cases:

• For the registration of persons or accounts additionally involved in the report who are not directly involved in transactions as one of the counterparties (see explanations below).

• For the registration of subjects that occur in a Trust structure (e.g. Trustee, Settlor, Protector, Beneficiary). Please refer to the explanations in the chapter "The data-entry of Trust structures in goAML".

• For the entry of alias identities/pseudonyms. Please refer to the explanations in the chapter "Person".

The MultiParty functionality in goAML must only be used in case the reporting entity would like to report to MROS additional subjects or accounts involved in the underlying report. The involved subjects can be either persons, accounts or entities, each with a specific role in the underlying report. They must not be directly involved in a transaction. Example: If the boss of a criminal organization instructs a subordinate to execute a transaction from the subordinate's account, he is not directly involved in any transaction and would therefore not be reported to MROS. Hence, considering the most-probably high relevance of this person in specific cases, the reporting entity could decide to register this person in goAML as additional involved subject

37 Version 2.1

by using the MultiParty functionality. In the MultiParty functionality it is crucial to register the “Role” that is assigned to every involved party. MultiParty "transactions" are defined as "transactions" in the logic of goAML, although this does not correspond to the generally known terminology. In order to register the additional participants in goAML, a “dummy transaction” is entered as follows (the following instructions are to be followed from the input mask "Transaction", see also chapter 9.4.2.1):

Please note that for "MULTIPARTY Dummy" transactions the transaction amount must always be CHF 0.00, otherwise the transaction will be rejected by the system. Specifically, the additional involved parties can then be registered by using the following screen:

Note 1: For each involved party, the user is required to mandatorily select a “role” from the

drop-down menu. In addition, the user must give additional background information to

38 Version 2.1

the role in the field “Add. info to role”. This allows MROS to get a better picture of the importance of the person within the case.

Note 2: In the field “Transaction type” it is mandatory to choose “MULTIPARTY Dummy”. Note 3: Since with above screen no real transaction is registered, please ignore the section

“Transaction Currency". All other screens used when reporting MultiParty transactions are the same as already explained above under BiParty transaction.

39 Version 2.1

9.4.2.3 Goods and Services reported by merchants The screen „Good or Service“ is used to record and describe the traded goods or services that are the subject of suspicious activity reports submitted by merchants:

• In the “Estimated Value” field the merchant assigns a reasonable value to the item. In

contrast, in the field “Market value” the effective value for this item in the transaction is registered.

9.5 Manually created web reports without transactions If no transactions exist in a business relationship that is the subject of the report, the reporting entity will select the option "No" in the introductory web input mask under the question "Report incl. transaction?" (for more details, see chapter "The field "Report incl. transaction?"). The system therefore offers the node "Activity" in the introductory web input mask, which is used to enter the natural persons, accounts and entities involved in the report. Apart from a few special aspects, the entry logic is the same as that used for entering Web reports with transactions, as explained in detail in the chapter "Manually created Web reports with transactions". Since no money transfers occur in a report without transactions and therefore no transactions have to be recorded in goAML, it is necessary to assign a role to all natural persons, accounts and entities involved. This is done in the input mask "Report parties", which appears after clicking on the aforementioned node "Activity":

40 Version 2.1

The "Role (see tooltip)" input field is important for describing the role of the natural person, account or legal entity involved in the report, which is then entered by clicking on the corresponding selection on the same input screen. A tooltip is a text appearing over a field, which is displayed to the user when the mouse pointer is held over the corresponding goAML input field. The tooltip for the input field "Role (see tooltip)" is as follows: "Please insert the following numbers into this field (depending on the role of the subject): 0 = Contracting party 1 = Beneficial owner / control owner / controller 2 = Power of attorney / Authorised signatory(s) 3 = Business partner 4 = Buyer/seller 5 = Trust 6 = Settlor 7 = Trustee 8 = Protector 9 = Beneficiary 10 = Other (if this selection is selected, it must be explained in the field next to "Additional info to role". This selection must also be selected if the subject performs several roles at the same time.)" As this explanation already shows, this input field is where only the numbers 0-10 may be entered. Each number is assigned a role according to the explanation in the tooltip. The selection option "10" is especially highlighted, which must be entered if the desired role is not available in the tooltip. The desired, non-existent role must then be explained in the field next to "Additional info to role". The selection "10" must also be entered if the subject assumes several roles simultaneously, so that the various roles can then be explained in the "Additional info to role" field. A special procedure must also be followed for the selection options "0", "1" and "2": If the report contains an account to be reported, the user should enter either the number 0, 1 or 2 in this field and then select the "Account" selection node below. By selecting "Save", the user then gets to the "Account" input screen:

41 Version 2.1

This input mask is the same mask that has already been explained in the separate chapter "Account". This means that it works according to the same principle and allows you to enter all account details and all subjects belonging to the account in the same account mask, without having to return again and again to the previously explained mask "Involved subject". According to the explanations in the chapters "Person" and "Account", it is important to point out again that entities can also be entered in the selection node " Contracting party / Beneficial owner(s) / Power of attorney / Signator(ies) " of the entry screen "Account". However, this is only permitted if, when entering accounts, either several entities have a role in the corresponding account (in terms of the system, only one legal entity and only as a contracting party can be entered in the "entity as contracting party" selection node provided for this purpose) or if, although only one entity appears in connection with the account, it does not have the role of a contracting party.

9.6 Attachments to the Report and Submission After having provided case-related information, registered the involved persons, accounts and entities and having added all the transactions, the reporting entity has completed the manual Web report compilation process. The reporting entity can now save the report and preview it by selecting the button “Preview” at the bottom of the report cover screen:

42 Version 2.1

Note: As per explanations in the chapter above called “The starting Web report screen”, the section called “Report type / suspected predicate offense(s) / factor(s) arousing suspicion / type of attachments” lists four categories, of which one specifies all possible attachments that can be added to the report:

Accepted formats for attachments are: *.txt; *.tif; *.tiff; *.bmp; *.doc; *.docx; *.pdf; *.jpg; *.xls; *.xlsx; *.ppt; *.pptx; *.rtf, *.zip, *.xml, *.png. Note 1: Users are kindly requested to always apply the optical character recognition property

(OCR) when creating attachments in one of the above-mentioned formats. Note 2: For the sake of clarity, it makes sense to structure the names of the inserts logically

according to their contents. For example: "Max Müller - Account 123 - Form A.pdf", "Max Müller - Account 123 – passport copy.pdf", "Max Müller - Account 123 – loan approval.pdf", etc.

Note 3: Before submitting the report to MROS, the reporting entity should click on the “+”-

symbol highlighted above, scroll to the category ending with code “B” and ensure that all necessary attachments have been uploaded to the report. Not having attached all necessary documents (e.g. asset overview/account overview of all accounts and securities custody accounts belonging to the business relationship, including balance), to the report will lead to a report rejection by MROS.

Note 4: A report shall not contain more than 5'000 transactions per transmission. However,

this does not mean that the whole case reported to MROS may not contain more than 5,000 transactions. It merely means that, in the case of more than 5,000 transactions

43 Version 2.1

per report, a maximum of 5,000 may be transmitted with the first transmission process for reasons of system capacity and that the remaining transactions must then be transmitted to the MROS by means of several AIFT reports at a maximum of 5,000 transactions in accordance with the instructions in the chapter 10.2 «Reports with more than 5’000 Transactions». In such a case, it is advisable to contact the MROS in advance.

Note 5: If the number of transactions reported exceeds 5,000, it is mandatory to enclose the relevant common bank statement in pdf format with the report. At this point it should be noted that MROS generally welcomes the inclusion of a pdf account statement with all reports, regardless of the total number of reported transactions. This allows MROS analysts to carry out special analyses on the account balance series if required. On the other hand, the early inclusion of the pdf account statement by the reporting body also minimizes the likelihood that MROS will later have to request it via inquiries based on Article 11a para. 1 AMLA.

Once all attachments have been uploaded to the report, the reporting entity clicks the “Submit Report” button. The report now undergoes various report statuses as explained in the next chapter (Report status during the reporting process) Important: Please note that transmitted reports are automatically deleted by the system within a specified period of time (see chapter "Automated deletion terms for reports and data within goAML Web").

9.7 The data entry of Trust structures in goAML If "Trusts" are involved in reports to be entered, all subjects who act as bearers of roles belonging to the Trust (e.g. trust, settlor, trustee, protector, beneficiary) should be registered in goAML. This chapter explains the procedure to be followed. • In the case of a report with transactions

All subjects who have a role within a Trust structure (trust, settlor, trustee, protector, beneficiary), if they are directly involved in a transaction as recipients or senders of funds, must be recorded with their identity within the transactions as described in the chapter "BiParty Transactions". The role they play within the Trust structure must be performed in a downstream step via the MultiParty functionality. After selecting the "MultiParty" node, the following window appears within the transaction screen mask:

44 Version 2.1

o The "Role" field contains a selection list where you can select the desired Trust role (Trust, settlor, trustee, protector, beneficiary).

o In the "Transaction type" field, "MULTIPARTY Dummy" must be selected. o In the "Add. info to role" field, important additional information on the relevant

subject can be entered. If there is none, "n/a" should be entered. o Then, by clicking on "Involved subject", the subject involved in the Trust structure

can be registered in the system as a natural or legal person.

• - In the case of a report without transactions In the case of a report without transactions, all subjects with a role within a Trust structure (Trust, settlor, trustee, protector, beneficiary) are recorded in goAML as described in the chapter "Manually created web reports without transactions". Please note that the numbers "5" (for Trust), "6" (for settlor), "7" (for trustee), "8" (for protector) or "9" (for beneficiary) must be entered in the input field "Role (see tooltip)". Subsequently, the relevant subject must be registered below as a natural or legal person in goAML

It is important to note that if, for example, the subject is also directly connected to an account as a contracting party, all necessary account information must be entered in the "Account" node, including the details of the subject belonging to the Trust structure that was previously registered.

45 Version 2.1

9.8 Reports which are made by leasing institutions, casinos or providers of life insurance policies

In the case of reporting entities that do not maintain (bank) accounts, the question arises as to how they should record a report in goAML. This concerns in particular the following reporting entities: o Leasing institutes o Casinos o Life insurance providers These reporting entities must comply with the following procedure to record reports in goAML:

1. Since the suspicion in reports of these reporting entities does not usually relate to the transactions that took place with them (e.g. payment of the initial leasing amount or the monthly instalments), but rather to the suspicious origin of the funds used by the customer, a "report without transactions" should be recorded in goAML. In the introductory web input mask the field "Report with transaction?" should be answered with "No".

2. in the introductory web input mask, the reporting entity must then provide the

following details in the fields "Description of facts" and "Reason for suspicion / what steps have been taken?” a. Explain the incident and the suspicion in detail. For leasing institutes, for

example, this includes detailed information on the leasing object. b. The existing business relationship must be explained in detail (e.g.

description of the transaction, contract number, date of contract conclusion, contract duration, amount, terms and conditions).

c. If payments (e.g. monthly instalments) have been made via bank accounts, it must also be explained at which bank your customer maintains his account. This is necessary so that MROS can then, in a subsequent step, carry out additional clarifications with the relevant bank via a request based on Article 11a para. 2 and 3 AMLA.

3. Fill in all other fields of the web input mask including the node "Report type /

suspected predicate offense(s) / factor(s) arousing suspicion / type of attachments".

4. Click on the "Activity" node to enter details of the natural and legal persons

involved. The "Account" selection node does not need to be filled in if the reporting entity does not maintain any (bank) accounts.

5. In addition to the contract documents, copies of the identification documents,

etc., except in the case of casinos, the enclosures must also contain, for example, a payment overview of the customer where you can see the paid and unpaid invoices/payment flows of the customer, possibly including the value of the leased item and a net balance (asset - liability).

46 Version 2.1

9.9 Report status during the reporting process

As displayed in the above graph, any XML file or manual report submitted by the reporting entity undergoes two automated data validation checks within goAML: 1) The «XML scheme check» is a technical check on the report structure (completeness,

mandatory fields, data formats, data logics). 2) The «Business rejection rules» consist in business checks (e.g. if an account is active

and belongs to a reported subject, then an account balance must be submitted). Once both checks were successful, the report is reviewed by MROS personnel, finally deciding whether to accept or reject it. In any case the reporting entity is notified via goAML message board (see chapter “Message Board” below): • If the report is accepted, it is ready to be analyzed in-depth by MROS analysts. The

processing deadline according to art. 23 para. 5 AMLA starts only at this point in time. • If the report is rejected, the reporting entity receives an e-mail in the message board

indicating the reason for rejection.

Please ensure that rejected reports are reverted and rectified accordingly. This can be done by selecting the specific report that was “rejected”, and then selecting “revert”.

• Note: After the report has been reverted it will be found for correction under the menu

bar function “drafted reports”. The status of any drafted or submitted report can be checked in the corresponding report lists accessible by selecting “Drafted Reports” or “Submitted Reports” in the menu bar (see corresponding chapters below for further information).

47 Version 2.1

10 Additional-Information (AIF)- und Additional-Information-with-Transaction (AIFT) – Reports

Important: Information on natural and legal persons or accounts must be entered again

completely in goAML, even if they have previously been disclosed to MROS with the report already filed. However, this is only necessary if the system logic requires it for the additional information requested by MROS (e.g. the subjects occur in new transactions which have not yet been reported to MROS).

It is mandatory to follow the rule, that transactions which previously have been

transmitted to MROS, are not to be transmitted to MROS again by means of an AIFT report. A transaction may only be transmitted to MROS once!

The transmission process of a report may not contain more than 5,000 transactions. If

the number of transactions exceeds 5,000, the remaining data must be transmitted by means of several AIFT reports with a maximum of 5,000 transactions each. The corresponding account statement of all transactions in pdf form must then be enclosed as well. In such a case, it is advisable to contact MROS in advance. Please refer to chapter 10.2 «Reports with more than 5’000 Transactions».

A reporting entity may provide additional information regarding an already transmitted

report to MROS by using an AIFT or AIF. Please refer to chapter 10.3 «Reporting of additional Information».

10.1 Requests based on Article 11a para. 1 and 3 of the Money Laundering Act (AMLA) or Article 11a para. 2 and 3 AMLA

If the reporting entity receives a request for supplementary information from MROS pursuant to Article 11a para. 1 and 3 AMLA or 11a para. 2 and 3 AMLA, the requested information must also be transmitted to MROS via goAML. The procedure is as follows:

1. In the introductory web input mask, the reporting entity must select "AIF" (if the MROS does not request transaction information) or "AIFT" (if the MROS also requests transaction information) in the input field "Report with transaction?” This means that the input fields "Description of facts" and "Reason for suspicion /

what steps have been taken?” will not appear and therefore do not have to be filled in (again).

2. In the case of MROS requesting additional information based on Article 11a para. 1

and 3 AMLA from the reporting entity, that reporting entity has already submitted a report to MROS in advance. In this case, the reference number which MROS has assigned to the report already filed, must be entered mandatorily in the "Ref. no. MROS" input field.

3. In the introductory web input mask, the node "Report type / suspected predicate

offense(s) / factor(s) arousing suspicion / type of attachments" must be completed mandatorily. For the four categories ("Report type", "suspected predicate offense(s)", "factor(s) arousing suspicion", "type of attachments"), the selection options "Art. 11a para. 1 and 3 AMLA" or "Art. 11a para. 2 and 3 AMLA" should be selected in each

48 Version 2.1

case. The only exception is category G "factor(s) arousing suspicion", for which the item "MROS-Info (Art. 11a para. 2 and 3 AMLA)" is to be selected in the event of a prior request by MROS pursuant to Art. 11a para. 2 and 3 AMLA.

4. The information requested by MROS must now be completed, either in the

"transactions" node for an "AIFT report" or in the "activity" node for an "AIF report". The procedure to be followed is the same as described in the chapters "Manually created web reports with transactions" and "Manually created web reports without transactions".

10.2 Reports with more than 5’000 Transactions In case a report involves more than 5’000 transactions, a normal STR report must first be entered. This STR consists of the first 5’000 transactions. For all other transactions, AIFT reports with a maximum of 5’000 transactions each must be transmitted. The procedure is as follows:

1. Transmission of an STR-Report according to chapter 9 “New Reports” including the first 5’000 transactions. The corresponding account statement of all transactions in pdf form must be enclosed.

2. For each further 5’000 transactions the report type “AIFT” needs to be selected in the

input field "Report with transaction?” of the introductory web input mask. This means that the input fields "Description of facts" and "Reason for suspicion /

what steps have been taken?” will not appear and therefore do not have to be filled in (again).

3. It is mandatory to enter the value “5k” in the "Ref. no. MROS" input field.

4. In the introductory web input mask, the node "Report type / suspected predicate

offense(s) / factor(s) arousing suspicion / type of attachments" must be completed obligatorily. The same selection options must be selected as in the original STR-Report for the three categories ("Report type", "suspected predicate offense(s)", "factor(s) arousing suspicion").

5. The information requested by MROS must now be completed for an "AIFT report" in

the "transactions" node or for an "AIF report" in the "activity" node. The procedure to be followed is the same as described in the chapters "Manually created web reports with transactions" and "Manually created web reports without transactions".

10.3 Reporting of additional Information In case a reporting entity wants to transmit additional information regarding a report already transmitted to MROS, either an AIFT- or an AIF-report needs to be submitted. The procedure is as follows:

1. In the introductory web input mask, the notifying body must select "AIF" (if the MROS does not request transaction information) or "AIFT" (if the MROS also requests transaction information) in the input field "Report with transaction?”

49 Version 2.1

This means that the input fields "Description of facts" and "Reason for suspicion / what steps have been taken?” will not appear and therefore do not have to be filled in (again).

2. The reference number of the already transmitted report must be entered mandatorily in

the "Ref. no. MROS" input field.

3. In the introductory web input mask, the node "Report type / suspected predicate offense(s) / factor(s) arousing suspicion / type of attachments" must be completed obligatorily. The same selection options must be selected as in the original STR-Report for the three categories ("Report type", "suspected predicate offense(s)", "factor(s) arousing suspicion"). The fourth category "type of attachments" needs to be completed according to the actual attachments.

4. The information requested by MROS must now be filled in, either in the "transactions"

node for an "AIFT report" or in the "activity" node for an "AIF report". The procedure to be followed is the same as described in the chapters "Manually created web reports with transactions" and "Manually created web reports without transactions".

11 Drafted Reports The Drafted Reports menu allows a rapid access to the reports on which the user is still working on. It can be accessed from the main menu bar as follows:

The reporting entity is allowed to save reports in goAML Web as long as it is working on them (“work-in-progress”), e.g. in the event that further information is required before submitting it. However, please note that these reports are available in the drafted reports menu for editing and submitting only for a limited time period defined by MROS (see “Automated deletion terms for reports and data within goAML Web”).

11.1 Current Report The term “current report” refers to the unfinished goAML Web report the reporting entity was last working on. To get back to that report, select the menu button “Drafted Reports” and then “Current Report” from the menu bar. The report sheet is then loaded and displayed.

11.2 Not Submitted Web Reports While working with goAML Web, the reporting entity will probably have a number of unfinished reports. These reports can be viewed, resumed, or deleted. A list of “not submitted web reports” can be accessed by selecting “Drafted Reports” and then “Not Submitted Web Reports” from the menu bar. The following list is loaded and displayed:

50 Version 2.1

Note 1: Reports that have not yet been transmitted are automatically deleted by the system within a specified period of time (see chapter "Automatic Deletion terms for reports").

Note 2: The list is automatically set to show the reports created during the last month. To view reports over a different date range, perform the following steps:

1. Change the Start Date and End Date fields on the top.

2. Click the refresh button . Each of the columns has its own filter which can be used to refine the reports list.

• To proceed with an unfinished report, the user selects the button on the right

and continues to edit it as required.

• To delete an unfinished report, the user can select the button on the right. After a security check, the report is deleted.

• To preview an unfinished report, the user selects the button on the right. The user can now click the “Expand All” link on the top left corner to see the report in its entirety or click “Collapse All” link to see the abridged form:

51 Version 2.1

Clicking on the “Print” link triggers a printout of the report preview:

Note 1: If the report is rejected, the reporting entity receives an e-mail in the message board indicating the reason for rejection. The report can then be corrected from within the system section “drafted reports”. • Please ensure that rejected reports are reverted and remediated accordingly. This can

be done by selecting the specific report that was “rejected”, and then selecting “revert”. Only after the report has been reverted, it will be found for correction under the menu bar function “drafted reports”.

Note 2: Reports that have not yet been transmitted are automatically deleted by the system within a specified period of time (see chapter "Automated Deletion terms for reports and data within goAML Web").

52 Version 2.1

12 Submitted Reports Submitted reports can be viewed in goAML Web in two separate lists containing “uploaded XML reports” and “manually created Web reports”. To view these lists select “Submitted Reports” and then “XML Reports” or “Web Reports” from the menu bar:

Note: These reports are available in the submitted reports menu for viewing and saving only for a limited time period defined by MROS (see chapter "Automated Deletion terms for reports and data within goAML Web"). Hence, for record keeping purposes the reporting entity may want to ensure that these reports are saved onto its own internal IT environment within a short time period after submission. To download a report in XML format to the local machine, the “Save” button must be selected. After a security check, the report is downloaded.

• To view the reason for a failed upload or submission, the failure link (“Failed Validation”) in the “status” column can be selected. An error message detailing the reason for failure is displayed:

• Reports can be printed by first selecting the view icon once a report has been submitted.

The submitted report will then be displayed. To print the report click on the print icon on the top of the page.

53 Version 2.1

13 Automated deletion terms for reports and data within goAML Web

For security and storage capacity reasons, reports and message board notifications, including attachments, are automatically deleted by the system within a certain period of time. Reporting entities are therefore recommended to make copies of all reports, messages and attachments and to store them in their own system. The automatic deletion process takes place in the system according to the following criteria: - Reports transmitted to MROS, whether accepted or rejected by MROS/the system, are automatically deleted by the system 7 days after their transmission.

• If the report was rejected by MROS and subsequently "restored" by the user, the report for post-processing is located in the "Drafts" folder (see chapter "Drafts") of the system. These reports are automatically deleted by the system 7 days after "recovery" if they have not been sent to the MROS beforehand.

• Newly created reports that have not yet been sent to MROS and therefore in the draft status, are automatically deleted by the system 14 days after creation.

• Notifications within the message board are automatically deleted by the system 30 days after they are received or sent.

So that the reporting entity can take the necessary measures in good time, its goAML administrator is informed of future deletions 7 days before each deletion by means of an automated goAML message.

14 Message Board The “Message Board” can be accessed from the main menu bar. All communication within goAML between MROS and the reporting entities/stakeholders will be conducted through the message board function available in the application. The goAML message board is therefore the internal means of communication between MROS and the goAML users. Since the message board does not correspond to an e-mail functionality, the various goAML users cannot interact with each other from within goAML. Any communication done via message board is only possible with MROS. The advantage of an internal communication channel is that the communicating parties can interact from within the system. Reporting entities and stakeholders are notified immediately and automatically if their reports are accepted or rejected. All information exchanged via message board is securely stored in the DMZ (see chapter goAML IT Architecture). Notification emails informing that there is an unread item on the message board or notifications related to entity change requests will be sent to the e-mail address registered for the “Organization” (reporting entity). Individual users are not notified on the e-mail address registered for the “user”. This is because the message board is a central message repository where all users of the same reporting entity see the same messages, if they are allowed to access the message board. Please note, that all notification emails will come from the e-mail address goamlVALIDATION@fedpol.admin.ch (do not reply to this address as it is not maintained by MROS!). Note: • The size to store e-mails and attachments in the message board is limited to a maximum

established by MROS.

54 Version 2.1

• Messages within the message board are automatically deleted by the system 30 days after they have been received or sent.

• Therefore reporting entities may want to ensure that they make copies of all messages and attachments and save them on their internal systems for record keeping purposes.

• For practical reasons, the message board is organized like an email client, although it does not consist in an email functionality.

• All users of the same reporting entity or stakeholder see the same messages. There are no individual message boxes.

Any message that has been written, sent, or archived can be searched using the feature, if they have not previously been deleted by the automatic deletion mechanism:

Enter the text you want to search for in the “Search Text” field and click “Search”. If you want to see only messages within a certain date range, enter the values in the “Start Date” and “End Date” boxes.

55 Version 2.1

15 My goAML The “My goAML section”, which is accessible from the main menu bar, is the personal maintenance section for the individual goAML Web users. Here they can change their password and modify personal/reporting entity data. Important notice: Each reporting entity is responsible for the management of its user base. This includes adding new users to goAML Web and removing users that no longer require access to it. Each user is responsible for ensuring that his/her password is changed at least every 365 days and adequately protected from any misuse.

15.1 Change password To change the goAML Web password perform the following steps: • In the main menu bar select “My goAML”:

• Select “Change Password”. • Enter the existing password, then the new password, confirm the new password and select

“Change Password”. A password between 8 and 20 characters must be chosen, which fulfils the following conditions: The password must contain at least 1 lower case letter [a-z] and at least 1 upper case letter [A-Z] as well as at least 1 number [0-9] and at least 1 special character as follows: "~`!@€#$%£ç^&*()-+={}.,[]\;:/?. The password must be kept confidential and changed every 365 days.

Note: If your password has been reset by a goAML administrator, changing the password is the only action you can do right after your next login. After changing the system password to your own one, your full functionality will be available again.

15.2 Forgotten password instructions • If you have forgotten your password go to the ‘Login’ page and click the “Forgot Password”

button:

56 Version 2.1

• Enter your username and email address. • An email will be sent to that address with a reset link. • That link will take you to a page where you must enter username, email address and a new

password, along with the confirmation of that password. • Click “Change Password” to confirm the new password.

15.3 Change My User / My Organization Details When something in the user or reporting entity data changes (e.g. they have a new phone number or change the office address), the goAML Web user/organization details must be updated accordingly. • In the main menu bar select “My goAML”:

• Select “My User Details” / “My Org Details”. • Make any amendments/additions as necessary • Select “Submit Request”. The changes must first be approved and are then stored in the

goAML Web database. Note: goAML administrators of the reporting entities can edit only the users of their own

reporting entity. They are obliged to approve new goAML access requests submitted by new users of their reporting entity and to cancel existing access rights, which are not needed any more. This is done by the administrator selecting the "Finalize" button from the possible selection options that appear in the request approval screen.

16 Administration For goAML Web users with administration rights, an additional admin menu is available in the menu bar:

With these functionalities the user gets access to the role and user management features.

57 Version 2.1

Note: If users see the menu, but not all entries mentioned above, they do not have permission for all of them.

16.1 Role Management “Roles” in goAML are permission groups. To fulfil certain tasks, users need a certain set of access permissions. For instance, a controller needs wide access, but not to the maintenance modules, as this is intended for administrators only. Permission groups (for “controllers”, “administrators” etc.) are set up in the “Role Management” area. Every role defines specific permissions for goAML Web. These roles are assigned to user accounts and thus define the users’ permissions. To create a new role, select the reporting entity from the “Roles for Specific Org or User” tab and select “Add a new role for this entity”:

After the role has been created, it can be selected in the Roles Available list and the permissions associated with the role can be checked/unchecked, if the user does indeed have the permission to perform this action. Select “Save”.

Note: Two role types are available for every reporting entity: 1. User access role

58 Version 2.1

2. Role for the reporting entity’s administrators The permissions for these roles are part of the goAML Web setup and thus cannot be modified. However, administrators can create their own roles with tailor-made access permissions at any time. • To edit/delete a role, select the role by clicking its role name, then add permissions by

activating, or remove them by deactivating, the respective checkboxes, respectively click on “Delete” to remove the role. After a security check, the role is deleted and removed from all users having it.

Note: When the deleted role is the last role a user had, the user cannot login to goAML Web until a new role is assigned to him/her.

16.2 User-Role Management The User-Role Management page allows administrators to manage the roles that are mapped to each of the users in an entity. The roles and the permissions associated with the users can be configured as follows: • Select “Admin” and then “User-Role Management” from the menu bar. The User

Management page is displayed.

• Selecting the user in the left-most column shows the associated roles and permissions

configured with the selected user.

59 Version 2.1

• Roles and permissions of the selected user can be updated by activating/deactivating some of the checkboxes in the roles and permissions preview columns, if the user does indeed have the permission to perform this action.

• After making these changes, click “Save” to save the changes. A message appears indicating that the user’s roles and permissions have been updated successfully.

Note: goAML administrators of the reporting entities can edit only the users of their own

reporting entity. They are obliged to approve new goAML access requests submitted by new users of their reporting entity and to cancel existing access rights, which are not needed any more. This is done by the administrator selecting the "Finalize" button from the possible selection options that appear in the request approval screen.

16.3 User Request Management This page allows the administrator to view and manage all the user change requests. The grid is initialized to show the user change requests4 created in the last month; if another period is to be displayed, enter the “Start Date” and “End Date” at the top of the grid and click the refresh button next to it.

• Click to create a new change request for this user. • Click to view the details of this user request. Note: goAML administrators are obliged to approve new goAML access requests

submitted by new users of their reporting entity and to cancel existing access rights, which are not needed any more. This is done by the administrator selecting the "Finalize" button from the possible selection options that appear in the request approval screen.

4 “Change requests” in the context of goAML is referred to any alteration of data or permission concerning a particular user or organization (e.g. to update the address).

60 Version 2.1

16.4 Overview Users The “Overview User” management grid allows to view and manage all users registered for a particular reporting entity. When opened, the grid shows the users that were registered during the last month; if another period is to be displayed, enter the “Start Date” and “End Date” at the top of the grid and click the refresh button next to it.

• Click to create a new change request for this user • Click to view the details of this user • Click to disable this user • Click to reset the password for this user

16.5 Org Request Management

This functionality allows to view and manage all the organization’s change requests. The grid is initialized to show the organization change requests created in the last month; if another period is to be displayed, enter the “Start Date” and “End Date” at the top of the grid and click the refresh button next to it.

• Click to view the change requests’ details.

16.6 Overview Organizations The “Overview Organizations” grid allows the user to view the registration state of its reporting entity and to manage the reporting entity delegation functionality.

61 Version 2.1

• Click to view the details of this reporting entity At the bottom left corner of the above screen, 2 functionalities related to “Delegating Organizations” are visible. A reporting entity can decide to delegate its reporting function to another reporting entity. • Click to make a change request to MROS for appointing a

selected reporting entity to be delegated. • Click to register a new delegating reporting entity in goAML.

16.7 Statistics This page allows to run pre-configured statistics: • To set the time range required for a particular statistic, select “Filter” on the top left corner

of the screen and adjust the “Start Date” and “End Date” accordingly:

• Select one of the pre-configured statistics from the list under “Report” (top left corner of the screen) and preview its result on the right as grid, pivot or chart (depending on the type of statistic). The statistic result can be exported to Excel and PDF.

62 Version 2.1

17 Application Support and System Maintenance Should the reporting entity encounter an issue with the goAML application, please notify MROS at your earliest convenience. If the system is available: Please use the Message Board for this communication. Else, please contact MROS at goaml.info@fedpol.admin.ch or call +41 58 463 40 40 (please select menu item 1 for “goAML”). System maintenance and updates will be applied to the goAML application on a regular basis. During these periods, it may be necessary to take the application offline. Correspondence detailing this down time will be provided in advance via goAML starting page.

18 Glossary The following list explains terms and abbreviations used in conjunction with the goAML Web application: Term Explanation AIF / AIFT Additional Information File / Additional Information File with

Transactions Change request Any request to alter data or permissions concerning a particular user or

organization (e.g. to update the address). DMZ Demilitarized zone (located in Switzerland), being a secure IT

environment protecting from unwanted access to the servers located in it

Reported subject / Counterparty / Involved subject

The term "Reported subject" includes all the main subjects who are object of the report issued by the reporting entity. On the other hand, the terms "Counterparty" or "Involved subject" refer to all subjects who appear as counterparties of the reported subject in the report of suspected transactions or as additional participants in the report.

63 Version 2.1

goAML Intelligence analysis system developed by United Nations Office on Drugs and Crime intended to be used by the FIU (Financial Intelligence Unit) to combat money laundering

GUI Graphical User Interface Reporting Entity (RE)

Reporting Entity - Financial intermediary and/or merchant authorized to submit suspicious activity reports in Switzerland based on the Anti-Money Laundering Act (AMLA) and/or the Swiss Criminal Code

Stakeholder Any user registered in goAML Web and being authorized to submit suspicious activity reports to MROS based on the Anti-Money Laundering Act (AMLA) and/or the Swiss Criminal Code.

Supervisory Body

This term includes supervisory bodies active in Switzerland, namely the Swiss Financial Market Supervisory Authority (FINMA), the Federal Gaming Board (FGB) and all self-regulatory organizations (SRO)

Tooltip Quick info window that is displayed when a user hovers the mouse pointer over a field

UNODC United Nations Office on Drugs and Crime, which is the developer of goAML

64 Version 2.1

19 Appendix The following screenshots and tables aim at providing an overview of the various screens available in goAML Web and at providing the translations in German, French, Italian and English of all field names. 19.1 Screen „Report Type“

a) Field Names English Deutsch Français Italiano Reporting Entity Meldende Stelle Entité déclarante Segnalante Reporting Entity Branch

Filiale der meldenden Stelle

Filiale de l’entité déclarante

Filiale del segnalante

Report with transaction?

Meldung inkl. Transaktion?

Communication avec transaction?

Comunicazione con transazione?

Reporting Entity Reference

Referenz Nr. meldende Stelle

Numéro de référence de l’entité déclarante

Numero di riferimento del segnalante

Submission Date Übermittlungsdatum Date de transmission Data di trasmissione Ref. No. MROS Ref. Nr. MROS N°. de réf. MROS N. di rif. MROS Description of facts Darstellung des

Sachverhalts Exposé des faits Descrizione dei fatti

Reason for suspicion / What steps have been taken?

Grund für Verdacht / Was haben Sie bereits unternommen?

Raisons du soupçon / Quelles mesures avez-vous déjà prises?

Motivi del sospetto / Quali misure sono già state adottate?

65 Version 2.1

b) Headers of screen section English Deutsch Français Italiano Contact person (reporting entity)

Ansprechpartner (Meldende Stelle)

Interlocuteur (Entité déclarante)

Interlocutore (Segnalante)

Address of reporting entity

Anschrift der meldenden Stelle

Adresse de l’entité déclarante

Indirizzo del segnalante

Report type / suspected predicate offense(s) / factor(s) arousing suspicion / type of attachments

Meldeart / Mutmassliche Vortat / Verdachtsbegründende Elemente / Art der Beilagen

Type de communication / infraction préalable soupçonnée / éléments à l’origine du soupçon / type d’annexes

Tipo di comunicazione / reato preliminare sospettato / elementi all’origine del sospetto / tipo di allegati

Transactions Transaktion(en) Transaction(s) Transazione/i Activity Aktivität Activité Attività

c) Buttons English Deutsch Français Italiano Submit Report Meldung übermitteln Transmettre la

communication Trasmettere la comunicazione

Save Report Meldung speichern Enregistrer la communication

Salvare la comunicazione

Show Attachments Beilagen zeigen Montrer les annexes Mostrare gli allegati 19.2 Screen „Address“

a) Field Names English Deutsch Français Italiano Type Art Type Tipo Address Adresse Adresse Indirizzo Inactive (n.a.) Inaktiv (n.a.) Inactif (n.a.) Inattivo (n.a.) City Ort Lieu Luogo Zip PLZ NPA NPA Country Land Pays Paese Canton Kanton Canton Cantone Comments Bemerkungen Remarques Osservazioni

66 Version 2.1

b) Buttons English Deutsch Français Italiano Use an existing address

Bereits erfasste Adresse verwenden

Utiliser adresse déjà existante

Utilizzare indirizzo già esistente

Save Speichern Enregistrer Salvare Cancel Abbrechen Annuler Annullare

19.3 Screen „Indicators“

a) Field Names English Deutsch Français Italiano Code Code Code Codice Report type / suspected predicate offense(s) / factor(s) arousing suspicion / type of attachments

Meldeart / Mutmassliche Vortat / Verdachtsbegründende Elemente / Art der Beilagen

Type de communication / infraction(s) préalable(s) soupçonnée(s) / éléments à l’origine du soupçon / type d’annexes

Tipo di comunicazione / reato/i preliminare/i sospettato/i / elementi all’origine del sospetto / tipo di allegati

b) Buttons

English Deutsch Français Italiano Close Schliessen Fermer Chiudere

67 Version 2.1

19.4 Screen „Transaction “

a) Field Names English Deutsch Français Italiano Transaction number Transaktions-

nummer Numéro de la transaction

Numero della transazione

Internal reference number

Interne Referenznummer

Numéro de référence interne

Numero di riferimento interno

Transaction type Transaktionsart Type de transaction Tipo di transazione If trans-type „other“, then description

Wenn Transaktionsart “andere”, dann Beschreibung

Si type de transaction “autre”, alors description

Se tipo di transazione “altro”, allora descrizione

Amount in CHF Betrag in CHF Montant en CHF Importo in CHF Date of transaction Datum der

Transaktion Date de la transaction

Data della transazione

Inactive (n.a.) Inaktiv (n.a.) Inactif (n.a.) Inattivo (n.a.) Inactive (n.a.) Inaktiv (n.a.) Inactif (n.a.) Inattivo (n.a.) Inactive (n.a.) Inaktiv (n.a.) Inactif (n.a.) Inattivo (n.a.) Inactive (n.a.) Inaktiv (n.a.) Inactif (n.a.) Inattivo (n.a.) Location (see tooltip) Ort (siehe Tooltip) Lieu (voir infobulle) Luogo (vedi

descrizione commando)

Payment reason Zahlungszweck Motif du paiement Motivo del pagamento

68 Version 2.1

English Deutsch Français Italiano Transaction comments

Kommentar zur Transaktion

Remarque au sujet de la transaction

Osservazione in merito alla transazione

b) Headers of screen section in case of BiParty transactions

English Deutsch Français Italiano From Von De Da To An En faveur de In favore di Goods and services Güter und

Dienstleistungen Biens et services Beni e servizi

69 Version 2.1

English Deutsch Français Italiano Transaction type Transaktionsart Type de transaction Tipo di transazione Additional information

Zusatzinformationen

Informations supplémentaires

Informazioni supplementari

Country Land Pays Paese Transaction currency

Transaktionswährung

Monnaie de la transaction

Valuta della transazione

Inactive (n.a.) Inaktiv (n.a.) Inactif (n.a.) Inattivo (n.a.) Party type Beteiligter Sujet impliqué Soggetto coinvolto Person Natürliche Person Personne physique Persona fisica Account Konto Compte Conto Entity Juristische Person Personne morale Persona giuridica

70 Version 2.1

c) Headers of screen section in case of MultiParty transactions and involved parties

English Deutsch Français Italiano MultiParty Multi-Party MultiParty MultiParty Involved Parties Beteiligte Sujets impliqués Soggetti coinvolti

71 Version 2.1

English Deutsch Français Italiano Role Rolle Rôle Ruolo Transaction type Transaktionsart Type de transaction Tipo di transazione Country Land Pays Paese Inactive (n.a.) Inaktiv (n.a.) Inactif (n.a.) Inattivo (n.a.) Add. info to trans. type

Zus.infos zu Trans.art

Infos suppl. type trans.

Info suppl. tipo di trans.

Add. info to role Zusatzinfos zur Rolle

Infos suppl. sur rôle Info suppl. sul ruolo

Transaction currency

Transaktionswährung

Monnaie de la transaction

Valuta della transazione

Party is Beteiligter Sujet impliqué Soggetto coinvolto Do not use Nicht benutzen Ne pas sélectionner Non selezionare Involved subject Involviertes Subjekt Sujet impliqué Soggetto coinvolto

19.5 Screen „Good or Service”

a) Field Names English Deutsch Français Italiano Item type Art Type Tipo Item maker Hersteller Producteur Produttore Description Beschreibung Description Descrizione Name of seller Name d. Verkäufers Nom du vendeur Nome venditore

72 Version 2.1

English Deutsch Français Italiano Name of buyer Name d. Käufers Nom de l’acquéreur Nome acquirente Estimated value Geschätzter Wert Valeur estimée Valore stimato Status code Status État Stato Market value Marktwert Valeur de marché Valore di mercato Currency code Währungscode Code de la monnaie Codice della valuta Size Grösse Mesure Misura Size UOM Masseinheit Unité de mesure Unità di misura Registration Date Zulassungsdatum Date

d‘immatriculation Data d‘immatricolazione

Registration Number

Zulassungsnummer Numéro d‘immatriculation

Numero d‘immatricolazione

Identification Number

Identifikationsnummer

Numéro d‘identification

Numero d‘identificazione

Comments according to Art. 19 OMLTV

Informationen gemäss Art. 19 GwV

Informations selon l’art. 19 OBA

Informazioni secondo l’art. 19 ORD

Additional comments

Zusatzinformationen Remarques supplémentaires

Osservazioni supplementari

b) Headers of screen section

English Deutsch Français Italiano Address Adresse Adresse Indirizzo

c) Buttons

English Deutsch Français Italiano Save Speichern Enregistrer Salvare Cancel Abbrechen Annuler Annullare

19.6 Screen „Transaction Currency “

a) Field Names English Deutsch Français Italiano Currency code Währungscode Code de la monnaie Codice della valuta Amount Betrag Montant Importo Exchange Rate (see tooltip)

Wechselkurs (siehe Tooltip)

Cours de change (voir infobulle)

Tasso di cambio (vedi descr. comando)

73 Version 2.1

b) Buttons English Deutsch Français Italiano Add Hinzufügen Ajouter Aggiungere Cancel Abbrechen Annuler Annullare

19.7 Screen „Person“

74 Version 2.1

a) Field Names English Deutsch Français Italiano Title Titel Titre Titolo Gender / Entity Geschlecht /

Juristische Person Sexe / Personne morale

Sesso / Persona giuridica

First name / see tooltip

Vorname bzw. siehe Tooltip

Prénom / voir infobulle

Nome / vedi descr. comando

Last name / Name Entity

Name Nom Cognome / Nome pers. giurid.

Middle name Zweiter Vorname Deuxième Prénom Secondo Nome Inactive (n.a.) Inaktiv (n.a.) Inactif (n.a.) Inattivo (n.a.) Birth date / Date of registration

Geb.datum / Reg.datum

Date de naissance / Date d'enregistrement

Data di nascita / Data di registrazione

Birth place / Place of origin

Geburtsort / Heimatort

Lieu de naissance / d’origine

Luogo di nascita / di attinenza

Inactive (n.a.) Inaktiv (n.a.) Inactif (n.a.) Inattivo (n.a.) Alias Alias / Pseudonym Alias / pseudonyme Alias / pseudonimo SSN Sozialvers.-Nr. Num. d'assurance

sociale No d'assicurazione sociale

Inactive (n.a.) Inaktiv (n.a.) Inactif (n.a.) Inattivo (n.a.) Nationality 1 1. Nationalität 1ère nationalité 1a nazionalità Nationality 2 2. Nationalität 2ème nationalité 2a nazionalità Nationality 3 3. Nationalität 3ème nationalité 3a nazionalità Inactive (n.a.) Inaktiv (n.a.) Inactif (n.a.) Inattivo (n.a.) Occupation Beruf Profession Professione Employer Arbeitgeber Employeur Datore di lavoro Inactive (n.a.) Inaktiv (n.a.) Inactif (n.a.) Inattivo (n.a.) Inactive (n.a.) Inaktiv (n.a.) Inactif (n.a.) Inattivo (n.a.) Source of wealth Herkunft der

Vermögenswerte Origine des valeurs patrimoniales

Origine dei valori patrimoniali

PEP? PEP? PEP? PEP? Function / term of office

Ausgeübtes Amt / Amtsperiode

Mandat exercé / durée du mandat

Funzione / periodo di carica

In what country? In welchem Land? Dans quel pays? In quale paese? Deceased? Verstorben? Décédé(e)? Deceduto/a? Date of death Todesdatum Date du décès Data del decesso Comments Bemerkungen Remarques Osservazioni

b) Headers of screen section

English Deutsch Français Italiano Phones Telefonnummer(n) Numéro(s) de

téléphone Numero/i di telefono

Addresses Adresse(n) Adresse(s) Indirizzo/i Identification Identifikation Identification Identificazione Emails E-Mail Adressen Adresses e-mail Indirizzi e-mail Employer address Adresse des

Arbeitgebers Adresse de l‘employeur

Indirizzo del datore di lavoro

Employer Phone Telefonnummer des Arbeitgebers

Numéro de téléphone de l‘employeur

Numero di telefono del datore di lavoro

75 Version 2.1

c) Buttons

English Deutsch Français Italiano No Nein Non No Yes Ja Oui Sì Use an existing person

Bereits erfasste natürliche Person verwenden

Utiliser personne physique déjà existante

Utilizzare persona fisica già esistente

Save Speichern Enregistrer Salvare Cancel Abbrechen Annuler Annullare

19.8 Screen „Phone“

a) Field Names English Deutsch Français Italiano Contact type Kontaktart Type de contact Tipo di contatto Comm. Type Kommunikationsart Type de

communication Tipo di comunicazione

Country prefix Ländervorwahl Indicatif international Prefisso internazionale

Number Telefonnummer Numéro de téléphone

Numero di telefono

Inactive (n.a.) Inaktiv (n.a.) Inactif (n.a.) Inattivo (n.a.) Comments Bemerkungen Remarques Osservazioni

b) Buttons

English Deutsch Français Italiano Save Speichern Enregistrer Salvare Cancel Abbrechen Annuler Annullare

76 Version 2.1

19.9 Screen „Identification“

a) Field Names English Deutsch Français Italiano Type Art Type Tipo ID number ID-Nr. Numéro

d'identification Numero d'identificazione

Issue date Ausstellungsdatum Date d’émission Data di rilascio Expiry Date Gültig bis Date d‘expiration Data di scadenza Issued by Ausstellende

Behörde Autorité de l‘émission

Autorità del rilascio

Issue Country Ausstellendes Land Pays de l‘émission Paese del rilascio Comments Bemerkungen Remarques Osservazioni

b) Buttons

English Deutsch Français Italiano Save Speichern Enregistrer Salvare Cancel Abbrechen Annuler Annullare

19.10 Screen „Email“

a) Field Names English Deutsch Français Italiano Email Address E-Mail Adresse Adresse e-mail Indirizzo e-mail

b) Buttons

English Deutsch Français Italiano Save Speichern Enregistrer Salvare Cancel Abbrechen Annuler Annullare

77 Version 2.1

19.11 Screen „Account“

a) Field Names English Deutsch Français Italiano Account- / IBAN - Number

Konto- bzw. IBAN-Nr.

Numéro de compte / IBAN

Numero di conto / IBAN

Account name Name des Kontos Nom du compte Nome del conto Institution name Name des Instituts Nom de l’institut Nome dell’istituto Canton of business relationship

Kanton der Geschäftsbeziehung

Canton de la relation d’affaires

Cantone della relazione d’affari

n/a n/a n/a n/a BIC BIC BIC BIC Account type Kontoart Type de compte Tipo di conto Status code Status des Kontos État du compte Stato del conto Account currency Kontowährung Monnaie du compte Valuta del conto Balance in foreign currency

Kontostand in Fremdwährung

Solde du compte en monnaie étrangère

Saldo del conto in valuta estera

IBAN IBAN IBAN IBAN Client Number Kundennummer Numéro du client Numero del cliente Opened Eröffnungsdatum Date d’ouverture Data di apertura Closed Saldierungsdatum Date de clôture Data di chiusura

78 Version 2.1

English Deutsch Français Italiano Balance in CHF Kontostand in CHF Solde du compte en

CHF Saldo del conto in CHF

Date of balance Kontostand am Date du solde du compte

Data del saldo del conto

City of relationship / other comments

Stadt der Geschäftsbez./ andere Zusatzinfos

Ville de la rel. d’aff. / autres remarques

Città della rel. d’affari / altre

Additional comments Zusatzinformationen Remarques supplémen.

Osserv. supplem.

b) Buttons

English Deutsch Français Italiano Inactive (n.a.) Inaktiv (n.a.) Inactif (n.a.) Inattivo (n.a.) BIC BIC BIC BIC Balance in CHF? Kontostand in CHF? Solde du compte en

CHF? Saldo del conto in CHF?

Entity as contracting party

Juristische Person als Vertragspartner

Personne morale comme cocontractant

Persona giuridica in qualità di parte contraente

Contracting party / Beneficial owner(s) / Power of attorney/Signator(ies)

Vertragspartner / wirtschaftlich Berechtigte(r) / Bevollmächtigte(r)/ Zeichnungsberechtigter(r)

Cocontractant / Ayant(s) droit économique(s) / Mandataire(s)/Signataires autorisés

Parte contraente / Avente/i economicamente diritto / Mandatario/Persone autorizzate a firmare

79 Version 2.1

19.12 Screen „Entity“

a) Field Names English Deutsch Français Italiano Name Name Nom Nome Name in commercial register

Name gemäss Handelsregisterauszug

Raison sociale inscrite au reg. du comm.

Ragione sociale nel reg. di comm.

Incorporation legal form

Rechtsform Forme juridique Forma giuridica

Business Branche Domaine d‘activité Settore d‘attività Incorporation number

Registernummer Numéro d‘identification

Numero d‘identificazione

Incorporation date Gründungsdatum Date de constitution Data di costituzione City of incorporation Stadt der

Registrierung Ville de constitution Città di costituzione

Incorporation Country Code

Land der Registrierung

Pays de constitution Paese di costituzione

Inactive (n.a.) Inaktiv (n.a.) Inactif (n.a.) Inattivo (n.a.) Website Homepage Page d‘accueil Home page Inactive (n.a.) Inaktiv (n.a.) Inactif (n.a.) Inattivo (n.a.) Domicile company? Sitzgesellschaft? Société de domicile? Società di sede? Comments Bemerkungen Remarques Osservazioni Date Closed Datum Einstellung

Business Date de cessation de l‘activité

Data cessazione attività

b) Headers of screen section

80 Version 2.1

English Deutsch Français Italiano Business closed? Geschäft

geschlossen? Activité cessée? Attività cessata?

Inactive (n.a.) Inaktiv (n.a.) Inactif (n.a.) Inattivo (n.a.) Addresses Adresse(n) Adresse(s) Indirizzo/i Inactive (n.a.) Inaktiv (n.a.) Inactif (n.a.) Inattivo (n.a.)

c) Buttons

English Deutsch Français Italiano Use an existing entity

Bereits erfasste juristische Person verwenden

Utiliser une personne morale déjà existante

Utilizzare una persona giuridica già esistente

Yes Ja Oui Si No Nein Non No Save Speichern Enregistrer Salvare Cancel Abbrechen Annuler Annullare

19.13 Screen „Contracting party / Beneficial owner(s) / Power of

attorney/Signator(ies) “

a) Field Names English Deutsch Français Italiano Role (see tooltip) Rolle (siehe Tooltip) Rôle (voir infobulle) Ruolo (vedi descr.

comando)

b) Headers of screen section English Deutsch Français Italiano Is contracting party?

Ist Vertragspartner? Est-il/elle cocontractant/e?

È parte contraente?

Person Natürliche Person Personne physique Persona fisica

c) Buttons English Deutsch Français Italiano Yes Ja Oui Si No Nein Non No Save Speichern Enregistrer Salvare Cancel Abbrechen Annuler Annullare

81 Version 2.1

19.14 Screen „Report Party“

a) Field Names English Deutsch Français Italiano Role (see tooltip) Rolle (siehe Tooltip) Rôle (voir infobulle) Ruolo (vedi descr.

comando) Addit. Info to role Zusatzinfo zu Rolle Info. suppl. rôle Info suppl. ruolo Comments Bemerkungen Remarques Osservazioni

b) Headers of screen section

English Deutsch Français Italiano Party type Beteiligter Sujet impliqué Soggetto coinvolto

c) Buttons

English Deutsch Français Italiano Person Natürliche Person Personne physique Persona fisica Account Konto Compte Conto Entity Juristische Person Personne morale Persona giuridica

82 Version 2.1

20 Disclaimer Limitation of liability Although every care has been taken by the Federal Authorities to ensure the accuracy of the information published, no warranty can be given in respect of the accuracy, reliability, up-to-dateness or completeness of this information. The Federal Authorities reserve the right to alter or remove the content, in full or in part, without prior notice. In no event will the Federal Authorities be liable for any loss or damage of a material or immaterial nature arising from access to, use or non-use of published information, or from misuse of the connection or technical faults.