FATF Travel Rule Setup for VASPs: Notabene and unhosted wallets

FATF Travel Rule: Where Data Exchange Between VASPs Breaks

A transfer between two platforms takes minutes, while payer and payee details catch up hours later or never arrive at all.

Formally, FATF Travel Rule requirements describe what exactly must be transmitted, but do not describe how to do it technically — so each pair of VASPs agrees on the exchange format on its own.

The first gap — incomplete fields. One side sends the name and wallet address, the other expects a customer identifier in its own format; free text instead of a structured field fails validation on receipt, and the request goes to manual rework.

The second — the transfer trigger threshold. It is set in different currencies and calculated by different rules: somewhere from the amount, somewhere from the equivalent at the time of the operation.

A transfer that is threshold-level for one platform is ordinary for another, and the data package is not generated at all.

The third — manual requests between VASPs. While platforms lack a common channel, confirmation of recipient data goes through email and web forms: a response comes a day later, the operation sits in pending status, and the compliance team manually reconciles every step.

Data exchange between platforms via Notabene removes part of the pain — routing and field templates are there — but unhosted wallets remain outside the loop, and data on them is collected manually.

What a Configured Data Exchange Delivers: Effect in Measurable Metrics

A configured data exchange turns the Travel Rule from manual correspondence into a regulated flow: routing rules themselves determine which counterparty receives what volume of sender and recipient data.

In a typical Notabene configuration, the share of operations without manual review reaches 85–95%, and the remainder is requests to unhosted wallets and nonstandard cases where a compliance specialist deliberately makes the decision.

Transfer processing time is reduced because the request goes to the counterparty automatically along with the transaction, rather than as a separate email after review.

A response to a standard request arrives in minutes instead of hours, and the queue of transfers awaiting data confirmation stops growing by the end of the day.

Counterparty data quality rests on validation at input: required fields are checked before sending, the counterparty directory stores current addresses and acceptance formats, and discrepancies are flagged immediately.

This removes the main cause of returns — an incomplete or wrong-format set of data about the parties to the transfer.

Reduction in transfer rejections is a separate measurable outcome: the class of delays caused by incomplete data goes away, and the share of operations that must be manually reopened decreases.

For transfers to unhosted wallets the effect is more modest — there the exchange is based on confirming address ownership — but this path also stops being a bottleneck.

Methods of Transmitting Travel Rule Data: Comparison of Options

The standard defines what payer and recipient data must travel with a transfer between VASPs, but does not fix which channel to transmit it through.

In practice, four transmission lines have emerged: a shared intermediary platform, a direct channel between participants, an open address registry, and manual transmission over a secure channel.

The choice of line determines how many integrations you have to maintain and how quickly a hold on an outgoing transfer is released.

The lines are usually combined: the platform covers the long tail of counterparties, the direct channel covers the main volume, and manual transmission remains a fallback. The address registry works on top of any scheme and reduces the share of requests that no one can answer.

The key selection criterion is not ease of sending but delivery confirmation: without it, the transfer looks untransmitted to an auditor, so request logging and retry sending are built into the scheme from the start.

Implementation Stages: From Flow Audit to Handover of Regulations

Implementing data exchange under the FATF Travel Rule differs from a conventional integration: the data must reach a counterparty that may work with a different provider or without one at all.

1. Audit of transfers and rules. We analyze incoming and outgoing flows, mark where payer and recipient data is lost, and compare internal rules with the regulator's threshold requirements.
2. Counterparty inventory. We compile a list of VASPs by turnover, determine who is ready to receive data, and record how each side interprets unhosted wallets.
3. Data routing scheme. We describe the field composition and message format, the sending route — via the Notabene provider or directly between nodes — and the behavior when the counterparty is silent: hold or re-request.
4. Operation selection rules. We set trigger conditions: amount, asset, jurisdiction, involvement of an unhosted wallet. Only the required flow goes through the exchange, not all traffic.
5. Integration with counterparties. We agree on interaction details, test keys, and the procedure for resolving discrepancies.
6. Test transfer scenarios. We run a regular transfer, a below-threshold operation, no response, a data discrepancy, and a transfer to an unhosted wallet — with verification of the journal entry and export.
7. Handover of regulations to the team. We provide flow diagrams, the rules matrix, duty shift instructions, and the escalation procedure for node failure or mass holds.

Acceptance is a reproducible review of any transfer: by which rule it was selected, where the data went, and what remains to be done manually.

What Remains with the Client: Configurations, Schemes, and Regulations

We do not leave the client with "panel access" — a working set remains in their environment, by which Travel Rule exchange can be operated and developed without our involvement. All artifacts are versioned together with the code in the client's repository.

• Exchange rules configuration — thresholds and directions for which data is requested, field mapping between formats, exceptions for specific counterparties, and the procedure for editing them.
• Data flow scheme — from the client's wallet to the Notabene node and back: where the request is formed, where the response is stored, what goes to analytics.
• Access policies and roles — who sees personal data, who changes rules, who approves exceptions; an action log by each role.
• Request handling regulations — response times for incoming requests, escalation, and the scenario when a counterparty refuses to provide data.
• Integration documentation — calls, message formats, error codes, behavior when the counterparty is unavailable, and a test environment with scenarios.
• Procedure for unhosted wallets — how address ownership is confirmed, what evidence is accepted, and what to do if it is absent.
• Degradation plan — what is disabled first so that exchange continues to flow rather than failing entirely.

The set closes regulator and internal audit questions: it is visible why a request was sent, who had access to the data, and how the rules changed. A new engineer enters the exchange through documentation, not through correspondence.

Case: Exchange with Unhosted Wallets Without Manual Requests

Exchange with wallets without a custodian is the most costly area of compliance.

An incoming transfer to an unhosted wallet has no counterparty from whom sender data can be requested: the address has to be verified manually, the client has to be contacted, and a response has to be awaited.

With a flow of several thousand operations per day, the share of transfers with manual confirmation reached one third, review of one took 20–30 minutes, and some operations hung waiting for more than a day.

What Was Changed

The first step was to mark up the flow: separate transfers between our own clients, operations with external VASPs, and transfers to addresses without a custodian.

For the latter, rules were assembled — amount threshold, automatic address screening against risk databases, and requesting data from the sender via Notabene.

Delivery was made fault-tolerant: a retry queue with increasing intervals, a log for each request, and reuse of already received responses so as not to duplicate requests to the same counterparty.

What Changed

The share of manual review fell from one third to a few percent — typical transfers are closed automatically. Average processing time decreased from half an hour to seconds, and operations hanging for more than a day disappeared from reporting.

Counterparty responses arrive on their own in most cases; if the recipient is silent, the request goes to the retry queue and does not block the rest of the flow. Manual review remained only for sanctions list hits and discrepancies in sender data.

How a Hosted Wallet Differs from Unhosted and What That Changes

A hosted wallet is an account whose keys are held by a licensed service provider. On the other side of the transfer is a counterparty with its own identification procedures, so it transmits customer data, and we only compare the received package with what was sent.

Unhosted — the keys are with the client, and we have to collect the data.

There is no auto-exchange here: we build owner identification on proof of control — a message signature with a private key, a test micro-transfer, a one-time comparison of the address with the client's details.

For the custodial side, it is enough to connect exchange in a Notabene-class tool and agree on a field set. For a wallet under client control, the same tool covers only the outgoing part — owner verification and storage of evidence.

Scenarios without a counterparty — a transfer to one's own address, a smart contract, or an address outside the scope of the rules — do not trigger data transmission. But we still retain the justification for the decision: during an audit it shows why data was not transmitted.

Technical Concerns: Access, Logs, Fault Tolerance

Access to Travel Rule data is segregated by role: the compliance officer sees the transfer and party data, the analyst sees only exchange metadata without personal data, and support sees delivery statuses without content.

Every action with a record goes into an immutable log: who requested, when, what the counterparty returned, which address was marked as unhosted. Thus, logging of exchange operations becomes evidence for the regulator, not just a set of application logs.

If the counterparty is unavailable, the transfer does not hang: the request goes to a queue with retries at increasing intervals, and after attempts are exhausted it is marked as unprocessed with notification to the responsible specialist.

Reprocessing of the transfer is idempotent — the key is the identifier of the original operation, so repeated delivery does not create a duplicate record and does not distort the data.

What happens if a transfer is delivered again?

The handler checks the idempotency key and returns the previously saved result instead of a new record. The log records the attempt as a separate line, so an investigation sees the full delivery history.

Let's Discuss Your Data Exchange Scheme and Come Back with a Plan

So that the scope estimate is based on facts rather than assumptions, we need inputs about your environment: how data exchange with counterparties is structured today, who initiates the transfer, and how you interpret unhosted wallets.

Without this, it is impossible either to choose a request routing scheme or to understand what modifications will be required in your infrastructure.

What is sufficient to send for the first review:

• a transfer flow diagram: sender and recipient jurisdictions, shares of fiat and crypto legs, average and peak operation volume;
• a list of VASP counterparties and their data exchange providers — for example, Notabene or in-house solutions;
• how you determine address ownership: signs of ownership, policy on unhosted wallets, grounds for refusing a transfer;
• trigger thresholds and exception rules, as well as requirements for response time to an incoming request;
• roles and access: who conducts correspondence with counterparties, who confirms personal data, and how this is logged;
• export formats for reporting and the procedure for resolving disputed transfers;
• constraints: what cannot be changed in current processes and which external systems must not be touched.

Based on the review, we will return with a scope estimate, an implementation plan for exchange with stages of preparation for integration with counterparties, and a list of checks before launch. Describe your environment in general terms — we will come back with an estimate and a plan.