How to assess account activity with Myaza Trust
Assess logins, account recovery and other non-payment activity. Send the actual customer and device context, read the returned decision and enforce it in your own app.
Charles Archibong, Co-founder
· 3 min read
Key takeaways
- Allow, Review and Block use distinct application paths.
- Missing device evidence is not invented.
- A same-request retry produces no duplicate side effect.
- A delayed decision change is reconciled against current state.
Assess logins, account recovery and other non-payment activity. Send the actual customer and device context, read the returned decision and enforce it in your own app.
Before you begin
Stable event and customer references
Published rules and a review owner
Your app handles the returned decision
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: Enable the relevant Fraud Monitoring area
Open Risk Intelligence → Fraud Monitoring in Sandbox. Follow the setup for account activity and review the activation requirements displayed for your organisation. Check your Manage fraud rules access. A saved setup is different from enabled decisions. Do not enable unrelated monitoring areas just to remove a setup warning.
Integration reference: Risk Intelligence quickstart
Step 2: Install or configure the relevant fraud rules
Open Rules & Policies → Fraud rules → Rule library. Search for the controls appropriate to the activity you send, then inspect them before selecting Install. Installation publishes a version in the current organisation and environment. Test a custom rule against historical evidence before publishing it. Review decision thresholds and money limits in Settings separately from individual rule conditions.
Integration reference: Start with the rule library
Step 3: Send a named activity from your backend
Use POST /api/v1/activities with a secret key. Supply a stable externalActivityId, typed subject, the supported activity type and original occurredAt. Types include login, signup, password_reset, beneficiary_added, profile_change, device_change, payout and withdrawal. Include deviceRef and end-user IP only when observed. Use the complete transaction endpoint for money movement with sender and recipient evidence.
Integration reference: Send behaviour activity
Step 4: Read and apply the decision summary
Read assessment.summary.outcome, reason and nextAction. allow permits the action under your policy; review requires the hold or review path; block stops it. Store the activity and decision references. Do not reconstruct the outcome from the score or count of matched rules. Myaza does not automatically revoke a login session or change access in your application.
Integration reference: API response
Step 5: Find the same activity in the dashboard
Open the Fraud Monitoring account-activity view and search by the external activity reference. Inspect the decision, matched rules and supporting evidence. Confirm that the customer and device are the ones your application intended. Shared device evidence can have a legitimate explanation. Use an investigation when the finding needs an owner or a deeper outcome.
Integration reference: Send behaviour activity
Step 6: Handle retries and later decision changes
Keep the same logical activity reference and idempotency key for an unchanged retry after response loss. Subscribe to fraud.activity.assessed and applicable fraud.decision.changed updates. Verify signatures and deduplicate by the envelope event ID. Re-read current state for a delayed update. A retry must not create another assessment, charge or account side effect.
Integration reference: Idempotency and freshness
Get more from the capability
Use the stable end-user device reference across journeys so new-device and relationship evidence can be useful.
Record only context your application actually observed. Do not substitute your server’s IP for the user’s IP.
Combine a review decision with a subject-bound extra check when your policy needs more login assurance.
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.
Allow, Review and Block use distinct application paths.
Missing device evidence is not invented.
A same-request retry produces no duplicate side effect.
A delayed decision change is reconciled against current state.
Troubleshooting
No rules match
Check the published rule scope and the fields your activity actually supplies.
The same event conflicts on retry
Compare immutable input. A stable reference cannot be reused for a different activity.
A Block decision did not stop the action
Inspect the backend enforcement path. Myaza records the decision; your app enforces it.
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.
