Travel Rule

1. Overview

The Travel Rule requirements apply to customers in European markets and are part of the EU regulatory framework.

The purpose of the Travel Rule is to collect information about the parties involved in a cryptocurrency transaction, including the ownership of the sending and receiving wallets.

For Paybis integrations, the Travel Rule information is collected through a questionnaire presented to the user during the transaction flow.

2. Travel Rule Questionnaire

By default, after a transaction is created, the Travel Rule questionnaire is displayed directly in the Paybis widget. The user completes the questionnaire themselves by answering questions about the ownership and type of wallet involved in the transaction.

The user must indicate:

• Whether the wallet belongs to them or to another person/company.
• Whether the wallet is self-hosted (personal wallet) or hosted by an exchange/platform.
• If the wallet belongs to a third party, whether that party is an individual or a company.

The information collected depends on the transaction flow:

• Buy Crypto: Information about the beneficiary (the recipient of the crypto-assets).
• Sell Crypto: Information about the originator (the sender of the crypto-assets).

API-based pre-filling (optional)

As an alternative to having the user enter the information manually in the widget, the integration can optionally provide the Travel Rule data through the API using the travelRuleInfo parameter in POST /v3/request

This allows the integration to pass the relevant information when creating the transaction, so that the questionnaire can be skipped.

3. Buy Crypto Flow

In the Buy Crypto flow, the user purchases cryptocurrency and specifies the wallet to which the crypto-assets will be sent.

Only the beneficiary object is allowed inside travelRuleInfo.

There are four possible scenarios.

3.1. Sending crypto-assets to myself → Personal wallet

The user purchases cryptocurrency and sends it to their own personal, self-hosted wallet.

This applies to:

• Non-custodial wallets
• WalletConnect integrations
• Partners with embedded non-custodial wallets
• White-label platforms with their own wallet infrastructure (depending on the custody model)

Examples: MetaMask, Trust Wallet, Phantom, Ledger.

{
  "flow": "buyCrypto",
  "travelRuleInfo": {
    "beneficiary": {
      "relationship": "SELF",
      "walletType": "SELF_HOSTED"
    }
  }
}

3.2. Sending crypto-assets to myself → Exchange or platform

The user purchases cryptocurrency and sends it to their own account on a centralized exchange or another hosted platform.

This applies to:

• Centralized exchanges
• Fintech/neobanking apps with custodial crypto accounts
• White-label platforms with their own wallet infrastructure (depending on the custody model)

Examples: Binance, Kraken, Coinbase.

{
  "flow": "buyCrypto",
  "travelRuleInfo": {
    "beneficiary": {
      "relationship": "SELF",
      "walletType": "HOSTED_AT_PLATFORM",
      "platform": "Binance"
    }
  }
}

The platform field must contain the name of the exchange or platform hosting the wallet.

3.3. Sending crypto-assets to another recipient → Individual

The user purchases cryptocurrency and sends it to a wallet belonging to another individual.

{
  "flow": "buyCrypto",
  "travelRuleInfo": {
    "beneficiary": {
      "relationship": "THIRD_PARTY",
      "recipientType": "INDIVIDUAL",
      "firstName": "John",
      "lastName": "Doe",
      "country": "DE"
    }
  }
}

Required information:

• firstName – recipient's first name.
• lastName – recipient's last name.
• country – recipient's country (ISO 3166-1 alpha-2 country code).

3.4. Sending crypto-assets to another recipient → Company

The user purchases cryptocurrency and sends it to a wallet belonging to another company.

{
  "flow": "buyCrypto",
  "travelRuleInfo": {
    "beneficiary": {
      "relationship": "THIRD_PARTY",
      "recipientType": "COMPANY",
      "companyName": "Acme Ltd",
      "country": "DE"
    }
  }
}

Required information:

• companyName – recipient company's name.
• country – company's country (ISO 3166-1 alpha-2 country code).

4. Sell Crypto Flow

In the Sell Crypto flow, the user sells cryptocurrency and sends crypto-assets from a wallet to Paybis.

Only the originator object is allowed inside travelRuleInfo.

There are four possible scenarios.

4.1. Sending crypto-assets from myself → Personal wallet

The user sends cryptocurrency from their own personal, self-hosted wallet.

Examples: MetaMask, Trust Wallet, Phantom, Ledger.

{
  "flow": "sellCrypto",
  "travelRuleInfo": {
    "originator": {
      "relationship": "SELF",
      "walletType": "SELF_HOSTED"
    }
  }
}

4.2. Sending crypto-assets from myself → Exchange or platform

The user sends cryptocurrency from their own account on a centralized exchange or another hosted platform.

Examples: Binance, Kraken.

{
  "flow": "sellCrypto",
  "travelRuleInfo": {
    "originator": {
      "relationship": "SELF",
      "walletType": "HOSTED_AT_PLATFORM",
      "platform": "Binance"
    }
  }
}

The platform field must contain the name of the exchange or platform hosting the wallet.

4.3. Sending crypto-assets from another individual

The cryptocurrency is sent from a wallet belonging to another individual (a third-party originator).

{
  "flow": "sellCrypto",
  "travelRuleInfo": {
    "originator": {
      "relationship": "THIRD_PARTY",
      "recipientType": "INDIVIDUAL",
      "firstName": "John",
      "lastName": "Doe",
      "country": "DE"
    }
  }
}

Required information:

• firstName – individual's first name.
• lastName – individual's last name.
• country – individual's country (ISO 3166-1 alpha-2 country code).

4.4. Sending crypto-assets from another company

The cryptocurrency is sent from a wallet belonging to another company (a third-party originator).

{
  "flow": "sellCrypto",
  "travelRuleInfo": {
    "originator": {
      "relationship": "THIRD_PARTY",
      "recipientType": "COMPANY",
      "companyName": "Acme Ltd",
      "country": "DE"
    }
  }
}

Required information:

• companyName – company's name.
• country – company's country (ISO 3166-1 alpha-2 country code).

5. Unhosted Wallet Verification

In addition to the Travel Rule questionnaire, an additional Unhosted Wallet Verification step is required for transactions with a value of USD 1,000 or more, according to the described Paybis flow.

This verification applies to both Buy Crypto and Sell Crypto transactions when the customer uses their own self-hosted wallet.

When is verification required?

This additional verification applies only when all the following conditions are met:

1. The transaction is either a Buy Crypto or Sell Crypto transaction.
2. The wallet belongs to the customer themselves (relationship = SELF).
3. The wallet is self-hosted (walletType = SELF_HOSTED).
4. The transaction value is USD 1,000 or more.

In other words, the verification is required when the customer uses their own personal, self-hosted wallet to send or receive crypto-assets.

When is verification performed?

The verification timing depends on the transaction flow:

Buy Crypto:

• The customer successfully completes the payment.
• Unhosted Wallet Verification is requested.
• Once verification is completed, the crypto-assets can be paid out to the customer's wallet.

Sell Crypto:

• Paybis receives the crypto-assets from the customer.
• Unhosted Wallet Verification is requested.
• Once verification is completed, the fiat payout can be processed.

Available verification methods

The user can complete the Unhosted Wallet Verification using one of the following methods.

1. Self-Declaration

The user selects the Self-Declaration option.

By selecting this option, the user confirms that they own and control the specified wallet address.

No wallet connection or blockchain transaction is required for this method.

2. Connect Wallet

The user connects their personal cryptocurrency wallet to verify ownership.

The user must connect the wallet associated with the address provided for the transaction.

3. Ownership Verification Transaction

The user performs a micro-transaction from their personal wallet to a wallet address provided by Paybis.

The purpose is to demonstrate that the user has control over the wallet from which the transaction is sent.

The user must:

1. Open their personal wallet.
2. Send the requested test amount to the wallet address provided by Paybis.
3. Complete the blockchain transaction.
4. Allow Paybis to verify the transaction.

The test transaction is used only for wallet ownership verification.

6. API Requirements and Validation Rules

The following rules must be followed when providing travelRuleInfo in the /v3/request endpoint.

Additional requirements:

• country must use a two-letter ISO 3166-1 alpha-2 country code (e.g. DE, PL, FR).
• recipientType must be either INDIVIDUAL or COMPANY.
• relationship must be either SELF or THIRD_PARTY.
• walletType must be either SELF_HOSTED or HOSTED_AT_PLATFORM.
• For Buy Crypto requests with travelRuleInfo, cryptoWalletAddress must also be provided, because the beneficiary questionnaire describes the destination wallet.

Providing Travel Rule data

There are two ways to handle Travel Rule questionnaire data:

1. Default widget flow: The questionnaire is displayed in the Paybis widget after transaction creation. The user completes it directly in the widget. No additional API-side questionnaire data needs to be provided by the integration.
2. API-based pre-filling (optional): The integration passes the relevant data using travelRuleInfo when creating the transaction. This functionality must first be agreed with the Paybis Account Manager and enabled for the integration.