> Toden documentation. For the full index fetch /llms.txt. Every page is available as Markdown by appending .md to its URL. Identity verification uses /api/kyc, Risk Intelligence uses /api/v1; they are separate contracts with different error shapes. Never invent an endpoint, field or enum value: read the API reference page for the operation first.

# Set up Travel Rule

> Your company, institutions and application.

## Get started in the dashboard

1. Open **Fraud Monitoring → Transactions → Travel Rule** and select **Set up Travel Rule**.
2. **Your company:** confirm the company you represent. Toden reuses your company verification and reviews the directory match.
3. **Institutions:** choose the exchanges you send to or receive from. Review each company before approving information exchange. Save your selection.
4. **Your application:** follow the integration guide and configure your result webhook. You can do this while Toden prepares the connections.
5. **Test and activate:** Toden checks the institution connection automatically; you can also rerun its test. Send a test transaction and enter its external activity reference. Complete the displayed checks and request activation.

Setup is saved for your organisation and environment. Close it and return later to
continue. Toden manages certificate issuance and renewal in the background; customers
do not upload certificates, edit server configuration or restart anything.
Direct TRP connections use managed certificates; CodeVASP connections use the approved
institution registration. CodeVASP-only setup does not require a TRP certificate.

An independent Toden reviewer confirms company representation and activation evidence.
Activation checks institution communication, configured notifications, the received
test and country policy reviews. The reviewer also checks evidence of real result
delivery/recovery and the organisation's wallet enforcement. A configured webhook is
not proof that your application verified its signature or acted on a decision.

**Active** means this organisation's setup is activated in the selected environment.
Every transfer still needs its own current clearance. **Pause Travel Rule** stops new
exchange and execution; it does not reverse a transfer that already completed.

### Connect a crypto company

If your company is missing from the directory, a Toden platform administrator can add
it through **Crypto providers → Add crypto company**, with its registration evidence.
Toden establishes the partner arrangement once, then provisions customer connections
covered by that arrangement automatically. **Awaiting institution** means Toden is
still arranging that channel. Selecting a name cannot make another company trust it.

Once the connection appears in **Set up Travel Rule**, use **Test connection** to check
it or **Pause** to stop new exchanges. **Messaging setup needed** means identity testing
passed but the exchange configuration is incomplete. Open the adjacent information
button for the next action. A verified connection is not an approval for any transfer.

Technical diagnostics and previous configuration remain under **Existing connections
and diagnostics**. Keep Sandbox and Live separate.

### Add another destination

Open **Institutions**, select the company and save. Existing active connections keep
working. Toden reuses the platform's approved partner route and provisions it for your
organisation without a restart or another company activation review. **Connection
requested** means the destination is still being arranged; **Connected** means its
current connection checks passed. Each transfer still has its own clearance checks.

Your team's institution approval and the destination's secure communication and
country reviews remain required. An unavailable destination does not disable other
destinations. Removing an institution stops new exchanges with that institution only.
Company identity changes, expired company approval or pausing the whole service still
require setup attention.

## A practical example

You operate **Exchange A**. Alice is your customer and wants to send USDT to Bob at
**Exchange B**.

1. Your backend sends Toden one transaction containing Alice's and Bob's available
   information, the amount and the destination institution.
2. Toden uses the approved connection to Exchange B to exchange the required information.
   You do not build another integration for every transfer or handle certificates.
3. Toden reports what is missing, needs review or is ready for the next step. Your
   backend retrieves the current clearance, consumes its short-lived authorisation
   once, and instructs **your own wallet** to send. For a held transfer it does not send.
4. If Bob's required details were missing, your backend submits only the additional
   information against the same transaction. If the first request was complete, that
   follow-up request is unnecessary.

Adding Exchange B to a directory is like adding a business contact. Establishing its
connection is like verifying that you have the right secure delivery address. A contact
record alone cannot receive a message. The connection is reused, not rebuilt per user.

## Your company and your counterparties

**Your company** identifies the organisation you represent. **Add crypto company** adds a directory record when an institution is missing; it does not connect an application or enable secure messaging.

**Connections** are authenticated channels between institutions. Before exchanging regulated information, Toden needs a reviewed channel to the institution involved. A saved directory entry is not enough. You do not need to configure a connection for each transfer or each individual customer. Reuse the institution connection within the correct organisation and environment.

Your application connects to **Toden's API and webhooks**. The institution connection is a different path: Toden exchanges the required information with the other institution. Your wallet still enforces the current decision.

### What if you only have a wallet address?

A blockchain wallet address does not tell Toden the owner's name, their exchange or
how to contact them. Toden does not guess ownership or send personal information to
an endpoint discovered from an unverified address.

Ask your sender for the recipient's exchange and available recipient details. The
recipient can obtain a **Travel Address** from a supporting exchange and share it
with the sender. This is a secure information-exchange address, not a crypto wallet
address. With a Travel Address, Toden can select an unambiguous existing approved
route automatically. The receiving exchange privately resolves its own customer.

If information is missing, Toden returns the required fields to **your application**.
Your application asks your sender to supply or obtain them. Toden cannot independently
contact an unknown wallet owner. Details must still be checked; supplying a name is
not proof that the person controls the wallet.

| Recipient destination               | What happens                                                                                                                         |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| Connected institution               | Exchange through its authenticated route, whether or not it is a Toden customer.                                                     |
| Institution without a working route | Request the destination in setup. Keep the transfer held while Toden arranges a compatible, approved channel.                        |
| Confirmed self-hosted wallet        | Follow the separate self-hosted wallet flow and required control checks. Do not call an unknown wallet self-hosted just to continue. |
| Unknown owner or institution        | Obtain more information; do not guess a route or release a held transfer.                                                            |

Toden is not a closed customer-only network. External institutions can communicate
through an approved CodeVASP route or compatible TRP connection without purchasing Toden. A supported
protocol does not mean every exchange already has a working connection.

For a new transfer, choose the receiving institution. Toden offers one ready route
per institution; where both are available, the managed CodeVASP route is preferred.
A prepared or uncertain message keeps its original route. Do not create another
message or switch protocols to work around a lost response.