--- name: myaza-travel-rule description: Integrate and improve Myaza Trust travel rule flows. Use when designing, implementing, debugging or reviewing travel rule, including policy outcomes, customer enforcement and recovery. --- # Myaza Trust: Travel Rule ## Start with the customer outcome Exchange transfer information securely and obtain an enforceable current decision. Ask only for missing choices that affect the design: the customer's business flow, launch markets, review team, desired decision and the action their application will enforce. Do not ask for API keys in chat. ## Read the current contract 1. Discover current resources at https://trust.myaza.co/llms.txt and https://trust.myaza.co/documentation/index.json. 2. Read these guides before implementation. They are the same authored source as the human documentation: - https://trust.myaza.co/documentation/travel-rule/markdown - https://trust.myaza.co/documentation/travel-rule-setup/markdown - https://trust.myaza.co/documentation/travel-rule-policies/markdown - https://trust.myaza.co/documentation/travel-rule-transactions/markdown - https://trust.myaza.co/documentation/travel-rule-information/markdown - https://trust.myaza.co/documentation/travel-rule-execution/markdown - https://trust.myaza.co/documentation/travel-rule-incoming/markdown - https://trust.myaza.co/documentation/travel-rule-self-hosted/markdown - https://trust.myaza.co/documentation/travel-rule-confirmation/markdown - https://trust.myaza.co/documentation/travel-rule-webhooks/markdown - https://trust.myaza.co/documentation/travel-rule-testing/markdown 3. Also read authentication, environments, errors and webhook authentication. Use https://trust.myaza.co/documentation/ai-integration/markdown for API-family boundaries and handoff requirements. 4. For /api/v1 operations, fetch https://trust.myaza.app/api/openapi.json and resolve referenced schemas. Do not assume it describes the separate /api/kyc or /api/identity families. Their guide contracts remain necessary. 5. If the guide and deployed response differ, report the discrepancy and inspect the actual schema. Never invent an endpoint, enum or readiness flag. Use the index SHA-256 values to identify the content reviewed. ## Design safeguards Create the transaction once with all available originator and beneficiary information. Submit information again only to fill or correct requested fields; it is not a second transaction. Reuse the returned activityId. A directory company is not an authenticated connection. Reviewed identity, current policy, secure channel, received information and wallet authorisation are separate gates. Consume a short-lived authorisation once before the organisation's wallet acts; uncertain retries reconcile rather than execute twice. Incoming confirmation and customer-reported txids do not prove independent settlement. Never infer clearance from an Allow risk score, webhook receipt, passing connection test or all fields being present. Keep API credentials on the customer's backend. Institution TLS certificates are managed by Myaza, not the customer. Use Travel Rule setup to confirm the company, select institutions, connect the application and request reviewed activation. Setup is separate in each environment. A missing partner arrangement remains awaiting institution; do not fabricate trust or ask customers to operate a certificate authority. Scope reads and writes to the organisation and environment. Use least-privilege permission checks. Never auto-publish a policy, activate Live, change financial entitlements or approve a company on the user's behalf without explicit permission. Country coverage and rules are not a guarantee of regulatory compliance; the organisation's authorised reviewer owns its obligations. ## Implement and verify - Myaza supports approved TRP and CodeVASP routes in the same organisation. Do not ask customers for institution certificates or vendor secrets. Keep protocol evidence distinct and use the canonical transaction exchange/execution APIs. A prepared or uncertain message must never switch routes or be blindly resent. Record an inbound intent with exact customer/wallet/network/asset/amount before a partner inquiry. A general address-book record does not establish a local deposit account. CodeVASP replies are journalled before response; a recorded response is not delivery, credit permission or independently observed settlement. - Keep organisation activation separate from destination readiness. Adding an institution must not reset company activation or interrupt an unchanged route. Pending routes remain unavailable until the partnership, team review, connection tests and country evidence are ready. This is not universal exchange connectivity. - A wallet address is not an institution identity or contact address. Collect the recipient institution and a recipient-issued Travel Address where supported. Exchange preparation can omit `connectionId` when that Travel Address matches exactly one current scoped route. Never fetch an arbitrary supplied endpoint, guess a recipient or relabel an unknown destination as self-hosted. Missing-field requests go to the integrating application, not directly to an unknown recipient. External TRP institutions need an agreed route, not a Myaza subscription. - Start in Sandbox. Use documented explicit scenarios for deterministic tests; ordinary Sandbox operations can use configured pricing. - Reuse stable customer and operation references. Send an idempotency key where the operation contract requires one. On an uncertain response, retain the same payload and key and reconcile current state. - Model pending, review, blocked, unavailable and retryable states explicitly. Never turn an error or missing result into approval. - Verify signed webhooks on raw bytes, deduplicate and persist before acknowledging, and fetch current state before enforcement. - Minimise personal data. Do not log keys, raw identity documents, party details, full wallet addresses or biometric evidence. - Add executable tests for the happy path, invalid input, missing information, tenant/environment isolation, permission denial, duplicate requests, timeout/recovery and out-of-order notifications. - Use the product's testing guide for required negative and boundary cases. A mocked success does not prove a real institution channel or Live readiness. ## Deliver the customer handoff Provide the implemented flow, exact API families and versions used, data mapping, decision-to-action table, review owner, webhook recovery procedure, test evidence, and unresolved external prerequisites. Separate local qualification from Sandbox integration and Live acceptance. Suggest workflow improvements with rationale and trade-offs; do not silently change the customer's risk appetite or claim legal approval.