Identity verification operations in Backoffice

After verifications start arriving, people in your organisation work them in the Identity Verification group of Backoffice. This guide covers every KYC page beyond invitations and hosted settings and the integration: what each page is for, who may use it, and what to check before you act. Reviewers and administrators do the work; a verification result is a signal, and the decision on an adverse result is yours.

What it is

Availability: Controlled availability (identity verification). Each page below also depends on your plan, your role and the modules enabled for your organisation; a page that is not enabled says so instead of showing data.

The sidebar lists the pages under Identity Verification. The landing page /kyc is the KYC item; every other page is a sub-item of it. This guide describes pages and permissions. It does not list what a verification captures; see the Privacy Policy and the Security page.

Older addresses such as /kyc-review-queue and /kyc-evidence-access redirect to these routes. The page heading can differ from the nav label: Evidence Access opens as Sensitive Evidence Access, Assisted Recovery as Assisted Recovery Operations, Passkeys as Passkey Credentials, Step-Up Verification as Passkey Step-Up.

Step-up is a fresh check of the signed-in person with their MFA method. Backoffice asks for it when an action needs it and then repeats the action. A completed check stays fresh for 360 minutes. It is not the same thing as the Step-Up Verification page, which describes your customers’ step-up.

Prerequisites

• The identity verification module is provisioned for your organisation. Without it the pages show “KYC verification is not enabled”, or a strip reading “KYC is not included in your plan”. Ask your account team.
• Roles. Analysts read. Administrators record decisions and change settings. See Roles and permissions.
• MFA enrolled for every person who will decide or change settings, so the step-up check can complete: Sign-in, SSO, SCIM, MFA and IP allowlist.
• Hosted settings and a legal basis recorded (Invitations). Without an active legal basis for the capture surface, Backoffice refuses to approve or override.
• Webhook endpoint (optional) to learn about decisions: Identity verification events and webhooks.
• Data lifecycle. Noxtica does not delete verification details or evidence automatically and sets no retention date. Nothing on these pages schedules a deletion. An administrator can delete verifications on purpose in KYC Verifications. See Verification data.

Steps

1. Decide who can review and see evidence

1. Give analysts the role for reading cases, the queue, processes, screening and device pages.
2. Give administrators the role for recording decisions, running recovery and changing policies. Keep the group small: every decision is audited with the person who made it.
3. Treat Evidence Access as a separate, higher permission. Administrators hold the permission to open original images, video or audio, and every open asks for step-up. Review the list at Backoffice → Administration → Users.
4. Check who did what in the audit log.

2. Check setup status on the KYC overview

Open Backoffice → Identity Verification → KYC (/kyc).

• A confirmation line, “KYC verification is set up — invitation links will open a working verification page.”, means customers can complete a link.
• A block titled “KYC verification isn’t ready for this organisation” lists each missing step with a link to the page that fixes it: activate the module, configure the hosted verification page, or register the legal basis. Two steps belong to Noxtica (the module is switched off on the deployment, or hosted links cannot be issued); the list says “Contact a platform operator” for those.
• The Verification steps guide below it shows which capture steps are on for your organisation.
• The directory links to every KYC page and to the Integration guide (/kyc/verifications?tab=integration).

3. Read cases in KYC Verifications

Open Backoffice → Identity Verification → KYC Verifications (/kyc/verifications). The Verifications tab is the default; Integration holds the in-app integration guide.

• Search by case id, session id or subject reference. Filter by Status, Verdict, Review, Source (Hosted or API), Document type, Issuing country, Reason code and a Created date range. Switch between the List and Cards layouts and choose columns.
• Case status reads Not started, In progress, Awaiting review, Completed, Abandoned, Expired, Cancelled or Error. The count shows “1000+” when the list is capped.
• Export downloads the loaded rows as CSV or JSON. Names stay masked and no face images are included.
• Select a case to open /kyc/cases/<id>. The tabs follow the steps that ran: Overview, Document, Face & liveness, Voice, Evidence, Checks & scores, Timeline & audit, Consent. Link to a tab with ?tab=<id>, for example ?tab=timeline.
• Original media is sealed. Unlock evidence asks for step-up once, then loads items on demand and audits each one. A role without evidence access sees findings and measurements, not the originals.
• Timeline & audit ends with the evidence access audit: who opened which evidence object, and when.
• Showing personal details on a case is audited before it is returned. If the audit entry cannot be written, Backoffice withholds the details instead.
• Delete verification (on a case) and the row checkboxes with Delete selected (on the list, up to 25 at a time) are visible to administrators only. The dialog asks for a reason of 3 to 500 characters and a typed confirmation phrase, and the action asks for step-up. A delete removes the verification and its evidence files, keeps the billing usage records, the legal-basis receipts and the audit trail, and cannot be undone. A legal hold or an open erasure request blocks it. Steps and refusals: Verification data.

4. Work the review queue

Open Backoffice → Identity Verification → KYC Review Queue (/kyc/review-queue). It lists verifications that need attention: a verdict of Unverified or Failed, or the reason code Manual review requested (provider_manual_review). A finished hosted capture currently waits here. The queue filters the pages already loaded; select Load more to reach older rows.

1. Read the row: Subject, Verdict, Review state (Open, In review, Approved, Overridden, Closed), Reason codes and Created. Select Open case and read the evidence before you decide.
2. Select Reason codes, note & history to attach reason codes (up to 10 from the closed list) and an optional note of up to 2000 characters, and to see the timeline of the automated checks and the linked hosted session.
3. Choose one decision and confirm the dialog. Approve and Override record that you affirm or overrule the result. Record escalation routes the case to deeper review without affirming or overriding the result.
4. Complete the step-up check when asked. The row shows the new review state.

The same three decisions (Approve, Override, Escalate) are on the Overview tab of a case, with one reason code and a note.

What a decision does:

• It needs an administrator and step-up. In the queue an analyst can select the buttons but the server refuses the decision. The case page hides them and says “Recording a review requires KYC management permission and fresh MFA.”
• It writes a versioned review record and an audit entry. It never changes the stored verdict of the verification.
• For a hosted session in review_pending, Approve or Override moves the session to completed and sends kyc.session.completed to subscribed endpoints. Escalate does not touch the session. The page has no Reject decision.
• Two people deciding at once: the second gets “This verification was reviewed in another session — reload and retry”.

5. Follow a process end to end

Open Backoffice → Identity Verification → KYC, then KYC Processes in the directory (/kyc/processes). Each row is one customer attempt, either a Hosted session or an S2S verification (started by your server).

• Filter by status, document type, or search by session or subject id. Statuses include Awaiting review, Submitted, Verified, Unverified, Error, Expired and Cancelled by user. A recorded review decision (Approved, Overridden, In review) replaces the session status.
• Select View for the detail: the hosted-session timeline, the verification and decision, failures and retakes, evidence objects (kind, state and quality, never the content), the stage results and Webhook deliveries.
• Webhook deliveries lists each event with Event, State, Attempts and Created. It shows no signing secret and no endpoint address. Use it after a decision to confirm the event was queued and delivered, then compare with your endpoint logs.
• A process with no hosted link reads “Not hosted-originated — a tenant S2S verification.” A hosted session that has not reached submit reads “Not yet admitted”.

6. Author policies and work screening cases

Availability depends on the review-policy and advisory screening modules enabled for your organisation.

KYC Policies (/kyc/policies) has three panels.

• Review policies. Select New policy and set Priority, Action (Allow, Challenge or Block), Enabled, Shadow and a Condition as a JSON object. A new rule starts disabled and in shadow, which means it is logged and does not act. Take a rule out of shadow with Graduate, which asks for step-up; editing cannot do it. Graduating does not by itself make a rule challenge or block anything.
• Response-side enforcement. An administrator arms or disarms it for your organisation. A rule acts on a live verification when enforcement is armed, the rule is graduated and the rule resolves an acting decision; all three must hold. Disarm stops every rule at once. Ask your account team before you rely on enforcement.
• Screening hits and Corpus versions. Hits are advisory: subject, best score, matches and outcome (Clear, Potential match, Not evaluated, Evaluation error). Corpus versions show provenance of the shared screening corpus; changing the serving pin is a platform operator action.

KYC Screening Cases (/kyc/screening-cases) is casework on advisory hits. The page says it makes no enforcement decisions.

1. Open a case from the list (State, Owner, Priority, Corpus version, Updated).
2. Move it through the states: Potential match → Triaged → Investigating. From Investigating choose a disposition: Clear as false positive, Confirm match, Mark insufficient data or Escalate for enhanced review.
3. After Confirm match you can Mark action pending and then Record action taken. A case with a final disposition can be reopened.
4. Every change needs a rationale (up to 2000 characters) and step-up. Save assignment and priority sets the Owner ID and Low, Normal or High priority.
5. Reopening needs a different evidence reference or a newer complete corpus version.

KYC Rescreening (/kyc/rescreening) is read-only. It shows coverage by corpus version, corpus deltas and tenant hit volume. It states that per-run history is not recorded.

7. Run assisted recovery

Availability depends on the trusted-device registry module enabled for your organisation.

Open Backoffice → Identity Verification → Assisted Recovery (/kyc/recovery). Two tabs: Recovery cases and Recovery appeals. Every action asks for step-up and is audited.

1. In Recovery cases read Tier, Status, Readiness and the SLA badges (On track, Overdue, Escalated).
2. Use the action the case needs: Vouch (trusted referee), Approve (one of two required approvers), Record fraud verdict, Block (when the required operations lane is unavailable) or Resolve.
3. Resolution needs a referee vouch, or two distinct approvers plus a cleared fraud review. A different operator than the approvers must resolve.
4. In Recovery appeals select Resolve and choose Upheld, Overturned or Expired.

8. Manage agent delegations (KYA × KYC)

Availability depends on the agent-delegation module enabled for your organisation.

Open Backoffice → Identity Verification → Agent Delegations (/kyc/agent-delegations). The table shows an opaque delegation id, principal type, scope, audience, activity (Minted, Presented, Verified, Refused, Revoked), expiry and revocation state. It shows no subject identity.

• Revoke ends a delegation. An analyst can do it with step-up. It cannot be undone.
• New Delegation needs an administrator and step-up. Enter Audience and Scope as lowercase letters, digits and :._- (1 to 64 characters), choose the Principal type, and optionally a TTL in minutes. The server clamps the maximum.

9. Open sensitive evidence when a decision needs it

Availability depends on raw-evidence storage being enabled for your organisation.

Open Backoffice → Identity Verification → Evidence Access (/kyc/evidence), or Unlock evidence on a case. The list is by session and shows metadata without step-up.

1. Select a session, then View evidence.
2. Pick the Access purpose from the closed list: Identity verification, Document authenticity, Liveness check, Address verification, Manual review or Regulatory audit.
3. Complete step-up. The evidence opens in memory in the viewer; closing it clears the decrypted bytes. No public address exists for it.
4. Download metadata manifest (CSV) exports metadata and Audit trail lists the access claims and audit events for one object. Both ask for step-up.

If the audit entry for a view cannot be committed, the view is blocked. Reading evidence does not delete it: see Verification data.

10. Review passkeys, customer step-up and device trust

Availability depends on the passkey and trusted-device registry modules enabled for your organisation.

• Passkeys (/kyc/passkey-credentials) lists registered credentials with Status Active or Revoked. Revoke is permanent. The AAGUID trust policy section sets a rule per authenticator model: Decision Allow, Require attestation or Block, and Enforcement Shadow (rules are logged and do not act; the default) or Enforce. Revoking and editing rules need an administrator and step-up.
• Step-Up Verification (/kyc/step-up) is read-only: the declared step-up configuration (not the live runtime value), the count of successful step-ups and the reason-code catalog. It says no health probe exists and failed attempts leave no row.
• Device Registry (/kyc/device-registry) lists trusted-device links with Verification level and Status (Proofed (unbound), Bound, Active, Suspended, Revoked, Migrated, Tenant terminated). Suspend is reversible, Revoke is permanent. The page has no reinstate control.
• Device Topology Policy (/kyc/device-topology) sets Maximum active devices (1 to 100, or blank for no cap), Shared and delegated device handling and Unmanaged-device handling (Allow or Step up). Select Save policy. Analysts see it read-only.

Verify it works

• The KYC overview shows the setup confirmation line, and a test invitation (Invitations) appears in KYC Verifications and the Review Queue.
• After Approve or Override, the row shows Approved or Overridden, the case Overview shows the new version, and a hosted session leaves Awaiting review.
• Your endpoint receives kyc.session.completed, and the process detail lists it under Webhook deliveries.
• A viewed evidence object appears in the Evidence access audit of the case and in the object’s Audit trail.
• A saved policy, topology setting or trust rule reads back after you reload the page.

Troubleshooting

Related

• Invitations and hosted verification settings: create links, set up the hosted page and the legal basis.
• Identity verification integration: create sessions from your server.
• Identity verification events and webhooks: the events a decision sends.
• Noxtica Verification ID (NVID): revoke or resend an ID from a case.
• Verification data: storage, access and deletion: who sees evidence and how an administrator deletes data.
• Identity verification FAQ and troubleshooting: session statuses and common questions.
• Backoffice guide: navigation, roles and shortcuts.
• Privacy Policy and Security page: how Noxtica handles personal data.