# Article 16 — Detection of missing information on the originator or the beneficiary

**Source:** [Regulation (EU) 2023/1113 — EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32023R1113)

1. The crypto-asset service provider of the beneficiary shall implement effective procedures, including, where appropriate, monitoring after or during the transfers, in order to detect whether the information referred to in Article 14(1) and (2) on the originator and the beneficiary is included in, or follows, the transfer or batch file transfer of crypto-assets.
2. In the case of a transfer of crypto-assets made from a self-hosted address, the crypto-asset service provider of the beneficiary shall obtain and hold the information referred to in Article 14(1) and (2) and shall ensure that the transfer of crypto-assets can be individually identified.

Without prejudice to specific risk mitigating measures taken in accordance with Article 19b of Directive (EU) 2015/849, in the case of a transfer of an amount exceeding EUR 1 000 from a self-hosted address, the crypto-asset service provider of the beneficiary shall take adequate measures to assess whether that address is owned or controlled by the beneficiary.

1. Before making the crypto-assets available to the beneficiary, the crypto-asset service provider of the beneficiary shall verify the accuracy of the information on the beneficiary referred to in Article 14(2) on the basis of documents, data or information obtained from a reliable and independent source.
2. Verification as referred to in paragraphs 2 and 3 of this Article shall be deemed to have taken place where one of the following applies:
   1. the identity of the beneficiary has been verified in accordance with Article 13 of Directive (EU) 2015/849 and the information obtained pursuant to that verification has been retained in accordance with Article 40 of that Directive;
   2. Article 14(5) of Directive (EU) 2015/849 applies to the beneficiary.

## What this means in practice

The receiving side mirrors the sending side, with two twists:

1. **No Article 7-style syntax check.** Unlike funds (Art. 7(1)), Article 16 does not refer to characters or inputs admissible to a messaging or settlement system. The beneficiary CASP must have procedures to detect whether the required information is included in, or follows, the transfer or batch transfer.
2. **Self-hosted inbound mirrors Art. 14(5).** Para 2 imposes the same baseline-plus-EUR-1 000 structure: the beneficiary CASP must hold full originator/beneficiary information for any self-hosted inbound transfer and ensure the transfer can be individually identified; above EUR 1 000, it must additionally assess whether the self-hosted address is owned or controlled by the *beneficiary*.

Beneficiary verification (para 3) can rely on AMLD5 CDD where the Article 16(4) conditions are met; Article 16 does not require fresh verification for every transfer as a standalone step. That does not displace risk-sensitive monitoring, sanctions controls, or updates where customer information has changed.

## Compliance checklist

A CASP acting as beneficiary-side CASP must, for every incoming transfer of crypto-assets:

* [ ] **Monitor for Travel Rule data** — confirm that the originator/beneficiary information has been included in, or follows, the transfer or batch transfer.
* [ ] **For inbound from a self-hosted address**, obtain and hold the full originator/beneficiary information set and ensure the transfer can be individually identified.
* [ ] **For inbound from a self-hosted address above EUR 1 000**, take adequate measures to assess that the self-hosted address is owned or controlled by the beneficiary (your customer), using one or more EBA-recognised verification methods where needed.
* [ ] **Verify beneficiary information** from a reliable and independent source before crediting the beneficiary (or rely on AMLD5 CDD).
* [ ] **Hold the crypto-assets** (or treat them as unsettled internally) until detection and verification are complete.
* [ ] **Document the determination** for retention purposes.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.mica.wtf/tofr/transfer-of-funds-regulation/chapter-iii-casp-obligations/article-16-detection-of-missing-information.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.