KYB on VASPs

A message lands in your Envoy inbox. A counterparty VASP is asking you to complete a Travel Rule transfer, or your own customer wants to withdraw funds to an address that resolves to another VASP. Either way, the instinct is to move fast: complete the message, send the data, keep the transaction flowing.

That instinct is exactly what creates risk. Before any personally identifiable information (PII) crosses the wire in either direction, the VASP on the other end needs to be verified — not just identified.

Start with a simple question: who is this VASP?

Every inbound or outbound Travel Rule message names a counterparty. Envoy's Counterparty VASPs section will tell you which VASP is on the other side of the transaction — checking the TRISA GDS tab, the Daybreak tab, or falling back to a manual entry — but appearing in one of those directories only tells you who is asking. It doesn't tell you whether they're legitimate, licensed, sanctioned, or safe to exchange originator and beneficiary data with.

So the first real decision point is: do you already have a verified relationship with this VASP?

• If yes, and the relationship is current, proceed with the message under your existing risk assessment.
• If no — or if the relationship has lapsed or was never verified — onboarding comes first, not after.

Why onboarding can't wait

Travel Rule data is some of the most sensitive information a VASP handles: originator and beneficiary names, wallet addresses, dates of birth, sometimes national ID numbers. Sending that data to an unverified counterparty is a data protection incident waiting to happen, regardless of which protocol (TRISA, TRP, or Sunrise) carries the message. This is true whether you're the one receiving the request or the one about to send funds out.

A withdrawal request is actually the higher-risk moment. Once your customer's data leaves your systems, you can't recall it. That's why due diligence on the beneficiary VASP has to happen before you hit send, not as a follow-up.

The three-part onboarding checklist

1. Get the LEI from the VASP

A Legal Entity Identifier ties the counterparty to a specific, verifiable legal entity in the Global LEI System, rather than just a name in a directory. It's the fastest way to confirm that the entity behind the Envoy message actually exists as a registered legal person, and it gives you a stable reference point if the VASP rebrands, changes domains, or is later referenced in a sanctions or enforcement action.

2. Do KYB on the VASP where possible

LEI confirms existence; KYB confirms legitimacy. A proper KYB check on a VASP counterparty typically covers:

• Corporate structure and ownership — who ultimately owns and controls the entity, including look-through on any corporate or trust layers
• Licensing and registration status — is it actually registered or licensed as a VASP/MSB/VASP-equivalent in its home jurisdiction, and is that registration still active
• Sanctions and adverse media screening — on the entity, its directors, and its beneficial owners
• Regulatory standing — any enforcement actions, license suspensions, or warnings from regulators or bodies like FATF's grey/black lists

Not every counterparty will hand over full KYB documentation on first contact, and not every jurisdiction makes registry data easy to reach — hence "where possible." But partial KYB (confirmed licensing plus sanctions screening) is still meaningfully better than proceeding on the VASP's name alone.

3. Sign an NDA / data-sharing agreement

Before any PII moves, both sides should be bound by a data protection and confidentiality agreement that sets out how the data will be stored, secured, and used, and what happens if there's a breach. This is the contractual backstop for everything the KYB check couldn't fully verify.

Same rules, both directions

This checklist applies symmetrically:

• Inbound message in Envoy → identify the sender → check for an existing verified relationship → if none, run LEI + KYB + NDA before responding with data.
• Outbound withdrawal → identify the destination VASP → check for an existing verified relationship → if none, run the same LEI + KYB + NDA sequence before the withdrawal message goes out.

The direction of the transaction doesn't change the underlying question: am I about to share sensitive customer data with an entity I've actually verified?

Where Blockpass fits in

Blockpass runs a KYB service that covers this exact counterparty-VASP check — corporate structure, beneficial ownership, licensing/registration status, and sanctions/adverse media screening — with results tracked in the KYB Dashboard so a counterparty only needs to be verified once, not re-checked before every transfer. It sits alongside Blockpass Envoy, which handles the Travel Rule messaging itself (Customer Accounts, Counterparty VASPs, and the Transfer Inbox for sending or receiving via TRP, or Sunrise).

In practice, that means the "identify the VASP" step in Envoy and the "verify the VASP" step in KYB can run on the same account: look the counterparty up in the KYB Dashboard before acting on the Envoy message, and if they're not yet verified, submit them for KYB before the transfer proceeds.