Конкурирующие требования к соблюдению KYC
Соблюдение требований Know Your Customer (KYC) создает специфическое напряжение в операциях финтеха: регуляторы требуют тщательной проверки личности — сбора и проверки личных документов — в то время как законы о защите данных требуют минимизации и защиты этих личных данных после их сбора.
Цифровой банк, который завершает KYC для нового заявителя на открытие счета, собирает удостоверения личности (национальные ID-карты, паспорта, водительские права), доказательства адреса и финансовые документы для проверки. Эти документы содержат высокую концентрацию именно тех личных данных, которые GDPR, AML и банковские надзорные органы требуют обрабатывать с соблюдением самых строгих мер защиты данных.
Когда собранные данные используются для аналитики, передаются в системы обнаружения мошенничества или обрабатываются для обучения ML моделей, принципы минимизации данных и ограничения целей GDPR требуют, чтобы личные данные были анонимизированы или псевдонимизированы перед использованием в вторичных процессах.
Проблема 2-дневного backlog
Цифровая банковская платформа, обрабатывающая 5,000 заявок KYC ежедневно в 15 европейских странах, столкнулась с конкретной операционной проблемой на этапе обнаружения PII: уровень ложных срабатываний в их автоматизированной системе обнаружения создавал очереди на проверку, которые растягивались до 2-дневного backlog.
Источник backlog: их инструмент обнаружения PII на основе ML отмечал примерно 8% текста, не относящегося к PII, в документах KYC как потенциальные личные данные. При 5,000 заявках в день, каждая из которых содержит несколько документов, суммарно десятки страниц, объем ложных срабатываний превышал то, что команда по соблюдению требований могла проверить в тот же рабочий день.
Ложные срабатывания были систематическими и предсказуемыми:
- Названия компаний в адресных документах отмечались как имена людей (модель ML путала собственные имена)
- Номера ссылок и коды заявок отмечались как потенциальные номера удостоверений (числовое сопоставление без проверки контрольной суммы)
- "Chase" и подобные распространенные имена, появляющиеся в названиях учреждений, отмечались как PII имена людей
Каждое ложное срабатывание требовало человеческой проверки для подтверждения или отклонения. При уровне ложных срабатываний 8% на 5,000 заявок это переводилось в тысячи ежедневных задач по проверке, которые не могли быть автоматизированы.
Что показывает исследование ACL
Исследование ACL 2024, оценивающее многоязычные NLP модели для обнаружения PII, показало, что только 5% многоязычных NLP моделей достигают более 85% F1-оценки для обнаружения неанглийских PII во всех 24 языках ЕС.
F1-оценка сочетает в себе точность и полноту — модель с высокой полнотой, но низкой точностью (много ложных срабатываний) показывает плохие результаты, как и модель с высокой точностью, но низкой полнотой (много ложных отрицаний). 95% уровень неудач в достижении 85% F1 во всех 24 языках ЕС отражает сложность создания модели, которая была бы как точной, так и всеобъемлющей для полного набора языков ЕС.
Для сравнения, XLM-RoBERTa достигает 91.4% кросс-язычной F1 для задач обнаружения PII, согласно бенчмаркингу HuggingFace 2024. Разница между 91.4% и медианным уровнем производительности многоязычных NLP моделей объясняет, почему многие финтех-организации сталкиваются с операционными проблемами при применении готовых многоязычных решений для рабочих процессов KYC.
Гибкое решение для KYC с высоким объемом
Для операций KYC, обрабатывающих большие объемы удостоверений личности в нескольких юрисдикциях ЕС, проблема ложных срабатываний решается через архитектурные решения:
Структурированный идентификатор regex с проверкой контрольной суммы: Национальные номера ID (немецкий Steuer-ID, голландский BSN, польский PESEL и т.д.) имеют детерминированные алгоритмы проверки. Обнаружение на основе формата + проверки контрольной суммы дает почти нулевой уровень ложных срабатываний для этих идентификаторов — номер ссылки, который не проходит алгоритм проверки контрольной суммы национального ID, не является национальным ID, независимо от его числовой длины.
Контекстно-осведомленный NLP для имен и свободного текста PII: Имена людей в удостоверениях личности появляются в предсказуемых контекстах ("Имя:", "Фамилия:", конкретные поля формы). Требования к контекстным словам для обнаружения NLP уменьшают ложные срабатывания от строк, похожих на имена, которые появляются в неименованных контекстах (названия учреждений, ссылки).
Настройка порогов по типу документа: Документы KYC имеют разные распределения PII, чем электронные письма службы поддержки клиентов или клинические заметки. Настройка порогов обнаружения отдельно для типов документов — более высокая точность для обработки KYC с высоким объемом, более высокая полнота для клинической деидентификации — позволяет настраивать под операционные требования, а не принимать универсальный стандарт.
Проблема backlog не является стоимостью автоматизации PII. Это стоимость использования инструментов, не настроенных под операционные требования высокообъемного многоязычного KYC.
Источники: