Onboarding screening fails in predictable places, and almost none of them are the screening itself. It fails when the check runs against an identity nobody verified, when three data sources produce three separate review queues, when a risk rating is implied rather than recorded, and when an approved customer is never enrolled into monitoring and so is screened exactly once, on the day they joined.
What each step hands to the next
The pipeline above shows the order and who acts. What matters operationally is what each step passes on, because a step that produces the wrong artefact breaks the one after it rather than failing on its own.
| Step | What it produces | What breaks downstream without it |
|---|---|---|
| Collect | Name, date of birth, jurisdiction, entity details | Screening matches against a partial identity, so candidates cannot be dismissed |
| Verify | A confirmed identity, or a failed application | Every later result describes a string rather than a customer |
| Screen | Clear, or one or more candidate matches | Nothing to resolve, and no record that anything was checked |
| Resolve | Cleared, escalated, or confirmed match | The decision falls to whoever approves, without the evidence in front of them |
| Rate and decide | An approved, escalated or declined application, with the rating recorded | Monitoring has no risk band to apply, so everyone is treated identically |
| Hand over | A customer who continues to be screened | The control becomes a one-off gate and the book silently ages |
Why verification comes before screening
Running a screening check against a name the applicant merely typed in produces a result about a string, not about a customer. If the applicant is impersonating someone, a clean result is actively harmful: it puts documented assurance in the file for a person who was never checked.
Verifying first means every downstream result attaches to a confirmed identity. It also reduces match volume, because verified attributes such as date of birth and jurisdiction are exactly what an analyst needs to dismiss a false positive quickly.
Match resolution is where the cost sits
Most candidate matches are false positives, usually common names sharing a surname with a listed person. The screening step is fast and cheap. Resolution is neither, because it needs a human comparing identifiers and recording why they reached their conclusion.
Three things reduce that cost without reducing coverage. Tuned matching thresholds set to your own risk appetite rather than a vendor default. Whitelisting, so a match you have already dismissed does not return on every subsequent scan. And verified identity attributes available in the review screen, so the analyst can dismiss a candidate in seconds rather than opening three systems.
The handover nobody audits
Approval feels like the end of the process, which is why enrolment into ongoing monitoring is the step most often left implicit. When it is implicit, it eventually stops happening, and no one notices, because nothing fails visibly. The customer book simply ages, screened once each on the day each customer joined.
Making enrolment an explicit step with its own record is what turns onboarding screening from a gate into a control. Sanctions lists change constantly, and a customer's status can change without any action on their part or any transaction through your product.
Where this sits against the rest
Onboarding is the first workflow, not the whole programme. Enhanced due diligence handles the cases this workflow escalates. Ongoing monitoring handles everything after step six. For the screening engine and data behind step three, see PEP and sanctions screening, adverse media checks and identity verification. For what happens to escalated cases, see enhanced due diligence.