Verification touches identity documents and protected characteristics. The design decisions below are deliberate, and one creates an obligation you must act on.
Users can only verify themselves
A check always belongs to the signed-in account. A user can start, view or abandon only their own checks, and nothing they submit can declare them verified.
Results only arrive through verified channels
A result is accepted only from a signature-verified message from the provider, or from ActiveManage reading the result back from the provider's own service. A user returning from a provider's flow is treated as a prompt to re-check, never as the result itself — otherwise somebody could verify themselves by editing the address they were returned to.
Only the decision is stored
What is kept is a decision, not a dossier: the provider's reference, the outcome, and a one-line evidence summary safe to show an administrator. Documents, selfies and dates of birth stay with the provider.
Set a retention policy on the event trail
This one needs your attention. Raw messages from providers are kept, in the Verification Events record, so support queries and disputes can be investigated. Those messages can contain considerably more personal data than the stored decision does.
ActiveManage does not prune that record for you. Decide how long you need those messages, set up a scheduled task to remove older rows, and write the decision into your retention schedule.
Audit
Verification status changes are written to the audit trail as well as the event trail, so they appear in the Activity Log alongside everything else.
Tell users what happens
Identity verification sends personal data to a third party. Make sure your privacy notice names the providers you use and what they receive — before you switch one on, rather than after.