KYC/CDD document intelligence

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

Це закриває найтрудомісткішу частину KYC/CDD: читання сканів, копіювання полів у систему, проходження по чек-листу.

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

1. Клієнт або менеджер по роботі з клієнтами завантажує пакет документів у файлове сховище — папку клієнтської справи або тимчасову папку для завантаження.
2. Автоматизація забирає файли за подією і класифікує кожен: паспорт, підтвердження адреси, установчі документи, виписки, UBO-декларація, корпоративна структура і так далі.
3. З кожного типу витягуються релевантні поля — ПІБ, дата народження, номер документа, адреса, дата видачі, строк дії, реєстраційні реквізити компанії.
4. Витягнуті дані звіряються з тим, що клієнт зазначив у формі або що вже є в CRM: розбіжності (місмети) позначаються із зазначенням джерела.
5. Документи проходять QA за рубрикою: читабельність скану, валідність дат, строк дії, наявність підпису і печатки, наявність обов'язкових полів, відповідність заявленому типу.
6. Результат — структурований запис клієнта в CRM з усіма витягнутими полями, посиланнями на вихідні файли і прапорцями рубрики, готовий до ревю.
7. Прості випадки (все сходиться, рубрику пройдено) автоматично йдуть далі за робочим процесом; складні маршрутизуються комплаєнс-офіцеру з підсвіченням проблемних пунктів і запропонованим вердиктом.
8. Кожне рішення — чому документ прийнятий, відхилений або надісланий на ревю — записується до журналу аудиту з версіонуванням моделі і рубрики.

Результат для команди: години аналітиків перерозподіляються з рутинної звірки на справді складні кейси — нестандартні юрисдикції, неповні пакети документів, ознаки підробки, складні корпоративні структури.

Що автоматизація НЕ робить:

• Не приймає остаточне рішення щодо підключення клієнта. Фінальний вердикт залишається за комплаєнс-офіцером, особливо для сегментів з підвищеним ризиком і складних корпоративних структур.
• Не замінює скринінг за санкційними списками, негативними публікаціями і PEP-базами — це окремі джерела даних і перевірки, які підключаються поряд, але не є частиною document intelligence.
• Не працює «з коробки» для екзотичних юрисдикцій і рідкісних типів документів без донавчання пайплайну на локальних зразках і додавання ручних правил у критерії оцінки.

Словник: рубрика — формальний чек-лист критеріїв прийняття/відхилення документа; CDD — поглиблена перевірка клієнта, розширена перевірка клієнта; UBO — кінцевий бенефіціарний власник, кінцевий бенефіціар; HITL — людина у контурі процесу, ревю людиною всередині автоматизованого процесу.

Технічна архітектура KYC/CDD document intelligence складається з чотирьох шарів: приймання документів, класифікація та вилучення (розуміння змісту), рубрика QA (правила комплаєнсу), оркестрація та людина у контурі процесу (маршрутизація та ревю).

Потік даних:

1. Приймання файлів із файлового сховища за подією (новий файл у папці) або за розкладом. Допустимі формати — PDF, JPEG, PNG, TIFF; багатосторінкові документи розбиваються посторінково.
2. OCR-шар перетворює зображення на текст з координатами (обмежувальні рамки). Для друкованих документів — стандартні рушії; для рукописного або низької якості сканів — спеціалізовані моделі.
3. Класифікатор визначає тип документа: ML-модель на ембедингах або запит до LLM з описом типів. Тип документа задає шаблон вилучення на наступному кроці.
4. Extractor витягує поля за шаблоном. Для структурованих документів (паспорти, ID-картки) — regex і позиційні правила; для неструктурованих (виписки, засновницькі) — LLM з JSON-схемою відповіді та валідацією.
5. Критеріальний рушій застосовує чек-лист: документ читабельний? дати валідні? термін дії не минув? поля збігаються з CRM? формат відповідає вимогам юрисдикції?
6. Підсумковий об'єкт записується в CRM (або в проміжну таблицю) разом із посиланнями на вихідні файли та рішенням критеріїв оцінки по кожному пункту.
7. Оркестратор маршрутизує справу: автоматично схвалено → наступний крок робочого процесу; потрібен ревю → черга комплаєнс-офіцера; відхилено → повернення менеджеру по роботі з клієнтами з причиною.

Кроки впровадження:

1. Зібрати 200-500 зразків документів кожного типу з бойового потоку. Розмітити: тип, коректні значення полів, підсумковий вердикт відповідності вимогам по кожному пункту критеріїв оцінки.
2. Зафіксувати критерії оцінки у вигляді документа: які поля обов'язкові для кожного типу, які ситуації — жорстка відмова, які — м'яке попередження з ревю людиною.
3. Вибрати вертикальне SaaS-рішення для KYC/CDD або зібрати кастомний конвеєр. Вертикальний SaaS покриває приймання документів, OCR, класифікацію та основні типи документів з коробки — це і є причина брати готове.
4. Налаштувати конектори до файлового сховища та CRM. Для CRM — маппінг полів (документ → картка клієнта) та статус-модель (які статуси справи відповідають яким результатам автоматизації).
5. Провести паралельний прогін: тиждень-два, коли документи йдуть і через людей, і через автоматизацію. Порівняти вердикти, виміряти precision/recall за кожним пунктом рубрики.
6. Запуск на пілотному сегменті клієнтів (одна юрисдикція або один продукт), поступове розширення на сусідні сегменти в міру стабілізації метрик.
7. Вбудувати HITL-інтерфейс: екран ревю, де офіцер бачить документ, вилучені поля, прапорці рубрики та приймає фінальне рішення одним кліком.

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

Якість вимірюється у двох розрізах: precision/recall вилучення полів (щоб дані в CRM були коректними) та precision/recall рішень рубрики (щоб нестандартні випадки не йшли на автоматичне схвалення, а стандартні — не блокувалися даремно).

Окремий шар — безпека та відповідність вимогам. Документи містять персональні дані, тому сховище шифрується, доступ — через сервісний акаунт з обмеженими правами, а політика зберігання збігається з політикою банку. Журнал аудиту зберігає всі вердикти моделі та офіцера з часовими мітками та версіями рубрики — це потрібно для регуляторних перевірок та внутрішніх аудитів.

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

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

• 200-500 розмічених зразків документів кожного типу, які оброблятимуться (паспорт, підтвердження адреси, виписка, установчі та інше).
• Поточні критерії оцінки комплаєнсу у формалізованому вигляді — що перевіряє офіцер зараз, які критерії є жорсткою відмовою, які — м'яким попередженням.
• Історія рішень комплаєнс-офіцерів за останні 3-6 місяців — знадобиться для валідації моделі на реальних граничних випадках.

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

• Файлове сховище з папковою структурою для клієнтських справ і правами на читання/запис для сервісного акаунту.
• CRM з API або вебхуками для запису структурованих даних клієнта та статусів справи.
• Виділені середовища (тестове → проміжне → бойове) і тестова CRM для безпечного пілота.
• Дотримання вимог щодо зберігання персональних даних клієнтів: локалізація даних, шифрування, політика зберігання, логування доступу.

Команда:

• Комплаєнс-офіцер або KYC-аналітик, готовий витратити 4-8 годин на тиждень на формалізацію критеріїв оцінки та розмітку зразків.
• Власник продукту або відповідальний за KYC для рішень щодо обсягу — які типи документів, які юрисдикції, з чого почати.
• Інженер або інтегратор на стороні банку для налаштування конекторів і доступів.

Терміни: 6-10 тижнів від старту до пілотного запуску. Перші 2 тижні — розмітка та формалізація критеріїв оцінки, наступні 3-4 — налаштування пайплайну та паралельний прогін, решта — пілот на обмеженому сегменті та розширення на суміжні продукти.