Sovereignty has, since time immemorial, been subject to attacks and conquests. It is perhaps no surprise, then, that at times it feels as if self-sovereignty is likewise being wrested from individuals, which makes the topic of self-hosted addresses a sensitive one. A lot of debate has arisen regarding this topic in view of the measures imposed under the EU’s re-cast Transfer of Funds Regulation (TFR), which has been amended to implement the Financial Action Task Force’s (FATF) so-called ‘Travel Rule’. The Travel Rule, ergo the FATF’s Recommendation 16, mandates that wire transfers, and now crypto-asset transfers, between entities subject to an AML framework are accompanied with information on the originator and the beneficiary of the transaction in question. The term ‘Recommendation’ is a bit of a misnomer, since FATF’s Recommendations tend to be adopted and implemented by most countries worldwide, which are either directly or indirectly member countries. Failure to adopt key Recommendations normally results in the relevant country becoming either listed in the FATF’s increased monitored jurisdictions list (grey-list), or else listed as a high-risk jurisdictions subject to a call for action (black-list).
Unlike wire transfers, crypto-asset transfers can be conducted using what are defined as ‘self-hosted addresses’ under the TFR, with the definition stating the following:
‘self-hosted address’ means a distributed ledger address not linked to either of the following:
The definition categorises self-hosted addresses through exclusion rather than inclusion; essentially, any distributed ledger address which is not linked to a crypto-asset service provider (CASP) or a non-EU entity providing services in a manner similar to CASP shall be classified as a self-hosted address. For an insight on what is a CASP and the criteria to qualify as such, please check out our article here; in essence, a CASP is a legal person or other undertaking with its registered office in the EU offering, on a professional basis, crypto-asset services (as defined under MiCA) by way of an occupation or business.
The term ‘linked to a CASP’ should be interpreted in the spirit of the TFR, rather than generally & extensively. In other words, a link to a CASP means a link by way of a contractual relationship with a CASP, namely being a client or user of a CASP. To use similar terminology as that used by the legislator, a self-hosted address would inversely be a hosted address, ergo an address that is either hosted by a CASP, or a non-EU entity that is carrying out the same activities as a CASP. To use industry parlance, this would mean custodial wallets as opposed to non-custodial wallets, with non-custodial wallets generally being self-hosted addresses.
The TFR mandates that transfers of crypto-assets are accompanied with the relevant information on both the originator of the transfer, as well as the beneficiary of the transfer. Before the pitchforks come out, the term ‘transfers of crypto-assets’ has been limitedly defined as follows:
‘transfer of crypto-assets’ means any transaction with the aim of moving crypto-assets from one distributed ledger address, crypto-asset account or other device allowing the storage of crypto-assets to another, carried out by at least one crypto-asset service provider acting on behalf of either an originator or a beneficiary, irrespective of whether the originator and the beneficiary are the same person and irrespective of whether the crypto-asset service provider of the originator and that of the beneficiary are one and the same;
Technical inaccuracies aside (“device allowing the storage of crypto-assets” in particular irks me), the scope of such transfers is limited to those instances there is the involvement of a CASP who is acting on behalf of an originator or a beneficiary. Indeed, to support this point, the legislator clarifies that the TFR shall not apply to transfers that constitute “a person-to-person transfer of crypto-assets carried out without the involvement of a crypto- asset service provider”, as stated under Article 2(4). In short, peer-to-peer crypto-asset transfers are outside the scope of the TFR, shooting down the concern that the EU legislators are out to regulate or restrict P2P transfers (at least for now).
So, what is actually in scope? The modalities below are mainly the crypto-asset transfers that will be within the TFR’s scope:
Apart from person-to-person transfers of crypto-assets carried without the involvement of a CASP, the other main exemption stated in the TFR applies to instances where both the originator and the beneficiary are CASPs acting on their own behalf.
It is important to keep in mind that the information covered in this section is to be transferred strictly and solely between the relevant entities, being the CASPs or non-EU service providers offering crypto services. The legislator makes it amply clear that such information is to be transferred securely, privately and in full compliance with the GDPR.
The CASP of the originator, being the CASP through which the originator’s transaction is initiated or made must ensure that the crypto-asset transfer is accompanied by the following information on the originator:
Moreover, the same CASP of the originator must also ensure that the transfer of crypto-assets is accompanied by the following information on the beneficiary:
The recipient of such information tends to be the CASP/service provider of the beneficiary. The CASP of the originator has the obligation to verify the accuracy of the information pertaining to the originator; in other words, due diligence must be performed on the originator. If the CASP already has updated records on the originator, naturally there is no obligation to perform such checks afresh with each and every single transaction, unless risk warnings are being triggered.
On the other side, the CASP of the beneficiary must ensure that:
In the case of intermediary CASPs, they must ensure that all the information received on the originator and the beneficiary that accompanies a transfer of crypto-assets is transmitted with the transfer.
If a transfer is made from a self-hosted address to a CASP, or from a CASP to a self-hosted address, then the information above needs to be collected by the CASP of the originator or the CASP of the beneficiary as the case may be, and additionally the relevant CASP would also need to verify the accuracy of the information provided. The CASP, in principle, is not required to verify the information on the user of the self-hosted address.
However, if the value of the crypto-asset transfer from or to a self-hosted address exceeds EUR 1,000, the CASP of the originator or beneficiary must also take adequate measures to assess whether the self-hosted address is owned or controlled by the originator or beneficiary, as the case may be.
Legal considerations and debates on whether a crypto address can be “owned” aside (I personally do not think an address can be owned in the proper legal sense of ownership under civil law), the ownership/control test is currently being conducted through 2 primary methods:
It can well be said that these two methods are more of a ‘ticking-the-box’ exercise than meaningfully proving ownership/control to an appreciable extent, but implementing either method would ensure that CASPs are in compliance with the TFR, which is ultimately simply implementing the FATF’s Travel Rule. Naturally, the second method can be costly to implement if the transfer in question is occurring on a blockchain network where the transaction fees are high, potentially outsizing the nominal pre-defined amount being sent.
For now – yes. However, Article 37 of the TFR mandates the EU Commission (in consultation with the EBA) to issue a report assessing the risks posed by transfers to or from self-hosted addresses, which report is likely to be published in 2026. One of the worrying elements is that the legislator may bring within its crosshairs hardware and software wallet providers, and the limitation, control or prohibition of transfers involving self-hosted addresses are all potential measures on the table. Under the current version of the TFR, persons providing wallet software or hardware wallets are outside of scope (unless they actively perform transfers of crypto-assets), but this is not to be taken as an indefinite exemption allowing them to sit on their laurels.
It is for this reason that an appeal is being made to providers of wallet solutions, be it hardware or software, as well as other crypto industry stakeholders, to start engaging with their local MEPs and EU-appointed officials in healthy dialogue and education, in order to avert a privacy-annihilating disaster.