vID Alert-to-Action Matrix
CRA processors and support teams reviewing flagged vID submissions in Cortex
How to use this document
When a vID submission does not clear auto-approval, the order is routed to manual review and remains in Pending status with a Pending score until your team resolves it. Cortex displays one or more alerts explaining why.
This matrix maps each alert to what triggered it, what it means, and the action most CRAs take in response.
Two things to keep in mind before you begin:
The recommended actions below are recommendations, not determinations. Cerebrum is not a consumer reporting agency and does not decide whether a submission is acceptable. Your organization owns the final decision on every flagged order. See Decision Ownership in the vID Workflow for the full explanation.
Your internal policy governs. Where this document says "most CRAs," substitute your own documented review standard. If you have not yet established one, we recommend developing it with your legal counsel before your team begins processing flagged orders at volume.
The three resolution paths
Every flagged submission resolves to one of three outcomes:
Outcome | When it applies | How to execute in Cortex |
|---|---|---|
Mark verified | Your reviewer is satisfied the applicant is who they claim to be, despite the alert | Set the score to ID Verified and move the order to Complete |
Reorder | The submission is not usable as-is, and the applicant can reasonably resubmit | Use Send Reorder Invite at the top of the order. The score moves to On Hold until the new submission arrives |
Route to client | The alert is substantive, and the decision belongs with the end-user employer, or your policy requires escalation | Set the score to ID Not Verified, move to Complete, and deliver the report through your standard process |
Reorders are initiated by the CRA, not by Cerebrum. Your team controls when an applicant is asked to try again.
Alert reference
Image quality and capture alerts
Verification data is missing
What happened: Cerebrum could not extract readable data from the ID scan, so the verification checks could not run. After two failed scan attempts, the applicant was routed to manual data entry, which is intentional product behavior — it prevents applicants from becoming stranded mid-flow.
What it means: This is an inability to read the document, not evidence of fraud. The underlying ID may be perfectly valid.
Typical action: Reorder, with guidance to the applicant on lighting and framing. Where the issuing state supports AAMVA, dispatching an AAMVA check may resolve the order without asking the applicant to resubmit. See the AAMVA Verification Guide.
Photo forgery check alert
What happened: The submitted image showed characteristics associated with an altered or reproduced document.
What it means: Most commonly, this is a scan or image quality artifact rather than an actual alteration. It can also indicate a genuinely manipulated document.
Typical action: Reorder to obtain higher-quality scans of the live document. If a second submission produces the same alert, escalate under your policy.
Photocopy check alert
What happened: The applicant uploaded a photograph or photocopy of their ID instead of the physical document.
What it means: The submission does not meet live-document capture requirements. It is not by itself evidence of fraud.
Typical action: Reorder with explicit instruction to photograph the physical ID in hand. Note that packages can be configured to require live capture and reject uploads outright — see the Partner Admin Guide.
Cropped or incomplete document
What happened: Part of the ID — commonly the back — was cut off in the capture, preventing full data extraction.
What it means: A framing error.
Typical action: If all other checks passed, many CRAs mark verified. If the missing region contains data your policy requires, reorder.
Barcode anomaly
What happened: The PDF417 barcode on the back of the ID could not be read cleanly, or its contents did not align with the data printed on the front.
What it means: Ranges from a poor capture of the barcode to a genuine mismatch between the document's printed and encoded data. The distinction matters.
Typical action: Review the extracted front-of-ID data against the barcode data shown in Cortex. If they agree and the anomaly appears to be a read failure, reorder for a cleaner capture or dispatch AAMVA where supported. If they disagree substantively, treat as a route to client escalation.
Biometric and liveness alerts
Selfie and ID image do not match
What happened: The facial comparison between the applicant's live selfie and the ID portrait did not meet the matching threshold.
What it means: Can result from lighting, angle, significant appearance change since the ID was issued, or a genuine mismatch.
Typical action: Review the images side by side in Cortex. If the discrepancy is explainable, mark verified under your policy. If not, route to client or escalate.
Alert on passive liveness biometric verification
What happened: Liveness or facial verification did not pass.
What it means: The system could not confirm that a live person completed the flow.
Typical action: Reorder. Persistent failure across attempts warrants escalation under your policy.
Note on accessibility and religious accommodation. Applicants may be unable or unwilling to present an unobstructed facial image — for medical, disability, or religious reasons. Packages can be configured to bypass liveness where a client's requirements allow it, and alternative verification paths are available. Contact your Cerebrum representative to discuss configuration. Because accommodation obligations vary by jurisdiction and employment context, we recommend that you determine your approach with your legal counsel.
Fraud and integrity alerts
Overall fraud check alert
What happened: This is a roll-up indicator. It reflects the state of the checks beneath it.
What it means: If any subordinate check triggers an alert, the overall fraud check also displays an alert. It is not an independent finding.
Typical action: Do not act on this alert directly. Open the order and identify which underlying check fired, then apply the guidance for that specific alert.
Expired ID
What happened: The document's expiration date has passed.
What it means: The identity data may still be accurate, but the document is no longer current. Expiry checks route to manual review rather than failing the order outright, so your team retains the decision.
Typical action: Governed by policy. Some CRAs accept a recently expired document where all other checks passed; others require a current document in all cases. Reorder if a valid document is required. This is a policy determination worth confirming with your legal counsel, particularly where the verification supports an I-9 or other regulated process.
Name variation flag
What happened: The name on the ID differs from the name on the order — a maiden name, a suffix, a middle-name inclusion, a transposition, or a genuine discrepancy.
What it means: Most name variations are benign.
Typical action: Review the variation in Cortex. Mark verified where the variation is explainable and consistent with your policy. Name variation checks can be enabled or disabled at the account and package level if the volume of benign flags is not useful to your workflow.
Connection and environment alerts
IP address / proxy alert
What happened: The submission originated from an IP address associated with a VPN, proxy, or anonymizing service, or from a location inconsistent with the order.
What it means: Corporate VPNs are the single most common cause. Applicants completing verification on a work laptop or from a corporate network routinely trigger this check.
Typical action: Where the connection is plausibly a corporate network and all other checks passed, many CRAs mark verified. If your policy requires a clean submission, reorder and ask the disconnect before resubmitting. IP address checks can be disabled at the account and package level.
Document type edge cases
Temporary or interim license
What happened: The applicant presented a temporary or paper interim credential, which typically lacks the security features and machine-readable data the verification checks rely on.
What it means: The document generally cannot be verified through the standard checks.
Typical action: Determine under your policy whether the credential is acceptable. Options include accepting with a documented exception, holding the order until a permanent document is issued, or requesting an alternative form of identification.
Tribal identification
What happened: Tribal IDs are not uniformly machine-readable and are not covered by AAMVA.
What it means: Standard verification checks may not complete.
Typical action: If there are alerts on the verification checks, ask the applicant to resubmit using a different ID type.
Unsupported documents
What happened: The document type is outside the set of supported types for the configured package.
Typical action: Reorder and ask the applicant to submit a supported ID type
Link to vID Supported IDs Document
Escalating to Cerebrum
Cerebrum support can help you understand why an order was flagged, confirm what the system observed, and investigate suspected technical faults. We cannot tell you whether to accept a submission — that determination is yours.
Submit escalations through the support portal at portal.cerebrum.com/support, including the Cortex order ID.
Was this helpful?