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 — налаштування пайплайну та паралельний прогін, решта — пілот на обмеженому сегменті та розширення на суміжні продукти.