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.

These changes mean that our previous API architecture doesn't work well if there are potential changes to the transaction as required by Travel Rule.

These changes fundamentally mean that using the API to create a transaction and returning the signing data (i.e. the exact transaction payload such as from / to / transaction count / UTXOs etc) is no longer possible. This is because when creating a transaction it is possible that the transaction is not ready for sending until after some time and as such key transaction attributes could change (such as UTXOs or the transaction count could change if another transaction is approved for sending) rendering the original transaction data incorrect.

These changes will mean we are planning to change our API to be a request / polling architecture such that an API call to create a transaction would return only a requestId and status. The API caller would then poll the API to find out the status of the transaction. Only after the transaction has passed all the compliance checks would it be ready for signing and thus the signing data would be made available. There will be additional webhooks for event driven systems.

These changes will affect:

These changes are currently in the design phase meaning that this may not be the finalised solution however, these changes are likely to require changes to your API integration with the Trust API.

Therefore we would like to keep you informed of progress and give you as much time as possible to plan for any changes.

Checkout our main blog on TR for the timelines for Travel Rule but we expect major API changes in the next few months.

A new article will be published soon with more details regarding these changes and we will notify our customers via email of these changes.

If you have any additional questions please reach out to help@bitpandacustody.com.