How to investigate connected customers with Myaza Trust
Investigate connections that may explain suspicious activity. Shared devices, instruments and locations help you ask better questions; they do not establish that every connected customer is the same person.
Charles Archibong, Co-founder
· 3 min read
Key takeaways
- Each reviewed connection has a source and observation time.
- A shared device is not automatically treated as a shared identity.
- The investigation stays scoped to the intended customer.
- An outcome and its rationale remain in the case history.
Investigate connections that may explain suspicious activity. Shared devices, instruments and locations help you ask better questions; they do not establish that every connected customer is the same person.
Before you begin
Authorised access to relevant customer evidence
An existing finding or supported relationship view
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 customer you are investigating
Choose the correct organisation and environment, then open Customers → Individuals or Businesses. Search by the known customer reference and open the record. Check the customer type and reference before reviewing connections. Use the permissions appropriate to that customer, and start from an actual finding rather than browsing unrelated personal records.
Integration reference: Identity Hub API
Step 2: Inspect the available connected records
Open the customer’s supported connected-record or relationship view. Review devices, payment instruments, locations and other evidence actually present. Keep the source record and observation time with every connection. An empty view can mean no recorded evidence; it cannot establish that the customer has never used another device or account.
Integration reference: Send behaviour activity
Step 3: Read the source of each connection
Open a connected record and inspect the activity, transaction or captured evidence that created the relationship. A deviceRef connects observations supplied by your application. A shared address can represent a household. A fingerprinted instrument can represent an observed payment method. None of those, on its own, proves fraud, legal ownership or identity equivalence.
Integration reference: Instrument fields
Step 4: Use bounded network exploration where available
For authorised server-side investigation, use GET /api/v1/risk-intelligence/network/{subjectKind}/{subjectId} with the supported depth and node limits. Keep results within the organisation and environment identified by your secret key. Follow the returned bounds rather than treating a partial network as a complete customer graph. Do not substitute historical score-lineage connections for a live ownership network.
Integration reference: Drift, check reliability and relationships
Step 5: Create accountable casework for material findings
When an alert needs more evidence, open it in Investigations and select Open investigation with an investigator. Group alerts only when they belong to the same entity. Record why the connection matters and what evidence could confirm or disprove your concern. Reviewers should see the originating finding, not an unsupported claim that every connected account is fraudulent.
Integration reference: Opening and assigning an investigation
Step 6: Record an evidence-backed outcome
Review the case evidence and record the appropriate outcome with a rationale. Resolve and close are different actions. A cleared investigation is not KYC approval, and a graph edge is not permission to freeze an account. Your application handles any authorised restriction through its own decision process, using the current result and the right customer reference.
Integration reference: Investigation workspace
Get more from the capability
Send stable device and instrument references with activity so relationships have useful provenance.
Record uncertainty and alternative explanations such as shared households or corporate devices.
Compare findings over the relevant time window; do not mix different historical snapshots as though they were simultaneous.
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.
Each reviewed connection has a source and observation time.
A shared device is not automatically treated as a shared identity.
The investigation stays scoped to the intended customer.
An outcome and its rationale remain in the case history.
Troubleshooting
Connections are absent
Check that your integration sends stable supported references. Do not invent missing relationships.
The network is truncated
Respect depth and node bounds and narrow the investigation rather than claiming full coverage.
The score map shows different links
Assessment lineage explains retained score contributors; it is not a customer-ownership network.
Open the setup and integration references
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.
