How to check and monitor address presence with Myaza Trust
Verify address presence over a supported observation window. Configure capture, native reporting and customer consent together, then distinguish verified, failed and inconclusive evidence.
Charles Archibong, Co-founder
· 3 min read
Key takeaways
- A zero-progress watch has a clear diagnostic path.
- Permission refusal has a usable foreground or recovery route.
- Verified, failed and inconclusive remain distinct.
- Sandbox’s compressed clock is not presented as live residency proof.
- Recurring cost and opt-out are clear before ongoing activation.
Verify address presence over a supported observation window. Configure capture, native reporting and customer consent together, then distinguish verified, failed and inconclusive evidence.
Before you begin
An eligible address and customer consent
Supported mobile location declarations
Separate opt-in for ongoing monitoring
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: Start with an eligible captured address
Confirm that the customer has an authorised address pin and stable external reference. In the workflow, enable Address Intelligence and open Presence. Choose the supported observation window and evidence requirements. A one-time pin is a claim; a multi-day watch needs separate reporting. Business premises and unsupported browser-only journeys cannot be assumed to produce residential presence evidence.
Integration reference: Presence verification
Step 2: Configure the native app and consent journey
Use the React Native or Flutter SDK and pass the stable userId. Follow the background-location setup for your platform when enabling background reporting. React Native needs the documented registration at startup; Flutter needs its manifest and Info.plist declarations. Explain what is collected and let the person control permission. Enabling the workflow switch without app setup leaves the watch short of evidence.
Integration reference: What your app has to do
Step 3: Report presence on app open and foreground return
Call the documented presence reporter for the same externalUserId whenever the app opens or returns to the foreground. This supports people who decline background permission and phones whose battery manager restricts it. Do not fabricate coordinates or substitute an IP location. If capture occurred in a hosted flow, use the documented authorised pin handoff before expecting native reports.
Integration reference: Reporting presence from your app
Step 4: Check the watch’s actual progress
Open Risk Intelligence → Address verification or retrieve GET /api/kyc/address/presence/{externalUserId}. Inspect status, progress, observation counts and evidence tier. The endpoint does not return the pin. A watch stuck at zero needs reporting recovery. Use the reporter’s reason and the SDK’s presenceStatus to distinguish missing pin, permission denial and disabled location services.
Integration reference: Showing the person where the check stands
Step 5: Interpret the three resolution paths
verified means the recorded evidence met the policy. failed requires an integrity contradiction such as spoofed-location evidence; absence is not a failure. inconclusive means the window ended without enough evidence and is not a finding against the customer. Use signed result events to update your application. A background-only requirement must inspect the appropriate policy evidence rather than relying on total days alone.
Integration reference: Holding the decision on it
Step 6: Enable ongoing cycles only when intended
For ongoing address confirmation, review the separate always-on setting, cadence and annual price. Supported cadence choices are 30, 60, 90, 180 or 365 days. Keep a one-off presence check distinct from annual renewal coverage. Turning renewal off stops future cycles; a check already in flight still has its own resolution. Review permissions and revocation recovery in your app.
Integration reference: Always-on monitoring
Get more from the capability
Use foreground reporting as a supported fallback and show the evidence tier actually running.
Test manufacturer battery restrictions on the Android devices your customers use; use the documented foreground-service option only with explicit setup and customer-visible disclosure.
Show progress without exposing the person’s address or live whereabouts. Notify through your app when the recorded outcome changes.
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.
A zero-progress watch has a clear diagnostic path.
Permission refusal has a usable foreground or recovery route.
Verified, failed and inconclusive remain distinct.
Sandbox’s compressed clock is not presented as live residency proof.
Recurring cost and opt-out are clear before ongoing activation.
Troubleshooting
Days stay at zero
Check reporter calls, stored pin, user reference, services and permissions.
Background reporting stopped
Read the actual SDK status and use the supported settings recovery path. Do not keep labelling it background.
The window was inconclusive
Collect the missing permitted evidence or offer the appropriate next journey. Absence does not prove a false address.
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.
