Buyers funding a Montenegrin property from crypto usually plan the conversion carefully and treat everything before it as private housekeeping — move the assets to a personal wallet, then sell into euros. The Prevention of Money Laundering and Terrorist Financing Act treats that intermediate step as a regulated event, and it imposes obligations on the sending provider that most buyers only discover when a withdrawal is refused.
Article numbers below are from the Zakon o sprečavanju pranja novca i finansiranja terorizma, published in "Službeni list CG" br. 110/2023, 65/2024, 24/2025, 41/2026 — a decision of the Constitutional Court — and 59/2026, read on 5 September 2026. General information, not advice on a specific transaction.
The vocabulary the Act uses
Three definitions in Article 6 decide how the rules apply, and they are worth stating in the Act's own terms.
Point 84 defines a transfer of crypto-assets as any transaction aimed at moving crypto-assets from one distributed-ledger address, crypto-asset account or similar instrument.
Point 83 defines the crypto-asset user as the person who is the intended recipient of a transfer — which is why the Act can impose recipient-side obligations even where the recipient is the sender's own wallet.
Point 87 defines a person-to-person transfer of crypto-assets as a transfer without the participation of any crypto-asset service provider. That is the category most buyers assume they are in. The moment a provider sits on either side of the movement, they are not.
The travel rule, and what it collects
Article 40f(1) requires the sender's crypto-asset service provider, on a transfer of crypto-assets, to secure data about the sender and the crypto-asset user.
Article 40f(2) lists the sender data: name; address or seat including the state, identity document number and personal or registration number, or date and place of birth; the distributed-ledger address where the transfer is registered on a network using DLT or similar technology, together with the crypto-asset account number if one exists and is used; the crypto-asset account number where the transfer is not registered on such a network; and the legal entity identifier where the message format has a field for it.
Article 40f(3) lists the corresponding recipient data: name; the recipient's distributed-ledger address and account number where applicable; the account number where the transfer is not DLT-registered; and the legal entity identifier.
Article 40f(4) covers the residual case: where the transfer is neither registered on a DLT network nor made to or from the sender's crypto-asset account, the provider must ensure a unique transaction identifier accompanies it.
Two paragraphs then temper the mechanics. Article 40f(5) provides that the sender and recipient data need not be included directly in the transfer itself — so the rule is about the information travelling, not about writing it on-chain. Article 40f(6) requires the data to be delivered to the other provider before, simultaneously with, or in parallel to the transaction, and in a manner that protects the data in accordance with the data protection legislation.
The self-hosted address rules
This is the part that reaches an individual buyer moving assets to a wallet they control.
Article 40f(7): on a transfer of crypto-assets to a self-hosted address, the sender's provider must obtain and retain the Article 40f(2) and (3) data and ensure that the transfer can be individually identified.
Article 40f(8): in addition to the measures under Article 53c, where the value of a transfer to a self-hosted address exceeds €1,000, the sender's provider must take appropriate measures to assess whether that address is owned or controlled by the sender.
That second obligation is the one to plan around. The provider is not merely recording a destination; above €1,000 it has to form a view on whose wallet it is. In practice that is what produces the requests buyers find intrusive and unexpected — signed messages, screenshots of the wallet, or a small verification transfer — and it is a statutory obligation on the provider rather than an internal policy it can waive on request.
Article 40f(9) requires the provider, before the transfer, to verify the accuracy of the sender and recipient data against documents, data or information from a reliable and independent source. Article 40f(10) treats that verification as done where either the sender's identity was verified under Article 17 and the resulting information retained under Article 127, or where Article 18(2) applies to the sender.
Article 40f(11) supplies the consequence, and it is absolute in form: the sender's provider must not allow the initiation of, or execute, the transfer where the conditions in paragraphs 1 to 10 are not met. A withdrawal that is blocked pending wallet verification is the provider complying with that paragraph, not exercising a discretion.
The same test applies on the way back in
The obligations are symmetrical, which matters because a buyer who moved assets out to a personal wallet will usually move them back to a provider to convert into euros.
Article 40h(1) requires the recipient's crypto-asset service provider to operate effective procedures — including, where appropriate, monitoring during or after the transfer — to establish whether the Article 40f(2), (3) and (4) data were included in the transfer or in the batch file, or are supplied afterwards.
Article 40h(2): on a transfer from a self-hosted address, the recipient's provider must obtain and retain that data and ensure the transfer can be individually identified.
Article 40h(3): in addition to the Article 53c measures, on a transfer of more than €1,000 from a self-hosted address, the recipient's provider must take appropriate measures to assess whether that address is owned or controlled by the crypto-asset user.
Article 40h(4) adds the timing rule that determines when funds actually become usable: before the crypto-assets are made available to the user, the recipient's provider must verify the accuracy of the Article 40f(3) recipient data against documents, data or information from a reliable and independent source. Article 40h(5) treats that as done where the user's identity was verified under Article 17 with the information retained under Article 127, or where Article 18(2) applies.
So the wallet a buyer used as a private staging point is examined twice — once by the provider that sent the assets out, and again by the provider that receives them back — and on the return leg the examination happens before the assets are released for use. A deposit that appears to be "pending" while an exchange asks about the originating address is Article 40h(4) operating as drafted.
The threshold that catches the small transfer
Separately from the travel rule, the Act requires full customer due diligence on every occasional transaction that is a transfer of crypto-assets of €1,000 or more, under the occasional-transaction provisions of Article 18. That threshold sits an order of magnitude below the €10,000 that applies to occasional transactions generally, which is why crypto movements trigger diligence at values that would be unremarkable in a bank transfer.
For a property purchase funded from crypto, the practical sequence is therefore: the movement to a personal wallet is itself a regulated transfer with a €1,000 verification threshold attached, the conversion to euros is a second regulated event, and only then does the payment leg of the purchase begin — with its own rules requiring the money to move through a transaction account at a Montenegrin credit institution.
Both sides of a self-hosted transfer, in one view
| Sending provider (Art. 40f) | Receiving provider (Art. 40h) | |
|---|---|---|
| Collect the sender and recipient data | Art. 40f(1)–(3) | Art. 40h(1) — establish whether it accompanied the transfer |
| Self-hosted address involved | Art. 40f(7) — obtain, retain, and make the transfer individually identifiable | Art. 40h(2) — same duty |
| Above €1,000 | Art. 40f(8) — assess whether the address is owned or controlled by the sender | Art. 40h(3) — assess whether it is owned or controlled by the user |
| Verification against an independent source | Art. 40f(9) — before the transfer | Art. 40h(4) — before the assets are made available |
| Verification deemed done | Art. 40f(10) — identity verified under Art. 17 and retained under Art. 127, or Art. 18(2) applies | Art. 40h(5) — same two routes |
| If conditions are not met | Art. 40f(11) — must not initiate or execute the transfer | Assets not made available until Art. 40h(4) is satisfied |
Who is outside the crypto rules entirely
Article 4a removes six categories from the crypto provisions of the Act, and the first is the one that matters to corporate structures:
- persons providing crypto-asset services exclusively to their parent companies, their subsidiaries, or other subsidiaries of their parent companies;
- a liquidator or bankruptcy trustee participating in liquidation or bankruptcy proceedings — except in the case of a plan supporting the orderly redemption of an asset-referenced token applied on bankruptcy, liquidation, resolution or withdrawal of the holder's authorisation;
- the European Central Bank, a central bank of an EU member state acting as a monetary authority, and other public bodies of EU member states;
- the European Investment Bank and its subsidiaries;
- the European Financial Stability Facility and the European Stability Mechanism;
- international organisations within the meaning of public international law.
Point 1 is a genuine intra-group carve-out: a treasury function serving only the group is outside the crypto provisions. It is also narrow — "exclusively" does the work, and a service offered to anyone outside that perimeter takes the provider back inside the Act.
What the record will say afterwards
It is worth knowing what is retained, because these files are frequently revisited years later when the property is sold.
The customer due diligence record required by Article 117(1) includes, among the transaction data, whether the transaction was cash, non-cash or crypto-asset, and — expressly — the deposit address of the sender of crypto-assets and the deposit address of the crypto-asset user.
So the addresses on both sides of the movement become part of a retained regulatory record, alongside the source-of-funds information. A buyer who treats the wallet-to-wallet step as invisible is making an assumption the statute contradicts.
Before you move the assets
If you are funding a Montenegrin purchase from crypto, the order of operations matters more than the tax analysis, and the questions that stall transactions are asked at the wallet step rather than at the notary. Send us the intended route — where the assets sit now, which provider will handle the conversion, and which wallet they will pass through — and we will identify where the Article 40f(7) and (8) obligations fall, what the sending provider will have to establish about your own address, and how that sequences against the payment rules for the purchase itself. The purchase-side mechanics are in paying for property in Montenegro, the register and licensing layer in Montenegro's crypto register, the obliged-entity duties that follow registration in now you're an obliged entity, and how we run these files sits with our crypto-backed real estate practice.
