KYC/CDD document intelligence

KYC/CDD document intelligence разбирает входящий поток клиентских документов и превращает его в структурированные данные с ревью-вердиктом. На выходе — заполненные поля в CRM, флаги для compliance-офицера и журнал решений, который можно показать регулятору. Это закрывает самую трудозатратную часть KYC/CDD: чтение сканов, копирование полей в систему, прохождение по чек-листу.

Типовой процесс выглядит так:

1. Клиент или Relationship Manager загружает пакет документов в File storage — папку клиентского дела или временную upload-папку.
2. Автоматизация забирает файлы по событию и классифицирует каждый: паспорт, proof of address, учредительные документы, выписки, UBO-декларация, корпоративная структура и так далее.
3. Из каждого типа извлекаются релевантные поля — ФИО, дата рождения, номер документа, адрес, дата выдачи, срок действия, регистрационные реквизиты компании.
4. Извлечённые данные сверяются с тем, что клиент указал в форме или что уже есть в CRM: расхождения (мисмэтчи) помечаются с указанием источника.
5. Документы проходят QA по rubric'у: читаемость скана, валидность дат, срок действия, наличие подписи и печати, наличие обязательных полей, соответствие заявленному типу.
6. Результат — структурированная запись клиента в CRM со всеми извлечёнными полями, ссылками на исходные файлы и флагами rubric'а, готовая к ревью.
7. Простые случаи (всё сходится, rubric passed) автоматически идут дальше по workflow; сложные маршрутизируются compliance-офицеру с подсветкой проблемных пунктов и предложенным вердиктом.
8. Каждое решение — почему документ принят, отвергнут или отправлен на ревью — записывается в audit trail с версионированием модели и rubric'а.

Результат для команды: analyst-часы перераспределяются с рутинной сверки на реально сложные кейсы — нестандартные юрисдикции, неполные пакеты документов, признаки подделки, сложные корпоративные структуры.

Что автоматизация НЕ делает:

• Не принимает окончательное решение об onboarding клиента. Финальный вердикт остаётся за compliance-офицером, особенно для high-risk сегментов и сложных корпоративных структур.
• Не заменяет скрининг по санкционным спискам, adverse media и PEP-базам — это отдельные источники данных и проверки, которые подключаются рядом, но не являются частью document intelligence.
• Не работает «из коробки» для экзотических юрисдикций и редких типов документов без дообучения пайплайна на локальных образцах и добавления ручных правил в rubric.

Словарь: rubric — формальный чек-лист критериев принятия/отклонения документа; CDD — customer due diligence, расширенная проверка клиента; UBO — ultimate beneficial owner, конечный бенефициар; HITL — human-in-the-loop, ревью человеком внутри автоматизированного процесса.

Техническая архитектура KYC/CDD document intelligence собирается из четырёх слоёв: ingestion (приём документов), classification + extraction (понимание содержимого), QA rubric (правила комплаенса), orchestration + human-in-the-loop (маршрутизация и ревью).

Поток данных:

1. Приём файлов из File storage по событию (новый файл в папке) или по расписанию. Допустимые форматы — PDF, JPEG, PNG, TIFF; многостраничные документы разбиваются постранично.
2. OCR-слой превращает картинку в текст с координатами (bounding boxes). Для печатных документов — стандартные движки; для рукописного или низкого качества сканов — специализированные модели.
3. Классификатор определяет тип документа: ML-модель на эмбеддингах или промпт к LLM с описанием типов. Тип документа задаёт шаблон извлечения на следующем шаге.
4. Extractor достаёт поля по шаблону. Для структурированных документов (паспорта, ID-карты) — regex и позиционные правила; для неструктурированных (выписки, учредительные) — LLM с JSON-схемой ответа и валидацией.
5. Rubric-движок применяет чек-лист: документ читаем? даты валидны? срок действия не истёк? поля совпадают с CRM? формат соответствует требованиям юрисдикции?
6. Итоговый объект пишется в CRM (или в промежуточную таблицу) вместе со ссылками на исходные файлы и решением rubric'а по каждому пункту.
7. Оркестратор маршрутизирует дело: auto-approved → следующий шаг workflow; нужен ревью → очередь compliance-офицера; отклонено → возврат Relationship Manager с причиной.

Implementation steps для внедрения:

1. Собрать 200-500 образцов документов каждого типа из боевого потока. Разметить: тип, корректные значения полей, итоговый вердикт compliance по каждому пункту rubric'а.
2. Зафиксировать rubric в виде документа: какие поля обязательны для каждого типа, какие ситуации — hard fail, какие — soft warning с ревью человеком.
3. Выбрать vertical SaaS-решение для KYC/CDD или собрать кастомный пайплайн. Vertical-saas покрывает ingestion, OCR, классификацию и основные типы документов из коробки — это и есть причина брать готовое.
4. Настроить коннекторы к File storage и CRM. Для CRM — маппинг полей (документ → карточка клиента) и статус-модель (какие статусы дела соответствуют каким исходам автоматизации).
5. Провести параллельный прогон: неделя-две, когда документы идут и через людей, и через автоматизацию. Сравнить вердикты, измерить precision/recall по каждому пункту rubric'а.
6. Запуск на пилотном сегменте клиентов (одна юрисдикция или один продукт), постепенное расширение на соседние сегменты по мере стабилизации метрик.
7. Встроить HITL-интерфейс: экран ревью, где офицер видит документ, извлечённые поля, rubric-флаги и принимает финальное решение одним кликом.

Компоненты системы:

Качество замеряется в двух разрезах: precision/recall извлечения полей (чтобы данные в CRM были корректными) и precision/recall решений rubric'а (чтобы нестандартные случаи не уходили в auto-approve, а стандартные — не блокировались зря).

Отдельный слой — безопасность и compliance. Документы содержат персональные данные, поэтому хранилище шифруется, доступ — через сервисный аккаунт с ограниченными правами, а retention-политика совпадает с политикой банка. Audit trail хранит все вердикты модели и офицера с временными метками и версиями rubric'а — это нужно для регуляторных проверок и внутренних аудитов.

Перед запуском KYC/CDD document intelligence понадобится три вещи: данные для обучения и валидации, доступы к системам и готовность команды.

Данные и документы:

• 200-500 размеченных образцов документов каждого типа, которые будут обрабатываться (паспорт, proof of address, выписка, учредительные и так далее).
• Текущий rubric комплаенса в формализованном виде — что проверяет офицер сейчас, какие критерии hard fail, какие soft warning.
• История решений compliance-офицеров за последние 3-6 месяцев — понадобится для валидации модели на реальных edge-кейсах.

Доступы и интеграции:

• File storage с папочной структурой для клиентских дел и правами на чтение/запись для сервисного аккаунта.
• CRM с API или webhook'ами для записи структурированных данных клиента и статусов дела.
• Выделенные среды (test → staging → prod) и sandbox CRM для безопасного пилота.
• Соблюдение требований по хранению персональных данных клиентов: data residency, шифрование, retention-политика, логирование доступа.

Команда:

• Compliance-офицер или KYC-аналитик, готовый потратить 4-8 часов в неделю на формализацию rubric'а и разметку образцов.
• Product owner или KYC lead для решений о scope — какие типы документов, какие юрисдикции, с чего начать.
• Инженер или интегратор на стороне банка для настройки коннекторов и доступов.

Timeline: 6-10 недель от старта до пилотного запуска. Первые 2 недели — разметка и формализация rubric'а, следующие 3-4 — настройка пайплайна и параллельный прогон, оставшиеся — пилот на ограниченном сегменте и расширение на соседние продукты.