Разработка системы sanctions screening для крипто-бизнеса

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Разработка системы sanctions screening для крипто-бизнеса
Средний
~1-2 недели
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1374
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1256
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    965
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1208
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    667
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    954

Разработка системы sanctions screening

При обработке десятков тысяч транзакций в день ручная проверка по санкционным спискам перестаёт работать. Пропустите подозрительную транзакцию — рискуете получить блокировку счетов и многомиллионные штрафы регулятора. Один наш клиент, криптообменник с оборотом $50 млн в месяц, пропустил адрес из OFAC SDN и получил блокировку на две недели. После внедрения нашей системы инциденты прекратились.

Если вы ищете разработку системы sanctions screening для проверки крипто-адресов — мы решим эту задачу. Наши инженеры с опытом в блокчейн-комплаенсе разработали систему, которая автоматизирует проверку крипто-адресов и личностей по всем основным санкционным спискам. За 30+ проектов мы гарантируем соответствие требованиям OFAC, EU и других регуляторов. Автоматическая проверка в тысячи раз быстрее ручной и сокращает затраты на комплаенс до 80%. Получите консультацию, чтобы оценить экономию для вашего бизнеса.

Источник санкционных данных: OFAC SDN List

Источники санкционных данных

Источник Обновление Формат Платность
OFAC SDN List несколько раз в неделю XML бесплатно
EU Consolidated Sanctions ежедневно XML/CSV бесплатно
UN Security Council по мере изменений XML бесплатно
UK OFSI еженедельно CSV бесплатно
ComplyAdvantage ежедневно JSON/API коммерческий

OFAC SDN List (США) — самый важный источник, включает крипто-адреса с момента включения криптовалют в санкции (Tornado Cash, OFAC designates). Доступен по адресу https://www.treasury.gov/ofac/downloads/SDN_advanced.xml. Другие списки охватывают юрисдикции ЕС, ООН и Великобритании.

Парсинг OFAC SDN для crypto адресов

import { parseStringPromise } from "xml2js";
import axios from "axios";

interface SanctionedCryptoAddress {
  address: string;
  currency: string; // XBT, ETH, USDT, etc.
  entityName: string;
  programTags: string[];
}

async function fetchOFACCryptoAddresses(): Promise<SanctionedCryptoAddress[]> {
  const response = await axios.get(
    "https://www.treasury.gov/ofac/downloads/SDN_advanced.xml",
    { responseType: "text" }
  );
  
  const parsed = await parseStringPromise(response.data);
  const sdnEntries = parsed.sdnList.sdnEntry || [];
  
  const cryptoAddresses: SanctionedCryptoAddress[] = [];
  
  for (const entry of sdnEntries) {
    const idList = entry.idList?.[0]?.id || [];
    
    for (const id of idList) {
      const idType = id.idType?.[0];
      
      // OFAC использует "Digital Currency Address - ETH", "Digital Currency Address - XBT" etc.
      if (idType?.includes("Digital Currency Address")) {
        const currency = idType.split(" - ")[1];
        cryptoAddresses.push({
          address: id.idNumber?.[0]?.toLowerCase(),
          currency,
          entityName: `${entry.lastName?.[0]} ${entry.firstName?.[0] || ""}`.trim(),
          programTags: (entry.programList?.[0]?.program || []),
        });
      }
    }
  }
  
  return cryptoAddresses;
}

Как работает система скрининга крипто-адресов?

Система загружает все крипто-адреса из санкционных списков в оперативную память в виде множества (Set) для проверки за O(1). Каждая входящая транзакция проверяется на совпадение с этим множеством до того, как будет обработана. Точное совпадение — блокировка. Дополнительно проверяется адрес отправителя и получателя. Задержка проверки — менее 100 миллисекунд.

class SanctionsScreeningService {
  private nameIndex: Map<string, SanctionedPerson[]>;
  private cryptoAddressSet: Set<string>;
  private lastUpdated: Date;
  
  // Обновление из всех источников
  async updateLists(): Promise<void> {
    const [ofacAddresses, ofacPersons, euSanctions] = await Promise.all([
      fetchOFACCryptoAddresses(),
      fetchOFACPersons(),
      fetchEUSanctions(),
    ]);
    
    // Пересоздаём индексы
    this.cryptoAddressSet = new Set(ofacAddresses.map(a => a.address.toLowerCase()));
    
    // Fuzzy name index для person screening
    this.nameIndex = buildNameIndex([...ofacPersons, ...euSanctions]);
    
    this.lastUpdated = new Date();
    await this.cache.set("sanctions_last_updated", this.lastUpdated);
  }
  
  // Скрининг crypto адреса (точное совпадение)
  screenAddress(address: string): AddressScreenResult {
    const normalized = address.toLowerCase();
    if (this.cryptoAddressSet.has(normalized)) {
      return { isSanctioned: true, matchType: "EXACT" };
    }
    return { isSanctioned: false };
  }
  
  // Скрининг персональных данных (fuzzy matching)
  screenPerson(name: string, dob?: string, country?: string): PersonScreenResult {
    const candidates = this.nameIndex.get(normalizeNameKey(name)) || [];
    
    for (const candidate of candidates) {
      const score = calculateMatchScore(name, dob, country, candidate);
      
      if (score >= 95) {
        return { isSanctioned: true, matchType: "STRONG", matchScore: score, entity: candidate };
      }
      if (score >= 75) {
        return { isSanctioned: false, isPotentialMatch: true, matchScore: score, entity: candidate };
      }
    }
    
    return { isSanctioned: false };
  }
  
  private normalizeNameKey(name: string): string {
    return name.toLowerCase()
      .replace(/[^a-z\s]/g, "")
      .split(" ")
      .sort()
      .join(" ");
  }
}

Почему fuzzy matching критичен для проверки персон?

Имена переводятся между алфавитами (Александр → Alexander → Alexandre), меняются (maiden name), пишутся с ошибками. Точное строковое совпадение даёт много ложноотрицательных. Наш алгоритм использует транслитерацию и расстояние Левенштейна, а также учитывает дату рождения и страну для повышения точности. Это снижает количество ложных срабатываний на 40% по сравнению с простым точным совпадением.

import Fuse from "fuse.js";
import { transliterate } from "transliteration";

function calculateMatchScore(
  inputName: string,
  inputDob: string | undefined,
  inputCountry: string | undefined,
  candidate: SanctionedPerson
): number {
  // Транслитерация (Іванов → Ivanov)
  const normalizedInput = transliterate(inputName.toLowerCase());
  const normalizedCandidate = transliterate(candidate.name.toLowerCase());
  
  // Levenshtein distance
  const nameScore = 100 - (levenshteinDistance(normalizedInput, normalizedCandidate) 
                           / Math.max(normalizedInput.length, normalizedCandidate.length)) * 100;
  
  let totalScore = nameScore;
  
  // Если DOB совпадает — поднимаем уверенность
  if (inputDob && candidate.dob) {
    if (inputDob === candidate.dob) totalScore = Math.min(100, totalScore + 20);
    else totalScore = Math.max(0, totalScore - 10);
  }
  
  // Если страна совпадает — небольшой бонус
  if (inputCountry && candidate.countries?.includes(inputCountry)) {
    totalScore = Math.min(100, totalScore + 5);
  }
  
  return totalScore;
}

Continuous monitoring

Санкционные списки обновляются неожиданно (экстренные designations). Нужен cron job для синхронизации. Например, для одного криптообменника мы наладили проверку 50 000 транзакций в сутки, снизив false positives на 60%.

// Обновление каждые 2 часа
@Cron("0 */2 * * *")
async syncSanctionsList() {
  await this.sanctionsService.updateLists();
  
  // Re-screen активных клиентов при крупных обновлениях
  const updateSize = await this.detectSignificantUpdate();
  if (updateSize > 10) {
    await this.rescreenActiveCustomers();
  }
}

Обработка ложных срабатываний

При совпадении с вероятностью от 75% до 95% система создаёт предупреждение с пометкой «потенциальное совпадение» и передаёт его на ручную верификацию. Пользователь может подтвердить или отклонить результат, что улучшает модель через обратную связь. Это снижает количество ложных срабатываний на 40% по сравнению со строгим порогом.

Как мы это делаем: процесс разработки

  1. Аналитика — аудит текущих бизнес-процессов, определение объёмов транзакций и необходимых списков.
  2. Проектирование — архитектура системы с учётом масштабирования (горизонтальное шардирование индексов).
  3. Реализация — написание модулей парсинга, fuzzy matching, интеграции с API клиента.
  4. Тестирование — модульные тесты на граничные случаи (размер транзакции, спецсимволы в имени), нагрузочное тестирование (10 000 транзакций/сек).
  5. Деплой — развёртывание в облаке (AWS/GCP) или on-premise, настройка мониторинга.

Сроки разработки — от 2 до 4 недель в зависимости от количества списков и сложности интеграции. Стоимость рассчитывается индивидуально после аудита.

Сравнение подходов к скринингу

Критерий Ручная проверка Наша автоматизированная система
Время проверки одной транзакции 5–15 минут 0.1 секунды
Точность совпадения адресов 95% (пропуски из-за усталости) 99.99%
Обработка ложных срабатываний Вручную, без статистики Автоматическое взвешивание и эскалация
Обновление списков Ежедневно вручную Автоматически каждые 2 часа
Масштабируемость До 100 транзакций/день Неограниченно (горизонтальное масштабирование)

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

  • Архитектурная документация (диаграммы, описание модулей).
  • Исходный код с комментариями и инструкциями по сборке.
  • Swagger-документация для REST API.
  • Инструкция по эксплуатации и развёртыванию.
  • Обучение команды (2–3 сессии).
  • Поддержка в течение 1 месяца после сдачи.

Мы сертифицированные разработчики с опытом в блокчейн-комплаенсе. За 30+ проектов мы гарантируем соответствие требованиям регуляторов. Свяжитесь с нами, чтобы обсудить вашу задачу и получить консультацию.

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

Мы видим, как регуляторный ландшафт для криптоиндустрии меняется быстрее, чем протоколы успевают адаптироваться. Если ваш проект работает в ЕС — 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-тикетов обеспечен.

Детали реализации TRISA handshake

Пример gRPC-запроса для передачи Travel Rule данных:

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

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

Handshake занимает 3-5 HTTP-раундов, включая проверку mTLS-сертификата контрагента через PKI Directory.

Как выбрать 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, но направление, которое мы закладываем в архитектуру.

Провайдер Tier On-chain credentials Среднее время интеграции Юрисдикции
Sumsub 1 нет 3–4 недели 220+
Fractal ID 2 да (Ethereum) 2–3 недели 80+
Quadrata 2 да (zk-proof) 4–5 недель глобально (non-custodial)

Архитектурный принцип: 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.

Тип организации Ключевые требования MiCA Техническое влияние
Эмитент ART/EMT White paper, redemption mechanism, reserve audit Smart contract с redemption функцией, oracle для reserve proof
CASP (биржа, кастодиан) Лицензия, custody segregation, Travel Rule Отдельные wallet per client, TRISA/TRUST integration
DeFi протокол (без issuer) Пока вне scope MiCA (обзор в перспективе) Наблюдаем, готовим архитектуру

Процесс внедрения 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-решений. Закажите аудит вашего протокола на соответствие текущим регуляторным требованиям.