KYC: approve, then verify

The two review stages, why they are not synonyms, and the one thing about KYC that is your firm's policy rather than a rule in the software.

Overview

Approve and verify sound like synonyms. They are not, and the difference is the substance of this lesson.

Approve is a reviewer saying I have looked at this and it is satisfactory. It is per reviewer.

Verify is the check being marked complete.

Between them sits a policy decision that is yours, not the platform's: how many approvals a check needs before it is verified.

What you'll learn

The status ladder a check moves through
What approving records, as against verifying
Who decides how many approvers are required
Why keeping the two apart matters

The status ladder

Status	Meaning
Initialised	The check exists. Nobody has been contacted.
Invited to Create Account	The invitation has been sent.
Account Created	The participant has an account.
Ready	They can begin.
Submitted	They have submitted their information and documents.
Reviewing	Under review by the team.
Verified	Complete.
Incomplete	Returned to the participant — A7.5.

Note that the first two are distinct states: a check sits at Initialised until somebody invites the participant.

Steps

From the project Dashboard, open the process under Active Operations. On its KYC dashboard, open a check showing Submitted.
Review the details and the uploaded documents — the identity document, the proof of address, the personal information.
If satisfactory, approve it. The dashboard records the approval.
Where your process requires further approvals, the next reviewer repeats steps 1 to 3.
When the required approvals are in, verify the check. It moves to Verified.
If something is wrong, mark it incomplete with a reason rather than approving it (A7.5).

How many approvers is your decision

The dashboard shows how many approvers a check has. How many it needs follows your firm's process, not a rule in the software.

On a one-person team, a single approval precedes verification. On a team with a four-eyes policy, two approvals do. The platform accommodates either — it records approvals and leaves the threshold to you.

The practical consequence: decide once and apply it consistently. A team that assumes the software enforces four-eyes will not get four eyes, and an inconsistently applied policy is worse than either policy.

What good looks like

Every check reads Verified, each having been approved by however many reviewers your process requires, and each having been genuinely looked at. The dashboard shows no outstanding or incomplete cases.

Common problems

A check is approved but not verified. A valid intermediate state, not a fault. It means the review has happened and verification has not — on a multi-approver process it may be waiting for a second reviewer.

Someone verified without reviewing. Nothing prevents it, which is exactly why the separation exists. Approval is the record that a person looked; treating it as a click to get past is the failure mode this design discourages.

You are unsure how many approvals are needed. That is a question for your team, not the platform. Agree it once.

The documents look fine but something feels wrong. Mark it incomplete with a reason. Approving something you are not satisfied with converts a compliance question into a record that says you were satisfied.