Identifying and vetting the counterparty

Before a VASP sends Travel Rule data it must answer two questions: who controls the destination address, and can that party be trusted with the customer's personal data? A wrong answer either leaks personal data to an unknown party or sends value to a business the firm would never have onboarded as a customer. This lesson covers how to identify the counterparty, how to vet it and what to do when it cannot receive data.

Is the destination a VASP?

A withdrawal request gives the firm an address and, at best, the customer's description of where it leads. Several methods can tell a VASP from an unhosted wallet, and each fails in its own way:

No single method is enough. A sound procedure triangulates: it records the customer's declaration, the analytics result with its confidence, and any directory response, then applies a rule for conflicts. A typical rule: if any reliable source says the address belongs to a service, treat it as a VASP transfer even if the customer said "my own wallet", and ask the customer. Analytics labels are hypotheses, not facts; see the lesson Blockchain analytics for compliance, and the IDFE-BA course for how clusters and labels are built.

Shared deposit addresses deserve care. Some providers use one address for all customers and separate them by a memo or destination tag. The address then identifies the provider, but only the tag identifies the beneficiary's account, so the tag must be captured and carried in the Travel Rule data.

VASP directories

Most Travel Rule networks maintain a directory of participating VASPs, typically listing the legal name, Legal Entity Identifier (LEI, ISO 17442), declared registrations, technical endpoints and the keys or certificates used to authenticate messages. Directories solve discovery and authentication, which the lesson Travel Rule data and messaging covers.

Discovery itself carries a privacy risk. A method that asks many VASPs at once whether they control an address tells all of them that some customer is about to send funds there. Prefer methods that query only the likely counterparty, and make sure no personal data travel until the counterparty has confirmed control and passed due diligence.

A directory listing is not due diligence. Directory operators apply different admission checks, and a listing says little about a counterparty's AML controls. Verify what matters independently: confirm registration or licensing in the public register kept by the competent authority, check the LEI record, and search for public enforcement actions.

Counterparty VASP due diligence

FATF expects an originating VASP to conduct counterparty VASP due diligence before it sends customer data, much as a bank vets a correspondent. It is not repeated for every transfer: it is done once, refreshed periodically according to risk, and reopened when a trigger occurs, such as adverse media, a license withdrawal or a spike in suspicious activity. Some teams borrow the structure of the Wolfsberg Group's Correspondent Banking Due Diligence Questionnaire (CBDDQ) and adapt it to crypto.

The output is a documented decision: approve, approve with conditions (for example, transfer limits or enhanced monitoring of flows), or reject, with a risk rating and a review date. Rejected counterparties go on an internal block list that the withdrawal flow checks automatically.

The sunrise issue

The sunrise issue is uneven implementation: a VASP where the Travel Rule is in force must transact with counterparts in countries where it is not yet law, or where it is law but the counterpart has no compatible tool. FATF expects a risk-based decision rather than a blanket rule either way.

Even when the counterparty cannot receive the data, the originating VASP still collects, screens and keeps it, so that it can answer authorities and monitor the flow. The incoming side of the sunrise issue, transfers that arrive without data, is handled in the lesson Travel Rule operations and exceptions.

Worked case

A customer asks to withdraw USDC worth USD 18,000 and declares the destination "Exchange Z". Analytics labels the address as belonging to a service named Exchange Z with medium confidence. Z is not in any directory the firm uses. Its website claims registration in fictional Country C, but the public register of Country C's competent authority has no entry for it.

1. Identification: two sources agree that the destination is a service, so the transfer is treated as a VASP transfer.
2. Vetting: Z cannot be confirmed as registered, there is no due diligence file, and no secure channel exists.
3. Decision: hold the withdrawal, tell the customer that the firm cannot send to this provider at present, and offer to send to a vetted provider or to a self-hosted wallet the customer can prove it controls.
4. Escalation: the compliance analyst reviews the customer's history for other flows to Z and considers whether the pattern is suspicious.
5. Record: the attribution evidence, the register search with its date, the decision and the approver are stored with the case.

The firm did not decide that Z is criminal. It decided that it could not meet its own obligations with an unverified counterparty, and it documented why.

Exam focus: methods for telling a VASP from an unhosted wallet and the weakness of each; why triangulation and a written conflict rule are needed; memo and tag addresses; why a directory listing does not replace due diligence; the elements of counterparty VASP due diligence (identity, license, AML controls, data protection, jurisdiction, exposure) and its periodic and trigger-based refresh; the sunrise issue and the risk-based responses to it; collecting and keeping data even when the counterparty cannot receive it.