Introduction

As part of the Travel Rule we have had to introduce new validation steps into the transaction workflow. You can see the old / new workflow in our Travel Rule blog.

In order to be compliant with Travel Rule, additional information is required for some transactions which result in the transfer(s) of assets. You can provide us this information via a mutation being added to our GraphQL API, updateTravelRuleInfo.

You must provide Travel Rule Information for each transfer of assets in a transaction. For Bitcoin this will likely only be 1 transfer between 2 addresses but this could result in many transfers in Ethereum due to smart contracts.

Getting the transfer(s) of the transaction

To get the transfers which require Travel Rule information for a Transaction you can make the following request to our GraphQL API.

query getTransaction($id: String!) {
  user {
    transaction(id: $id) {
      transfers {
        items {
          id
          from {
            id
          }
          to {
            id
          }
          direction
          asset {
            name
          }
          amount {
            value
          }
          originator {
            ...FullTravelRuleInfo
          }
          beneficiary {
            ...FullTravelRuleInfo
          }
        }
      }
    }
  }
}

fragment FullTravelRuleInfo on TravelRuleInfo {
  isCaller
  name
  accountId
  customerId
  vasp {
    id
    name
  }
}

The input of $transactionId changes depending on whether you created the transaction(outbound) or whether the transaction involves you but was not created by you (inbound).

Transaction Direction	`$transactionId`
Outbound	Use the `requestId` returned after creating the transaction via one of our API endpoints.
Inbound	Use the `transactionHash` of the transaction on chain

This query will return a list of the transfers which require Travel Rule information from the Transaction.

Sending us Travel Rule information for the transfer(s)

You can then use the transfer.id to send us Travel Rule information for all the transfers using the updateTravelRuleInfo mutation.

  mutation updateTransfersWithTravelRuleInformation(
    $transfers: [TransferInput!]!
  ) {
    updateTravelRuleInfo(transfers: $transfers) {
      success
    }
  }

Where the $transfers input accepts an array of objects with the following schema.

input TransferInput {
  id: String!
  beneficiary: TravelRuleInfoInput
  originator: TravelRuleInfoInput
  submit: Boolean
}

input TravelRuleInfoInput {
  # A value of true indicates that the user's Organisation is the originator/beneficiary of this transaction, depending on the transfer direction of SENT/RECEIVED respectively, in which case no further information is required. If any other fields are provided, they will be overwritten.
  # A value of false indicates that the current user's Organisation is a broker or a 3rd party, in which case all additional fields below are required.
  isCaller: Boolean!
  name: String
  accountId: String // this can be the wallet address
  # If value >= 1000 EUR, an additional identifier for customer is required for the originator
  customerId: String
  vasp: VaspInfoInput
}

enum VaspType {
  LISTED
  UNLISTED
  UNKNOWN
  UNHOSTED
}

input VaspInfoInput {
  # If the type is LISTED, the other fields below are not required.
  # For any other type, all fields are required
  type: VaspType
  id: String
  name: String
}

Below is an example JSON payload providing Travel Rule information for a Transfer.

{
  "variables": {
    "transfers": [
      {
        "id": "f37ce790-6f85-06ed-505f-6eeb2e636a3c:0",
        "beneficiary": {
          "name": "Jane Doe",
          "isCaller": false,
          "vasp": {
            "name": "Bitpanda Custody (Prev Trustology)",
            "id": "6463bc4adc04916198c994bf",
            "type": "LISTED"
          }
        },
        "originator": {
          "name": "John Doe",
          "isCaller": false,
          "vasp": {
            "name": "Bitpanda Custody (Prev Trustology)",
            "id": "6463bc4adc04916198c994bf",
            "type": "LISTED"
          }
        },
        "submit": true,
      }
    ]
  }
}

Please make sure you submit Travel Rule information to us for every transfer within the transaction. Bitpanda Custody Compliance must approve the transfer of every asset within a transaction, before a transaction can be signed and submitted to the network.

With the submit flag in the payload, Bitpanda Custody Compliance will now have received the beneficiary and originator information provided to review and ensure Travel Rule is being followed. If the submit flag is omitted from the request or false , the information provided will simply be saved and a subsequent request will need to be made with the submit flag set to true to submit the information to Bitpanda Custody Compliance.

What data should be sent for Travel Rule

The exact guidelines are covered in our Travel Rule blog but please see our Travel Rule - what data is required article for more information.

Providing the correct VASP information

We provide another API you can use to retrieve the list of registered Virtual Asset Service Providers (VASP).

query getVasps {
  vasps {
    items {
      id
      name
    }
  }
}

There are 4 different VASP types that describes an originator/beneficiary:

UNKNOWN - You do not know the VASP information about the originator/beneficiary.
UNHOSTED - You know that the originator/beneficiary is an unhosted address.
UNLISTED - You know the VASP information for the originator/beneficiary yet it's not in the list provided.
- Please send us what you believe the vasp.name and/or vasp.id in this case.
LISTED - You know the VASP information for the originator/beneficiary and it's in the list provided
- In this case, the vasp.name and vasp.id are not required.

Contact us

If you have any issues, please get in touch. For technical support reach out to help@bitpandacustody.com. For compliance issues reach out to travelrule@bitpanda.com.