How to manage crypto destinations and observations with Myaza Trust
Keep crypto destination records and deposit observations organised. A deposit observation, customer match, screening decision and settled funds are separate facts.
Charles Archibong, Co-founder
· 3 min read
Key takeaways
- An unchanged deposit retry creates no duplicate observation.
- A matching existing transaction creates no second assessment charge.
- A chain reorganisation preserves history and reaches the backend.
- Address control and approval remain separate.
- A matched deposit does not automatically credit funds.
Keep crypto destination records and deposit observations organised. A deposit observation, customer match, screening decision and settled funds are separate facts.
Before you begin
Crypto-operation permissions
Reviewed provider and address evidence where required
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 crypto transaction workspace
Open Risk Intelligence → Fraud Monitoring → Transactions → Crypto in the intended environment. Use Crypto transfers, Unmatched deposits, Crypto Provider Directory and Address book for their different jobs. Read permission allows inspection; reviews require management permission. Check the current network catalogue for supported record syntax, without assuming it supplies an automatic blockchain feed.
Integration reference: What each record means
Step 2: Connect your deposit-observation feed
Open Integration guide → Deposit feed, choose your stack and follow the exact backend request. POST /api/v1/crypto/deposits needs a secret key and Idempotency-Key. Include the stable deposit reference, network, transaction hash, output index, destination, exact decimal-string amount, currency, confirmations and observedAt. Keep the original chain output identity stable across retries.
Integration reference: Report and match a deposit
Step 3: Review unmatched observations
Open Unmatched deposits. Find the reported deposit by its reference and check the network, asset, amount and chain-output evidence. An observation does not yet identify a customer or contain a completed risk decision. Use Needs review or Ignored with a reason when your evidence cannot justify a match. Do not credit a customer merely because an observation arrived.
Integration reference: Report and match a deposit
Step 4: Match the customer or link an existing transaction
Choose Match customer to select the known customer and run the existing assessment and pricing. Choose Link existing transaction only for a matching assessed inbound crypto transaction; amount, currency, network, hash, output and destination must agree. Linking does not create another assessment charge. Keep the current version and reason with the operation and reuse unchanged retry keys after a timeout.
Integration reference: Report and match a deposit
Step 5: Manage destination records with separate reviews
In Address book, save an authorised destination and review its status deliberately. Screen it through Screen address when required. Use Verify control only for supported personal wallets and ask for a signed message, never a key or recovery phrase. A control proof establishes key control at that time, not legal ownership. Approval, screening and provider discovery do not replace one another.
Integration reference: Screen, edit or verify control
Step 6: Handle confirmations, reorganisations and enforcement
Update deposit confirmations or report a chain reorganisation through the documented API. Reorganisation retains historical assessment evidence rather than silently erasing the match. Subscribe to supported deposit and address events, verify signatures and deduplicate by logical event ID. Your backend checks chain finality and current clearance before funds movement or credit; a matched observation is not settlement.
Integration reference: Webhooks and safe retries
Get more from the capability
Use stable output indices to avoid treating two outputs from one chain transaction as the same deposit.
Keep team reviews scoped to your organisation without changing platform-sourced provider evidence.
Use address reveal only with the appropriate permission and recorded reason; masked records are the default.
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.
An unchanged deposit retry creates no duplicate observation.
A matching existing transaction creates no second assessment charge.
A chain reorganisation preserves history and reaches the backend.
Address control and approval remain separate.
A matched deposit does not automatically credit funds.
Troubleshooting
The deposit has no customer
Resolve the relationship using authorised evidence; an observation is not automatic attribution.
A review save conflicts
Reload the current record version and reconcile any earlier uncertain operation.
An institution lookup is unknown
Discovery coverage is separate from ownership and screening. Do not infer self-hosting or approval.
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.
