Notabene integration: Travel Rule compliance for crypto exchanges

Travel Rule compliance for crypto exchanges: where data exchange breaks

Travel Rule requires that along with a transfer above the threshold amount, sender and recipient information goes to the counterparty: name, account number or wallet address, transaction identifier.

On the network, the transaction and accompanying data travel through different channels — and the exchange of transfer data breaks precisely at the junction.

Typical failure: a client initiates a withdrawal, the crypto exchange forms a transaction, and the message either isn't assembled due to an empty field, or goes out in a structure the receiving side cannot parse — free text instead of IVMS101, only an address instead of an account identifier.

The counterparty rejects the message, and the transfer hangs: on the network it is executed, at the recipient it is not credited.

The cost grows quickly. The return is agreed by both sides, funds freeze indefinitely, and the investigation falls on the compliance team: it checks correspondence, looks for the counterparty contact, and restores fields manually. One such case means hours of specialist work and a broken client scenario.

A separate layer is the mismatch of rules: threshold amounts and the list of mandatory fields differ by jurisdiction, some counterparties connect the exchange protocol through an intermediary, some do not support it at all.

A crypto exchange without routing for each counterparty gets stuck here, not in the blockchain part itself. The Notabene layer covers this section: a single connection point, bringing data to a common schema, distributing messages to recipients.

Below we break down how this is covered: from analyzing the transfer flow and threshold amounts to message routing and automated scenarios for stuck payments.

What implementation changes: onboarding time, rejections, downtime

The first measurable shift is the time to onboard a new counterparty.

Previously we coordinated the message format, test environment, and rules for matching details with each recipient separately: correspondence stretched over days, and some counterparties remained outside the exchange.

After connecting to Notabene, addresses and data are verified against a common registry, and exchange runs in a single format — a new counterparty is onboarded in hours, not a week.

The second metric is the share of rejected transfers. The main cause of rejections is incomplete or mismatched sender and recipient data: the operator caught the discrepancy manually and only after sending.

Pre-check before debit and matching rules move the rejection share from double digits to low single-digit percentages.

The third is manual review of operations. The queue of requests for additional data shrinks due to automated scenarios: typical discrepancies are closed without operator involvement, leaving only disputed cases for a human.

Separately, we count exchange channel downtime.

Message queues, retries, and processing of undelivered packets are configured so that if one node fails, the exchange recovers automatically: downtime shrinks from hours to minutes, and the full message history is preserved for audit.

We take metrics before and after implementation and deliver a report for each counterparty — you can see where manual work remains and what to improve next.

Connection options: own node, intermediary service, hybrid

Data exchange about a transfer between exchanges is built in one of several ways, and the choice here is not binary.

The criteria are the volume of outgoing operations, the regulator's requirement for where the sender's personal data resides, and counterparties' readiness to maintain a direct channel.

Local data storage is not a separate exchange method, but a mode superimposed on any of the first three: the full set of fields remains with you, while confirmation goes out.

In practice, a hybrid is more often assembled — a direct channel for large counterparties and an intermediary for the rest. We design the scheme so that switching between options does not require rewriting validation logic.

Implementation stages: from scheme analysis to handover of regulations

Implementing the Travel Rule requirement affects all transfers between providers, not a separate scenario: if sender data is lost along the way, the transaction hangs on the counterparty side or goes to manual review. Therefore work proceeds in stages — from inventory of flows to handover of internal regulations.

1. Audit of transfer routes. We collect a flow map: assets, networks, jurisdictions of the parties, counterparties with whom data exchange is already required. We note at which step sender information is lost in the current process.
2. Integration scheme. We determine the point of data request, system behavior when the counterparty refuses to respond, mapping of message fields to the internal transaction model. The result of the stage is an agreed scheme and a list of modifications to the accounting system.
3. Exchange setup. We connect the channel, fill the counterparty registry, set routing rules, and maintain a message journal for subsequent audit.
4. Pilot validation. We run real scenarios: matching data, discrepancies in name spelling, request without response, fallback to manual review. We observe what happens to the transaction in each case and whether the exception closes correctly.
5. Handover of regulations. We describe operator actions in typical and disputed situations, escalation procedure, criteria for stopping a transfer. We hand over documentation and train the support team.
6. Support. We monitor the share of manual reviews and rejection statistics, update rules when requirements change and new counterparties are connected.

What we hand over: configurations, schemes, regulations

Travel Rule integration does not end with a successful test transfer. Then the system lives in the operational perimeter: counterparties change receiving addresses, regulators expand the set of mandatory fields, and the duty shift must understand what to do with a stuck request.

Therefore we hand over not access credentials and call recordings, but a package by which support works without us.

• Configuration package — environment profiles, signing keys and their rotation procedure, volume and request-rate limits, message templates for different transfer types.
• Data flow schemes — path from withdrawal initiation to confirmation by the receiving party, with marked failure points and places where beneficiary data is lost.
• Routing rules — to which counterparty and via which channel a request goes, priorities, behavior when the recipient is unavailable, and the retry procedure.
• Compliance regulations — response deadlines for incoming requests, escalation when a counterparty refuses, rules for stopping a transfer with incomplete data.
• Requirements matrix by direction — mandatory field set for each jurisdiction and procedure when diverging from counterparty requirements.
• Instructions for duty shift and compliance — checklists for typical incidents: growing queue of unprocessed requests, mass rejections, status desynchronization.

We test each artifact on staging: scenarios with an unavailable counterparty, a changed response format, a revoked key. The package is accepted when the duty officer closes a typical incident according to instructions without involving developers.

Case: how an exchange removed transfer blocks after implementation

Clients saw not a rejection but a suspended transfer: funds debited, no credit, support replies "we are clarifying data with the counterparty." This is what the compliance process looked like before integration — every eighth outgoing transfer went to manual review, the median response to a source-of-funds request stayed around 40 minutes, and during peak hours the queue reached several hours.

How it was organized before implementation

Review happened in correspondence: the compliance officer manually checked the counterparty against the list, requested sender and recipient data from it, collected it into a table, and only then confirmed the transaction.

When the flow tripled, the shift did not scale — only delays and the share of erroneous rejections grew, because some responses were lost between email and the internal system.

What was changed

Travel Rule data exchange was moved to Notabene: counterparty address book with routing rules, automatic matching of wallet owners, request and confirmation templates.

For providers with confirmed infrastructure, data is sent and received without a human; the rest go into a unified queue with full transfer context.

Manual reviews became about 3% of the flow instead of 12%, confirmation on typical routes takes 2-4 minutes, client transfer cancellations almost stopped, and on the shift instead of three officers one remained — for non-standard cases.

A separate class of rejections also disappeared, when a transfer was declined due to a lost counterparty response.

How does compliance verification work when connecting a counterparty?

Compliance verification when connecting a counterparty begins before the first data exchange: the parties check whether the other side has a working Travel Rule compliance process, in which jurisdiction it operates, and whether it is ready to transmit sender and recipient information.

Usually this is a short questionnaire plus a trial exchange on a test environment — you can see how the counterparty responds to requests and what it does with fields it does not have.

Then comes exchange of lists. Each party publishes a registry of addresses tied to its infrastructure: custodial wallets, exchange addresses, client addresses.

With it, an incoming transaction is immediately recognized as its own, and a data request does not go where it is not needed — the number of false positives and manual reviews drops.

Address confirmation is the most sensitive part. If a transfer goes to an address whose ownership is unknown to us, a request is formed to the counterparty: confirm that the address is yours and that a specific client is behind it.

While there is no answer, the transaction remains unconfirmed, and internal policy decides — suspend it or let it through with a risk flag.

Discrepancies are inevitable: the address is not found in the registry, the counterparty responds with another jurisdiction, fields do not match in format.

They are handled as an incident queue: routing rules, automatic retries, escalation to a compliance control officer after attempts are exhausted. Each discrepancy goes into the journal with a reason — this is the basis for regulatory reporting.

The link between counterparties is handled by Notabene: request routing and data formats. Our task is to describe internal rules and exceptions so that compliance verification does not turn into a manual pipeline.

Technical concerns: journals, data storage, false positives

Every Travel Rule event — sending a data set to a counterparty, its service's response, confirmation or rejection — goes into an immutable operations journal.

Recording is asynchronous: unavailability of an external node does not block withdrawal of funds, the event is recorded with "pending confirmation" status and is replayed when the channel recovers.

Below are the things that most often come up at acceptance: retention periods, export on request, behavior during failures, and sensitivity threshold configuration.

What happens to a transfer if the channel to the counterparty goes down?

A retry queue with increasing delay and separation of temporary and permanent response errors. The transfer does not hang: it either arrives after connection is restored or goes to manual review with full context of all attempts. Unavailability of the external service does not stop deposit acceptance and internal operations.

Will we drown in false positives?

Thresholds are configured separately by scenario: amount, jurisdiction, counterparty type, relationship history, source of funds.

Rules are calibrated on real flow — first observation mode, where triggers are only logged, then transition to blocking mode for scenarios where the noise share is close to zero. This keeps the manual review queue manageable.

Let's discuss the task: we'll return with an estimate and connection plan

The estimate and connection plan are assembled for your perimeter: which assets and jurisdictions are in scope, how client accounting is organized, who acts as counterparty for transfers.

First we look at the current process — where payer and recipient data already exists, and where it will have to be collected, and only after that we fix the scope of work and sequence of stages.

What will be included in the work plan and in trial connection of one counterparty:

• Mapping scheme: how records from your accounting system turn into an outgoing message under the Travel Rule requirement and what to do with incomplete fields.
• Routing rules: to whom we transmit data directly, for whom we use the common compliance registry, at which step manual verification turns on.
• Exchange setup with Notabene: counterparty registry, message formats, handling rejections and retries.
• Role and access matrix: who confirms sending, who reviews discrepancies, whose actions go into the immutable journal.
• Trial connection of one counterparty on a live but limited transfer flow — you can see how routing behaves and what the operator interface shows.
• Exception review regulation and post-launch support: updating registries, responding to requirement changes, monitoring the share of successfully transmitted data.
• Documentation package: data flow schemes, operator instructions, acceptance checklist.

A trial connection reduces risk: one counterparty and a limited flow show system behavior before the entire transfer volume goes through it. Describe the task — we'll return with an estimate and connection plan.