Purpose
Apply Travel Rule expectations, counterparty VASP due diligence and wallet ownership verification where relevant to virtual asset transfers.
Scope
This procedure applies to virtual asset transfers, VASP-to-VASP exposure, self-hosted wallets, counterparty VASP relationships and higher-risk wallet or jurisdiction exposure.
Steps
| # | Action | Details | Evidence |
|---|---|---|---|
| 1 | Determine Travel Rule applicability | Determine whether a virtual-asset transfer is between Bitkaya and another VASP or obliged entity (e.g. financial institution) and therefore requires Travel Rule handling | Travel Rule review record |
| 2 | Collect originator information | For transfers of USD/EUR 1,000 or more, collect and transmit: full name; account number or unique transaction identifier; and physical address, national identity number, customer identification number, or date and place of birth | Originator and beneficiary data |
| 3 | Collect beneficiary information | For those transfers, collect and transmit: full name; and account number or unique transaction identifier. For transactions below the threshold, collect and retain basic information as per Bitkaya’s risk-based approach | Originator and beneficiary data |
| 4 | Verify information accuracy | Implement robust KYC procedures to verify identities of originators and beneficiaries. Ensure collected information is accurate and up-to-date. Maintain records | Originator and beneficiary data |
| 5 | Transmit information securely | Use approved encryption, an interoperable protocol such as InterVASP Messaging Standard (IVMS 101) where applicable, or an approved Travel Rule compliance solution supporting secure data sharing | Secure transmission record |
| 6 | Assess counterparty VASP | Before relevant transfers, assess counterparty VASP’s licensing/registration, regulator, jurisdiction, AML/CTF controls, sanctions exposure, ownership and control, company registration, and ability to meet Travel Rule obligations. Continuously monitor for changes in compliance status | Counterparty VASP assessment |
| 7 | Maintain KYV file | Retain the KYV file including: license/regulatory supervisor info, company registry extract, certificate of incorporation/registration, ownership and control information where relevant, sanctions screening results, and independent data sources. Monitor counterparty for changes in status or risk | Counterparty VASP assessment |
| 8 | Handle unhosted wallet transfers | FATF does not require Travel Rule information submitted to unhosted wallets. As risk mitigation, collect required originator/beneficiary information from own customer. Apply EDD measures (e.g. verify unhosted wallet owner identity) when appropriate. Retain all relevant information | Wallet verification evidence |
| 9 | Verify non-custodial wallet ownership | Permit a non-custodial wallet only after approved ownership-verification and whitelisting requirements are complete, ensuring the wallet is owned and controlled by the client. Aligns with FATF Recommendation 16 and guidance from Switzerland, EU, Singapore | Wallet verification evidence |
| 10 | Apply verification methods | Clients must complete one of: (a) Self Declaration; (b) Message Signing (compatible with MetaMask, Ledger, Trezor, WalletConnect); (c) Satoshi Test (small specified amount sent to Bitkaya-designated address within set timeframe); (d) AOPP (QR codes/links for streamlined ownership proof without exposing private keys) | Wallet verification evidence |
| 11 | Verify low-risk wallets | For low-risk clients, use approved self-declaration or timestamped visual proof where regulation and risk permit | Wallet whitelist record |
| 12 | Verify medium-risk wallets | For medium-risk clients, require verified digital signature or controlled micro-transaction within prescribed period. Approved AOPP workflow may be used where it provides equivalent cryptographic ownership proof | Wallet whitelist record |
| 13 | Verify high-risk wallets | For high-risk clients, require digital-signature and micro-transaction evidence and obtain an AML wallet-monitoring report (risk scoring, exposure to illicit activities, associations with sanctioned entities) before transaction processing | Wallet verification evidence |
| 14 | Whitelist or reject wallet | Upon successful verification, add wallet address to client’s whitelist; future transactions to/from this address permitted without additional verification. If verification fails or is incomplete, transactions prohibited. Record wallet, client, method, result, verifier, date and supporting evidence | Wallet whitelist record |
| 15 | Reassess whitelisted wallets | Conduct periodic reviews of whitelisted wallets. Reassess after significant transaction-pattern change, regulatory change, security concern or client-risk change. Reverify when required | Counterparty monitoring and reassessment evidence |
| 16 | Protect verification data | Handle all verification data per Bitkaya’s Data Protection and Privacy Policy, ensuring confidentiality and compliance with applicable data protection laws | Wallet verification evidence |
| 17 | Escalate and retain transfer records | Escalate missing, unreliable or inconsistent information before execution or completion. Retain transfer decision, KYV, wallet evidence, and any documented risk acceptance for at least the applicable AML retention period | Risk acceptance or escalation record |
Evidence
- originator and beneficiary data
- counterparty VASP assessment
- wallet verification evidence
- Travel Rule review record
- risk acceptance or escalation record
- secure transmission record
- counterparty monitoring and reassessment evidence
- wallet whitelist and reverification record
Relationships
- Policy: POL-AML-001 AML CTF CPF Compliance Manual
- Process: PRC-FCI-001 Financial Crime and Integrity
- Controls: CTRL-AML-006 Ensure Travel Rule KYV and Wallet Verification Are Applied
- Privacy handling: PROC-PRIV-006 Handle AML Sanctions and Regulatory Data Confidentially
- Manual coverage: sections 6.1-6.9 and 13.1-13.5.
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 the Travel Rule threshold and data fields, secure transmission, KYV file, tiered wallet-verification methods, whitelisting and reverification after a full manual rescreen.
- 2026-07-26: Created from the approved AML/CTF/CPF Compliance Manual version 2.2.