How to set up Travel Rule exchange with Myaza Trust
Set up your organisation’s Travel Rule information-exchange journey, test it and follow the displayed activation requirements. Every transfer still needs its own current authorisation before your wallet acts.

Charles Archibong, Co-founder
· 4 min read

Key takeaways
- Missing beneficiary data is collected against the original transaction.
- Potential and confirmed sanctions have separate Review and stopped paths.
- Lost responses reuse the same request and route.
- A test fixture is never treated as live institution proof.
- Real wallet enforcement is qualified before live release.
Set up your organisation’s Travel Rule information-exchange journey, test it and follow the displayed activation requirements. Every transfer still needs its own current authorisation before your wallet acts.
Before you begin
Institution and company review
Supported TRP connection and secure-channel setup
Current policy and applicable information requirements
Use a team member with permission for this control. Check the organisation and environment before changing a setting. Review the current price before a paid check or ongoing enrolment. Screenshots show an example workspace or the public integration reference; they do not show a real customer or a completed paid check.
Set up and use the capability
Step 1: Open the saved setup for your environment
Choose Sandbox and open Fraud Monitoring → Transactions → Travel Rule → Set up Travel Rule. The setup is saved for the organisation and environment so you can return later. Review the current supported connection path. New R1 setup uses managed TRP connections; do not select a parked legacy connector as a new activation route.

Integration reference: Get started in the dashboard
Step 2: Confirm the company you represent
In Your company, select the correct company and inspect its verification and directory evidence. A company selection is not approval to represent it. Myaza’s independent review confirms representation. If the company is missing, use the supported request process for a platform administrator to add its sourced record; do not enter another company just to finish setup.

Integration reference: Your company and your counterparties
Step 3: Choose and review the destination institutions
In Institutions, select the counterparties your organisation intends to exchange with and save. Review each offered connection’s actual readiness. Awaiting institution, Messaging setup needed and a connected route are different states. A directory listing or successful identity test cannot establish a working information channel. Existing active destinations keep their own state when you request another institution.

Integration reference: Add another destination
Step 4: Publish the applicable transfer rules
Open the linked Fraud rules → Travel Rule controls. Install a suitable rule or create a draft, then inspect the scope, network, information requirements and deliberate authorisation opt-ins. Save and Publish draft separately. Country qualification and execution requirements remain additional checks. A threshold amount alone does not enable funds movement.

Integration reference: Test in Sandbox
Step 5: Connect your application and result receiver
In Your application, follow the exact server integration and configure the result webhook. Verify raw-body signatures, deduplicate events and recover failed delivery. Your backend asks the sender only for fields the current transfer reports missing. An unknown wallet address does not identify the recipient or their exchange; obtain the institution or supported Travel Address rather than guessing.

Integration reference: What if you only have a wallet address?
Step 6: Test, request activation and retain holds
In Test and activate, run the offered connection check, send the supported Sandbox transaction and provide its external activity reference. Complete the displayed requirements and request activation when eligible. Independent review checks more than a saved webhook count. After activation, each transfer still needs fresh clearance and the required single-use backend authorisation. Your wallet moves or credits funds; Myaza does not.

Integration reference: Acceptance checklist
Get more from the capability
Add destinations through Institutions so their readiness remains distinct from your organisation’s overall setup.
Use a supported Travel Address to select an already approved route where available, rather than treating a blockchain address as an exchange address.
Keep self-hosted wallet controls separate from institution exchange. Do not label an unknown wallet self-hosted to avoid requirements.
Test before relying on it
Run the supported Sandbox or simulator scenarios for this product. Where a tool is Production only, check access and scope first, then use only a permitted, deliberately reviewed Production test. A documentation screenshot or a successful page load is not an end-to-end integration test.
Missing beneficiary data is collected against the original transaction.
Potential and confirmed sanctions have separate Review and stopped paths.
Lost responses reuse the same request and route.
A test fixture is never treated as live institution proof.
Real wallet enforcement is qualified before live release.
Troubleshooting
A selected institution is awaiting connection
Its route still needs preparation or review. Keep the affected transfer held; other ready destinations have separate state.
A webhook is configured but activation is blocked
Check the displayed requirements, actual signature verification, delivery recovery and wallet enforcement evidence.
A response was lost
Retain the prepared route, body and request key. Reconcile the existing operation before sending another message.
Open the setup and integration references
Read the integration reference
Back to Solutions. Choose the capability you want to activate, then follow its own guide.
Sources

Charles Archibong
Co-founder
Charles Archibong co-founded Myaza Trust. He writes about identity verification, financial technology, and the practical work of building trusted digital services.


