Разработка системы PEP (Politically Exposed Persons) проверки

Финансовый регулятор оштрафовал криптобиржу на $3 млн за отсутствие EDD по PEP-клиенту. Такие случаи — не редкость: FATF R12 требует обязательной идентификации политически значимых лиц. Если ваша система AML не умеет различать PEP и RCA (родственников), вы рискуете пропустить high-risk клиента. Мы разрабатываем PEP-проверку под ключ: от выбора провайдера до EDD-воркфлоу и непрерывного мониторинга. Оцениваем проект за 2 дня, деплой — за 2–4 недели.

Без автоматизации compliance-отдел тратит часы на ручную проверку каждого клиента. Наша система сокращает это время до секунд, обрабатывая запросы в реальном времени через API ComplyAdvantage или World-Check. Точность скрининга — более 95% после настройки фильтров. В этой статье разберём, как избежать типичных ошибок и построить надёжную PEP-систему.

Проблемы, которые решаем

Ложные срабатывания. База ComplyAdvantage выдаёт 30% совпадений, но большинство — false positives. Настраиваем fuzziness и фильтры по DOB для точности 95%.

Отсутствие RCA. Родственники PEP не менее рискованны. Интегрируем API с покрытием relatives.

Регулярный rescreening. PEP статус меняется со временем. Ставим cron каждую неделю с уведомлением compliance officer.

Как мы это делаем

Используем ComplyAdvantage как основной источник. Пример интеграции на TypeScript:

class PEPScreeningService {
  async screenPerson(params: {
    firstName: string;
    lastName: string;
    dateOfBirth?: string;
    nationality?: string;
  }): Promise<PEPScreenResult> {
    
    const response = await this.complyAdvantage.search({
      search_term: `${params.firstName} ${params.lastName}`,
      fuzziness: 0.7,
      filters: {
        types: ["pep", "pep-class-1", "pep-class-2", "pep-class-3", "pep-class-4"],
      },
    });
    
    const matches = response.content.data.hits;
    
    if (matches.length === 0) return { isPEP: false, isRCA: false };
    
    // Фильтруем по DOB если есть
    const strongMatches = params.dateOfBirth
      ? matches.filter(m => this.dobMatches(m, params.dateOfBirth!))
      : matches;
    
    if (strongMatches.length === 0) {
      return { isPEP: false, possibleMatches: matches.slice(0, 3) };
    }
    
    const match = strongMatches[0];
    return {
      isPEP: match.doc.types.some(t => t.startsWith("pep")),
      isRCA: match.doc.types.includes("relative-close-associate"),
      pepClass: this.extractPEPClass(match.doc.types),
      positions: match.doc.fields?.filter(f => f.tag === "position") ?? [],
      country: match.doc.fields?.find(f => f.tag === "country_names")?.value,
      matchScore: match.score,
      entity: match.doc,
    };
  }
  
  private extractPEPClass(types: string[]): number {
    if (types.includes("pep-class-1")) return 1; // Head of state, government ministers
    if (types.includes("pep-class-2")) return 2; // Parliament members, senior judiciary
    if (types.includes("pep-class-3")) return 3; // Senior military, state-owned enterprise heads
    if (types.includes("pep-class-4")) return 4; // Local government, lower-risk positions
    return 0;
  }
}

После определения статуса запускаем EDD workflow для PEP классов 1–2 — требуется одобрение senior management.

async function handlePEPResult(userId: string, result: PEPScreenResult): Promise<void> {
  if (!result.isPEP && !result.isRCA) {
    await db.setUserRiskFactor(userId, "pep", false);
    return;
  }
  
  // PEP требует Enhanced Due Diligence
  await db.setUserRiskFactor(userId, "pep", true);
  await db.updateUserRiskLevel(userId, RiskLevel.HIGH);
  
  const eddRequired: EDDRequirement = {
    sourceOfFunds: true,
    sourceOfWealth: true,
    seniorManagementApproval: result.pepClass <= 2,
    enhancedOngoingMonitoring: true,
    annualReview: true,
  };
  
  await requestEDD(userId, eddRequired);
  await notifyComplianceOfficer(userId, result);
}

Для непрерывного мониторинга настраиваем еженедельный rescreening всех активных клиентов.

@Cron("0 2 * * 0") // каждое воскресенье в 2:00
async weeklyPEPRescreening() {
  const activeCustomers = await db.getActiveCustomers();
  
  for (const customer of activeCustomers) {
    const result = await this.pepService.screenPerson(customer);
    const previousStatus = customer.pepStatus;
    
    if (result.isPEP && !previousStatus) {
      // Новый PEP — немедленное уведомление
      await this.handleNewPEPDetection(customer.id, result);
    }
  }
}

Почему важна классификация PEP по уровню риска?

PEP класс 1 (главы государств, премьер-министры) требует одобрения senior management и расширенной проверки источников средств. Класс 4 (чиновники местного уровня) — только облегчённая EDD. Неправильная классификация ведёт к штрафам или избыточной нагрузке на compliance. Наш API возвращает pepClass, что позволяет автоматизировать эти процессы.

Как настроить автоматическое обновление PEP статусов?

Используем регулярный запуск скрипта через cron: каждое воскресенье в 2:00. API ComplyAdvantage возвращает обновлённые статусы. При обнаружении нового PEP система немедленно уведомляет compliance-офицера и запускает EDD workflow. Это исключает человеческий фактор и гарантирует соответствие требованиям FATF Recommendation 12.

Сравнение провайдеров PEP данных

ComplyAdvantage лучше для стартапов из-за простой интеграции, а World-Check — для банков благодаря глубине данных. Мы помогаем выбрать провайдера под ваш бюджет и регуляторные требования.

Этапы и сроки

Что входит в работу

• Документация API и workflow (OpenAPI, диаграммы)
• Исходный код на TypeScript (скрипты миграции, тесты)
• Дашборд мониторинга с графиками false positives
• 2-часовое обучение compliance команды
• 1 месяц поддержки после запуска

Типичные ошибки при интеграции PEP-проверки

• Игнорирование RCA — проверяйте не только самого PEP, но и его окружение. Данные есть у всех провайдеров.
• Слишком высокий порог fuzziness (> 0.9) — пропустите реальные совпадения из-за опечаток в именах. Оптимум — 0.7.
• Отсутствие rescreening — статус PEP может появиться после открытия счета. Настраивайте автоматический пересчёт.

Сроки ориентировочно

От 2 до 4 недель в зависимости от количества провайдеров и сложности EDD-логики. Базовую интеграцию с одним провайдером и базовым скринингом делаем за 2 недели. Полный цикл с RCA, rescreening и дашбордом — 4 недели.

Свяжитесь с нами для оценки вашего проекта — рассчитаем сроки и стоимость за 2 дня. Закажите разработку системы PEP-проверки под ключ уже сейчас. У нас 7+ лет опыта в AML-системах, 30+ интеграций с провайдерами PEP, гарантируем прохождение AML-аудита. Подробнее о ComplyAdvantage API.

Услуги блокчейн комплаенса: почему ваш проект рискует без них

Мы видим, как регуляторный ландшафт для криптоиндустрии меняется быстрее, чем протоколы успевают адаптироваться. Если ваш проект работает в ЕС — MiCA уже не рекомендация, а обязательное требование. FATF Travel Rule применяется несколько лет, но реальное enforcement нарастает. Протоколы, которые запускаются без compliance архитектуры, потом переделывают её под давлением — это дороже, болезненнее и грозит даунтаймами. Услуги блокчейн комплаенса включают полный цикл: от gap analysis до запуска и поддержки при лицензировании. Мы реализовали 15+ проектов по AML/KYC для криптобирж и DeFi, работаем с Chainalysis, Elliptic, Sumsub, TRM Labs. Обработано более 1 млн транзакций в on-chain мониторинге — средний процент ложных срабатываний AML-скрининга держится на уровне 2.3%.

Почему Travel Rule — техническая, а не юридическая задача?

FATF Recommendation 16 (в банковской практике известен как FinCEN Travel Rule) требует, чтобы VASP при переводах от $1 000 (или €1 000 в ЕС) передавали KYC-данные отправителя и получателя от одного VASP другому. Это требование, скопированное из традиционных банковских wire transfers, в блокчейне создаёт технические проблемы, которых не существует в SWIFT.

Первая проблема — определение VASP-to-VASP. Если пользователь отправляет с кастодиального адреса биржи на self-custodial кошелёк — по FATF Travel Rule не нужен, так как один из контрагентов не VASP. Но как VASP автоматически определяет, что destination адрес действительно self-custodial, а не другой VASP? Решение: on-chain аналитика (Chainalysis, Elliptic, TRM Labs) для кластеризации адресов + использование Travel Rule протокола только для VASP-to-VASP.

Вторая проблема — interoperability между VASP. Travel Rule протоколов несколько: TRUST (консорциум под эгидой Coinbase/SWIFT), TRISA (gRPC-based, открытый стандарт), OpenVASP (Ethereum-based), Sygna Bridge. Они несовместимы между собой. Большинство крупных бирж поддерживают несколько одновременно. Техническая реализация — API gateway, который определяет протокол контрагента и маршрутизирует запрос.

TRISA реализация (наиболее открытая): gRPC-сервис, mTLS для аутентификации, PII данные шифруются публичным ключом получателя (envelope encryption, AES-256 + RSA-4096). Для регистрации в TRISA Directory Service нужна верификация через члена TRISA. Код — открытый SDK на Go и Python.

Конкретная грабля: timing. Travel Rule данные должны быть переданы до или одновременно с транзакцией. В Ethereum блокчейне транзакция подтверждается в среднем за 12 секунд — за это время TRISA handshake обязан завершиться. Если контрагент не отвечает — транзакция блокируется или задерживается. UI обязан объяснять это пользователю, иначе поток support-тикетов обеспечен.

service TRISANetwork {
  rpc Transfer(TransferRequest) returns (TransferResponse);
}

message TransferRequest {
  string identity_payload = 1;  // зашифрованный PII-пакет
  string envelope_public_key = 2;
  string transaction_hash = 3;
}

Как выбрать KYC/AML провайдера для криптопроекта?

KYC-провайдеры для криптовалют делятся на несколько классов:

Tier 1 (enterprise, regulatory grade): Jumio, Onfido, Sumsub, Veriff. Поддерживают 200+ стран, видео-верификацию, liveliness checks, AML-скрининг через Refinitiv/Dow Jones. Интеграция через REST API + webhooks. Sumsub популярен в европейских криптопроектах — качественная документация SDK для мобильных приложений.

Tier 2 (DeFi-native, privacy-focused): Fractal ID, Synaps, Persona. Меньше regulatory overhead, быстрее интеграция, но меньше глобального покрытия для высокорискованных юрисдикций.

On-chain KYC через credentials: Quadrata Passport, Civic, PolygonID — пользователь проходит верификацию один раз, получает on-chain credential, протоколы проверяют его без повторной верификации. Privacy-preserving через ZK. Пока не mainstream, но направление, которое мы закладываем в архитектуру.

Архитектурный принцип: KYC-данные никогда не хранятся on-chain. Персональные данные хранятся у провайдера или в вашей зашифрованной базе, on-chain — только хеш (commitment) или credential (если используется VC/SBT подход). Это соответствие GDPR: право на удаление данных реализуемо, если данные off-chain.

Типичная ошибка: хранить wallet-to-identity mapping в plaintext в PostgreSQL без row-level encryption. Один SQL injection — и вся база KYC-данных скомпрометирована. Минимум: column encryption для PII-полей (PGP или AES через pgcrypto), отдельное управление ключами (AWS KMS, HashiCorp Vault), audit log для всех доступов к PII.

Для AML-скрининга используем Chainalysis, Elliptic или TRM Labs. Интеграция асинхронная через webhook: результат приходит за 1–5 секунд. Threshold-based блокировка: HIGH risk — автоблок, MEDIUM — manual review. Hold-период для подозрительных транзакций — 24–72 часа до manual review. Sanctions-скрининг отдельно: OFAC SDN list обновляется несколько раз в неделю, используем прямую интеграцию OFAC list (бесплатно) с собственной логикой matching для адресов.

Услуги блокчейн комплаенса: как мы реализуем поддержку MiCA

Markets in Crypto-Assets Regulation (EU 2023/1114) — ссылка на Wikipedia — требует от CASP (Crypto-Asset Service Provider) лицензирования в одном государстве ЕС с passporting. Технические требования, влияющие на разработку:

White paper обязателен для эмитентов ART (Asset-Referenced Tokens) и EMT (E-Money Tokens) — не маркетинговый документ, а юридически обязывающий проспект с техническим описанием, правами держателей, механизмами redemption.

Custody requirements: клиентские активы отдельно от операционных. Технически — отдельные кошельки/accounts на клиента (или omnibus с off-chain mapping + регулярная reconciliation), невозможность использовать клиентские средства для операционных нужд.

Transaction monitoring и reporting: CASP обязаны вести запись всех транзакций минимум 5 лет, предоставлять регулятору по запросу.

Travel Rule в MiCA: порог €0 для VASP-to-VASP переводов — не €1 000, как в FATF. Реализация требует Travel Rule endpoint, работающего 24/7.

Процесс внедрения compliance инфраструктуры

Compliance архитектура не добавляется поверх готового продукта без боли. Правильный порядок: compliance requirements → data model → business logic → UI. Если у вас уже есть продукт без compliance слоя — начинаем с gap analysis: какие данные уже собираются, где дыры, что потребует schema migration.

1. Gap analysis — аудит текущей архитектуры и data flow (1–2 недели).
2. Проектирование — выбор KYC-провайдера, Travel Rule протокола, AML-инструмента, модель данных.
3. Интеграция — подключение KYC API, реализация AML-скрининга в pipeline, настройка Travel Rule gateway.
4. Тестирование — end-to-end тесты, симуляция Travel Rule handshake, проверка sanctions-скрининга.
5. Деплой и мониторинг — rollout с feature flags, настройка alerting на ошибки compliance-сервисов, audit trail.
6. Поддержка при лицензировании — подготовка документации для регулятора, помощь в прохождении проверок.

Что включает услуга блокчейн комплаенса?

• Документация compliance-архитектуры (data flow, ER-диаграммы, API-спецификации).
• Интеграция KYC/AML/Travel Rule API с вашим бэкендом.
• Настройка мониторинга и alerting для compliance-сервисов.
• Обучение вашей команды работе с инструментами (Chainalysis, Sumsub и т.д.).
• Поддержка при прохождении лицензирования (MiCA, FATF).

Ориентиры по срокам

• KYC/AML интеграция с Sumsub или Jumio — от 3 до 6 недель.
• Travel Rule (TRISA или Sygna) — от 6 до 10 недель.
• Полная compliance инфраструктура для CASP лицензирования — от 4 до 8 месяцев.
• On-chain compliance через VC/SBT с ZK (MiCA-ready) — от 5 до 9 месяцев.

Scope уточняется после gap analysis. Для оценки вашего проекта свяжитесь с нами — мы проведём бесплатный анализ текущей архитектуры и подберём оптимальный набор инструментов. Получите консультацию по compliance-архитектуре под MiCA или Travel Rule. Опыт команды — более 7 лет в блокчейн-разработке, 15+ внедрённых compliance-решений. Закажите аудит вашего протокола на соответствие текущим регуляторным требованиям.