Публикация была переведена автоматически. Исходный язык: Русский
Большинство KYC-проверок начинается слишком поздно, когда клиент уже пришёл в банк.
Но мы решили проверить другую гипотезу:
можно ли увидеть комплаенс-риски раньше — через рынок труда?
Вакансии компаний часто отражают реальные изменения в бизнесе быстрее, чем официальные реестры.
Например:
- компания ищет специалистов для криптообменника без лицензии
- появляются вакансии с аномально высокими зарплатами
- работодатель скрывает юридическое лицо
- особенно интересный сигнал это вакансии, которые исчезают через несколько часов после публикации (404).
Все это может быть ранним сигналом риска.
Поэтому мы построили небольшой RegTech-pipeline, который превращает данные HeadHunter API в реестр риск-сигналов.
Пайплайн построен по принципам Medallion Architecture:
- Bronze — MinIO
Сырые JSON-данные сохраняются как неизменяемый Source of Truth.
Это позволяет переигрывать данные без повторных обращений к API.
- Staging — Postgres
Буферный слой, который защищает аналитику от изменений в API HeadHunter.
- Silver / Gold — dbt
На этих слоях рассчитываются rule-based риск-сигналы и формируется таблица:
vacancy_risk_signals
В процессе разработки оказалось, что главный вызов — не сбор данных, а надежность системы.
1. Time-Skew
Для корректного аудита мы отказались от системных макросов Airflow и передаем дату запуска явно через dag_run.conf.
Теперь можно восстановить статус вакансии на любую дату проверки.
2. Rate-Limiting
Чтобы не попасть в бан HeadHunter API:
- используем requests.Session
- уменьшили батчи до 50 запросов
- реализовали stop-on-block.
3. Smart SKIP
Система различает:
- отсутствие новых данных (норма)
- техническую ошибку (инцидент)
Это снижает alert fatigue и оставляет только реальные проблемы.
Аналитик работает не с таблицами, а с очередью кейсов.
Каждая запись содержит:
- тип риска
- объяснение (evidence)
- рекомендацию по проверке.
Сейчас мы работаем над следующими модулями:
- автоматическая загрузка санкционных списков UN / OFAC
- Compliance Case Queue
- анализ описаний вакансий через LLM
- BI-дашборды для мониторинга рисков.
Интересно узнать мнение сообщества:
Используете ли вы OSINT-источники в комплаенс-мониторинге?
Если да, то какие сигналы оказываются самыми полезными на практике?
Больше «черновиков» и разборов по проекту в моем канале: @kyc_regtech_diary
Большинство KYC-проверок начинается слишком поздно, когда клиент уже пришёл в банк.
Но мы решили проверить другую гипотезу:
можно ли увидеть комплаенс-риски раньше — через рынок труда?
Вакансии компаний часто отражают реальные изменения в бизнесе быстрее, чем официальные реестры.
Например:
- компания ищет специалистов для криптообменника без лицензии
- появляются вакансии с аномально высокими зарплатами
- работодатель скрывает юридическое лицо
- особенно интересный сигнал это вакансии, которые исчезают через несколько часов после публикации (404).
Все это может быть ранним сигналом риска.
Поэтому мы построили небольшой RegTech-pipeline, который превращает данные HeadHunter API в реестр риск-сигналов.
Пайплайн построен по принципам Medallion Architecture:
- Bronze — MinIO
Сырые JSON-данные сохраняются как неизменяемый Source of Truth.
Это позволяет переигрывать данные без повторных обращений к API.
- Staging — Postgres
Буферный слой, который защищает аналитику от изменений в API HeadHunter.
- Silver / Gold — dbt
На этих слоях рассчитываются rule-based риск-сигналы и формируется таблица:
vacancy_risk_signals
В процессе разработки оказалось, что главный вызов — не сбор данных, а надежность системы.
1. Time-Skew
Для корректного аудита мы отказались от системных макросов Airflow и передаем дату запуска явно через dag_run.conf.
Теперь можно восстановить статус вакансии на любую дату проверки.
2. Rate-Limiting
Чтобы не попасть в бан HeadHunter API:
- используем requests.Session
- уменьшили батчи до 50 запросов
- реализовали stop-on-block.
3. Smart SKIP
Система различает:
- отсутствие новых данных (норма)
- техническую ошибку (инцидент)
Это снижает alert fatigue и оставляет только реальные проблемы.
Аналитик работает не с таблицами, а с очередью кейсов.
Каждая запись содержит:
- тип риска
- объяснение (evidence)
- рекомендацию по проверке.
Сейчас мы работаем над следующими модулями:
- автоматическая загрузка санкционных списков UN / OFAC
- Compliance Case Queue
- анализ описаний вакансий через LLM
- BI-дашборды для мониторинга рисков.
Интересно узнать мнение сообщества:
Используете ли вы OSINT-источники в комплаенс-мониторинге?
Если да, то какие сигналы оказываются самыми полезными на практике?
Больше «черновиков» и разборов по проекту в моем канале: @kyc_regtech_diary
Поделиться
