In addition to the Swiss legal framework – mainly represented by Article 10 AMLO-FINMA and the FINMA “Guidance 02/2019 Payments on the blockchain” – FATF has issued the Updated Guidance for a Risk-Based Approach to Financial Intermediaries.

The FATF Guidance provides additional clarity to obliged entities – such as VASPs or Financial Institutions (“FIs”) – as to the correct implementation of Recommendation 16 (the “travel rule”). This rule requires obliged entities performing a VA transfer to obtain, hold and securely and immediately transmit specific information on the payment’s originator and beneficiary. This is required to identify and report suspicious transactions, take freezing actions, and prohibit transactions with designated persons and entities.

The above requirements apply to VASPs whenever their transactions (fiat or crypto) involve: (a) a traditional wire transfer, (b) a VA transfer between a VASP and another obliged entity, or (c) a VA transfer between a VASP and a non-obliged entity (i.e., an unhosted wallet).

Whilst the FATF Guidance requires the application of full travel rule’s requirements only to (a) and (b), the Swiss regulators have adopted a stricter approach according to which all requirements must also apply to (c).

  1. FATF Guidance

Obtaining and holding required and accurate originator and required beneficiary information

The ordering institutions involved in a VA transfer must obtain and hold required and accurate originator information and required beneficiary information and submit the information to beneficiary institutions (VASP or FI), if any.

Further, the beneficiary institutions must obtain and hold required (but not necessarily accurate) originator information and required and accurate beneficiary information, as set forth below.

More precisely, the ordering institution must obtain and hold the following information:

  1. originator’s accurate full name (“accurate” means “verified”);
  2. originator’s accurate account number (e.g., the “wallet address” of the VA) where such an account is used to process the transaction;
  3. originator’s accurate address, or national identity number, or customer identification number (i.e., not a transaction number) that uniquely identifies the originator to the ordering institution, or date and place of birth;
  4. beneficiary’s full name (i.e., the name of the person who is identified by the originator as the receiver of the VA transfer). This is not required to be verified by the ordering institution for accuracy, but should be reviewed for the purpose of STR monitoring and sanction screening; and
  5. beneficiary account number, where such an account is used to process the transaction.

On the other hand, the beneficiary institution must obtain from the originator institution and hold, the below information:

  1. originator’s full name, which does not have been verified by the beneficiary institution for accuracy (it must however be reviewed for the purpose of STR monitoring and sanction screening);
  2. originator’s account number, where such an account is used to process the transaction;
  3. originator’s address, or national identity number, or customer identification number (i.e., not a transaction number) that uniquely identifies the originator to the ordering institution, or date and place of birth;
  4. beneficiary’s full name, which must be verified for accuracy, if not already previously verified; and
  5. beneficiary’s account number.

Sanctions screening for VA transfers

The ordering and beneficiary institutions must then screen the names of the other party (the originator or the beneficiary) when they conduct the VA transfer.

Immediate and secure submission of information

The ordering institution must submit the required information to the beneficiary institution (where this exists) immediately and securely.

“Immediately” means that the required information must be submitted prior, simultaneously or concurrently with the transfer itself. Post facto submission of the required information should not be permitted (i.e., submission must occur before or when the VA transfer is conducted).

“Securely” means that the required information must be transmitted and stored in a secure manner, so as to protect the integrity and availability of the required information to facilitate record-keeping (among other requirements), facilitate the use of such information by receiving VASPs or other obliged entities and protect the information from unauthorized disclosure.

It is not necessary for the information to be attached directly to the VA transfer itself. The information can be submitted either directly or indirectly, as long as it is submitted “immediately and securely” and available upon request to appropriate authorities. Consistent with the FATF’s technology-neutral approach, the required information need not be communicated as part of (or incorporated into) the transfer on the blockchain or other DLT platform itself. Submitting information to the beneficiary VASP could be an entirely distinct process from that of the blockchain or other DLT VA transfers. Any technology or software solution is acceptable, provided that the solution enables the ordering and beneficiary institutions to comply with the above requirements. For example, a solution for obtaining, holding, and transmitting the required information could be code that is built into the VA transfer’s underlying DLT transaction protocol or that runs on top of the DLT platform (e.g., using a smart contract, multiple-signature, or any other technology); an independent (i.e., non-DLT) messaging platform or application program interface (API); or any other effective means for complying with the Recommendation 16 measures.

Examples of existing technologies include:

  1. Public and private keys, which are created in pairs for each entity involved in a transmission and encrypt and decrypt information during the initial part of the transmission so that only the sender and recipient of the transmission can
  2. decrypt and read the information, wherein the public key is available to everyone while the private key is known only to the creator of the keys;
  3. Transport Layer Security/Secure Sockets Layer (TLS/SSL) connections, which make use of public and private keys among parties when establishing a connection and secure almost all transmissions on the Internet, including emails, web browsing, logins, and financial transactions, ensuring that all data that passes between a web server and a browser remains private and secure;
  4. 509 certificates, which are digital certificates administered by certificate authorities that use the X.509 PKI standard to verify that a public key belongs to the user, computer, or service identity in the certificate and which are used worldwide across public and private sectors;
  5. 509 attribute certificates, which can encode attributes (such as name, date of birth, address, and unique identifier number), are attached cryptographically to the X.509 certificate, and are administered by attribute certificate authorities;
  6. API technology, which provides routines, protocols, and tools for building software applications and specifies how software components should interact; as well as
  7. Other commercially available technology or potential software or data sharing solutions.

Transfers below 1,000 EUR

If a country decides to adopt a de minimis threshold for VA transfers of EUR 1,000, and. For VA transfers under the threshold, fewer requirements apply to VASPs, that may simply collect:

  1. originator’s name
  2. beneficiary’s name; and
  3. the VA wallet address for each or a unique transaction reference number.

Such information does not need to be verified unless there are ML/FT suspicious circumstances.

VA transfers to/from other VASPs and counterparty VASP identification and due diligence

For a VASP to transmit the required information to another VASP, it is necessary to identify and conduct due diligence on their counterparty VASP before transmitting the required information. VASPs do not need to undertake the counterparty VASP due diligence process for every individual VA transfer when dealing with VASPs for which they have previously conducted counterparty due diligence, unless there is a suspicious transaction history or other information (such as adverse media, published information about regulatory or criminal penalties) indicating they should. Considering the concept of due diligence, countries should expect a VASP to refresh their counterparty due diligence information periodically or when risk emerges from the relationship in line with their defined RBA control structure.

Not all VASPs are the same. They vary in size from small independent businesses to large multinational corporations. Similarly, no country’s AML/CFT regime for VASPs is exactly the same. When establishing a new counterparty VASP relationship, a VASP may obtain the required information (as set out by Recommendations 10 and 13) directly from the counterparty VASP. Under the requirements of those Recommendations, this information should be verified by making reference to reliable, independent sources of information for the verification of the identity and beneficial ownership.

Lastly, the VASP would need to assess the counterparty VASP’s AML/CFT controls to avoid submitting their customer information to illicit actors or sanctioned entities and should also consider whether there is a reasonable basis to believe the VASP can adequately protect sensitive information. The assessment should include confirming that the counterparty’s AML/CFT controls are subject to independent audit.

VA transfers to/from unhosted wallets

Where a VA transfer involves only one obliged entity (e.g., when an ordering VASP sends VAs on behalf of the originator to a beneficiary that is an individual VA user who receives the VA transfer to an unhosted wallet, and who is therefore not a customer of a beneficiary institution), FATF requires VASPs to collect data on their unhosted wallet transfers and to monitor and assess that information as necessary to determine to what extent a transaction is within their risk appetite, and the appropriate risk-based controls to apply to such a transaction/individual customer. Key ML/FT indicators include:

  1. Technological features that increase anonymity – such as mixers, tumblers, or AECs;
  2. Geographical risks – criminals can exploit countries with weak, or absent, national measures for VAs;
  3. Transaction patterns – including transactions which are structured to avoid reporting or appear irregular, unusual or uncommon;
  4. Transaction size – if the amount and frequency has no logical business explanation;
  5. Sender or recipient profiles; and
  6. Source of funds or wealth.

However, FATF does not require VASPs to “submit” the required information to individuals who are not obliged entities; FATF simply requires that VASPs effectively scrutinize such transfers, in particular, to meet their STR and sanctions implementation obligations. Nevertheless, Switzerland has adopted an approach that is even stricter than the one outlined by FATF.

  1. The Swiss AML framework and FINMA’s standpoint

FINMA issued “Guidance 02/2019 Payments on the blockchain” in 2019 whereby the below key points are stated.

Article 10 AMLO-FINMA requires that information about the client and the beneficiary be transmitted with payment orders, so as to let the financial intermediary receiving this information to check the originator’s name against sanction lists and that the information for the beneficiary is correct (or whether it should return the payment in the event of discrepancies).

Furthermore, FINMA’s stricter interpretation of Article 10 than FATF does not provide for any exemptions whenever payments involve unregulated wallet providers: all information required in payment transactions must be collected and transmitted.

However, blockchain transactions are currently restricted in technical terms, since most blockchain systems operate only pseudo-anonymous transactions – the originator and the beneficiary are identified via crypto addresses and the persons behind such addresses remain unknown. Therefore, at present it is technically impossible to pass on data on the originator and the beneficiary (which is why FATF and FINMA allow for the transmission of information to take place independently of the initial blockchain transaction).

FINMA, further, states that FATF expects information about the client and the beneficiary to be transmitted with token transfers in the same way as for bank transfers. No system currently exists at either a national or an international level (such as, for example, SWIFT for interbank transfers) for reliably transferring identification data for payment transactions on the blockchain. Neither are bilateral agreements between individual service providers in existence to date. For such systems or such agreements to meet the requirements of Article 10 AMLO-FINMA in the future, they would have to

If a financial institution is not able to send and receive the data prerequisite information required in payment transactions, then such transactions can only be made: (a) between customers of the same institution; or (b) from and to external wallets that belong to the institution’s own customers and that such ownership can be proven via suitable technical means.

Lastly, FINMA clarifies that a transfer from or to an external wallet belonging to a third party is only possible if, as for a client relationship, the institution has first verified the identity of the third party, established the identity of the beneficial owner, and proven the third party’s ownership of the external wallet using suitable technical means.

  1. Conclusion

Although non-binding and not overriding the domestic laws, the latest FATF Guidance provides for further clarification as to the correct implementation of the travel rule. Nevertheless, Swiss VASPs must also refer to their domestic legal framework and, as highlighted above, urgently need a technical solution to comply with the “travel rule”, especially when transacting with unregulated users. The below solutions are currently being considered:

  1. The adoption of a second layer messaging protocol that uses cryptography to authenticate the participating VASPs. An open protocol is being developed by the OpenVASP community, to allow for the exchange of information between VASPs directly on the Ethereum blockchain, without the need to be registered with a centralized party;
  2. A “manual” proof of wallet ownership, to prove – via adequate technical means – that the external wallet belongs to the institution’s customer;
  3. An “automated” proof of wallet ownership, by linking the customers with their own client-ID.