Understanding risk events

Last updated: September 25, 2026

A risk event is a flag Onboarded raises when an employee's verified identity doesn't line up with what they submitted on their forms. Each one carries a severity and a category, sits in an unresolved queue until someone on your team reviews it, and records who resolved it and why.

What it is

When you connect an identity verification provider, Onboarded stores a verified identity record for each employee it checks — the name, date of birth, and SSN match result the provider returned. A risk event is what Onboarded creates when that verified data disagrees with the data the employee typed into their own forms, or when the verification itself fails.

If you remember nothing else: a risk event is a disagreement between two sources of truth about the same person, held open until a human decides what it means.

Why it matters

An identity check on its own is a point-in-time answer. It tells you the person passed at the moment they were checked. It doesn't tell you that the date of birth they entered on their I-9 three days later is off by a year.

That gap is where identity fraud lives, and closing it by hand means someone comparing a provider dashboard against form submissions employee by employee. Risk events do that comparison automatically and put the disagreements in one queue. This matters most when:

You're onboarding at volume and no one has time to eyeball every verification result.
Your end customers hold you contractually responsible for who you place.
You need a defensible record that a mismatch was seen, reviewed, and dispositioned — not silently ignored.

How it works

Where the verified data comes from

Risk events need an identity verification provider connected under Account Settings → Integrations. Onboarded supports Socure and Persona for this. Socure runs hosted verification covering KYC, document, and watchlist checks; the provider returns its result and Onboarded writes a verified identity record against the employee.

With Socure, each form uses your account's default workflow unless you override it. You can set a Workflow override on the form, which applies to every Socure field on it, and an individual field can override that in turn. The value has to match a published workflow name for your account.

The cross-reference check

Once a verified identity exists, Onboarded compares it against what the employee submitted. That comparison runs at two moments: when the verified identity record is created, and when the employee completes an I-9 or W-4 task. Whichever arrives second triggers the check.

These are the fields compared today, and the severity each mismatch produces:

Verified field	Compared against	Match type	Severity
First name	I-9 Section 1, W-4	Exact, normalized	`Warning`
Last name	I-9 Section 1, W-4	Exact, normalized	`Warning`
Date of birth	I-9 Section 1	Date-normalized	`Critical`
SSN match result	Provider result	Pass / fail	`Critical`

Names are normalized before comparison, so casing and surrounding whitespace won't flag on their own. Document number and address comparisons aren't part of the check yet.

Silence isn't the same as a pass. The cross-reference only runs when both sides exist. If an employee has no verified identity record, or hasn't submitted an I-9 or W-4 yet, there's nothing to compare and no risk event is created. An empty queue means no mismatches were found among the employees who have both — it doesn't mean everyone has been checked.

Severity and category

Every risk event carries a severity — Critical, Warning, or Info — and a category that tells you what kind of signal it is:

Cross Reference Mismatch — verified data disagrees with submitted form data.
Verification Failure — the verification itself didn't complete or didn't pass.
Behavioral Risk — a risk signal from the provider that isn't a field-level mismatch.

Each event is attached to an employee, and to a placement when the trigger came from placement work. It carries a plain-language message describing the specific disagreement.

Reviewing and resolving

Risk events appear under Risk Events in the sidebar. The view opens filtered to unresolved, and the sidebar item carries a badge with your unresolved count so the queue stays visible without anyone going looking for it. You can filter by status, severity, and category. An employee's own record also shows their verification and risk state directly on their profile.

Resolving an event records the timestamp, the user who resolved it, and an optional reason. Write the reason — it's what turns the queue into an audit trail. An event can only be resolved once; a second attempt is rejected rather than overwriting the first disposition.

Resolving is a review decision, not a repair. It marks that a person looked at the disagreement and made a call. It doesn't change the verified identity record, the employee's form answers, or the state of their tasks.

Example

Take an account that runs identity verification early in onboarding, before the I-9. An employee clears verification on Monday — the provider returns a verified identity, no risk events, because there's no form data to compare against yet.

On Wednesday the employee completes their I-9. The cross-reference runs again, this time with both sides present. The last name matches. The date of birth on Section 1 is a year off from the verified record, and that produces a Critical risk event in the Cross Reference Mismatch category. The unresolved badge in the sidebar ticks up.

A reviewer opens the event and sees both values side by side. From there it's a judgment call: a typo the employee can correct through a change request, or something that warrants stopping the placement. Either way, the reviewer resolves the event with a reason — Confirmed typo, employee corrected DOB on I-9 via change request — and the record of that decision stays attached to the employee.