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

Оператор, управляющий сорока аккаунтами на вашей платформе, имеет сорок адресов электронной почты, вероятно, сорок платежных инструментов и, возможно, сорок устройств. Чего у него нет, так это сорока лиц.
Если какая-либо часть вашего процесса доступа фиксирует селфи, у вас уже есть один идентификатор, который действительно дорого умножать. Поиск по лицу 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_type—most_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 для выполнения поиска по черному списку по уже имеющемуся изображению.
Превращение совпадений в карту действующих лиц
Практический рабочий процесс, начиная с одного подозрительного аккаунта:
- Поиск лица.
total_matches: 12— двенадцать аккаунтов, один человек. - Чтение
vendor_data. Двенадцать ваших собственных идентификаторов аккаунтов, без необходимости объединения. - Чтение временной шкалы. Кластеризация значений
verification_date. Аккаунты, созданные всплесками, операционно отличаются от аккаунтов, созданных в течение многих лет. - Поворот по
session_id. Извлечение предупреждений об устройстве и сети для каждого сеанса. Лица, имеющиеDUPLICATED_DEVICE_FINGERPRINT, усиливают кластер; аккаунты на несвязанных устройствах могут представлять собой другое расположение. - Расширение. Устройства и диапазоны IP, выявленные на шаге 4, привлекут аккаунты, которые пропустил поиск по лицу — потому что другой человек выполнял эти проверки.
- Принятие решения один раз, применение ко всем идентификаторам. Если кластер подтвержден как злоупотребление, опубликуйте подтвержденный
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, без необходимости покупать отдельный продукт.
- Прочитайте документацию — обзор поиска по лицу 1:N и API списков для черных списков лиц.
- Посмотрите продукт — Верификация пользователя.
- Проверьте цены — Поиск по лицу 1:N бесплатен; пакет верификации, который строит индекс, стоит 0,33 доллара.
- Начните бесплатно — business.didit.me, 500 проверок KYC в месяц бесплатно.
Похожие статьи
- Проблема учетной записи «Гидры»: почему защита от дистилляции начинается с разрешения идентификации (RU)
- Верификация бизнеса для доступа к API ИИ: Кто на самом деле контролирует этот аккаунт? (RU)
- Доступ к API на основе верификации для поставщиков AI-моделей: многоуровневая архитектура с учетом рисков (RU)
- Биометрическая ступенчатая аутентификация для доступа к API ИИ: Привязка привилегий к человеку (RU)
- Сети аккаунтов «Гидра»: как 20 000 аккаунтов становятся одним субъектом (RU)
- Распространение черных списков: Как один подтвержденный случай злоупотребления может уничтожить всю сеть (RU)