Standard XML Reporting

Instructions and Specifications for goAML

Adapted Version for FIU Switzerland

Version CH 2.0

Specifications valid for FIU Switzerland

Seite 1 von 88
 Last update: January 2024

Revision History
Rev Date Description Author
CH 2.0 January 2024 Adaptation of FIU Switzerland MROS
document version CH 1.1.6 to comply (FIU Switzerland)
with xsd schema version 5

Notes on the contents of the manual

The adaptations in XSD Schema 5 enable a more standardized transmission of information

between the reporting entities (RE) and MROS.
Adjustments have been made at the transaction and account levels in particular, which will
improve the quality of the transmissions and thus the analysis of the data.
Not all sectors will require the same adjustments, as MROS has structured the requirements
specifically to the reported information, which generally reduces past “N/A” information in the
new schema.
Chapters 1 - 5 present and discuss background information on the adjustments in the new
Schema 5.
Chapters 6 - 8 illustrate the specific adjustments at the XSD level and used lookups. In
addition, all nodes activated within the MROS are described.

For quick recognition, certain relevant sections have been coloured yellow.

Important (but not conclusive) focal points of the changes to goAML Scheme 5
• Adjustments to the permitted report types per RE sector (Chapter 3.1)
• In Switzerland, reporting entities report suspicious business relationships. This can
be specified again at the report level in goAML 5. At report level, the number of
reported business relationships must be specified numerically under Additional
Information. (Chapter 3.2; Chapter 6.1; Business Rule Chapter 6.1.1)
• Information on the requirements for the cancellation notifications (CANCL/CANCT).
(Chapter 3.4)
• New structure of information at transaction and account level, which
standardises the allocation of information. (Chapter 3.5, (Table 3); transactions:
Chapter 6.3; account: “my client” Chapter 7.1, “not my client” Chapter 7.2 )
• Bi-party transactions between a Reported Subject and a counterparty
(not_my_client) only contain available information at the account level on the
counterparty side. The account holder information is only added as an account
comment. No structured specification of account holders is required in the
"account_not_my_client" node. (Chapter 3.5.1; chapter 7.2)
• For better standardisation of transaction information, the Transaction_mode has
been replaced by the Transaction_type lookup now used in goAML 5. This helps
to better sign off the type of transaction. (Chapter 8.6) A detailed list of possible bi-
party transaction types can be found in Table 11 in chapter 6.3.
• New assignments of entities in account roles. It is now possible to report entities
as such if they have other roles as contracting parties in an account relationship
(chapter 3.5.3).
• New standard for labelling attachments. (Chapter 3.6)
Seite 2 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
• Dealing with unavailable information. (Chapter 3.7)
• Schema 5 now offers the option of automatically rejecting reports if important
structural information is missing or incorrect. This function is known as asserts.
(Chapter 6.1.2; chapter 6.2.1) In future, the network of asserts will be expanded by
MROS; these will be created in accordance with the communicated guidelines and
communicated through the established information channels.

Page 3 of 83
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
1. TABLE OF CONTENTS
Standard XML Reporting Instructions and Specifications for goAML 1
1. TABLE OF CONTENTS 4
2. Summary 6
3. Important general information 7
3.1 Overview: type of reports 8
3.2 General requirements related to STR/SAR report types 10
3.2.1 In principle, reporting entities should report their suspicions with STR report type 10
3.2.2 Exception to the general rule: cases in which a report type SAR has to be chosen
11
3.3 General requirements related to AIFT/AIF report types 11
3.4 General requirements related to CANCT/CANCL report types 12
3.5 General requirements related to object information of related to persons, 13
entities, accounts in relation with report and transaction types 13
3.5.1 Objects in report types with transactions (STR, AIFT, CANCT) 13
3.5.2 Objects in report types without transactions (SAR, AIF, CANCL) 15
3.5.3 Entity to entity relationship and depiction of trust structures 18
3.5.4 Multiple roles 19
3.6 General requirements related to attachments 19
3.7 Handling of missing information 19
3.8 Miscellaneous 20
4. Conventions used in this document 20
4.1 Format of tables 20
4.2 Remarks on Types entity, account and person 21
5. References 21
6. Description of XML Nodes 22
6.1 Node “report” 22
6.1.1 Business rules for Node “report” 24
6.1.2 Assert for Node “report” 25
6.2 Subnode “report indicators” 25
6.2.1 Asserts for Node “report indicators” 25
6.3 Node “transaction” 26
6.3.1 Business rules for Node Transaction 30
6.4 Node “activity“ 31
6.4.1 Business rules for Node “activity” 31
6.5 Node “t_from_my_client” 32
6.5.1. Business rules for Node “t_from_my_client” 33
6.6 Node “t_from” 33
6.7 Node “t_to_my_client” 34
6.7.1. Business rules for Node “t_to_my_client” 35
6.8 Node “t_to” 36
6.9 Subnode “goods_services” 36
6.9.1. Business rules for Node “goods_services” 38
7. Description of Common Types Used in the Schema 39
7.1 Type “t_account_my_client” 39
7.1.1. Business rules for t_account_my_client 41
7.1.2. Restriction in xsd-Schema for t_account_my_client 42
7.2 Type “t_account” 43
7.3 Type “t_account_related_entity” 44
7.4 Type “t_account_related_person” (my_client) 45
7.5 Type “t_account_related_account” 45
7.6 Type “t_account_funds” 46
7.7 Type “t_entity_my_client” 47
7.7.1. Business rules for t_entity_my_client 49
7.8 Type “t_entity” 50
7.9 Type “t_person_my_client” 52
7.9.1. Business rules for t_person_my_client 54
7.10 Type “t_person” 55
Seite 4 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
7.11 Type “t_peps” 57
7.12 Type t_person_registration_in_report 58
7.13 Type “t_party” 59
7.13.1 Business rules for t_party 60
7.14 Type “t_address” 61
7.15 Type “t_phone” 62
7.16 Type “t_foreign_currency” 63
7.16.1 Business rules for t_foreign_currency 63
7.17 Type “t_person_identification” 63
7.17.1 Business rules for t_person_identification 64
7.18 Type “report_party_type” 64
7.18.1. Business rules for t_report_party_type 65
7.19 Type t_trans_item 65
7.20 Type generic additional information type 66
8. Lookup Values 67
8.1 Submission type 67
8.2 Funds type 67
8.3 Account type 67
8.4 Account status type 68
8.5 Identification type 68
8.6 Transaction Type 68
8.7 Transaction Item Status / Property Status 68
8.8 Report Code 69
8.9 Phone Address Type 69
8.10 Communication Type 69
8.11 Entity Legal Form Type 69
8.12 Transaction Item Type 70
8.13 Currency codes 70
8.14 Country Codes 74
8.15 Account person role type 80
8.16 Entity person role type 80
8.17 Party role type 81
8.18 Report Indicators 82
8.19 Gender type 85
8.20 Allowed values for Cantons 85
8.21 Account-Account relation type 86
8.22 Account Category type 86
8.23 Account entity relation type 86
8.24 Entity to Entity relation type 87
8.25 Person to Person relation type 87
8.26 Additional information type 87
8.27 Allowed values for fields with yes/no answers 87
8.28 Report Party type 87
9. Disclaimer 88

Seite 5 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
2. Summary
The purpose of this specifications document is to provide IT-personnel of reporting entities
(RE) with the requirements and conditions for creating compatible XML files using the
provided XSD schema for the different supported report types. This manual is not intended
for goAML users that want to file a report via web forms. To do the latter, please consult
the goAML Web manual available on the following web page:
https://www.fedpol.admin.ch/fedpol/de/home/kriminalitaet/geldwaescherei/meldung.html

The version number of the XSD schema file and of this document will always be in sync
for easier referral.

A report file contains the following information which can be represented in the goAML
Client after uploading and verifying the XML file:

• Basic information about the report

• Where does the money come from?
• Where does the money go to?
• Who conducted the transaction?
• Was the transaction related to a property transfer?
• Who reported the transaction(s)? (Optional)
• What was the reason for the report and which actions have been taken?
• In multi-party transactions, list of all involved parties and their respective roles in the
transactions

This document will provide a reference to the schema, nodes and types as well as the
lookup tables for enumeration values. (e.g., Country Codes). This document is based on
the original Version 5.0 provided by UN-EAC and reflects the needs of the FIU Switzerland.

Seite 6 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

3. Important general information

This document explains the requirements and specifications of the XSD schema as defined by
MROS for reporting entities. It is valid from January 1st 2025 onwards. It amends and replaces all
previous versions. Amendments on a smaller scale at a later date are not excluded. However, any
such adjustments would be communicated ahead of time.

Legal requirements that have to be met by reporting entities while filing a report are defined in the
relevant articles of the MROS-Ordinance (see notably article 3). This document describes in detail,
where appropriate, how some of those requirements have to be met on a technical basis. Data
transmitted to MROS within reports that do not observe the requirements described hereafter or with
a structure that does not meet the technical specifications will be rejected.

Technical requirements and specifications are divided into two different categories. The first
category is exposed in this chapter. It is related to general principles that have to be met by
reporting entities while filing a report, such as, for instance, which type of technical report or which
type of information has to be submitted, according to the type of activities conducted by the
reporting entity, or else, how enclosed documents have to be structured, etc. The second category
is exposed in the chapters 6 and 7. It is related to the various specifications of each node and field
of the XSD schema, such as format requirements, mandatory information, or specific business rules
and asserts.

Seite 7 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

3.1 Overview: type of reports

According to Swiss laws and ordinances, reporting entities are confronted with different duties to
report to MROS. Within goAML, specific report types have to be selected accordingly. In goAML
there is a fundamental distinction between transaction (STR, AIFT, CANCT) and activity reports
(SAR, AIF, CANCL). Only transaction reports contain structured transaction data. Activity reports do
not. The following table gives an overview of the different report types and of their use.

Report Definition Use for reporting entities

Type
STR Suspicious activity - Suspicions of money laundering or terrorism financing etc. on the
report with basis of Art. 9 para. 1 lit. a or c AMLA or Art. 305ter para. 2 of the
transaction(s) Swiss Criminal Code (SCC), as a general rule (please see table 2 for
further details).
- Reports issued by Supervisory authorities and supervisory
organizations based on Art. 16 para 1 or on Art. 27 para 4 AMLA.

SAR Suspicious activity - Suspicions of money laundering or terrorism financing etc. on the
report without basis of Art. 9 para. 1 lit. a or c AMLA or Art. 305ter para. 2 of the
transaction(s) Swiss Criminal Code (SCC) for some financial intermediaries (please
see table 2 for further details).
- Suspicions of money laundering or terrorism financing etc. on the
basis of Art. 9 para. 1 lit. b AMLA (termination of negotiations aimed
at establishing a business relationship).
- Suspicions of money laundering or terrorism financing etc. based on
Art. 9 1bis AMLA (dealers according to Art. 8a AMLA reporting
suspicions raised in the course of a commercial transaction).
- Suspicions of money laundering or terrorism financing etc. on the
basis of Art. 9 para. 1 lit. a or c AMLA or Art. 305ter para. 2 of the
Swiss Criminal Code (SCC) for operations over the counter for which
no client information is available according to Art. 51 and Art. 51a
FINMA Anti-Money Laundering Ordinance (please refer to section
3.5.2 below).

AIFT Additional - Response to requests of MROS based on Art. 11a para. 1 and 3
information report AMLA or Art. 11a para. 2 resp. 2bis and 3 AMLA, where transactional
with transaction(s) information has been requested (see section 3.3).
- Addendum to a STR filed at the same time containing additional
suspicious transactions, if the number of transactions to be reported
exceeds 100.
- Submission of additional information to a SAR/STR that has already
been submitted within 40 working days of the date of receipt indicated
on the receipt confirmation of the original report to MROS, based on
Art. 9b AMLA, with transaction(s) information.

AIF Additional - Response to requests of MROS based on Art. 11a para. 1 and 3
information report AMLA or Art. 11a para. 2 resp. 2bis and 3 AMLA, where no
without transactional information has been requested (see section 3.3).
transaction(s) - Submission of additional information to a SAR/STR that has already
been submitted within 40 working days of the date of receipt indicated
on the receipt confirmation of the original report to MROS, based on
Art. 9b AMLA, without transaction information.

CANCT Report pursuant - Notification of the termination of a business relationship pursuant to

to the termination art. 9b AMLA with at least one specific transaction (see section 3.4).
of a business
relationship with
transaction(s)
CANCL Report pursuant - Notification of the termination of a business relationship pursuant to
to the termination art. 9b AMLA without specific transactions (see section 3.4).
of a business
relationship
without
transaction(s)
Table 1: Overview: Definition of the report types for reporting entities

Seite 8 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
Financial intermediaries conduct different types of activities. The type of report they have to select
when reporting to MROS does not only depend on what has to be reported according to law (as
described in the previous table), but also from a technical point of view on the type of activities
conducted by the reporting entity. The major difference is related to the requirement to report
suspicious transactions in a structured way or not (e.g., STR vs. SAR report type). The following
table shows an overview of requirements applied to the different types of financial intermediaries.
Details about these requirements are provided below (see sections 3.2 to 3.5).

Type of report Type of financial intermediary

Banks, Money Transmitters, All others (for instance Credit-/Debit
Virtual Assets Service Providers card providers, Fiduciaries, Trustees,
(VASP) External asset managers, Casinos,
Insurances, dealers according to Art.
8a AMLA, etc.).
STR

(max. 100 suspicious transactions;

no suspicious date range)
SAR

(only Art. 9 para. 1 lit. b AMLA or for (observe reported subject/Counterparty;

‘over the counter’ operations where linked bank accounts needed)
no client information is available Art
51 or 51a FINMA-Ord)
AIFT

(max. 1,000 transactions per report,

suspicious date range upon request
MROS possible)
AIF

(as an answer to MROS, only when

no transactions have been asked)
CANCT

(transactions only for relevant in- /

outflows)
CANCL

Table 2: Overview of report types for different categories of financial intermediaries or for dealers*

* Some specific conditions might apply to distinct types of businesses / activities. Those specificities are referred to hereafter under
dedicated sections. The present table only sums up the overall requirements.

Important remarks:
In this document, the term “VASP” stands for “Virtual Asset Service Providers”. This terminology
refers to financial intermediaries who provide services in relation to Virtual Assets such as
exchangers, wallet providers or trading platforms.

Seite 9 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

3.2 General requirements related to STR/SAR report types

The report types STR/SAR are dedicated to reporting suspicions of money laundering or terrorism
financing based on art. 9 para. 1 lit. a, b or c AMLA or art. 305ter para. 2 of the Swiss Criminal Code
(SCC). It is also dedicated to dealers reporting suspicious activities accordingly to art. 9 1bis AMLA
or to supervisory authorities and organizations reporting suspicions accordingly to art. 16 para 1 or
art. 27 para 4. AMLA.

The following general provisions have to be respected for both STR and SAR report types:
- As a matter of principle, reporting entities shall report business relationships. Therefore, all
active accounts of a reported business relationship must be recorded in an STR or SAR-
report type. The number of business relationships reported, must be recorded in the
designated field “additional information” on report level (see 6.1).
- The reports may involve multiple business relationships as long as these relationships are
related to and relevant for the issue to be reported.
- A statement of assets in PDF format must be submitted as an attachment for all accounts (e.g., fiat,
securities, virtual assets) of a reported business relationship.
- Additional documents according to OMLRO art. 3 such as opening documents, KYC, any media
reports, etc. must also be submitted as attachment (see below, section 3.6, for specific technical
requirements);

3.2.1 In principle, reporting entities should report their suspicions with STR
report type
As a general rule, reporting entities are requested to file reports containing suspicious transactions.
Thus, the STR report type must be selected wherever possible.

The following general provisions apply:

- If multiple business relationships are reported in the same report, at least one (suspicious)
BiParty transaction must be recorded per reported business relation (see below,
section 3.5.1).
- Within the same business relationship, further accounts and/or securities accounts of the
reported business relation(s) as well as additional information concerning natural or legal
persons may be recorded by means of so-called MultiParty transaction (see below,
section 3.5.1 point B);
- Suspicious transactions have to be selected carefully and must be directly relevant to the
reasons that raised the suspicions. For instance, all suspicious transactions mentioned as a
reason for suspicion must also be recorded as structured transaction data.
- If none of the transactions on the accounts of the reported subject deems to be specifically
suspicious, the reporting entity has to record the most important in- and outflow of funds.
- The reported transactions should not be chosen with a date range approach (= “all
transactions between Date X and Date Y are suspicious”).
- Financial intermediaries are requested to refrain from transmitting transactions relating to
account maintenance fees and charges, balancing fees, interest credits, etc.
- A maximum of 100 suspicious transactions may be recorded and transmitted per STR; On
rare occasions, when more than 100 transactions should be submitted, the reporting entity
must discuss the exact submission procedure with MROS in advance; in most cases, the
suspicious transactions exceeding this number will have to be submitted by the way of an
additional report of type AIFT (see section 3.3).

Seite 10 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

3.2.2 Exception to the general rule: cases in which a report type SAR
has to be chosen
The report type SAR has to be chosen only in the following circumstances:
A) By all financial intermediaries: to report suspicions of money laundering or terrorism financing etc.
accordingly to art. 9 para. 1 lit. b AMLA (termination of negotiations aimed at establishing a business
relationship).
B) By all reporting entities other than banks, money transmitters and Crypto businesses (VASP): to report
suspicions of money laundering or terrorism financing etc. accordingly to art. 9 para. 1 lit. a or c AMLA
or art. 305ter para. 2 of the Swiss Criminal Code (SCC).
C) By dealers according to art. 8a AMLA reporting suspicions of money laundering or terrorism financing
etc. raised in the course of a commercial transaction based on art. 9 para. 1bis AMLA.
D) By all financial intermediaries: to report suspicions of money laundering or terrorism financing etc.
accordingly to art. 9 para. 1 lit. a or c AMLA or art. 305ter para. 2 of the Swiss Criminal Code (SCC) for
over-the-counter operations where no client information is available according to Art 51 or 51a FINMA-
Ord.
These circumstances and the principles that do apply to each of them are described in the following
lines.

In such cases, all details of the natural and legal persons or entities involved in the reported
business relationship must be reported in the Activity node using the “my client” option (see below
section 3.5.2).

A) Termination of negotiations aimed at establishing a business relationship

In such cases, no suspicious transaction has occurred and no transaction has to be recorded. All
reporting entities should therefore use SAR-report types.
B) By all reporting entities other than banks, money transmitters and Crypto businesses (VASP)
This affects in particular the following reporting entities:
leasing institutes, casinos, life insurance providers, debit / credit card providers, external asset
managers, fiduciaries, precious metal dealers, etc. Since the reasons that lead to suspicion of these
reporting entities do 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
invested by the customer, these reporting entities should use a SAR report type. If payments (e.g.,
monthly instalments) have been made via bank accounts, those accounts must be recorded as
accounts (counterparty “not my client”), including all details available to the reporting entity. The
specific provisions that have to be met for such reports are described in the table “Objects in report
types without transactions” (see below section 3.5.2).
C) Dealers according to art. 8a AMLA reporting suspicions based on art. 9 1bis AMLA.
In such cases, the reporting dealer will fill in a SAR report type, and refer to the specific provisions
applying to such reports (see section 6.9).
D) Over the counter operations where no client information is available according to Art 51 or 51a
FINMA-Ord.

3.3 General requirements related to AIFT/AIF report types

The difference between the AIF and the AIFT report types is that the AIFT will contain transactions. An AIF
is based on the same logic as a SAR whereas an AIFT is based on the STR logic. The information must be
filled in, either in the ‘Transactions’ node for an AIFT report or in the ‘Activity’ node for an AIF report.

To determine if an AIF or an AIFT has to be submitted, reporting entities will rely on the type of information
that has to be provided. If they want to report details about transactions, then an AIFT is requested. This will
also be the case if they respond to a MROS request asking for transaction information, etc. Financial
intermediaries that do not belong to the categories Bank, Money Transmitter or VASP do not have to file
AIFT reports.

Seite 11 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
The report types AIFT/AIF are dedicated to following circumstances:
- A) Submission of a response to requests for further information issued by MROS based on art. 11a
para. 1 and 3 AMLA or art. 11a para. 2 resp. 2bis and 3 AMLA.
- B) Submission of additional suspicious transactions to a STR if the number of reported transactions
exceeds 100.
- C) Submission of additional information to a SAR/STR that has already been submitted within 40
working days of the date of receipt (date indicated on the receipt confirmation of the initial report to
MROS), based on art. 9b AMLA. Otherwise, a new SAR/STR must be submitted.

The following general provisions have to be respected for AIFT/AIF report types:
- Transactions which have already been submitted to MROS previously (for instance within a STR)
must not be submitted again via an AIFT report. A transaction must only be transmitted to MROS
once.
- For AIFTs, and, if needed, for AIFs, the corresponding account statement containing all (requested)
transactions must be attached as a PDF.
- The number of transactions in AIFTs is strictly limited to 1’000. Submissions exceeding this number
should be split into multiple AIFTs so that none of the AIFTs exceeds the strict limit. In such cases,
the reporting entity should contact MROS in advance.
- If MROS requests additional information from the reporting entity based on art. 11a para. 1 and 3
AMLA, an initial report to MROS already exists (e.g., SAR or STR). In this case, the MROS’s
reference number assigned to the initial report must be recorded in the Ref. no. MROS
(fiu_ref_number) input field of the AIFT/AIFT (see Section 3.2).
- In the case of MROS requesting additional information based on art. 11a para. 2 resp. 2bis and 3
AMLA, the reference number that MROS indicated in its request for the disclosure of information
must be entered in the input field Ref. no. MROS (fiu_ref_number).
- The indicators, in the web input mask to be found in the tab ‘Report type/suspected predicate
offence(s)/factor(s) arousing suspicion/type of attachments’ must be completed mandatorily. For the
three categories “M” (Report type), “V” (suspected predicate offence(s)) and “G” (factor(s) arousing
suspicion), the selection options art. 11a para. 1 and 3 AMLA or art. 11a para. 2 resp. 2bis and 3
AMLA should be selected in each.
- Replies to requests for information resp. requests from MROS pursuant to art. 11a AMLA that are
sent via goAML Message Board will be rejected.

3.4 General requirements related to CANCT/CANCL report types

The report types CANCT/CANCL are dedicated to reporting the termination notices based on art. 9b
AMLA. According to this legal provision, financial intermediaries are allowed, under certain
conditions, to terminate a business relationship that has previously been the subject of a suspicious
activity report (SAR/STR). If they do so, they have to inform MROS without delay. This provision
does not apply to business relationships indicated in reports whose information has already been
transmitted to a law enforcement authority. The content of such termination notices of a business
relationship is determined in art. 3 para. 1bis of the Ordinance on the Money Laundering Reporting
Office (OMLRO). For this purpose, the CANCL (without transaction) or CANCT (with transaction)
report type should be selected.
From a technical point of view, it is optional to document the credit/debit of significant assets in the
context of the termination of the business relationship (art. 3 para. 1bis OMLRO) by means of
transactions (CANCT report). Such withdrawal (or deposits) of significant assets might indeed never
have taken place (e.g., if there were already no assets left in the business relationship at the time of
the suspicious activity report). The terminated business relationship can therefore be reported to
MROS by means of a CANCL report (without transactions – analogous to the SAR report) or, if
necessary, by means of a CANCT report where any withdrawal of significant assets in the context of
the termination of the business relationship can be reported by means of BiParty transactions.
Additionally, for accounts without transactions or with zero balance as well as already closed
accounts (without suspicious transactions), MultiParty dummy transactions should be entered.

Seite 12 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

The following general provisions have to be respected for CANCT/CANCL report types:
- Reporting entities that do not have to file STRs according to section 3.2.2, are requested to
choose CANCL-report types exclusively to notify the termination of a reported business
relationship.
- Any withdrawal of significant assets in the context of the termination of the business
relationship must be documented by means of account statements attached to the report.
This provision applies regardless of the report type.
- The termination of several business relationships may be reported at the same time in one
termination notice, but only if they were originally reported under the same suspicious activity
report (SAR/STR).
- As for the indicators, the codes 0024M, 1207V, 2103G and 3023B must be selected in the
submenu "Report type / suspected predicate offense / factor(s) arousing suspicion / type of
attachments".
- The reference number of the related previous report in which the terminated business
relationship has been reported to MROS (e.g., STR-00021x) must always be entered in the
field ref. No. MROS (fiu_ref_number). Only the reference number itself must be entered
without any additional text such as "MROS Ref” (e.g., STR-123456).
- No matter if report type CANCL or CANCT was chosen, the node “account_my_client” has to
be selected for all closed accounts and all details of said account must be provided.
- Closed account info must contain closing date, zero balance and account status “closed”.

3.5 General requirements related to object information of related to persons,

entities, accounts in relation with report and transaction types
In all report types including transactions (STR, AIFT, CANCT), objects (namely persons, accounts,
entities) are logically linked to specific transactions. Therefore, the information related to those
objects will be delivered in a way determined by the relation between each of these objects and
specific transactions. In report types without transactions (SAR, AIF, CANCL), information related
to objects will be delivered directly in relation to the report and distinguished only between reported
subject (t_account_my_client; t_person_my_client; t_entity_my_client) or “Other” (e.g., related
subject or counterparties for instance for the account funding a reported credit card).

The object “account” is a general term for all sort of numbers that identify the sender or recipient of
funds. For example, it can be a classic account number at a bank, an IBAN, a cellphone (e.g., for
TWINT-payments), a virtual wallet or crypto address or even an email address. Important is that all
such numbers, reported as “my_client” are categorized using the two lookups 8.22 account
category and 8.3 account type.

The object “person” is used for all natural persons while the object “entity” is used for any type of
legal entity as described in section 8.11 entity legal form.

This section describes the logic according to which this object-related information has to be seized
and the major requirements that have to be met, for both types of report categories (with or without
transaction(s) respectively in both sections 3.5.1 and 3.5.2).

At a very general level, please note that all relevant objects (natural persons / legal entities) that
have a role in relation with a reported business relationship are to be recorded.

3.5.1 Objects in report types with transactions (STR, AIFT, CANCT)

In report types with transactions (STR, AIFT, CANCT), a distinction is drawn between two different
types of transactions: the BiParty transaction (see letter A below) and the MultiParty transaction
(see letter B below). The MultiParty transaction is in fact a functionality, which is used in transaction
type reports to report objects that aren’t directly connected to effective transactions. Hence, MROS
requires all real transactions to be registered as BiParty transactions.

Seite 13 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

A) Bi-Party transactions
BiParty transactions correspond to commonly-known transactions, where two parties are involved
(the sender and the receiver of funds). Logically, BiParty transactions are composed of a source
(From) and a destination (To). The source and destination may each either be the reported subject
or a counterparty and, depending on the type of transaction, each may be an account, a person or
an entity (see below, section 6.3).
In a BiParty transaction, at least one of the parties will be the client of the reporting entity.
Therefore, it is mandatory to seize at least one party of a BiParty transaction as “my client”. As a
rule, and according to legal requirements, reporting entities will generally have very extensive
information about their clients, much less about the counterparty of a BiParty transaction. For
instance, they wouldn’t know the balance on the “not my client” account. Hence, the amount of
information that has to be provided for “my client” parties is higher. This materializes in the higher
number of mandatory fields for “my client” objects (persons, entities, accounts).

The following general provisions apply for BiParty transactions:

- MROS considers a party as reported according to law only if it has been consistently marked
as “my client”.
- Please note that in the nodes t_entity_my_client, t_account_my_client and
t_person_my_client, only a “Reported subject” should be entered while in the sections
t_entity, t_account and t_person the counterparty should be entered even if that person,
account or entity is also a customer of the reporting entity (but is not suspicious / is not
reported).
- As a general rule, the information provided on counterparties should be limited to what the
reporting entity knows. So, for example, if a reported transaction is a transfer between two
bank accounts, the information related to the counterparty will be limited to an account “not
my client”. The account can be a normal bank account number, an IBAN, a wallet or even a
phone number (e.g., for TWINT-payments) or any other number that helps to identify the
counterparty of such a transaction.
- If the “not my client” side of a transaction is an account, all available information must be
provided at account level. Information regarding the account holder (person or entity) and - if
available - an address must be placed in the account-commentary. No additional person or
entity should be created in relation with this account.
- If both sides of a transaction are reported (for instance, because a transaction occurs
between two reported accounts), both sides of the transaction have to be marked as “my
client” and the relevant information (account holder and signatory details, address info etc.)
must be provided on both sides of the transaction and the further relevant objects (persons,
entities) relating to persons or entities that have a relation to the account (beneficial owner
etc.) must also be provided.
- On the counterparty side (either from or to) of a transaction, no correspondent bank or
omnibus accounts should be recorded, but exclusively the effective accounts and or party of
origin or destination (be it on the sender’s as well as on the receiver’s side).
Exception: If a reported suspicious transaction directly involves an omnibus (collection)
account either on the sender or on the end beneficiary side, then this account must also be
recorded.
- Some specific rules define whether the party of a transaction is an account, an entity or a
person. Please refer to section 6.3.
- Whenever a transaction involves bank accounts, the field BIC/SWIFT is mandatory on both
sides of the transaction. If no BIC/SWIFT is known or the account holding bank does not
have a BIC/SWIFT, any other unique identifier will do (SIC, Routing-Nr., BSB etc.). “N/A”
information in this field is not accepted.
- On transaction level, the field “transaction_description” is used to provide details of the
transaction such as payment reason (e.g., “loan agreement”), location of the use of the debit
card or any other useful information pertaining to this transaction.

Seite 14 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

B) MultiParty functionalities in transaction reports

MultiParty transactions are defined as transactions in the logic of goAML, but represent rather
single objects such as accounts, persons or entities than transactions in a strict sense. MuliParty
transactions are used in the following situations:
- If information related to persons, entities or accounts involved in the report must be provided
and if those objects aren’t directly involved in transactions as one of the counterparties. For
instance, this can be an (active or already closed) account for which no suspicious
transactions are reported. This can also be a person or an entity, for example the head of a
criminal organization, which is identified by the reporting entity in connection with a reported
business relationship and named in the statement of facts, but is not involved formally in any
of the reported business relationships. The reporting entity may decide to enter details about
this person as an additional involved person or entity using the MultiParty functionality in
goAML.
- In CANCT reports, the MultiParty transaction must be used for accounts that were reported in
the initial report, were subsequently closed but did not have any relevant closing transactions
such as a transfer to or from another financial intermediary.

The following general provisions apply for MultiParty transactions:

- 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.
- In the MultiParty node, it is not specified whether an involved party is the source (From) or
the destination (To counterparty) of the funds, but it is crucial to define their role. For this
reason, a list of roles is available (see lookup 8.17 party role type) and mandatory.
- A Multiparty transaction can’t stand alone in a transactional report (STR; AIFT; CANCT) but
holds supporting information only. Therefore at least one Bi-Party transaction must be
present when a Multiparty transaction is reported.

3.5.2 Objects in report types without transactions (SAR, AIF, CANCL)

In all report types without transactions (SAR, AIF, CANCL), the reported parties are identified
through the node t_activity. As of version 5.2, the logic of “my_client / counterparty” is now also
available in an activity report. An account, a person or an entity that has to be reported must
therefore be entered under an object on the "my_client" node (t_account_my_client,
t_person_my_client or t_entity_my_client). Hence, for report types without transactions, at least one
of the selected t_account, t_person or t_entity must be of type “reported subject” and therefore
t_account_my_client, t_person_my_client or t_entity_my_client.

Seite 15 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
FI-Type Object myClient PartyRole (for Object_not my client PartyRole (for Commentary
(reported subject) my Client Node) (accounts/persons linked to not my Client
reported subject) Node)
Credit-/Debit cards 1 Account (Credit card) Reported account Account Related account Parties within the
Field account: credit (Account linked to fund the account_my_client can be
card nr. credit card) an entity and/or one or
Field iban: credit card Person multiple person(s)
nr. (Holder of a credit card that
Field swift/bic: gem. was issued for an entity
RE Detail such as lorry drivers,
Field balance: representatives etc.)
balance of card
Field:account_comm
entary: Exp. Date of
Card
Insurance Person Reported person Account (linked to pay Related account For not_my_client info,
premiums) please provide as much info
Person (Beneficiary of Beneficiary as available
insurance policy) For beneficiary (person):
minimum of name, first
name, date of birth and
nationality
Casinos Person Reported person Person (any other person Person linked to For not_my_client info,
linked to the reported main subject(s) please provide as much info
subject) as available
Fiduciary Person / Entity/ Reported person / Account (linked to Person linked to For not_my_client info,
(Account*) entity reported subject) main subject(s) please provide as much info
Person (any other person as available
*for accounts with founding linked to the reported
capital
subject)

1
Credit and debit card providers should report their suspicions using a SAR report type only. It is important that the credit / debit card is reported as “myClient”-account (t_account_my_client), while the related
bank account, which is used to fund the credit card is entered as well but as “t_account” only. Important remark: this specific provision does not apply for banking institutions that do report transactions of their
clients conducted with debit or credit cards. For this type of activity, please see below, section 6.3
Seite 16 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
External Asset Person / Entity Reported person / Account (managed Person linked to For not_my_client info,
manager EAM / entity Swiss accounts) main subject(s) please provide as much info
Investment advisor 2 Person (any other person as available
linked to the reported If the managed accounts
subject) are not held in Switzerland,
please provide a list of them
with all details as appendix.
Securities firm / Person / Entity Reported person / Person (any other person Person linked to For not_my_client info,
Foreign Exchange entity* linked to the reported main subject(s) please provide as much info
Trader / Attorney & subject) as available
Notary / Distributor of
investment funds /
Loan, leasing and
factoring business / *in exceptional case for
Foreign Exchange
Other FI / Dealers Traders
(acc. to art. 8 AMLA)
Commodity and Person / Entity Reported person / Account (Debit or credit Person linked to For not_my_client info,
precious metal trader entity card) to process the main subject(s) please provide as much info
transaction as available
Person (any other person
linked to the reported
subject)
Currency Exchange Person Reported person Account (Debit or credit Person linked to For not_my_client info,
card) to process the main subject(s) please provide as much info
transaction as available

Person (any other person

linked to the reported
subject or person with
exception according to
Art. 51 or 51a GwV-
FINMA)
Table 3: Objects in report types without transactions

2
External asset managers (EAM) should report their customer in the nodes person_my_client or entity_my_client with all the details of the customer and should additionally enter all Swiss accounts that are
managed by the EAM in the node “account”. At least the account number, bank information and the account holder - person and/or entity - should be depicted. Please note that managed accounts abroad
(outside of Switzerland) should not be entered as account in the system but listed on a separate sheet and uploaded as attachment
Seite 17 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

3.5.3 Entity to entity relationship and depiction of trust structures

Although goAML 5 technically allows to enter one entity and then add another entity one level
below (hence creating a relation between the two entities as shown in table 3 below), entities
should always be depicted in relation to the reported account (as shown in table 4).

Table 4: Table of References

This means that within the reported account there is one entity reported as contracting party (node
t_entity) while other(s) will be reported as related entity(ies) of the account (node
account_related_entity), each of them depicted with the adequate account-entity-relation role. The
same logic applies to other entities or persons that have a role within the account (e.g., power of
attorney, trustee etc.). For category details please consult lookup 8.23 account entity relation type.
If no applicable role is available, please chose “other” and describe the role of the entity in the
account_related_entity commentary field.

The logic described above is especially important when depicting a trust structure that holds the
reported account. goAML 5 allows more than one entity to be part of an account structure. This
option allows it to depict a complete trust structure within the reported account. With goAML 4, as a
workaround solution another than the account holding entity (contracting party) had to be entered in
the t_person_node. It is therefore no longer necessary to add a multiparty transaction to the report
that involves trust structures in order to give a complete overview of the trust.

Table 5: Table of References

Seite 18 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

3.5.4 Multiple roles

goAML 5 allows depicting a person multiple times with different roles within the account. Since this
option was not available with older versions of goAML, combined roles were created (e.g.,
contracting party & beneficial owner). These combined roles still have to be used and reporting
entities are requested not to enter the same person more than once within the XML with different
individual roles. For the various types of roles that a person can have within the account section,
please refer to the lookup 8.15 account person role type.

3.6 General requirements related to attachments

While filing a report, reporting entities should ensure that all necessary attachments in accordance
with the relevant legal requirements (Art. 3 OMLRO) or, if appropriate, documents requested by
MROS have been uploaded. Not attaching all necessary documents to the report (e.g., asset
overview/overview of all accounts and securities custody accounts belonging to the business
relationship, including balance, any disclosure order(s) issued by prosecution authorities etc.) will
lead to the report being rejected by MROS (as set out under art. 4 para. 1 OMLRO).

The following general requirements apply for attachments:

- Maximum size limit: The maximum size of the entire report is 300 MB and 20 MB per
attachment.
- Naming convention for attachments: The attachments are to be labeled comprehensibly
according to the content of the document
o not correct: attachment 1, attachment 2, etc.;
• correct: 1. opening documents - business relation X;
2. account statement - account XY May 20-June 21;
3. KYC - business relation X
press articles, etc.
- Text recognition: All mandatory enclosures according to art. 3 OMLRO have to be sent as
PDF documents (with automated text recognition OCR). MROS reserves the right to reject
reports if this is not the case.
- All attachments have to be free from password protection and / or encryption

3.7 Handling of missing information

Missing information must be handled following the general rules defined here:

- Missing information in non-mandatory fields:

• If information for a non-mandatory field is unavailable, leave the field blank (do not
enter “n/a”, “unknown”, “0”, “X”, or any other alternative value).
- Missing information in mandatory fields:
• If information is unavailable for a mandatory field and if the field requests a value from
a drop-down menu, use the item provided for this purpose, i.e., “-“. If the field is not a
drop-down menu enter “n/a” (but not “NA”, “n.a.”, “unknown”, “null” or any other
alternative text) for text, “0.0” for numeric, or “1900-01-01” for date fields.

- Please note that the BIC/SWIFT field must always be completed with a real value related to
the name of the bank, “n/a” is not permitted (for further details please see section “Bi-party
transactions” in section 3.5.1).

Seite 19 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

3.8 Miscellaneous
Code 2011G
Suspicious activity reports are often submitted due to a disclosure order of a prosecution authority.
Nevertheless, the indicator “Information from prosecution authorities” (Code 2011G) is rarely
selected. Please make sure to always select the correct indicator 2011G if applicable and to also
add a copy of the underlying disclosure order issued by the prosecution authority to the
attachments of the report.

4. Conventions used in this document

The following conventions are used in this document:
Symbol Description
Required field

Required, 1 to N values

Optional field
Optional sub node

Required sub node

Optional, but one of the two nodes should be provided

Integer A 32 bit value

DateTime A date value in the following format:
YYYY-MM-DD (2006-03-25T11:55:00)
Date The type date or sql_date is exactly the same format as this
datetime however it restricts the input to contain a date with
minimum value of year 1753. This is restricted as SQL
databases do not allow for a date older than this year.
Sequence to sub nodes

4.1 Format of tables

Within the tables we used different formats to define various meanings. The following table
describes how to read the tables within the chapters 6 and 7.

Format Description
Normal nothing special
Normal cursive Fixed value given
Normal Bold Mandatory Fields
Light Blue Comment for following rows
Dark grey and bold Table Header
Light green Business Rule applied
Pink Assert applied

Please note that the inactive fields have been hidden in the web UI of goAML in most cases
in order to improve the overall usability.

Seite 20 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

4.2 Remarks on Types entity, account and person

In the following chapters you will see a set of two types of entity, account and person:
• t_entity_my_client and t_entity;
• t_account_my_client and t_account;
• t_person_my_client and t_person.

The structure of the different types is similar. Therefore t_entity_my client has the same
structure as t_entity; t_account_my_client the same as t_account and t_person_my_client
the same as t_person. The difference can be within some restrictions, i.e., some
nodes/fields which are not mandatory in “t_account” may be mandatory in
“t_account_my_client”. These restrictions are defined by FIU Switzerland.

5. References
ID Document name Description Link to Document / Page
1 XML Reporting XML structure of goAML https://www.fedpol.admin.ch/dam/f
Schema CH adapted to Swiss edpol/de/data/kriminalitaet/geldwa
configuration as XSD-File escherei/aml/XML_Schema.xsd.do
wnload.xsd/XML_Schema.xsd
2 goAML Web – Web user guide by https://www.fedpol.admin.ch/dam/f
Manual UNODC providing general edpol/en/data/kriminalitaet/geldwa
information about the escherei/aml/goaml-web-manual-
goAML Web application. e.pdf.download.pdf/goaml-web-
manual-e.pdf
Table 6: Table of References

Seite 21 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

6. Description of XML Nodes

6.1 Node “report”

Basic information about the RE, reporting date and type of report. It must contain either
one or multiple transactions (for transactional reports such STR, AIFT, CANCT) or one
or multiple parties (for activity reports via node activity).

Figure 1: Overview node “report”

Seite 22 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
Name Description Length Req. Example
schema_version Version of schema which Char (25) N 5
report is based on
rentity_id RE number defined by Integer Y 1237
FIU
rentity_branch Branch of current RE Char (255) N Branch of Money
Transmitter
reporting the
transactions
submission_code Type of submission Enumeration Y Value is fixed to
“E”
electronically
report_code 3 Type of report Enumeration Y STR, SAR etc. see
depending on answer 8.8 Report Code
to question defined in for details
tooltip of this field

entity_reference Reference to the Char (255) Y STR Ref No 392

report, used by RE
fiu_ref_number Ref. number used by Char (255) N STR-000001
MROS and related to a Note: If MROS
previous report requests additional
info acc. to art. 11a
para. 1 and 3
AMLA, RE must
use that number in
their reply. When
entering a
CANCL/CANCT-
Report, always fill
in the Ref. Nr.
indicated by
MROS (SAR/STR)
prev_rejected_ref Ref. number of Char (255) N Report Key
_number previously rejected e.g., 61xxx-0-0
report

report_date Report date Date Y Needs to be set

for XML
currency_code_ Local Currency code Type N Value is fixed to:
local “Currency- CHF
type”

3
Explanations defined in a tooltip are as follows (as an example):
If the business relationship subject to this report contains transactions, select “STR”, else select “SAR”. If you are
submitting additional information belonging to a report submitted to MROS in the past, select “AIF” (if no transactions are
going to bereported) or “AIFT” (if transactions are going to be reported). If you are reporting the termination of a business
relationship pursuant to art. 9b AMLA, select “CANCL” (without transactions) or “CANCT” (with transactions). For any
questions or spontaneous dissemination of information, foreign FIUs select IRI (Incoming Request for Information –
International), while domestic authorities select IRD (Incoming Request for Information – Domestic).

Seite 23 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
reporting_person Full details of the Type Y
report’s reporting “t_person_
person registration
_in_report”
reporting_user_ User code for the Char (50) Y
code reporting person

location Describes location of Type Y

the reporting entity “t_address”
reason Explanation of Char (8000) Y4 In German:
circumstances/activity “Sachverhalt”
that led to the report

action Describes the reason Char (8000) Y5 In German:

for suspicion and “Grund für
eventual Verdacht / Was
measures/actions haben Sie bereits
undertaken by RE unternommen”
transaction Transaction Type Y See 6.3 Node
information “transaction (one “transaction”
” of
activity Involved subjects and Type the See 6.4
items list linked “t_person”, m) Node “activity“
directly to report “t_entity” or,
“t_account“
report_indicators List of indicators for Subnode Y See 6.2 Subnode
the current reports 1 … many “report indicators”

Additional Generic node for Additional_info N See 7.20 Type

information adding additional rmation_type generic additional
information information type

Table 7: Details node “report”

6.1.1 Business rules for Node “report”

Name Business rule (short description)
rentity_branch If “rentity-ID” is „Raiffeisen Schweiz“, then “rentity_branch” is mandatory
report_code If “report_code” equals value “STR”, then at least one Bi-Party
transaction is mandatory
fiu_ref_number If “report_code” equals “AIF”, “AIFT”, “CANCL” or “CANCT”
then “fiu_ref_number” is mandatory
BR-Count When report type is STR or SAR and indicator does not
contain “0003M”, additional information is mandatory and
must include Info type “Number of business relationships
in this report” and Info Numeric >0

Table 8: Business rules for Node report

4 This field is not to be filled in if in the field "report_code" the values "AIF", "AIFT", “CANCL” or “CANCT” are selected.
5 This field is not to be filled in if in the field "report_code" the values "AIF", "AIFT", “CANCL” or “CANCT” are selected.

Seite 24 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

6.1.2 Assert for Node “report”

fiu_ref_number The field “Ref. no. MROS” is mandatory for CANCL/CANCT
reports.
Table 9: Assert for Node report

6.2 Subnode “report indicators”

Figure 2: Overview subnode report_indicators

Name Description Length Req. Example

indicator Classification on Char (25) Y See 8.18 Report
report type (M), Indicators
suspected
predicate
offense (V) and
reason for
reporting (G)
Indicators;
See asserts in More than one can be
6.2.1. below chosen
Table 10: Details subnode report_indicators

Attachments: ensure all necessary attachments according to MROSO Art. 3 were added to
the suspicious activity report before submission. Incomplete reports will be
rejected by MROS!

6.2.1 Asserts for Node “report indicators”

indicator a category M (report types) indicator must be selected and at least one V
(predicate offenses) and one G (reasons) indicator
indicator The indicator code ‘0003M’ must only be used for SARs

Indicator CANCL resp. CANCT reports must have indicators 0024M,

1207V and 2103G

Seite 25 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
6.3 Node “transaction”

Figure 3: Overview node transaction

Seite 26 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

Name Description Length Req. Example

transactionnumber Unique transaction Char (100) Y 20084711
number for bank
transaction
internal_ref_number Additional RE internal Char (100) N WU_BRNCH01_0
transaction reference 001
number
agent_name Name of the operating Char (255) N Agency XY
agency

transaction_location Country and city Char (255) N Branch 001

where “ATM” or
“Counter” transaction
took place
transaction_ Free text field to Char (8000) Y Darlehen
description describe the
purpose of the
transaction
date_transaction Date and time of the Date Y 03.08.2023T10:59:
transaction 00
teller Unique transaction Char (20) N 123456
number for second
leg of bank
transaction
value_date Value date Date N
Transaction_type_code Description of Enumeration Y See 8.6
transaction type Transaction type
amount_local The value of the Decimal Y
transaction in local
currency (always
CHF)
Transaction could be either a bi-party transaction with clear “From” and “To” sides, or a
multi-party transaction with unlimited list of subjects (Persons, Accounts and Entities) where
each has a role rather than a clear “From” or “To” side.
Multi-Party Transaction
The Multi-Party functionality may only be used in Report type transactions additionally to
BiParty Transactions when additional subjects, namely accounts, persons or entities, have
to be entered (see Section 3.5.1 let. b). This can also be an active or closed account for
which no transactions are being reported. A multi-party transaction never has an amount
and does not depict a real transaction.
involved_parties Describes the Type Y See 7.13 Type
involved party “t_party” “t_party”
details

Seite 27 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
Bi-Party Transaction
Note: Bi-directional transactions are composed of a source and destination. The
source and destination may be either a person, an account or an entity. At
least one transaction side (source or destination) has to be qualified as
“my_client” (i.e., a reported subject, see 4.2) but if both accounts of a
particular transaction are to be reported, both sides are to be depicted as
“my client”. This requirement is ensured by the business rule described in
subsection 6.3.1).

Most frequent examples and specific rules applying to them:

For account (ATM / cash) deposits, the source is a person and the
destination is an account. The following transaction configuration should be
depicted:
 From_person and to_account
Note that at least one side must be a subnode of either t_from_my_client or
t_to_my_client

For account (ATM / cash) withdrawals, the source is an account and the
destination is a person. The following transaction configuration should be
depicted:
 From_account and to_person
Note that at least one side must be a subnode of either t_from_my_client or
t_to_my_client

For money remittances, the source and destination is a person. The

following transaction configuration should be depicted:
 From t_person and to_person
Note that at least one side must be a subnode of either t_from_my_client or
t_to_my_client

The same structure of person-to-person transactions can be used for any

money service type of transaction.

For account transfers, the source and destination is an account. The

following transaction configuration should be depicted:
 From t_account to t_account
Note that at least one side must be a subnode of either t_from_my_client or
t_to_my_client

For debit or credit card payments, the source is an account and the
destination is an entity. The following transaction configuration should be
depicted:
 From t_account to t_entity
Note that at least one side must be a subnode of either t_from_my_client or
t_to_my_client

Seite 28 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
Purchase/sale of securities
The purchase/sale of securities is entered as a BiParty account-to-account
transaction. The transaction type ‘Securities’ should be selected. In the
payment purpose field, users should enter the name of the security (and
ISIN code if available) and the quantity of the traded security. For the
monetary part of the transaction, the relevant account type (e.g., savings
account) should be selected, as well as the equivalent value in CHF and in
foreign currency if necessary. For the securities part of the transaction, the
account type ‘Securities custody account’ should be selected, as well as the
equivalent value in CHF and in foreign currency if necessary.

Receipt/delivery of securities
The delivery of securities is entered as a BiParty account-to-person
transaction. The receipt of securities is entered as a BiParty person-to-
account transaction. Both cases apply even if securities are held at a central
securities depository such as SIX and moved from one bank to another,
e.g., delivery free of payment). Users should select the transaction type
Securities. In the Payment purpose field, they should enter the name and
quantity of the security. The account type ‘Securities custody account’
should be selected, as well as the equivalent value in CHF and in foreign
currency if necessary. If the counterparty is unknown, the delivering or
receiving depository is recorded as an entity.

Corporate action/dividends
Corporate actions/dividends are entered as BiParty account-to-account
transactions.

Users must select the transaction type Securities. In the Payment purpose
field, they enter the name and quantity of the securities.
The account type ‘Securities custody account’ has to be selected, as well as
the equivalent value in CHF and in foreign currency if necessary.
For the client side of the transaction, the relevant account type (e.g.,
savings account) must be selected, as well as the equivalent value in CHF
and in foreign currency if necessary. The bank side (e.g., omnibus account)
of the transaction needs to be entered as account with account type
“Securities custody account”. It should be noted that this is an account of a
counterparty.

In this case, Corporate Action and the name of the bank have to be entered
as the account number and additional information (e.g., Corporate Action
Cantonal Bank XY).

One of the nodes t_from_my_client or t_from must be provided. Both CANNOT be

present together in a transaction, but one of them must be present.
t_from_my_client Specifies where the Subnode See 6.5 Node
money came from. If the “t_from_my_
source is reporting Y client”
bank’s client and (one
subject to be reported, of
then this node should be them)
provided
t_from Specifies where the Subnode See 6.6 Node
money came from “t_from”
Seite 29 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
One of the nodes t_to_my_client or t_to must be provided. Both CANNOT be present
together in a transaction, but one of them must be present.
t_to_my_client Specifies where the Subnode See 6.7 Node
money went. If the “t_to_my_
destination is reporting Y client”
bank’s client and subject (one
to be reported, then this of
node should be provided them)
t_to Specifies where the Subnode See 6.8 Node
money went “t_to”

goods_services6 The goods/services linked Subnode N See 6.9

to the transaction Subnode
“goods_
services”
comments Generic comments field Char N
Details of account (4000)
owner/transaction
counterparty as available
from payment system
(e.g. content of SWIFT
field 50a “Ordering
Customer” or 59a
“Beneficiary Customer”):
name and address, if
available, else “n/a”
Table 11: Details node transaction

6.3.1 Business rules for Node Transaction

Name Business rule (short description)
Internal_ref_number If rentity type is money transmitter, then mandatory
Transaction_location If transaction_type (see 8.6) is IN (DEPAC, WITHD)), then
mandatory. If value is unknown, enter “n/a”.
Amount_local If transaction_type equals “MULTIPARTY Dummy”, then field
“amount_local” must equal value zero (0), else field
“amount_local” must be any other number value greater than
zero.
t_from(_my_client); If it is a Bi-Party transaction, then either “t_from” or “t_to” must
t_to(_my_client) be of type “My Client”
Table 12: Business rules for Node transaction

6 This node should only be used by dealers according to Art. 8a AMLA reporting suspicious activities according to Art. 9 para 1a AMLA. Hence, it
should not be used by financial intermediaries.
Seite 30 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

6.4 Node “activity“

Reports can include an activity node to represent an event where a list of objects
(person, entity, account) are related directly to the report without the need of a
transaction. The activity node is only to be used when no transaction at all is involved
(see 3.2.2). Certain reporting entity categories (e.g., fiduciaries, external asset
managers, life insurance companies) are requested to forward reports which do not
contain information concerning any transactions.

Figure 4: Overview node activity

Name Description Length Req. Example

report_parties Represents a collection Y
of involved subjects

report_party Represents a single Type Y See 7.18 Type

involved subject. At least “report_par “report_party_
one party must be ty_type” type”
included.
goods_services 7 The goods/services linked to Subnode N See 6.9 Subnode
the transaction “goods_services”
Table 13: Details node activity

6.4.1 Business rules for Node “activity”

Name Business rule (short description)
account The following business rule only applies when the report
type is CANCL:

Closed is mandatory (Date of closing)

Balance has to be zero (0)

Status_Code has to be value “2” (closed)

MyClient At least one party in a SAR must be of type “my_client”,

either account_my_client, person_my_client or
entity_my_client
Table 14: Business rule for node activity

7 This node should only be used by dealers according to Art. 8a AMLA reporting suspicious activities according to Art. 9 para 1a AMLA. Hence, it
should not be used by financial intermediaries.
Seite 31 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
6.5 Node “t_from_my_client”
This node should be provided if the source side of the transaction is the reported subject
and client of the reporting bank. Entity could be a direct party in bi-party transactions.

Figure 5: Overview node t_from_my_client

Name Description Length Req. Example

from_funds_ Type of funds used Enumeration Y See 8.2 “Funds
code in initiating Type”
transaction
from_funds_ Description, if Char (255) N
comment funds_code is
“O”(Other).
From_transaction Supporting info Type N 8.26 Additional
_additional_info regarding the transaction_addi information type
transaction tional_info

from_foreign_ Specifies currency Type Y See 7.16 Type

currency details and must be “t_foreign_curr “t_foreign_curre
used for all ency” ncy”
transactions, i.e., for
CHF and foreign
currency
transactions
from_account Subnode that Type See 7.1 Type
holds account “t_account_my “t_account_my
information _client” Y _client”
from_person Subnode that Type (one See 7.9 Type
holds “from “t_person_my_ of “t_person_my_
person” client” them) client”
Seite 32 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
information

from_entity Subnode that Type See 7.7 Type

holds “from “t_entity_my_ “t_entity_my_
entity” client” client”
information
from_country Country where Enumeration N See 8.14
transaction was Country Codes
initiated
Table 15: Details node t_from_my_client

6.5.1. Business rules for Node “t_from_my_client”

Name Business rule (short description)
to_account The following business rule is only applicable, if the business
type of your institution corresponds to one of the following:

Bank or VASP

IF “Transaction type” does not equal “MULTIPARTY Dummy” OR

“report_indicators” does not equal “0003M” (Art. 9 para. 1 letter b
AMLA), THEN node "from_account" or “to_account” is mandatory.

Table 16: Business rules for Node t_to_my_client

6.6 Node “t_from”

Source of the transaction. Can be either a person, an account or an entity.

Figure 6: Overview node t_from

Seite 33 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
Name Description Length Req. Example
from_funds_code Type of funds used Enumeration Y See 8.2
in initiating Funds type
transaction
from_funds_comm Description, if Char (255) N
ent funds_code is “O”
(Other).
from_foreign_curre This node aims at Type N See 7.16 Type
ncy specifying currency “t_foreign_curr “t_foreign_
details and is to be ency” currency”
used for all
transactions, i.e., for
CHF and foreign
currency transactions
from_account Subnode that holds Type See 7.2 Type
account information “t_account” “t_account”
from_person Subnode that holds Type See 7.10
Y
“from person” “t_person” Type
(one
information “t_person”
of
from_entity Subnode that holds Type See 7.8
them)
“from entity” “t_entity” Type
information “t_entity”
from_country Country where Enumeration N See 8.14
transaction was Country Codes
initiated
Table 17: Details node t_from

6.7 Node “t_to_my_client”

This node should be provided if the destination side of the transaction is the reported
subject and client of the reporting entity.

Figure 7: Overview node t_to_my_client

Seite 34 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

Name Description Length Req. Example

to_funds_code Disposition of funds Enumeration Y See 8.2
Funds type
to_funds_comment Description, if Char (255) N
to_funds_code is “O”
(Other).
To_transaction_ad Supporting info Type N See 8.26
ditional_info regarding the transaction_ad additional_info
transaction ditional_info

to_foreign_ Specifies currency Type Y See 7.16

currency details and must be “t_foreign_cu Type
used for all rrency” “t_foreign_
transactions, i.e. for currency”
CHF and foreign
currency transactions

to_account Subnode that holds Type See 7.1 Type

account information “t_account_m “t_account_
y_client” Y my_client”
to_person Subnode that holds Type (one 7.4 Type
person information “t_person_my of “t_account_
them)
_client” related_
person ”
(my_client)
to_entity Subnode that holds “to Type 7.3 Type
entity” information “t_entity_my_ “t_account_
client” related_
entity”
to_country Target country of the Enumeration N See 8.14
transaction Country
Codes
Table 18: Details node t_to_my_client

6.7.1. Business rules for Node “t_to_my_client”

Name Business rule (short description)
to_account The following business rule is only applicable, if the business
type of your institution corresponds to one of the following:

Bank or VASP

IF “Transaction type” does not equal “MULTIPARTY Dummy” OR

“report_indicators” does not equal “0003M” (Art. 9 para. 1 letter b
AMLA), THEN node "from_account" or “to_account” is mandatory.

Table 19: Business rules for Node t_to_my_client

Seite 35 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

6.8 Node “t_to”

Information about the transaction disposition(s) - i.e., where the money went. “t_to”
can point either to a person or to an account. See also the descriptions in chapter 6.3.

Figure 8: Overview node t_to

Name Description Length Req. Example

to_funds_code Disposition of funds Enumeration Y See 8.2
Funds type
to_funds_comment Description, if to_funds_code Char (255) N
is “O” (Other).
to_foreign_currency This node aims at specifying Type N See 7.16
currency details and is to be “t_foreign_cur Type
used for all transactions, i.e., rency” “t_foreign_
for CHF and foreign currency currency”
transactions
to_account Subnode that holds Type See 7.2
account information “t_account” Type
Y “t_accoun
(one t”
to_person Subnode that holds person Type of See 7.10
information “t_person” the Type
m) “t_person”
to_entity Subnode that holds “to Type See 7.8
entity” information. “t_entity” Type
“t_entity”
to_country Target country of the Enumeration N See 8.14
transaction Country
Codes
Table 20: Details node t_to

6.9 Subnode “goods_services”

This node Goods and Services is used to record the traded goods or services that are
the subject of reports submitted by dealers according to Art. 8a AMLA reporting

Seite 36 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
suspicious activities according to Art. 9 para 1a AMLA. Hence, it must not be used
by financial intermediaries.

Figure 9: Overview subnode goods_services

Hint: Type t_trans_item is the same as subnode goods, see Figure 9: Overview subnode
goods_services

Name Description Length Req. Example

item_type Lookup code Type Y See 8.12
describes the item “trans_item Transaction
type _type” Item Type
item_make Item Maker Char (255) Y In case of
a car e.g.,
BMW

description Text Char (8000) Y Apartment

building
previously_registered Name of seller Char (500) N John Miller
_to
presently_registered Name of buyer Char (500) Y Jane Smith
_to
estimated_value Estimated value of Decimal N 250,000.00
the property – Used
(Currency is the one
specified in node
from_currency)
status_code Status code Enumeration N See 8.8
Transaction
Item Status /
Property
Status
status_comments Status Comments. Char (500) N
Seite 37 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
disposed_value effective value for Decimal N 500000.00
property transfer – Used
Currency is the one
specified in node
from_currency
currency_code Currency of Enumeration Y See 8.13
“estimated value” or Currencies
“disposed_value”
size Size of the property – in Decimal N 150
unit specified in node
size_uom
size_uom Unit of measurement Char (250) N Square
meters
address Address of the property Type N See 7.14
“t_address” Type
“t_address”
registration_date Official registration date Date N
registration_number Official registration Char (500) N Car VIN
number Number
identification_number Any number that can Char (255) N Car Plate
identify the item Number
comments Additional comments Char (8000) Y
Additional information
(Art. 19 GwV)
Table 21: Details subnode goods_services

6.9.1. Business rules for Node “goods_services”

Name Business rule (short description)
Estimated_value Either estimated_value or disposed_value must be given
Disposed_value Either disposed_value or estimated_value must be given
Status_comments If item_type or status_code equals “other”, then mandatory
address If field “Item_type” is “Property”, then field “address” is mandatory
Table 22: Business rules for Node “goods_services”

Seite 38 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

7. Description of Common Types Used in the Schema

7.1 Type “t_account_my_client”

Figure 10: Overview type t_account_my_client

Seite 39 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
Description Length Req. Example
Name
institution_name The name of Char (255) Bank XY
Y
the account
holding Bank
swift BIC Number Char (11) Y
collection_account Indicate if collection Boolean N
account

branch Canton of Char (2) Y e.g., BE

relation- See 8.20 for
ship Allowed
values for
Cantons
account_category Select a Type Y e.g., Mobile
category “account_
of account category”
account Account number Char (255) Y 31032027088
currency_code Currency the Enumeration Y See 8.13
account is kept Currencies
in
Account_funds Information on the Type N
currency, balance “account_
and date of an fund”
account
account_name This is a free text field Char (255) N “Vacation”,
used to “label” the “Household
account, budget”,
“Invoices”

iban IBAN Char (34) Y LT6010100123

45678901
client_number Client number / Char (30) Y 31032027088
Stammnummer
account_type Account type Type Y See 8.3
“account_ty Account
pe” Type
t_entity Business entity Type N See 7.7 Type
owning the “t_entity_my “t_entity_my_cl
account _client” ient”
related_entity Related entity Type N See 7.8 Type
“entity_my_ “t_entity”
client”
related_persons Subnode holding Type Y See 7.9 Type
detailed “t_person_ “t_person_my
information about my_client” _client”
the signatory. for account_

Seite 40 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
Mandatory for person_
signatories in the relation
XML report.
related_accounts Identifies related N Virtual IBAN,
accounts QR-IBAN,
personalisierte
IBAN, Crypto,
Mobile Money,
etc.
opened Date account Date Y
opened
closed Date account closed Date N
balance The account Decimal N 5,000.50
balance in CHF at
date of reporting
date_balance Specify the date of Date N
the reported balance.
Application will
show balance
history
status_code Account status Enumeration Y See 8.4
when transaction Account
was initiated status type
beneficiary Balance of account Decimal N E.g., 30,500.00
in foreign currency
beneficiary_ City of relationship Char (255) Y E.g., Lugano
comment
comments Generic Char (8000) N
comments
elements
Table 23: Details type t_account_my_client

7.1.1. Business rules for t_account_my_client

Name Business rule (short description)
Related persons Related person must always be chosen
Closed If no balance is given, then mandatory
If report type is CANCL/CANCT:
Value “Date of closing” is mandatory
Date_balance If balance is given, then mandatory
Status_Code If field “closed” is not blank, then field “status_code” must equal
value “Closed”

If report type is CANCL/CANCT:

Value “Closed” is mandatory
Beneficiary If [“currency_code” is not “CHF” and “status_code” is not
“closed”] and if “personal_account_type” is not “safe depositbox”,
then “Beneficiary” is mandatory

Seite 41 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
from_account The following business rule is only applicable if the
business type registered for your institution in
goAMLcorresponds to one of the following:
Bank or VASP

IF “Transaction mode” does not equal “MULTIPARTY Dummy”

OR “report_indicators” does not equal “0003M” (Art. 9 para. 1
letter b AMLA), THEN node "from_account" or “to_account” is
mandatory.
Comments If _account_type equals “other”, then mandatory
Table 24: Business rules for t_account_my_client

7.1.2. Restriction in xsd-Schema for t_account_my_client

Balance If a value is entered in the “Balance” field of a “my client” account
(reported subject), then a value must also be entered in
“Date_Balance” and vice versa
Table 25: Restricion in xsd-Schema for t_account_my_client

Seite 42 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
7.2 Type “t_account”

Figure 11: Overview type t_account

Seite 43 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

Name Description Length Req. Example

institution_ The name of the account Char (255) Bank XY
Y
name holding Bank
swift BIC Number Char (11) Y
account Account number / Char (255) Y 31032027088
IBAN
comments Details of account Char (8000) Y John Doe, Main
owner/transaction Street, Timbuktu,
counterparty as Mali
available from payment
system (e.g., content of
SWIFT field 50a
“Ordering Customer” or
59a “Beneficiary
Customer”): name and
address, if
available, else “n/a”
Table 26: Details type t_account

7.3 Type “t_account_related_entity”

Figure 12: Overview type t_account_related_entity

Name Description Length Req. Example

account_entity_ Relation of the entity Enumeration N See 8.22
relation to the account Account_entity
_relation
entity Name of the Type t_entity N Abc Inc.
entity

relation_date_range Date range of Date range N

the relation

comments Generic comments Char (8000) N

field

Table 27: Details type t_account_related_entity

Seite 44 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

7.4 Type “t_account_related_person” (my_client)

Figure 13: Overview type t_account_related_person (my_client)

Name Description Length Req. Example

is_primary Identifies the primary Boolean N
account holder. Only one
related person should be
marked as is_primary. Has
to be ‘true’ when node is
set.

t_person Person Type t_person Y

role Role Enumeration Y See 8.15

Account
person role
type
Relation_date_r Date range Date N
ange

Comments General comments field Char (8000) N

Table 28: Details type t_account_related_person (my_client)

7.5 Type “t_account_related_account”

This node is foreseen to hold alternative account information related to a reported
account, such as for instance a second virtual IBAN used for a specific account.

Figure 15: Overview type t_account_related_account

Seite 45 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

Name Description Length Req. Example

Account_account_ Type of relation Enumeration See 8.21
relation Account-
Account
relation type
account Account Type t_account N

relation_date_range Date range of Date range N

the relation

comments Generic comments Char (8000) N

field

Table 29: Details type t_account_related_account

7.6 Type “t_account_funds”

Figure 16: Overview type t_account_funds

Name Description Length Req. Example

Account_fund Fund of the account Type N
account_fund (Yes if
node is
active)
Currency_code Currency code Enumeration N See 8.13
(Yes if currency
node is codes
active)
Currency_balance Balance Decimal N
(Yes if
node is
active)
Currency_balance_ Balance date Date N
date (Yes if
node is
active)
Table 30: Details type t_account_funds

Seite 46 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

7.7 Type “t_entity_my_client”

Figure 17: Overview type t_entity_my_client

Seite 47 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
Name Description Length Req. Example
name Name of Entity Char (255) Y Doe Inc.
commercial_name Short version of the Char (255) N
entityname (company
abbreviation)
incorporation_ The legal form of Type Y See 8.11
legal_form theentity “legal_for Entity Legal
m_type” Form Type
incorporation_ The registration number Char (50) N UUID-Nr.
number of the entity / 12345
"company" in the
relevant authority (e.g.
Chamber of Commerce)
business Business area of the Char (255) N Free text
entity describing
business e.g.
,IT Services
addresses A Holder node Type Y See 7.14
for a1...many “t_addres s” Type
Addresses “t_address”
emails Email Type “email_ N
addresses address”
Char (255)
URLs Websites Type “url- N
address”
Char (255)
Incorporation state State of incorporation Char (155) N

incorporation_ Country of Enumeration Y See 8.14

country_code incorporation Country
Codes
incorporation_date Incorporation Date N
registrationdate
business_closed Boolean to indicate if Boolean N
thecompany is
closed down
date_business_ If entity is closed Date N
closed thenspecify close
date.
tax_reg_number Is it a domicile Char (100) Y See 8.27
company?8 Allowed
values for
fields with
yes/no
answers
comments Generic comments field Char N
(8000)
Table 31: Details type t_entity_my_client

8 Financial intermediaries are required to comply with the special due diligence obligations in connection with domicile companies pursuant to Art. 2
lit. a para. 1 and 2 and Art. 13 AMLO-FINMA.

Seite 48 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
7.7.1. Business rules for t_entity_my_client
Name Business rule (short description)
Date_business_closed If field business_closed equals Y, then specify close date
Comments If incorporation_legal_form equals “other”, then specify
Table 32: Business rules t_entity_my_client

Seite 49 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

7.8 Type “t_entity”

Figure 18: Overview type t_entity

Seite 50 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

Name Description Length Req. Example

name Name of Entity Char (255) Y Doe Inc.
commercial_name Short version of the Char (255) N
entity name (company
abbreviation)

incorporation_legal The legal form of the Type N See 8.11

_form entity “legal_form_ Entity
type” Legal Form
Type
incorporation_ The registration number of Char (50) N UUID-Nr.
number the entity / "company"at 12345
the relevant authority (e.g.
Chamber of Commerce)

addresses A Holder node for a N

1...many Addresses
address One occurrence of Type N See 7.14
address node “t_address” Type
“t_addres
s”
incorporation_ Country of incorporation Enumeration N 8.14
country_code Country
Codes
comments Generic comments field Char (8000) N
Table 33: Details type t_entity

Seite 51 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
7.9 Type “t_person_my_client”

Figure 19: Overview type t_person_my_client

Seite 52 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

Name Description Length Req. Example

gender Gender Enumeration Y See 8.19
Gender type
Title Title Char (30) N Professor
first_name First name Char (100) Y Hans
middle_name Middle name Char (100) N Peter
last_name Last name of Char (100) Y Muster
person
birthdate Birth date of Date Y 2023/09/24
person
birth_place Place of origin for Char (255) N Olten
Swiss citizens /
Place of birth for
other
Country_of_birth Country of birth Enumeration N Malta

Previous_names Subnode that holds Type N See 7.10 Type

person information “t_person” “t_person”

This node can be

used to register
different names
(such as alternative
spellings or
previous names) of
a persons’ name.
nationality1 9 Country of Enumeration Y See 8.14
nationality Country
Codes
nationality2 Country of Enumeration N See 8.14
Nationality (2) Country Codes
nationality3 Country of Enumeration N See 8.14
Nationality (3) Country Codes
phones A Holder node for a N
1…many Phones
phone One occurrence of Type “t_phone” N See 7.15 Type
phone node “t_phone”
addresses A Holder node for Y
a 1…many
Addresses
address One occurrence of Type Y See 7.14 Type
address node “t_address” “t_address”
emails Email addresses Type N
“email_address”
(Char 255)

9If the person in question is of Swiss nationality and possesses additional nationalities, use the nationality1 field for the Swiss nationality and the
nationality 2 to 3 fields for the remaining nationalities in alphabetical order of the corresponding country codes.
Seite 53 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
occupation Occupation Char (255) N Financial
Analyst
employer_name Employer’s name Char (255) N Bank Y
employer_address_id Employer’s address Type N See 7.14 Type
“t_address” “t_address”
Employment_history Type “t_employer” N

Identifications Subnode(s) for Type Y See 7.17 Type

identification “t_person_iden “t_person_id
documents tification” (This entification”
subnode can be
repeated to
specify multiple
identification
documents)
deceased A Boolean to Boolean N
indicate if person
has passed away
(should only be set
if person is
deceased)
date_deceased If deceased, then Date N Since CH
RE must report 1.1.4 this is
deceased date no longera
mandatory
field but is
checked by a
business rule
peps Politically exposed Type “pep_details” N
persons (PEP)

comments Generic comments Char (8000) N Provide

field additional info
you deem
relevant, e.g.
changed his
name and
nationality
Table 34: Details type t_person_my_client

7.9.1. Business rules for t_person_my_client

Name Business rule (short description)
Deceased_date_mandatory If field “deceased” has been checked, then the field
“date_deceased” is mandatory
Table 35: Business rules for t_person_my_client

Seite 54 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
7.10 Type “t_person”

Figure 20: Overview type t_person

Seite 55 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

Name Description Length Req. Example

gender Gender Enumeration N See 8.19
Gender type
first_name First name (enter Char (100) Y Hans
“n/a” if an entity
isbeing
registered)
middle_name Middle name Char (100) N Peter
last_name Last name of Char (100) Y Muster
person / name
of entity
birthdate Birth date of person Date N

birth_place Heimatort for Char (255) N Olten

Swiss citizen /
Place of birth
Country_of_birth Country of birth Char (255) N Malta

Previous_names Subnode that holds Type See 7.10 Type

personinformation “t_person” “t_person”

This node can be

used to register
different names
(such as alternative
spellings or
previous names) of
a persons’ name.
nationality1 10 Country of Enumeration N See 8.14
nationality/incorpora Country Codes
tion (1)
nationality2 Country of Enumeration N See 8.14
Nationality Country Codes
(2)
nationality3 Country of Enumeration N See 8.14
Nationality Country Codes
(3)
addresses A Holder node for N
a 1…many
Addresses
address One occurrence Type N See 7.14 Type
of address node “t_address” “t_address”

10Ifthe person in question is of Swiss nationality and possesses additional nationalities, use the nationality1 field for the Swiss nationality and the
nationality 2 to 3 fields for the remaining nationalities in alphabetical order of the corresponding country codes.
Seite 56 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
identifications Subnode(s) Type N See 7.17 Type
for “t_person_id “t_person_identi
identification entification” fication”
documents (This subnode
can be repeated
to specify
multiple
identification
documents)

comments Generic Char (8000) N Provide additional

comments field info you deem
relevant, e.g.,
changed his
name and
nationality
Table 36: Details type t_person

7.11 Type “t_peps”

Figure 21: Overview type t_peps

Name Description Length Req. Example

pep_country Country of function Enumeration Y

function_name Name of the function Char (255) Y Member of

the
government
function_description Description Char (8000) Y Minister of
the Defense

pep_date_range Date range of the Date range N

function
comments Generic comments Char (8000) N Provide
field comments you
consider
relevant: e.g.
for years, X
was the
closest person
to President Y
of country Z
Table 37: Details Type t_peps
Seite 57 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

7.12 Type t_person_registration_in_report

The structure of t_person_registration_in_report is similar to the one of type t_person,
however, adapted to the person submitting the report to MROS.

Figure 22: Overview t_person_registration_in_report

Seite 58 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

Name Description Length Req. Example

gender Gender Enumeration N See 8.19
Gender type
first_name First name Char (100) Y Hans
last_name Last name Char (100) Y Muster
phones A Holder node for a Y
1…many Phones
phone One occurrence of Type Y See 7.15 Type
phone node “t_phone” “t_phone”
Email Email address Type Y hans.muster@x
“t_email_ yz.com
address”
comments Generic comments Char (8000) N
field
Table 38: Details Type t_person_registration_in_report

7.13 Type “t_party”

Figure 23: Overview type t_party

Seite 59 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
Name Description Length Req. Example
role Subject role in the Enumeration Y See 8.17 Party
transaction role Type
person Involved Person Type “t_person” Y See 7.10 Type
(One “t_person”
person_my_client Involved Person Type of See 7.9 Type
“t_person_my_ them “t_person_my_
client” must client”
account Involved Account Type be See 7.2 Type
“t_account” selec “t_account”
account_my_client Involved Account Type ted See 7.1 Type
“t_account_my_ and “t_account_my
client” of _client”
entity Involved Entity Type “t_entity” type See 7.8 Type
my_c “t_entity”
entity_my_client Involved Entity Type lient) See 7.7 Type
“t_entity_my_ “t_entity_my_
client” client”
funds_code Type of funds Enumeration Y See 8.2 Funds
used in initiating type
transaction
funds_comment Additional Char (255) N
information to the
funds_code if
funds_type is
“other”.
foreign_currency If the transaction is Type “t_foreign_ N See 7.16 Type
conducted in currency” “t_foreign_curre
foreign currency, ncy”
then specify the
foreign currency
details.
country Country Enumeration N See 8.14
Country Codes
comments Provide additional Char (8000) Y
information to the
role and the
background of
the involved
person
Table 39: Details type t_party

7.13.1 Business rules for t_party

Name Business rule (short description)
Funds_code If funds_code is not “MULTIPARTY Dummy”, then reject.
Table 40: Business rules for t_party

Seite 60 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
7.14 Type “t_address”

Figure 24: Overview type t_address

Name Description Length Req. Example

address_type The contact type of Enumeration Y e.g., Private
the address see 8.9 Phone
Address Type

address Street name and Char (100) Y

house number
city City Char (255) Y e.g., Bern
(please no
combination of
zip + city)
zip Zip Char (10) N e.g., 3008
(please no
combination of
country +zip)
country_code Country Enumeration Y See 8.14
Country
Codes
state Canton Type N For Swiss
“state_type” addresses
Char (2) provide Canton
exclusively as a
two-character
code (e.g., GE,
TI etc.).
See 8.20
Seite 61 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
Allowed values
for Cantons

Note: For foreign

addresses
provide name of
State,
Prefecture,
District, etc.
comments Generic comments Char (8000) N
Table 41: Details type t_address

7.15 Type “t_phone”

Figure 25: Overview type t_phone

Name Description Length Req. Example

tph_contact_type The contact type Enumeration Y See 8.9 Phone
of the Phone Address Type
tph_communication_ Communication Enumeration Y See 8.10
type type of the Phone Communication
Type
tph_country_prefix Country phone Char (4) N ++41
code
tph_number Phone number Char (50) Y 0794587798;
Provide phone
number without
special characters
and country codes.
Register the country
code in the
dedicated
tph_country_prefix-
field only
comments Generic comments Char (8000) N
Table 42: Details type t_phone

Seite 62 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

7.16 Type “t_foreign_currency”

Figure 26: Overview type t_foreign_currency

Name Description Length Req. Example

foreign_currency_code Currency Code Enumeration Y See 8.14
according to ISO Country
4217 Codes
foreign_amount Transaction amount Decimal Y 1300.50
in original currency
(CHF or foreign
currency depending
on transaction)
foreign_exchange_rate Exchange rate used Integer Y Must be set
for transaction to 1
Table 43: Details type t_foreign_currency

7.16.1 Business rules for t_foreign_currency

Name Business rule (short description)
foreign_amount If transaction_type equals “MULTIPARTY Dummy”, then field
“foreign_amount” must be zero (0)
Table 44: Business rules t_foreign currency

7.17 Type “t_person_identification”

This chapter is dedicated to the documents that allow to identify subjects (individuals)
such as passports, national IDs, driver licenses or any other legal document. If more
than one identification is available, please provide all of them

Figure 27: Overview type t_person_identification

Seite 63 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

Name Description Length Req. Example

type Document type Enumeration Y See 8.5 Identifier
type
number ID of the identification Char (255) Y AT08154711
document
issue_date Identification document Date N
issue date
expiry_date Identification document Date N
expiry date
issued_by Name of Authority issued Char (255) N Interior Ministry
the document
issue_country Country where the Enumeration Y See 8.14 Country
document was issued Codes
comments Generic comments field Char (8000) N
Table 45: Details type t_person_identification

7.17.1 Business rules for t_person_identification

Name Business rule (short description)
comments If type is “other”, then give additional information
Table 46: Business rules t_person_identification

7.18 Type “report_party_type”

Represents an involved subject in a report and its details. Subject can be a Person, an
Account or an Entity – one of them must be included per involved party.

Figure 28: Overview report_party_type

Seite 64 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
Name Description Length Req. Example
role Role Enumeration Y See 8.28
Report_Party
role
person Involved person Type N See 7.10 Type
“t_person” “t_person”
person_my_ Person as reported subject Type N See 7.9 Type
client (my client) “t_person_my “t_person_my
_client” _client”
account Involved account Type N See 7.2 Type
“t_account” “t_account”
account_my_ Account as reported subject Type N See 7.1 Type
client (my client) “t_account_ “t_account_my
my_client” _client”
entity Involved entity Type N See 7.8 Type
“t_entity” “t_entity”
entity_my_ Type N See 7.7 Type
client “t_entity_my_ “t_entity_my_c
client” lient”
country Type N See 8.13
“t_country” Country
Codes
reason Register additional Char (8000) N
information to the role of
the corresponding subject.
comments Generic comments; e.g., Char (8000) N
why the subject is involved
in the current report.
Table 47: Details report_party_type

7.18.1. Business rules for t_report_party_type

Name Business rule (short description)
if SAR and indicator is not ‘0003M’, then either
“account_my_client”, “person_my_client” or “entity_my client” is
mandatory. If “entity my client”, then “person my client” is
mandatory.
Table 48: Business rules t_report_party_type

7.19 Type t_trans_item

For information on this Type, please look at 6.9 Subnode “goods_services”.

Seite 65 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
7.20 Type generic additional information type
A new optional generic node for adding any number of unplanned extra information in a controlled
way.

Figure 29: Overview generic_additional_information_type

Name Description Length Req. Example

info_type Type of the provided info Enumeration Y See 8.26
Additional
information
type
Info_numeric Number of reported business decimal Y 5
relationships
Table 49: Details generic_additional_information_type

Seite 66 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
8. Lookup Values
All schema lookups are defined as enumerations. The goAML application has the option to
update the schema automatically with the lookup codes defined by the FIU in the “Lookup
Master” screen. Reporting entities will not be able to submit reports with undefined lookup
codes.

The lookups mentioned in the following chapters reflect the lookup tables defined by FIU
Switzerland.

8.1 Submission type

Value Description
E Electronically
Table 50: submission type

8.2 Funds type

Value Description
2 Virtual Assets (Crypto)
6 Precious metals
14 Casino chips
20 Securities
23 Cheque
25 MULTIPARTY Dummy
26 Cash
27 Fiat money
Table 51: Funds type

8.3 Account type

Value Description
1 Business account
2 Current account
5 Capital payment account
6 Precious metals account
7 Commodity account
8 Loan account
9 Credit card account
10 Debit card account
12 Insurance policy
13 Custody account (Securities)
14 Other
15 Savings account
17 Safe deposit box
18 Custody Account (Virtual Assets)
19 External-Custodial Address (Virtual Assets)
20 Fiat Custody Account for VASP
Table 52: Account type

Seite 67 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

8.4 Account status type

Value Description
1 Active
2 Closed
3 Dormant
4 Unknown
Table 53: Account status type

8.5 Identification type

Value Description
1 Driver's license
2 Identity Card
3 Passport
4 Other
5 Residence permit
6 Commercial register
Table 54: Identification type

8.6 Transaction Type

Value Description
B2BWT Bank2Bank wire transfer
FXOFC Currency exchange office
DEPAC Deposit (ATM or Counter)
WITHD Withdrawal (ATM or Counter)
INTAT Internal Account transfer
MOMOT Money transfer by cell phone
POSAL POS (Point of Sale)
PREMT Precious metals (sale or purchase)
SECCA Securities (dividends or corporate actions)
SECSP Securities (sale or purchase)
SECIO Securities (transfer in or out)
VASSP Virtual assets (sale or purchase)
VASIO Virtual assets (transfer in or out)
MUPAD MultiParty Dummy
CASHT Cash money transfer
Table 55: Transaction Type

8.7 Transaction Item Status / Property Status

Value Description
1 UNKNOWN
2 Bought
3 Sold
4 Let
5 Hired
6 Exchanged
7 Donated
8 Destroyed
9 Other
Table 56: Transaction Item Status

Seite 68 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

8.8 Report Code

Value Description
STR Suspicious Transaction Report (with transactions)
SAR Suspicious Activity Report (without transactions)
AIF AIF - Additional information based on art. 11a para. 1 / 2 / 3 AMLA
(without transactions)
AIFT AIFT - Additional information based on art. 11a para. 1 / 2 / 3 AMLA (with
transactions)
CANCL Termination of a business relationship based on art. 9b AMLA (without
transactions)
CANCT Termination of a business relationship based on art. 9b AMLA (with
transactions)
IRD Incoming request for information 11
ISD Incoming spontaneous disclosure of information 12
Table 57: Report Code

8.9 Phone Address Type

Value Description
1 Unknown
2 Other
3 Private
4 Business
Table 58: Contact Type

8.10 Communication Type

Value Description
1 Landline Phone
2 Mobile Phone
3 E-Mail
4 Other
5 Fax
6 Unknown
Table 59: Communication Type

8.11 Entity Legal Form Type

Value Description
1 Unknown
2 Association (bisher NGO)
3 Charity
4 Other
5 Trust
6 Sovereign wealth fund
7 Investment company
8 Limited
9 LLC
10 Single-member company
11 Partnership
12 Private limited partnership

11 Only relevant for authorities / REs do not have this report type available
12 Only relevant for authorities / REs do not have this report type available
Seite 69 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
13 Club
14 Foundation
15 Cooperative
16 Simple partnership
17 Holding
18 Public law corporation (OERK)
Table 60: Legal Form Type

8.12 Transaction Item Type

Value Description
1 Unknown
2 Other
3 Equipment
4 Object of art
5 Furniture
6 Jewellery
7 Property
8 Vehicle
9 Weapon
Table 61: Transaction Item Type

8.13 Currency codes

World Currencies listed by ISO 4217
Value Description
AFN Afghan afghani
DZD Algerian Dinar
AOA Angolan kwanza
ARS Argentinean Nuevo Peso
AWG Aruban Guilder
AUD Australian Dollar
AZN Azerbaijani manat
BSD Bahamian Dollar
BHD Bahraini Dinar
THB Baht
PAB Balboa
BBD Barbados Dollar
BYR Belarussian Rouble
BZD Belize Dollar
BMD Bermudian Dollar
BTC Bitcoin
BOB Boliviano
BND Brunei Dollar
BGN Bulgarian lev
BIF Burundi Franc
CAD Canadian Dollar
KYD Cayman Islands Dollar
CLP Chilean Peso
XTS Code reserved for testing purposes
COP Colombian Peso
Seite 70 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
KMF Comorian Franc
CDF Congolese franc
BEC Convertible Belgian Franc (no longer in use)
BAM Convertible Mark
NIO Cordoba oro
CRC Costa Rican Colón
HRK Croatian Kuna
CUP Cuban Peso
CZK Czech Koruna
GMD Dalasi
DKK Danish Krone
KPW Democratic People's Republic of Korean Won
DJF Djibouti Franc
STD Dobra
XDG Dogecoin
DOP Dominican Republic Peso
AMD Dram
XCD East Caribbean Dollar
EGP Egyptian Pound
ERN Eritrean Nakfa
CVE Escudo Caboverdiano
ETH Ethereum
ETB Ethiopian Birr
EUR Euro (replacement name for the ECU)
XBA European Composite Unit
XBB European Monetary Unit
XBD European Unit of Account 17
XBC European Unit of Account 9
FKP Falkland Pound
FJD Fiji Dollar
BEL Financial Belgian Franc (no longer in use)
HUF Forint
XAF Franc de la Communauté financière africaine
XPF Franc des Comptoirs français du Pacifique
GHS Ghanaian cedi
GIP Gibraltar Pound
XAU Gold
HTG Gourde
PYG Guarani
GNF Guinean franc
GYD Guyana Dollar
HKD Hong Kong Dollar
UAH Hryvna
ISK Icelandic Króna
UKP Incorrectly used for GBP
INR Indian Rupee
XDR International Monetary Fund Special Drawing Rights

Seite 71 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
IRR Iranian Rial
IQD Iraqi Dinar
JMD Jamaican Dollar
JOD Jordanian Dinar
KES Kenyan Shilling
PGK Kina
LAK Kip
EEK Kroon
KWD Kuwaiti Dinar
AOK Kwanza
MMK Kyat
KGS Kyrgyzstani Som
GEL Lari
LVL Lats
LBP Lebanese Pound
ALL Lek
HNL Lempira
SLL Leone
LRD Liberian Dollar
LYD Libyan Dinar
SZL Lilangeni
LTL Litas
LTC Litecoin
LSL Loti
MKD Macedonian Dinar
MGA Malagasy ariary
MWK Malawian Kwacha
LSM Maloti
MTP Maltese Pound, replaced by Maltese Lira
MUR Mauritius Rupee
MXN Mexican New Peso (replacement for Mexican Peso)
MDL Moldavian Leu
MAD Moroccan Dirham
MZN Mozambican metical
NGN Naira
NAD Namibian Dollar
NPR Nepalese Rupee
ANG Netherlands Antilles Guilder
PEN New Sol
CDZ New Zaïre
NZD New Zealand Dollar
PLN New Zloty
BTN Ngultrum
NOK Norwegian Krone
OMR Omani Rial
OVC Other Virtual Currencies
MRO Ouguiya

Seite 72 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
TOP Pa'anga
PKR Pakistani Rupee
XPD Palladium (one troy ounce)
MOP Pataca
PHP Philippines Peso
XPT Platinum (one troy ounce)
GBP Pound Sterling (United Kingdom Pound)
BWP Pula
QAR Qatari Riyal
GTQ Quetzal
ZAR Rand
BRL Real
BUK Replaced by MMK
KRW Republic of Korean Won
KHR Riel
MYR Ringgit (also known as Malaysian Dollar)
RON Romanian new leu
MVR Rufiyaa
IDR Rupiah
RUB Russian Federation Rouble (formerly RUR)
RWF Rwandan Franc
SAR Saudi Riyal
RSD Serbian dinar
SCR Seychelles Rupee
ILS Shekel
XAG Silver (one troy ounce)
SGD Singapore Dollar
PES Sol (replaced by New Sol [PEN])
SBD Solomon Islands Dollar
SOS Somali Shilling
SSP South Sudanese Pound
LKR Sri Lankan Rupee
SHP St Helena Pound
XLM Stellar
SDG Sudanese pound
SRD Surinamese dollar
SEK Swedish Krona
CHF Swiss Franc
GNS Syli (also known as Guinea Franc)
SYP Syrian Pound
TWD Taiwan Dollar
TJS Tajikistani somoni
BDT Taka
WST Tala
TZS Tanzanian Shilling
KZT Tenge
USDT Tether

Seite 73 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
TPE Timorian Escudo
TTD Trinidad and Tobago Dollar
MNT Tugrik
TND Tunisian Dinar
TRY Turkish lira
TMT Turkmenistani manat
UGX Ugandan shilling
XFU UIC franc (special settlement currency)
COU Unidad de Valor Real
CLF Unidades de Fomento
AED United Arab Emirates Dirham
USD United States Dollar
USN United States Dollar (Next day)
USS United States Dollar (Same day)
UYU Uruguayan New Peso
UYP Uruguayan Peso, replaced by Uruguayan New Peso (UYU)
UZS Uzbekistani Som
VUV Vatu
VEF Venezuelan bolívar fuerte
VND Viet Nam Dông
XOF West African Franc
CHW WIR Bank (complementary currency)
CHE WIR Bank (complementary currency)
XRP XRP
YER Yemeni Riyal
JPY Yen
CNY Yuan Renminbi
ZMW Zambian Kwacha
ZMK Zambian Kwacha (obsolete)
Table 62: Currency Codes

8.14 Country Codes

This list shows the country names (official short names in English) in alphabetical order as
given in ISO 3166-1 and the corresponding ISO 3166-1-alpha-2 code elements.

Value Description
AD ANDORRA
AE UNITED ARAB EMIRATES
AF AFGHANISTAN
AG ANTIGUA AND BARBUDA
AI ANGUILLA
AL ALBANIA
AM ARMENIA
AN NETHERLANDS ANTILLES
AO ANGOLA
AQ ANTARCTICA
AR ARGENTINA
AS AMERICAN SAMOA

Seite 74 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
AT AUSTRIA
AU AUSTRALIA
AW ARUBA
AX ÅLAND ISLANDS
AZ AZERBAIJAN
BA BOSNIA AND HERZEGOVINA
BB BARBADOS
BD BANGLADESH
BE BELGIUM
BF BURKINA FASO
BG BULGARIA
BH BAHRAIN
BI BURUNDI
BJ BENIN
BL SAINT BARTHÉLEMY
BM BERMUDA
BN BRUNEI DARUSSALAM
BO BOLIVIA
BQ BONAIRE, SAINT EUSTATIUS AND SABA
BR BRAZIL
BS BAHAMAS
BT BHUTAN
BV BOUVET ISLAND
BW BOTSWANA
BY BELARUS
BZ BELIZE
CA CANADA
CC COCOS (KEELING) ISLANDS
CD CONGO, THE DEMOCRATIC REPUBLIC OF THE
CF CENTRAL AFRICAN REPUBLIC
CG CONGO
CH SWITZERLAND
CI COTE D'IVOIRE
CK COOK ISLANDS
CL CHILE
CM CAMEROON
CN CHINA
CO COLOMBIA
CR COSTA RICA
CU CUBA
CV CAPE VERDE
CW CURAÇAO
CX CHRISTMAS ISLAND
CY CYPRUS
CZ CZECH REPUBLIC
DE GERMANY
DJ DJIBOUTI
DK DENMARK
DM DOMINICA
DO DOMINICAN REPUBLIC
Seite 75 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
DZ ALGERIA
EC ECUADOR
EE ESTONIA
EG EGYPT
EH WESTERN SAHARA
ER ERITREA
ES SPAIN
ET ETHIOPIA
FI FINLAND
FJ FIJI
FK FALKLAND ISLANDS (MALVINAS)
FM MICRONESIA, FEDERATED STATES OF
FO FAROE ISLANDS
FR FRANCE
GA GABON
GB UNITED KINGDOM
GD GRENADA
GE GEORGIA
GF FRENCH GUIANA
GG GUERNSEY
GH GHANA
GI GIBRALTAR
GL GREENLAND
GM GAMBIA
GN GUINEA
GP GUADELOUPE
GQ EQUATORIAL GUINEA
GR GREECE
GS SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS
GT GUATEMALA
GU GUAM
GW GUINEA-BISSAU
GY GUYANA
HK HONG KONG
HM HEARD ISLAND AND MCDONALD ISLANDS
HN HONDURAS
HR CROATIA
HT HAITI
HU HUNGARY
ID INDONESIA
IE IRELAND
IL ISRAEL
IM ISLE OF MAN
IN INDIA
IO BRITISH INDIAN OCEAN TERRITORY
IQ IRAQ
IR IRAN, ISLAMIC REPUBLIC OF
IS ICELAND
IT ITALY
JE JERSEY
Seite 76 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
JM JAMAICA
JO JORDAN
JP JAPAN
KE KENYA
KG KYRGYZSTAN
KH CAMBODIA
KI KIRIBATI
KM COMOROS
KN SAINT KITTS AND NEVIS
KP KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OF
KR KOREA, REPUBLIC OF
KS KOSOVO (old – KS)
KW KUWAIT
KY CAYMAN ISLANDS
KZ KAZAKHSTAN
LA LAO PEOPLE'S DEMOCRATIC REPUBLIC
LB LEBANON
LC SAINT LUCIA
LI LIECHTENSTEIN
LK SRI LANKA
LR LIBERIA
LS LESOTHO
LT LITHUANIA
LU LUXEMBOURG
LV LATVIA
LY LIBYAN ARAB JAMAHIRIYA
MA MOROCCO
MC MONACO
MD MOLDOVA, REPUBLIC OF
ME MONTENEGRO
MF SAINT MARTIN (FRENCH PART)
MG MADAGASCAR
MH MARSHALL ISLANDS
MK MACEDONIA
ML MALI
MM MYANMAR
MN MONGOLIA
MO MACAO
MP NORTHERN MARIANA ISLANDS
MQ MARTINIQUE
MR MAURITANIA
MS MONTSERRAT
MT MALTA
MU MAURITIUS
MV MALDIVES
MW MALAWI
MX MEXICO
MY MALAYSIA
MZ MOZAMBIQUE
NA NAMIBIA
Seite 77 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
NC NEW CALEDONIA
NE NIGER
NF NORFOLK ISLAND
NG NIGERIA
NI NICARAGUA
NL NETHERLANDS
NO NORWAY
NP NEPAL
NR NAURU
NU NIUE
NZ NEW ZEALAND
OM OMAN
PA PANAMA
PE PERU
PF FRENCH POLYNESIA
PG PAPUA NEW GUINEA
PH PHILIPPINES
PK PAKISTAN
PL POLAND
PM SAINT PIERRE AND MIQUELON
PN PITCAIRN
PR PUERTO RICO
PS PALESTINIAN TERRITORY, OCCUPIED
PT PORTUGAL
PW PALAU
PY PARAGUAY
QA QATAR
RE REUNION
RO ROMANIA
RS SERBIA
RU RUSSIAN FEDERATION
RW RWANDA
SA SAUDI ARABIA
SB SOLOMON ISLANDS
SC SEYCHELLES
SD SUDAN
SE SWEDEN
SG SINGAPORE
SH SAINT HELENA
SI SLOVENIA
SJ SVALBARD AND JAN MAYEN
SK SLOVAKIA
SL SIERRA LEONE
SM SAN MARINO
SN SENEGAL
SO SOMALIA
SR SURINAME
SS SOUTH SUDAN
ST SAO TOME AND PRINCIPE
SV EL SALVADOR
Seite 78 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
SY SYRIAN ARAB REPUBLIC
SZ SWAZILAND
SX SINT MAARTEN (DUTCH PART)
TC TURKS AND CAICOS ISLANDS
TD CHAD
TF FRENCH SOUTHERN TERRITORIES
TG TOGO
TH THAILAND
TJ TAJIKISTAN
TK TOKELAU
TL TIMOR-LESTE
TM TURKMENISTAN
TN TUNISIA
TO TONGA
TR TURKEY
TT TRINIDAD AND TOBAGO
TV TUVALU
TW TAIWAN, PROVINCE OF CHINA
TZ TANZANIA, UNITED REPUBLIC OF
UA UKRAINE
UG UGANDA
UM UNITED STATES MINOR OUTLYING ISLANDS
UNK UNKNOWN
US UNITED STATES
UY URUGUAY
UZ UZBEKISTAN
VA HOLY SEE (VATICAN CITY STATE)
VC SAINT VINCENT AND THE GRENADINES
VE VENEZUELA
VG VIRGIN ISLANDS, BRITISH
VI VIRGIN ISLANDS, U.S.
VN VIET NAM
VU VANUATU
WF WALLIS AND FUTUNA
WS SAMOA
XK KOSOVO
YE YEMEN
YT MAYOTTE
ZA SOUTH AFRICA
ZM ZAMBIA
ZW ZIMBABWE
Table 63: Country Codes

Seite 79 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
8.15 Account person role type
Value Description
1 Addressee
6 Other
7 Control owner / Controller
13 Beneficial owner
14 Contracting party
15 Power of attorney / Authorised signatory
17 Sender of funds
18 Receiver of funds
19 Contracting party & Beneficial owner
20 Contracting party & Control owner/controller
21 Contracting party & Power of attorney / Authorised signatory
22 Beneficial Owner & Power of attorney / Authorised signatory
23 Control owner / controller & Power of attorney / Authorised signatory
Contracting party & Beneficial Owner & Power of attorney / Authorised
24 signatory
Contracting party & Control owner / controller & Power of attorney /
25 Authorised signatory
Table 64: account_person_role_type

8.16 Entity person role type

Value Description
2 CEO
3 Beneficial Owner
4 CFO
5 Power of attorney / Authorised signatory
6 Director
7 Settlor
8 Trustee
9 Protector
10 Trust
11 Guarantor
12 Member of management
13 Owner
14 Control owner / Controller
15 Partner
16 Other
17 Parent company
18 Subsidiary
19 Beneficiary
20 Board of Directors member / Board of Directors president
Table 65: entity_person_role_type

Seite 80 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

8.17 Party role type

Value Description
1 Unknown
2 CEO
3 CFO
4 Director
5 Settlor
6 Trustee
7 Protector
8 Trust
9 Guarantor
10 Member of management
11 Owner
12 Control owner / Controller
13 Partner
14 Other
15 Legal representative
16 Shareholder
17 Employer
18 Colleague
19 Acquaintance
20 Relative
21 Domicile holder
22 Company's founder
23 Business partner
24 Customer
25 Employee
26 President
27 Auditor
28 Member of the board
29 Supervisor
30 Buyer
31 Seller
32 Beneficiary
33 Prospect
Table 66: party_role_type

Seite 81 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
8.18 Report Indicators
This list contains more than only one category and is split in subchapters. These can be
differentiated by looking at the Code. All report types end with “M”, predicate offenses to
money laundering end with “V”; reasons for suspicion with “G” and attachments with “B”

Code Description
0001M Art. 305ter para. 2 SCC
0002M Art. 9 para. 1 letter a AMLA
0003M Art. 9 para. 1 letter b AMLA
0004M Art. 9 para. 1 letter c AMLA
0005M Art. 16 para. 1 letter a AMLA
0006M Art. 27 AMLA
0007M Art. 7 FIAA
0008M Art. 9 para. 1bis AMLA (merchants)
0009M Article 11a paragraph 1 and 3 AMLA
0010M Article 11a paragraph 2 and 3 AMLA
0011M For Swiss authorities: IRD (Request for info/Spontaneous dissemination of info)
0012M For foreign authorities: IRI (Request for info/Spontaneous dissemination of info)
0013M For Swiss authorities: Article 29a paragraph 1 AMLA
0014M For Swiss authorities: Article 29a paragraph 2 AMLA
0024M Termination of a business relationship pursuant to art. 9b AMLA
1001V Misappropriation (Art. 138 SCC)
1002V Theft (Art. 139 SCC)
1003V Unauthorized obtaining of data (Art. 143 SCC)
1004V Fraud (Art. 146 SCC)
1005V Computer fraud (Art. 147 SCC)
1006V Counterfeiting of goods (Art. 155 para. 2 SCC)
1007V Extortion (Art. 156 SCC)
1008V Criminal mismanagement (Art. 158 no 1 and 2 SCC)
1009V Trafficking in human beings (Art. 182 SCC)
1010V Counterfeiting money (Art. 240 para. 1 SCC)
1011V Import, acquisition and storage of counterfeit money (Art. 244 para. 2 SCC)
1013V Criminal organization (Art. 260ter SCC)
1014V Financing terrorism (Art. 260quinquies SCC)
1015V Abuse of public office (Art. 312 SCC)
1016V Misconduct in public office (Art. 314 SCC)
Federal Act on the Proscription of the Groups «Al-Qaeda» and «Islamic State»
1022V and Associated Organizations (Art. 2)
1073V Endangering public safety with weapons (Art. 260quater SCC)
1090V Forgery of military orders or instructions (Art. 277 no 1 SCC)
1091V Hostility towards a country at war or foreign troops (Art. 300 SCC)
1099V Infringement of a design right (Art. 41 para. 2 DesA)
1102V Patent infringement (Art. 81 para. 3 PatA)
1103V Agriculture Act (Art. 172 para. 2 AgricA)
1104V Topographies Act (Art. 11 para. 2 ToG)
1105V Federal Act on Foodstuffs and Utility Articles (Art. 63 para. 2 FSA)
1106V Therapeutic Products Act (Art. 86 para. 2 TPA)
1107V Sport Promotion Act (Art. 22 para. 2 and 3 SpoPA)
1108V Goods Control Act (Art. 14 para. 2 GCA)
1109V Gambling Act (Art. 130 para. 2 GamblA)
Seite 82 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
1110V Weapons Act (Art. 33 para. 3 WA)
Misdemeanors against Federal Act on the Implementation of International
1116V Sanctions (Art. 9 para. 2 EmbA)
1119V child trafficking (Art. 24 para. 2 HCAA)
1120V Transplantation Act (Art. 69 para. 2)
1121V Stem Cell Research Act (Art. 24 para. 3 StRA)
1124V Chemicals Act (Art. 49 para. 2 and 4 ChemA)
Federal Act on Illegal Employment, offences against official duty ( Art. 19
1125V BGSA)
1126V Collective Investment Schemes Act (Art. 148 para. 1bis CISA)
1127V Banking Act (Art. 47 para. 1bis BankA)
1128V Financial Institutions Act (Art. 69 para. 2 FSA)
1129V Endangering the health of another (Art. 63 para. 2 FSA)
1130V Aggravated tax misdemeanor (Art. 305bis no 1 and 1bis SCC)
1131V Not classifiable
1132V Art. 11a para. 1 and 3 AMLA
1133V Art. 11a para. 2 resp. 2bis and 3 AMLA
For Swiss authorities: IRD/ISD (Request for info/Spontaneous dissemination of
1134V info)
1135V For foreign authorities: IRI (Request for info/Spontaneous dissemination of info)
1136V For Swiss authorities: Art. 29a para. 1 AMLA
1137V For Swiss authorities: Art. 29a para. 1 AMLA
1138V Forgery of documents (art. 251 para.1, art. 253, art. 254, art. 317 para. 1 SCC)
1139V Corruption (Art. 322ter, Art. 322quater, Art. 322septies SCC)
1140V Narcotics Crimes (art. 19 para. 2, art. 2 para. 2 NarcA)
1141V Insider trading or market manipulation (art. 154 para. 2, art. 155 para. 2 FinMA)
Trademark law (art. 61 para. 3, art. 62 para. 2, art. 63 para. 4, art. 64 para. 2
1142V TmPA)
1143V Homicide offences (art. 111, art. 112, art. 113, art. 115 SCC)
1144V Personal injury (art. 122, art. 124 SCC)
1145V Endangering life and health (art. 127, art. 129, art. 134 SCC)
Other crimes against wealth (art. 140, art. 144bis para. 2, art. 148, art. 157, art.
1146V 160 SCC)
Bankruptcy and debt collection crimes (art. 163 para. 1, art. 164 para. 1, art.
1147V 165, art. 171 para. 1 SCC)
1148V Crimes against freedom (art. 183, art. 185 SCC)
Sexual Offences (art. 187 para. 1, art. 189, art. 190, art. 191, art. 195, art. 197
1149V para. 4 SCC)
Public dangerous crimes (art. 221, art. 223 para. 1 no. 1, art. 224 para. 1, art.
1150V 225, art. 226, art. 226bis, art. 226ter, art. 227 SCC)
Crimes against public health (art. 230bis para. 1, art. 231 para. 1, art. 232 para.
1151V 1 no. 2, art. 234 para. 1 SCC)
1152V Crimes against public transport (art. 237 para. 1 no. 2, art. 238 para. 1 SCC)
1153V Counterfeiting of money, measure and weight (art. 241 para. 1, art. 248 SCC)
1154V Genocide and crimes against humanity (art. 264, art .264a SCC)
1155V War Crimes (art. 264c, art. 264d, art. 264e, art. 264f, art. 264g SCC)
Crimes or offences against the State (art. 265, art. 266bis, art. 266b, art. 267
1156V para. 1 and 2, art. 271 para. 1 no. 4, para. 2 and 3 SCC)
Prohibited intelligence (art. 272 para. 2, art. 273 para. 3, art. 274 para. 1 no. 3
1157V SCC)
Crimes against the administration of justice (art. 303 para. 1, art. 207 para. 1
1158V and 2 SCC)
Seite 83 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
1159V Tax crimes (art. 14 para. 4 ACLA, art. 51 NESA)
1160V Copyright law (art. 67 para. 2, art. 69 para. 2 CopA)
War Material Law (art. 33 para. 2, art. 34 para. 1, art. 35, art. 35a para. 1, art
1161V .35b para. 1 WMA)
1162V Foreigners and Integration Law (art. 116 para. 3, art. 118 para. 3 FNIA)
1163V Nuclear Energy Law (art. 88 para. 2, art. 89 para. 2 NEA)
1164V Other offences
1165V For Swiss authorities: for proceedings based on art. 102 SCC
Recruiting, training and travelling with a view to committing a terrorist offence
1166V (art. 260sexies SCC)
1167V Illegal wildlife trafficking (art. 26 para. 2 BGCITES)
1206V For Swiss authorities: Money laundering
1207V Termination of a business relationship pursuant to art. 9b AMLA
2001G Cash transaction
2002G Check transaction
2003G Various
2004G Transitory / suspense account
2005G Precious metals
2006G Opening of account
2007G Forgery
2008G Currency exchange
2009G Third-party information
2010G Information from within corporate group
2011G Information from prosecution authorities
2012G Loan transaction
2013G High-risk countries
2014G Life insurance
2015G MROS-Info (Art. 11a para. 2 AMLA)
2016G Audit / supervisory board
2017G Smurfing
2018G Transactions-monitoring
2019G Trust activity
2020G Non-cash cashier transaction
2021G Securities
2022G Economic background
2023G Media
2024G Request for information accordingly to article 11a paragraph 1 and 3 AMLA
2025G Request for information accordingly to article 11a paragraph 2 and 3 AMLA
2026G For Swiss authorities: IRD (Request for info/Spontaneous dissemination of info)
2027G For foreign authorities: IRI (Request for info/Spontaneous dissemination of info)
2028G For Swiss authorities: Article 29a paragraph 1 AMLA
2029G For Swiss authorities: Article 29a paragraph 2 AMLA
2103G Termination of a business relationship pursuant to art. 9b AMLA
3001B Identification documents of contracting party
3002B Documentation on establishment of the business relationship / For money
transmitters: client master data sheet
3003B Power(s) of attorney
3004B Form A and/or Form K / I / R / S / T
3005B Documentation on beneficial owner(s) / authorised signatories/power of attorney
holder / control owners

Seite 84 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
3006B Assets involved: balance overview
3007B Account statements

3008B Detailed documents on suspicious or non-plausible transactions incl. payment

orders and/or credit memos (details on beneficiary/contractor including account
details)
3009B Documentary records of suspicious facts (e.g. printout of World-Check entries,
press or media reports, etc. and/or other tangible documents (e.g. orders from
prosecution authorities))
3010B Clarification on suspicious and / or implausible transactions
3011B Form according to art. 21 para. 1 AMLO (merchants)
3012B KYC documentation
3013B Documentation of special due diligence obligations according to Art. 6 AMLA
resp. documentation of internal clarifications on e.g. business relations with
increased risks / transactions with increased risks / additional clarification on
increased risks (Articles 13 - 15 AMLO-FINMA)
3014B Debit advice if relationship already terminated
3015B Form related to suspicious activity report under art. 7 FIAA (mandatory if report
is based on FIAA)
3016B Other attachments
3017B Article 11a paragraph 1 and 3 AMLA
3018B Article 11a paragraph 2 and 3 AMLA
3019B For Swiss authorities: IRD (Request for info/Spontaneous dissemination of info)
3020B For foreign authorities: IRI (Request for info/Spontaneous dissemination of info)
3021B For Swiss authorities: Article 29a paragraph 1 AMLA
3022B For Swiss authorities: Article 29a paragraph 2 AMLA
3023B Proof of balance due to termination of a business relationship pursuant to art. 9b
AMLA
Table 67: report_indicators

8.19 Gender type

Code Description
W Female
M Male
X Transgender
U Unknown
Table 68: gender_type

8.20 Allowed values for Cantons

For fields where a Swiss canton has to be entered the following values are allowed (always
uppercase, always two characters):
Code Description
AG Aargau
AI Appenzell Innerrhoden
AR Appenzell Ausserrhoden
BE Bern
BL Basel Land
BS Basel Stadt
FR Freiburg
GE Genf
Seite 85 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
GL Glarus
GR Graubünden
JU Jura
LU Luzern
NE Neuenburg
NW Nidwalden
OW Obwalden
SG St. Gallen
SH Schaffhausen
SO Solothurn
SZ Schwyz
TG Thurgau
TI Tessin
UR Uri
VD Waadt
VS Wallis
ZG Zug
ZH Zürich
Table 69: Values for cantons

8.21 Account-Account relation type

Value Description
A2A1 Main/Sub-Account
A2A2 Part of
QRIBA QR IBAN
VIBAN Virtual IBAN
4 Other
Table 70: account_account_relation

8.22 Account Category type

Value Description
ACCNT Fiat account
MOB Mobile number
VADDR Virtual Address
OTHER Other
Table 71: account_category_type

8.23 Account entity relation type

Value Description
BEOWN Beneficial Owner
ACCCO Control Owner
CORAD Correspondence address
EXTAM External Asset Manager
INSUR Premium Payer
ACCPR Proxy
TRSTE Trustee
UNLAY Underlying Company
OTHER Other
Table 72: account_entity_relation_type

Seite 86 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland
8.24 Entity to Entity relation type
Value Description
BENEF Beneficiary
COOWN Co-owner
GUARA Guarantor
LEGRE Legal representative
MEMBA Member of management
PROTC Protector
SETTL Settlor
TRUSE Trustee
UNDCO Underlying company
Table 73: entity_to_entity_relation_type

8.25 Person to Person relation type

Value Description
2 Boss / Employee
BUIPA Business partner
HUWIF Husband / Wife
3 Other
1 Relative
Table 74: person_to_person_relation_type

8.26 Additional information type

Value Description
BRNR Number of Business Relationships in this report
Table 75: additional information type

8.27 Allowed values for fields with yes/no answers

For fields like “domiciled company” the following values are allowed:

Yes, No, yes, no, Ja, Nein, ja, nein, Si, No, sì, no, Oui, Non, oui, non

8.28 Report Party type

Value Description
0 Contracting party
1 Beneficial Owner / Control owner / controller
2 Power of attorney / Authorized signatory
3 Business partner
4 Buyer / seller
5 Trust
6 Settlor
7 Trustee
8 Protector
9 Beneficiary
10 Other (please specify in text field below)
Table 76: Report_Party_type

Seite 87 von 88
 Standard XML Reporting Instructions and Specifications
Adapted for Switzerland

9. 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.

Seite 88 von 88