> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Проверка 4-eyes: подтверждение maker/checker

> В Didit каждое решение по шаблону требует одобрения второго сотрудника: исход ожидает, пока его не подтвердит другой проверяющий.

4-eyes review добавляет второе независимое подтверждение до того, как решение по кейсу вступит в силу. Это стандартный контроль разделения обязанностей для расследований повышенного риска.

Проверка в четыре глаза добавляет второе независимое подтверждение до того, как решение по кейсу вступит в силу. Это стандартный контроль разделения обязанностей для расследований повышенного риска.

***

## Настройка

В шаблоне исполнителя укажите в поле **Проверка в четыре глаза** **шаблон проверяющего**. Именно заполнение этого поля включает проверку в четыре глаза для шаблона исполнителя, отдельного переключателя нет.

## Как это работает

1. Сотрудник, работающий по шаблону исполнителя, решает кейс обычным образом (ложное срабатывание или подлинная угроза, при необходимости с примечанием).
2. Вместо закрытия статус кейса остаётся **Открыт**, предложенное решение сохраняется как ожидающее применения, а кейс попадает в очередь **шаблона проверяющего**. В хронологии кейса появляется запись `Submitted for approval`.
3. Проверяющий просматривает вкладку «Обзор» кейса, где в баннере двойного контроля доступны действия **Одобрить** и **Отклонить**.
4. **Одобрить** применяет промежуточное решение: кейс переходит в статус **Решено** с исходным решением и примечанием, с указанием сотрудника, который его отправил. В хронологии появляются записи `Approval granted`, затем `Resolved`.
5. **Отклонить** сбрасывает промежуточное решение и возвращает кейс в **шаблон исполнителя**. В хронологии появляется запись `Approval rejected`, а исполнитель получает уведомление.

> [!WARNING]
>
> Сотрудник, который отправил решение, не может одобрить или отклонить его сам. Это проверяется на стороне сервера. Попытка возвращает ответ 403. (Одобрение или отклонение кейса без решения, ожидающего подтверждения, возвращает ответ 409.)

## Назначение проверяющего

Сотрудник, который решает кейс, может указать участника, который должен подтвердить решение, с помощью поля `checker` в [API для решения по кейсу](https://docs.didit.me/ru/management-api/cases/resolve.md).
Только этот участник может затем одобрить или отклонить решение. Любой другой, включая API-ключ, получает ответ 403.
Поле `checker` кейса показывает назначенного участника до тех пор, пока решение не будет одобрено, отклонено или возвращено на повторную проверку.
Если проверяющий не назначен, решение ждёт в очереди шаблона проверяющего, как описано выше.
Назначенный проверяющий должен иметь доступ к кейсам этого приложения и не может быть сотрудником, который отправил решение.

## Когда меняются доказательства

Изменение ответа в чек-листе или добавление либо удаление связанной верификации или транзакции сбрасывает ожидающее решение и возвращает кейс к исходной политике проверки.
В хронологии активности фиксируется, что требуется новое решение по проверке, а предыдущее предложение сохраняется в событии аудита.
Проверяющий должен изучить обновлённые доказательства и отправить новое решение, прежде чем второй сотрудник сможет его одобрить.
Повторный ответ в чек-листе с тем же значением не отменяет ожидающую проверку.

При одобрении также проверяется, соответствуют ли связанные исходные доказательства тем, что было отправлено на проверку. Изменившийся статус верификации, исправленное поле документа, изменившиеся данные транзакции или недоступный источник блокируют одобрение с кодом `409`.
Потеря доступа к глобальным сетевым доказательствам, связанным через Fraud Check, также требует новой проверки.
Используйте **Отклонить**, чтобы вернуть кейс исполнителю, изучить обновлённые доказательства и отправить новое решение.
Открытие исходной записи или добавление внутреннего примечания к кейсу само по себе не блокирует неизменённую проверку.
Если отправленные доказательства невозможно проверить, перед одобрением требуется новая проверка.

## Примечания

* Требования к проверке сохраняются при открытии кейса.
  Перемещение в очередь проверяющего не заменяет эти требования более поздними изменениями политики.
* Одновременно у кейса может быть только одно промежуточное решение. Запрос дополнительной информации (**Ожидание пользователя**) заблокирован, пока решение ожидает подтверждения.
* Проверка в четыре глаза работает вместе с [обязательными примечаниями к решению](https://docs.didit.me/ru/console/case-management/blueprints.md#общие-настройки). Включите оба параметра для шаблонов с самым высоким риском, чтобы требовать одновременно документированное обоснование и второго проверяющего.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.