# Transfer requirements

## Create a Travel Rule rule

Open **Risk Intelligence → Rules & Policies → Fraud rules → Travel Rule**.

1. Select **Rule library** and compare the reviewed starting points in the table. Select **Install** beside one to open a prefilled draft, or select **Create rule** to start from a blank scope.
2. Name the rule and choose its transfer direction, counterparty type, jurisdictions, assets and networks.
3. Choose the standard, enhanced or **Supporting detail with alternatives** package.
4. Add an optional amount threshold only when your governing policy requires one.
5. Select **Test impact**. This previews the complete draft against recent crypto transfers without changing transactions, creating alerts or charging customers.
6. Select **Save draft**.
7. Select **Publish draft** when you are ready to make the saved policy version active.

The active policy can contain several ordered rules. The first rule matching a transfer determines the information requirements. A transfer outside every explicit scope remains unknown and is held rather than treated as exempt.

### Let customers provide a permitted alternative

**Supporting detail with alternatives** collects the core party information plus
one supporting sender detail: a customer reference or a structured address. Choose
**Individuals** for **Sender type** under **Advanced transfer filters** to also
allow date and place of birth together. Business rules do not offer birth details.
Review the chosen package against your country requirements before publication;
these are configurable building blocks, not automatic country approval.

On a transaction with missing information, select **Add missing information**.
When the policy permits alternatives, choose the detail you can provide and fill
the displayed fields. Myaza reassesses the transaction and retains the previous
attempt for audit. A partial address correction preserves the address fields
already supplied. Hidden alternatives are not submitted by the form.

For API clients, `fields.baseRequired` lists always-required paths, while
`fields.alternatives` lists groups of fully qualified paths. Supply **every** field
in **one** group for each requirement. Send nested address fields as an object:

```json
{
  "originator": {
    "residentialAddress": { "city": "Lagos", "country": "NG" }
  }
}
```

The example completes a previously supplied street address; it is not a complete
address by itself. Post corrections to
`/api/v1/transactions/{id}/travel-rule/information` using the same idempotency key
and body on retries. Missing/unknown evidence still holds the transfer, and the
organisation's wallet must use the separate execution authorisation flow.

## Publish a draft

Saving a rule never activates it. Myaza stores the complete configuration as a new draft version so the active policy and historical assessments remain unchanged. Any authorised Travel Rule manager can publish the draft, including the person who created it. Publication records the publisher and activation time, then freezes that policy version so historical decisions remain reproducible.

## Information packages

**Standard party information** collects legal names and account identifiers for the originator and beneficiary. VASP transfers also collect the counterparty VASP legal name and jurisdiction.

**Enhanced party and VASP information** additionally collects party residential addresses and countries of residence, plus VASP registration and licence identifiers.

These packages are product starting points, not a legal determination. Review and adjust the saved draft for the laws, corridors and services applicable to your organisation.