How to screen customers for risk with Myaza Trust
Screen customers for sanctions, politically exposed person and adverse-media findings. Start with a correctly linked customer, run the supported checks, then review possible matches with the evidence available.
Charles Archibong, Co-founder
· 3 min read
Key takeaways
- Inactive, queued, clear and potential-match results are distinct.
- Person and business checks use the correct subject.
- Review outcome and history are visible to the authorised team.
- The application receives and handles the resolved decision once.
Screen customers for sanctions, politically exposed person and adverse-media findings. Start with a correctly linked customer, run the supported checks, then review possible matches with the evidence available.
Before you begin
Screening enabled and available
Sufficient person or business information
A team member to review possible matches
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: Check screening access and the customer
Select your organisation and environment. Open the customer record and confirm the reference and subject type. Screening requires the product to be active and your role to have the appropriate access. A customer registration can report INACTIVE when screening is not running. Do not treat an inactive or queued state as a clear screening result.
Integration reference: Enrolment
Step 2: Supply usable person or business details
Use the customer’s permitted name and identity context to reduce ambiguity. For a customer already verified elsewhere, upsert the record with your stable external reference and truthful verification provenance before requesting an assessment. Keep individuals and businesses separate. A common name without supporting context can create a possible match; inventing a date of birth to make a check clearer creates incorrect evidence.
Integration reference: Assess or monitor an existing customer
Step 3: Choose onboarding screening or an explicit assessment
For onboarding, open the customer’s workflow and turn on Screening & AML. Review its ongoing-monitoring choice, then publish the workflow. Passing a workflow with screening switched off does not automatically enrol its customers through that workflow. For a specific server-side check, use the documented risk-assessment request with the returned entity ID and the selected sanctions, PEP and adverse-media checks.
Dashboard example: Choose onboarding screening or an explicit assessment
Step 4: Read the recorded screening result
In the customer’s Risk view, inspect each screening type, status, match count and checked time. The supported states distinguish queued, clear, potential match and confirmed findings. Open the evidence row to read the selected match details. No recorded evidence is not equivalent to a completed clear check, and a PEP finding is not a finding that the person committed a crime.
Integration reference: What you see in the dashboard
Step 5: Review possible matches before applying policy
Compare the customer and match evidence, including names, aliases and available identity context. Use the permitted adjudication process and record the outcome with a concise reason. Review history remains part of the evidence. Use Investigations when the finding needs accountable casework. Do not restrict another customer because their name resembles a listed person.
Integration reference: Matches
Step 6: Deliver the resolved decision to your application
Subscribe to the screening and risk events your backend actually handles. Verify webhook signatures, deduplicate by logical event ID and correlate the documented subject reference. Retrieve current screening or decision state before applying a delayed update. Your application applies the restriction or next check required by its policy; a Myaza match alone does not automatically block an account.
Integration reference: Enforcing decisions in your app
Get more from the capability
Collect useful identity context before screening to make review more reliable.
Enable ongoing monitoring deliberately when your policy needs fresh screening, with explicit cost and cadence review.
Retain both the original finding and the adjudication reason. A cleared name match should remain explainable.
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.
Inactive, queued, clear and potential-match results are distinct.
Person and business checks use the correct subject.
Review outcome and history are visible to the authorised team.
The application receives and handles the resolved decision once.
Troubleshooting
Screening says INACTIVE
Check organisation access and service activation. Nothing has been screened in that state.
A customer was verified but never enrolled
Inspect the published workflow’s screening setting and the applicable enrolment path.
There is a possible match
Review the recorded evidence and adjudicate it; do not replace uncertainty with a clear label.
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.
