BCMS

Ensure Travel Rule KYV and Wallet Verification Are Applied

4 min read

Objective

Ensure Travel Rule, counterparty VASP due diligence and wallet verification controls are applied where required.

Control Activity

Before a relevant virtual-asset transfer or wallet use, personnel confirm the applicable USD/EUR 1,000 Travel Rule information, secure transmission, counterparty VASP assessment and risk-tier wallet-control evidence are complete. Unhosted-wallet information is collected from Bitkaya’s customer; failed verification prevents wallet use; and counterparty and whitelisted-wallet changes trigger monitoring or reassessment.

Travel Rule Applicability

The Travel Rule applies to virtual asset transfers involving client funds when:

  • The transaction is between Bitkaya and another VASP
  • The transaction is between Bitkaya and another obliged entity, such as a financial institution

For transactions involving unhosted wallets, the FATF does not require VASPs to submit collected Travel Rule information to the unhosted wallet. However, as a risk mitigation measure, Bitkaya should collect the required originator and beneficiary information from its own customer.

Travel Rule Information Requirements (≥ USD/EUR 1,000)

Originator Information:

  • Full name
  • Account number or unique transaction identifier
  • Physical address, national identity number, customer identification number, or date and place of birth

Beneficiary Information:

  • Full name
  • Account number or unique transaction identifier

For transactions below the threshold, Bitkaya should collect and retain basic information as per its risk-based approach.

Secure Data Transmission

  • Encryption: Utilize secure encryption methods to transmit information to beneficiary institutions
  • Protocols: Adopt standardized protocols like the InterVASP Messaging Standard (IVMS 101) to facilitate interoperability
  • Third-Party Solutions: Leveraging Travel Rule compliance solutions that support secure data sharing

KYV File Requirements

The Know Your VASP compliance file contains, as appropriate to risk:

  • License and/or information about the regulatory supervisor
  • Company registry extract
  • Certificate of incorporation (or other appropriate certificate of registration or licensing)
  • Ownership and control information where relevant
  • Sanctions screening results
  • Independent data sources, including electronic sources (e.g. business information services)

Non-Custodial Wallet Verification Methods

Clients must complete one of the following verification methods to whitelist a non-custodial wallet on a risk-based basis:

  • Self Declaration — The customer declares that he owns the address
  • Message Signing — Clients sign a unique, Bitkaya-provided message using their wallet’s private key (compatible with MetaMask, Ledger, Trezor, WalletConnect)
  • Satoshi Test — Clients send a small, specified amount of cryptocurrency from their non-custodial wallet to a Bitkaya-designated address within a set timeframe
  • Address Ownership Proof Protocol (AOPP) — Clients prove wallet ownership through QR codes or links, facilitating automatic verification without exposing private keys

Risk-Tiered Wallet Verification

Low-risk clients: Self-Declaration or Visual Proof (screenshot/video displaying wallet interface with relevant address and timestamp)

Medium-risk clients: Digital Signature (client signs unique message with private key) or Micro-Transaction (Satoshi Test)

High-risk clients: Digital Signature + Micro-Transaction + AML Wallet Monitoring Report (risk scoring, exposure to illicit activities, associations with sanctioned entities)

Whitelisting and Reassessment

Upon successful verification, the wallet address is added to the client’s whitelist and future transactions to or from this address are permitted without additional verification. If verification fails or is incomplete, transactions involving the wallet are prohibited. Bitkaya conducts periodic reviews of whitelisted wallets to ensure continued compliance. Clients may be required to re-verify ownership if there are significant changes in transaction patterns, regulatory requirements evolve, or security concerns arise.

Evidence

  • Expected evidence: Travel Rule data record.
  • Expected evidence: counterparty VASP assessment.
  • Expected evidence: wallet verification evidence.
  • Expected evidence: transfer decision record.
  • Expected evidence: secure transmission and data-completeness record.
  • Expected evidence: counterparty and wallet reassessment record.
  • Evidence location: compliance evidence repository and applicable operating system.
  • Retention: according to Bitkaya AML/CTF/CPF record-retention requirements.
  • Testing method: Sample above- and below-threshold transfers, hosted and unhosted wallets, counterparties and clients in each risk tier; verify required originator/beneficiary fields, secure transmission, KYV evidence, prescribed ownership method, whitelist status, failed-verification stop control and reassessment triggers.
  • Testing frequency: annual, and after material AML/CTF/CPF changes where applicable.

Relationships

Assurance

Runtime effectiveness results are maintained in Odoo and assessed through the Hermes workflow tracked in ISS-HERMES-001. This note defines design, ownership, evidence expectations and testing method; it does not contain a manually maintained operation, evidence or overall effectiveness rating.

  • Design status: implemented from approved AML/CTF/CPF Compliance Manual version 2.2

History

  • 2026-07-26: Added Travel Rule threshold, field, secure-transmission, tiered wallet-verification and reassessment testing after a full manual rescreen.
  • 2026-07-26: Created from the approved AML/CTF/CPF Compliance Manual version 2.2.

Graph View

Backlinks