# Set up Travel Rule

## 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. Myaza 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 Myaza prepares the connections.
5. **Test and activate:** Myaza 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. Myaza 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 Myaza 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 Myaza platform administrator can add
it through **Crypto providers → Add crypto company**, with its registration evidence.
Myaza establishes the partner arrangement once, then provisions customer connections
covered by that arrangement automatically. **Awaiting institution** means Myaza 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. Myaza 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 Myaza one transaction containing Alice's and Bob's available
   information, the amount and the destination institution.
2. Myaza 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. Myaza 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, Myaza 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 **Myaza's API and webhooks**. The institution connection is a different path: Myaza 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 Myaza the owner's name, their exchange or
how to contact them. Myaza 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, Myaza can select an unambiguous existing approved
route automatically. The receiving exchange privately resolves its own customer.

If information is missing, Myaza returns the required fields to **your application**.
Your application asks your sender to supply or obtain them. Myaza 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 Myaza customer. |
| Institution without a working route | Request the destination in setup. Keep the transfer held while Myaza 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. |

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

For a new transfer, choose the receiving institution. Myaza 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.