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:

{
  "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.