Перейти к основному содержимому
Didit привлёк $7,5 млн на инфраструктуру для идентификации и борьбы с мошенничеством
Didit
В блог
Блог · 4 августа 2026 г.

Поиск по лицу 1:N: Обнаружение всех аккаунтов, контролируемых одним человеком (RU)

Один вызов API позволяет найти лицо среди всех верифицированных пользователей и получить каждый совпадающий аккаунт с вашим собственным идентификатором.

Автор: DiditОбновлено
face-search-duplicate-account-detection.png

Оператор, управляющий сорока аккаунтами на вашей платформе, имеет сорок адресов электронной почты, вероятно, сорок платежных инструментов и, возможно, сорок устройств. Чего у него нет, так это сорока лиц.

Если какая-либо часть вашего процесса доступа фиксирует селфи, у вас уже есть один идентификатор, который действительно дорого умножать. Поиск по лицу 1:N — это вызов, который использует его: один запрос, одно лицо, и в ответ вы получаете все аккаунты в вашей системе, которые верифицировал один и тот же человек.

Это бесплатно с верификацией личности Didit, ответ приходит менее чем за две секунды, и он автоматически запускается во время проверки активности в рамках сеанса верификации.

Ключевые выводы

  • POST /v3/face-search/ ищет лицо среди лиц, зарегистрированных вашим собственным приложением — сеансы, запущенные с save_api_request=true — а не в общем глобальном индексе.
  • Совпадения возвращаются с вашим собственным vendor_data для каждого, поэтому результаты напрямую сопоставляются с вашими идентификаторами аккаунтов.
  • Два режима: most_similar для дедупликации и возвращающихся пользователей, blocklisted_or_approved для проверки по черному списку.
  • status имеет значение "Declined" только при совпадении с черным списком. Дубликаты возвращают "Approved" с предупреждением DUPLICATED_FACE — информационным по замыслу, поскольку политика дедупликации определяется вами.
  • Ответ представляет собой единственный объект face_search, а не массив. Это сбивает с толку.
  • Бесплатно с верификацией Didit. Время ответа менее двух секунд. Автоматически запускается во время проверки активности.

Что означает 1:N и почему это правильный инструмент

Сопоставление лиц 1:1 отвечает на вопрос: «является ли это лицо человеком на этом документе?» Это вопрос верификации, и он используется при регистрации.

Поиск 1:N отвечает на другой вопрос: «из всех людей, которых я уже верифицировал, этот человек является одним из них?» Одно изображение поступает, и каждое совпадение в вашем индексе выходит.

Для скоординированного злоупотребления аккаунтами важен второй вопрос. Отчет Anthropic о кампаниях дистилляции описывает атрибуцию, построенную на реляционных сигналах — общих способах оплаты, скоординированном времени, общей инфраструктуре. Биометрический поиск 1:N относится к тому же классу сигналов, полученных из самого дорогого идентификатора, который оператор должен умножать.

Индекс ваш. Поиск по лицу выполняется по лицам, которые ваше собственное приложение зарегистрировало в ходе предыдущих верификаций — сеансы с save_api_request=true или проверка активности без участия пользователя (Passive Liveness) с save_api_request=true. Это не поиск среди пользователей других клиентов Didit. Если вы не зарегистрировали лица, искать нечего.

API

Запрос

curl -X POST 'https://verification.didit.me/v3/face-search/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -F 'user_image=@./selfie.jpg' \
  -F 'search_type=most_similar' \
  -F 'save_api_request=true' \
  -F 'vendor_data=acct_8842'

multipart/form-data, аутентифицированный с помощью x-api-key.

Обязательно: user_image — jpg, jpeg, png, tiff или webp, максимум 5 МБ. PDF не принимаются. Изображение должно содержать хотя бы одно обнаруживаемое лицо; если их несколько, побеждает самый большой ограничивающий прямоугольник.

Необязательно:

  • search_typemost_similar (по умолчанию) для дедупликации и обнаружения возвращающихся пользователей, или blocklisted_or_approved для проверки по черному списку.
  • save_api_request — зарегистрировать это изображение в вашем индексе.
  • vendor_data — ваш собственный идентификатор субъекта.

Ответ

Ответ содержит единственный объект face_search. Большинство функций Didit возвращают массивы, поэтому это та форма, которую стоит внимательно изучить, прежде чем писать парсер.

{
  "request_id": "...",
  "face_search": {
    "status": "Approved",
    "total_matches": 12,
    "matches": [
      {
        "session_id": "...",
        "session_number": 4471,
        "similarity_percentage": 97.4,
        "vendor_data": "acct_3310",
        "verification_date": "2026-06-02T09:14:00Z",
        "user_details": { },
        "match_image_url": "...",
        "status": "Approved",
        "is_blocklisted": false
      }
    ],
    "user_image": { "entities": [] },
    "warnings": []
  }
}

Поля, которые несут информацию для расследования:

  • total_matches — сколько аккаунтов имеют это лицо.
  • vendor_data для каждого совпадения — ваш идентификатор, так что список совпадений сразу становится списком аккаунтов.
  • similarity_percentage — сила каждого отдельного совпадения.
  • verification_date — временная шкала. Двенадцать аккаунтов, верифицированных за одиннадцать месяцев, читаются иначе, чем двенадцать, верифицированных за один день.
  • is_blocklisted — находится ли это совпадение уже в вашем черном списке.
  • session_id — точка входа ко всему остальному, что было зафиксировано в этом сеансе, включая предупреждения об устройстве и сети.

Семантика статуса

Это самое важное поведение во всей конечной точке:

status имеет значение "Declined" только при обнаружении хотя бы одного совпадения с черным списком. Чистые дубликаты возвращают "Approved".

Дубликат — это не отказ. Это информация. Didit намеренно отказывается принимать решение о дедупликации за вас, потому что дубликаты могут иметь законные объяснения, и только вы знаете правила вашего продукта.

Предупреждения

ПредупреждениеЗначение
FACE_IN_BLOCKLISTОпределенное совпадение с черным списком — отклонить
POSSIBLE_FACE_IN_BLOCKLISTПограничное совпадение ниже жесткого порога — направить на ручную проверку
DUPLICATED_FACEЭто лицо уже верифицировано под другим vendor_data
POSSIBLE_DUPLICATED_FACEПограничный дубликат
MULTIPLE_FACES_DETECTEDВ отправленном изображении обнаружено несколько лиц

Режимы отказа

  • HTTP 400 — лицо не обнаружено в user_image. Попросите переделать.
  • HTTP 403 — нет кредитов.
  • status: "Declined" с FACE_IN_BLOCKLIST — определенное совпадение. Отклонить.
  • POSSIBLE_FACE_IN_BLOCKLIST — ниже жесткого порога. Ручная проверка.
  • DUPLICATED_FACE — уже верифицировано под другим vendor_data. Объединить, заблокировать или разрешить в соответствии с вашей политикой.

Автоматический путь

Вам часто вообще не нужно вызывать конечную точку. Поиск по лицу запускается автоматически во время проверки активности в рамках сеанса верификации:

  • Биометрические данные лица сравниваются со всеми ранее верифицированными пользователями.
  • Потенциальные дубликаты аккаунтов выявляются по сходству лиц.
  • Совпадения отмечаются в соответствии с настроенными вами порогами сходства.
  • Лица проверяются по вашему черному списку, и совпадение с черным списком автоматически отклоняет верификацию.

Таким образом, для любого уровня, где вы уже проводите полную верификацию, обнаружение дубликатов включено без дополнительных затрат и дополнительных вызовов. Отдельная конечная точка предназначена для случаев, которые не охватывает поток сеансов — расследование аккаунта постфактум, проверка изображения, полученного другим способом, или переключение search_type для выполнения поиска по черному списку по уже имеющемуся изображению.

Превращение совпадений в карту действующих лиц

Практический рабочий процесс, начиная с одного подозрительного аккаунта:

  1. Поиск лица. total_matches: 12 — двенадцать аккаунтов, один человек.
  2. Чтение vendor_data. Двенадцать ваших собственных идентификаторов аккаунтов, без необходимости объединения.
  3. Чтение временной шкалы. Кластеризация значений verification_date. Аккаунты, созданные всплесками, операционно отличаются от аккаунтов, созданных в течение многих лет.
  4. Поворот по session_id. Извлечение предупреждений об устройстве и сети для каждого сеанса. Лица, имеющие DUPLICATED_DEVICE_FINGERPRINT, усиливают кластер; аккаунты на несвязанных устройствах могут представлять собой другое расположение.
  5. Расширение. Устройства и диапазоны IP, выявленные на шаге 4, привлекут аккаунты, которые пропустил поиск по лицу — потому что другой человек выполнял эти проверки.
  6. Принятие решения один раз, применение ко всем идентификаторам. Если кластер подтвержден как злоупотребление, опубликуйте подтвержденный reference_session_id в каждом черном списке, который вас интересует — лицо, устройство, IP, электронная почта, телефон, документ. Это один вызов на список, и каждый вызов автоматически извлекает правильное значение из этого сеанса, поэтому ничего не нужно вводить вручную.

Шесть шагов, одна отправная точка, и никаких проверок запросов. Уровень трафика говорит вам: с этим аккаунтом что-то не так. Это говорит вам: сколько на самом деле таких аккаунтов.

Стоит прямо заявить: поиск по лицу 1:N не предотвращает извлечение модели и не обнаруживает его. Поиск по лицу не имеет доступа к вашему трафику API. Он сопоставляет аккаунты с людьми, что позволяет вам действовать по оповещению для всего кластера, а не для одной строки. Элементы управления выводом на уровне модели и семантическое обнаружение трафика являются отдельными уровнями, и они остаются ответственностью поставщика модели.

Случаи использования

AI API платформы, преобразующие поведенческое предупреждение в полный набор аккаунтов, контролируемых оператором.

Злоупотребление бесплатными тарифными планами и кредитами — один человек, много пробных аккаунтов, это та же проблема обнаружения, но с меньшими ставками.

Торговые площадки и платформы для фрилансеров, отслеживающие повторную регистрацию забаненных продавцов, водителей или курьеров.

iGaming, обеспечивающий соблюдение правил одного аккаунта и самоисключения, где возвращающийся исключенный игрок является регуляторным сбоем, а не просто случаем злоупотребления.

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

Часто задаваемые вопросы

Используется ли мой индекс лиц совместно с другими клиентами Didit?

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

Что определяет, попадает ли лицо в индекс?

save_api_request=true в сеансе верификации или вызов Passive Liveness. Вы решаете, что регистрируется, и вы контролируете хранение данных в соответствии с вашим уведомлением о конфиденциальности и правовыми основаниями для обработки биометрических данных.

Какой порог сходства мне следует использовать?

Обратите внимание, где применяется настройка. В автономной конечной точке диапазоны сходства, которые отделяют подтвержденные совпадения (FACE_IN_BLOCKLIST, DUPLICATED_FACE) от возможных совпадений (POSSIBLE_FACE_IN_BLOCKLIST, POSSIBLE_DUPLICATED_FACE), фиксированы внутри — настройка порогов для каждого приложения применяется к проверке активности рабочего процесса, а не к POST /v3/face-search/. Поэтому в автономном режиме читайте similarity_percentage для каждого совпадения и применяйте свой собственный порог в логике приложения, а предупреждения POSSIBLE_* рассматривайте как очередь для проверки, а не как очередь для отклонения.

Насколько быстро это работает в масштабе?

Время ответа менее двух секунд.

Могу ли я искать лицо, которое никогда не проходило верификацию Didit?

Да. Любое user_image в принятом формате работает. Если лицо не обнаружено, вызов возвращает HTTP 400.

Это действительно бесплатно?

Да — поиск по лицу 1:N бесплатен с верификацией личности Didit. Плата за каждый поиск не взимается. Вы платите за верификации, которые строят индекс, по цене 0,33 доллара за полный пакет, при этом первые 500 проверок в месяц бесплатны.

Что, если у одного и того же человека законно есть два аккаунта?

Тогда DUPLICATED_FACE — это именно тот информационный сигнал, для которого он был разработан — поэтому он не отклоняет. Объедините их, разрешите их или спросите пользователя в соответствии с правилами вашего продукта.

Готовы начать?

Поиск по лицу доступен на каждом аккаунте Didit, без необходимости покупать отдельный продукт.

Инфраструктура для идентификации и борьбы с мошенничеством.

Единый API для KYC, KYB, мониторинга транзакций и проверки кошельков. Интеграция за 5 минут.

Попросите ИИ кратко изложить эту страницу