# Sessions stuck in review, and how to reduce them

Source: https://help.didit.me/verification-sessions/session-in-review
Updated: 2026-10-12

In review means the automated checks flagged something a person must settle, and it never resolves by itself. Here is how to clear the queue and lower the rate.

**In review never clears on its own.** It means a check flagged something and is
waiting for a person on your team to approve, decline, or ask for a resubmission.
If your review rate is high, the cause is nearly always a threshold set too
tight - not fraud.

[Video: Tags, status and session chat: reviewing cases as a team - Didit Academy](https://www.youtube.com/watch?v=bRkH0agxVDc)

> **Warning:** **Didit does not review sessions.** An In review session is waiting for a person on your team, in your Business Console, and nobody at Didit is looking at it. There is no queue on Didit's side and no time estimate: it stays In review until someone on your team decides.

Of all the statuses, **In review** is the one that generates the most support questions, for a simple reason: it looks like the platform is still working, when in fact the platform has finished and is waiting for you.

## What In review actually means

The automated checks all ran. At least one raised a warning that your workflow routes to review rather than to an automatic decision. The session now sits in your queue until a human resolves it. There is no timeout that eventually decides for you, and no way to make the system re-run the checks and change its own mind.

## Clearing a session

1. **Open the review queue**

   In the [Business Console](https://business.didit.me), open **Identity verification → User verifications**. It opens on **Needs review**: every session waiting for a person. Where the **Inbox** has rolled out to your organization, it collects the same sessions alongside your other decisions. See [your Inbox](https://help.didit.me/investigations/inbox).

2. **Read the warnings, not just the status**

   Open the session and look at which check flagged it and what the warning says. That determines what you're actually deciding. See [how to read a verification result](https://help.didit.me/verification-sessions/reading-a-verification-result).

3. **Decide**

   Press **Approve**, **Decline** or **Resubmit** (or **A**, **D** or **R** on your keyboard) to approve, decline, or request a resubmission of just the failing step. Add a note - it becomes part of the audit trail. **J** and **K** move to the next or previous session in the queue.

4. **Let your backend know**

   The decision fires a `status.updated` webhook, so your system picks up the final state without you having to reconcile by hand.

![The Needs review view of User verifications in the Didit console, with sessions selected for a bulk action](https://help.didit.me/screenshots/sessions-bulk-light.webp)

*Needs review is the queue. Select sessions to decide several at once.*

## Why your review rate might be high

In roughly this order of likelihood:

1. **Face match thresholds too close together.** If your review band is wide, ordinary lighting variation lands in it. See [face match scores and thresholds](https://help.didit.me/liveness-biometrics/face-match-thresholds).
2. **AML review threshold set at a low match score.** Common names generate candidate hits at low match scores. Setting the review threshold too low sends nearly everyone to review. See [resolving AML hits](https://help.didit.me/aml-screening/resolving-aml-hits).
3. **Proof of address partial matches.** Address formats vary enormously by country; an abbreviation difference reads as a partial match. Decide deliberately whether a partial match should review or pass.
4. **Database validation partial matches.** Same cause - a name recorded differently in an authoritative source.
5. **Duplicate-face flags on legitimate returning users.** If the same real person verifies more than once, they'll match themselves. See [duplicate detection](https://help.didit.me/verification-sessions/duplicate-detection).
6. **Every warning routed to review "to be safe".** Reviewing everything is the same as reviewing nothing, because the queue stops getting worked. Pick the warnings that genuinely need judgement.

## Reordering the workflow to review earlier and cheaper

If your flow is expensive and a lot of sessions end up in review anyway, moving the cheap risk checks to the front means the flow stops before the expensive ones run. Device and IP analysis at $0.03 in front of a full KYC flow will cut spend on traffic that was never going to pass.

The tradeoff is user experience: a person who gets stopped at step one has invested nothing, but they also learn nothing about why. Decide which matters more for your funnel.

## Four-eyes review

If your compliance process requires two people to sign off, use a case: a case blueprint can require **4-eyes review**, so a second teammate confirms the resolution. Cases are rolling out and may not be available to your organization yet. See [cases](https://help.didit.me/investigations/cases).

## What In review is not

- **It is not "still processing."** If you're waiting for the platform to finish, the status you want is In progress.
- **It is not a soft decline.** An In review session has no verdict at all yet, so don't map it to "rejected" in your own system - map it to its own pending state.
- **It is not something support can decide for you.** Only your team has the authority to approve or decline your own customer. Support can explain *why* a session flagged, and will need the `session_id` to do it.

## Ongoing monitoring can push an approved session back to review

If you have AML monitoring enabled, a previously approved session can move to In review later, when a daily re-screen finds a new hit that crosses your review threshold. That's expected behaviour, not a regression - and it's the whole point of monitoring. See [ongoing AML monitoring](https://help.didit.me/aml-screening/ongoing-monitoring).