How to keep customer screening up to date with Myaza Trust
Continuous monitoring rechecks selected customer evidence over time. Configure a policy, enrol eligible customers and give material changes a clear review owner.
Charles Archibong, Co-founder
· 3 min read
Key takeaways
- The effective frequency matches the selected default or override.
- Pause creates no future scheduled check or charge.
- Resume restarts the retained configuration.
- Off and re-enable preserve separate historical periods.
- A material change reaches an accountable review process.
Continuous monitoring rechecks selected customer evidence over time. Configure a policy, enrol eligible customers and give material changes a clear review owner.
Before you begin
A published monitoring policy
Eligible customer references
Explicit enrolment and cost review
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: Choose the checks and monitoring policy
Open Risk Intelligence → Rules & Policies → Ongoing monitoring. Inspect the available policy defaults. Decide which evidence needs rechecking, the default frequency, material-change threshold and escalation behaviour. Monitoring is a recurring operation, so review the current price and your expected customer volume before enrolment. A one-time clear screen does not establish future screening coverage.
Integration reference: Policy defaults and entity overrides
Step 2: Publish a policy with the correct customer scope
Review the policy’s supported entity types and publish the intended version through the policy controls. Scope belongs to the version and governs which subjects may subscribe. Start with one test customer in Sandbox. A policy saved as a draft is not necessarily the version a subscription uses. Keep organisation and environment consistent throughout the setup.
Integration reference: Entity scope and high-risk handling
Step 3: Enable monitoring for an eligible customer
Open the customer’s Risk view and use its monitoring controls, or call POST /api/v1/monitoring/subscriptions on your backend with the typed entity ID and published policyId. Send an Idempotency-Key for the mutation. Omit frequency, or use null, to follow the policy default. Send a supported explicit frequency only when the customer needs an override.
Integration reference: Enable monitoring
Step 4: Check the effective schedule and current state
Read the subscription result and the customer view. Compare frequency.effective, policyDefault, override and source so you know whether the customer follows the default or an override. Review runs, deltas, alerts and billing evidence. A changed policy default updates customers following it; it does not silently overwrite an explicit customer frequency.
Integration reference: Retrieve state and history
Step 5: Wire material changes into the team’s workflow
Subscribe to monitoring.delta.detected, and add monitoring.run.failed if your team must respond to failed checks. Verify and durably store deliveries before acknowledging them. Use Risk Intelligence for portfolio changes and the Review Queue for actionable findings. Give escalations an owner. A scheduled run or delivery notification is not proof that your team investigated the change.
Integration reference: Webhooks
Step 6: Use Pause, Resume and Off correctly
Pause temporarily stops future scheduled checks while keeping configuration and history. Resume restarts a paused subscription. Off ends that subscription permanently; re-enabling creates a linked new active period instead of rewriting the ended one. Restore frequency: null to remove an override. Test these actions on Sandbox records before using them to manage your customer book.
Integration reference: Pause, resume and Off
Get more from the capability
Apply defaults to suitable groups and reserve overrides for a documented customer need.
Review material changes rather than treating every repeated check as a new alert requiring the same work.
Monitor failed runs and spend as operational signals. A recurring check needs both evidence collection and a response process.
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.
The effective frequency matches the selected default or override.
Pause creates no future scheduled check or charge.
Resume restarts the retained configuration.
Off and re-enable preserve separate historical periods.
A material change reaches an accountable review process.
Troubleshooting
A customer cannot enrol
Check the entity type against the published policy version’s scope and the organisation’s product access.
A policy edit did not change a customer’s frequency
Check whether the customer has an explicit override.
Off cannot be resumed
An ended period is terminal. Use the documented enable operation to create its linked new period.
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.
