What the Travel Rule Means in Georgian Law
Georgian law on the prevention of money laundering and terrorism financing places virtual asset service providers (VASPs) within the circle of accountable persons. A crypto exchange, a transfer service or a custodian acting for the benefit of another person therefore operates under the same preventive obligations as the banking sector. The core of those obligations for crypto transfers is Article 17¹ of the AML law, which transposes the Travel Rule into Georgian law: transfers of convertible virtual assets must travel together with defined originator and beneficiary information. This page takes the implementation angle — the data fields, thresholds, checks and internal go-live steps an obligated provider needs.
Under the first paragraph of Article 17¹, a transfer is an operation performed by the initiator, or on his instruction/with his consent, by digital means, to make a convertible virtual asset available to a recipient. The law contemplates that the initiator and the recipient may be the same person, or that both parties may be served by the same provider — these cases remain within the transfer regime.
Originator and Beneficiary Data — Accompanying Information
The second paragraph of Article 17¹ obliges a VASP to ensure that any transfer or receipt of a convertible virtual asset is accompanied by information defined through a procedure established by the supervisory authority. The statute itself does not list the individual fields — the precise dataset identifying the initiator and the recipient is fixed by a legal act of the supervisory authority. The first task of any implementation project is to analyse that act and build a data model attached to each transfer and transmitted to the counterparty provider.
The receiving side carries its own duty: under the third paragraph of Article 17¹, the recipient’s provider must examine whether grounds for submitting a report exist where the transfer does not fully contain identification data of the initiator/recipient per the supervisory authority’s procedure. An incoming transfer with incomplete data triggers an internal review and, where warranted, a report.
Thresholds That Trigger Preventive Measures
The identification triggers are fixed in Article 11 of the law. As a general rule, preventive measures are required where a one-off transaction or the aggregate of related transactions exceeds 15,000 GEL or its foreign-currency equivalent. For a one-off transaction connected to convertible virtual asset services, the law sets a separate, much lower threshold: 1,000 US dollars, 1,000 euros or 3,000 GEL. For a one-off transfer of funds the threshold is 3,000 GEL. These figures must be encoded in the provider’s rules engine, including the aggregation of related transactions.
The exception matters most: Article 11 obliges the accountable person to apply preventive measures irrespective of the monetary threshold or any other reservation where suspicion of money laundering or terrorism financing exists. Once suspicion is recorded, the threshold loses its protective function.
Risk-Based Procedure and the Sequence of Execution
Article 12 lays down how preventive measures are carried out: in proportion to the client’s risk level — before concluding a one-off transaction and before establishing a business relationship, and with appropriate periodicity while the relationship continues and when material circumstances change. Where risks are low, verification of the client and the beneficial owner may be completed after the relationship is established, if necessary to avoid interrupting service — but as quickly as reasonably possible.
Opening or maintaining anonymous or fictitiously named accounts is prohibited. Identification may be performed electronically, under a procedure established by the supervisory authority and with agreed operational and technical procedures that ensure effective management of the risks. The exact list of identification data and verification documents is set by a subordinate normative act of the head of the service.
A Practical Go-Live Plan for the Organisation
A workable launch plan consists of several blocks. First, process inventory: every operation meeting the definition of a transfer, including same-person and single-provider cases. Second, the data model and integration with counterparty VASPs, so that accompanying information is sent together with the transfer and incoming data is validated. Third, an internal rule for handling incomplete data, including the criteria under which the existence of reporting grounds becomes assessable.
Sanctions and risk screening must be wired into onboarding and monitoring; the precise procedures are established by acts of the supervisory authority and other provisions of the law. The final block covers documentation, training and testing. The statute sets no explicit deadlines — the obligation stands, and its breach is a ground for sanctions.
Frequently Asked Questions
Which amount triggers identification on a crypto transaction?
For a one-off transaction connected to convertible virtual asset services, preventive measures are required above 1,000 US dollars, 1,000 euros or 3,000 GEL; the general threshold is 15,000 GEL, and 3,000 GEL for transfers of funds. Where suspicion exists, identification applies irrespective of the threshold.
Where are the exact fields of the accompanying information listed?
Article 17¹ delegates the content of the accompanying information to a procedure established by the supervisory authority. Implementation should therefore start by reading that procedure and building the data model it implies.
Does the rule apply when one VASP serves both sides?
Yes — under Article 17¹ such an operation still counts as a transfer and must be wired into the relevant processes.
Can verification be completed later?
Where the risk is low, verification of the client and the beneficial owner may be completed after the business relationship is established, if necessary to avoid interrupting service — but as quickly as reasonably possible.
How We Help on Legal.ge
The Legal.ge team runs the full Travel Rule implementation cycle for VASPs: we analyse the effective legal acts, build the originator/beneficiary data model, draft internal rules and procedures, connect screening and monitoring systems and prepare the organisation for supervisory inspection. Contact us to assess the current state of your platform and to design a precise go-live plan.