Verifications — Detail Page

The Verification detail page (/verifications/:type/:id) is where reviewers actually work. The list view tells you which verifications are pending; the detail page is where you read the documents, check the biometric match, scan the audit timeline, and click Approve or Reject.

The page is the largest single screen in the portal — a 2/3-1/3 split between review tabs on the left and a sticky action column on the right.

Anatomy of the page

1. Page header

PageHeader with the subject’s display name as the title and the verification’s short ID as the description. Breadcrumbs link back to the Verifications list.

2. Left column — review tabs

A VerificationDetailTabs component renders five tabs:

Tab	Component	Content
Documents	DocumentsTab	Front/back images, OCR fields, mismatch flags
Biometric	BiometricTab	Selfie + face-match score
KYC	KycTab	Sanctions / PEP / FATF screening findings
Audit	AuditTab	Per-event timeline
Notes	NotesTab	Reviewer freeform notes

3. Right column — sticky action panel

Cards stacked top to bottom:

• Score gauge — ScoreGauge renders the score_total from the verification record
• Status pill — current lifecycle stage
• Device proximity — when the score breakdown includes a geolocation signal
• Subject card — name, email, phone, avatar
• Matter link — link to the parent matter
• Action buttons — context-sensitive

4. Action button rules

status: in_progress     → [Resend invite] [Cancel]
status: pending_review  → [Approve] [Reject] [Cancel]
status: approved        → [Download audit PDF]
status: rejected        → [Download audit PDF] [Reopen]
status: canceled / expired → (no actions)

Score model

The score is the sum of the document scores in the verification, each computed as 100 − sum(deductions per mismatch) using the weights configured under Settings ▸ Scoring. The aggregate score is informational — it never auto-approves or auto-rejects.

The right column also shows a device proximity badge when the subject’s device geolocation diverged significantly from their declared address — the threshold is configurable under Settings ▸ Scoring.

Decision flow

Clicking Approve or Reject:

1. Opens a confirm dialog with an optional reviewer note
2. On confirm, the verification transitions to the terminal status
3. The platform emits request.approved or request.rejected to the audit log + webhook subscribers
4. A notification fires per the org’s Notification Templates
5. The audit-stamped PDF is generated and becomes downloadable

The reviewer note is preserved in the audit event payload and embedded in the audit PDF.

Confirm a possible match

On the Business tab, each person the client listed as owning or controlling the business shows their role and ownership %. When someone already on file in your organization has the same email, the line shows a Possible match. It is staff-only: the client is never told, and it does not appear on the PDF report or through the API.

• Confirm match — if it is the same person, click Confirm match beside them and confirm. Athenty adds that person to the entity (the verification’s entity participant) as a representative, with the role the client entered and, for an ownership role, the ownership %. Their profile, matters, verifications and trust history are not changed — nothing is merged. If they already hold that role on the entity, no second entry is added.
• Confirmed — the line then shows Confirmed: and the person, linking to their profile.
• Undo — reverses the match. If the match added the representative entry, it is removed; if they were already a representative, they stay. Nothing else changes.

A verification that is not yet linked to an entity participant cannot be confirmed. Confirm match and Undo need permission to decide verifications, and both are recorded in the audit log (verification.officer_match.confirmed / verification.officer_match.undone).

Reopen

Available only on rejected verifications. Reopen:

1. Transitions the verification back to pending_review
2. Captures the reopener’s identity in a request.reopened event
3. Preserves the prior decision in the audit timeline (does not overwrite)

Use cases: the subject corrects their address, supplies additional documents, or the rejection turned out to be a false-positive that the reviewer wants to re-evaluate.

Automatic face data deletion is built but not switched on yet. Once it is, a finished verification’s face data is deleted after a grace period (7 days by default) that keeps reopening possible. See Face data deletion after verification.

Permissions and scope

Role	View	Decide	Resend / Cancel	Reopen	Download
Owner / Admin	✓	✓	✓	✓	✓
Member (assigned reviewer)	✓	✓	✓	✓	✓
Member (requester only)	✓	✗	✓ (own)	✗	✓
Viewer	✓	✗	✗	✗	✓

Audit logging

Action	Event
Approve	request.approved (with reviewer note)
Reject	request.rejected (with reviewer note)
Cancel	request.canceled
Resend	request.invite_resent
Reopen	request.reopened
Download PDF	request.pdf_downloaded

Events surface in Settings ▸ Audit Log and on the verification’s own Audit tab.

Troubleshooting

Symptom	Most likely cause	Fix
No Approve/Reject buttons	Status is not pending_review	Status check
Resend disabled	Status not in_progress or invite expired	Cancel + recreate
Download 404	Not yet decided	Decide first
Audit tab incomplete	Cache stale	Refresh; events arrive in batches
Reopen missing	Status not rejected	Only post-rejection

Related pages

• Verifications — the list view
• Verifications ▸ New — wizard that creates these records
• Settings ▸ Scoring — deduction weights powering the score
• Settings ▸ Notification Templates — emails fired on decisions
• Settings ▸ Audit Log — request.* events