Теоретически проверка соответствия торговым требованиям выглядит просто: взять данные документа, сверить с авторитетными государственными базами и сообщить результаты. На практике эти «авторитетные государственные базы» — разрозненная смесь устаревающих систем, непоследовательных API, ненадёжной доступности и радикально различающихся форматов данных.
В Atlas Verified мы подключаемся к десяткам государственных и нормативных источников для проверки торговых документов в реальном времени. Каждая интеграция стала уроком проектирования с защитой от сбоев. В этой публикации мы делимся опытом создания надёжных систем поверх ненадёжной государственной инфраструктуры.
Обзор источников
Соблюдение требований международной торговли связано с несколькими ведомствами США, каждое из которых ведёт собственные базы данных со своими способами доступа:
USDA Organic Integrity Database. Основной источник статуса органической сертификации в США. Содержит все сертифицированные органические хозяйства, их органы сертификации, области сертификации и текущий статус. API реального времени нет. USDA публикует CSV-выгрузку — один огромный файл, который нужно скачать, разобрать и загрузить в собственную базу данных. Обновления происходят по расписанию USDA, а не вашему.
Список специально обозначенных лиц OFAC (SDN). Ведётся Управлением по контролю за иностранными активами Министерства финансов США. Каждый бизнес, участвующий в международной торговле, обязан по закону проверять контрагентов по этому списку. Доступен в виде XML-выгрузок и через сторонние API-сервисы. Список часто меняется по мере развития геополитической ситуации.
Предупреждения FDA об импорте. Управление по санитарному надзору за качеством пищевых продуктов и медикаментов публикует предупреждения об импорте, отмечающие определённые продукты, компании или страны для усиленной инспекции или задержания без физического осмотра. Доступны через OpenFDA API в формате JSON, но модель данных сложна, а связь между предупреждениями, фирмами и продуктами не всегда очевидна.
Сводный список для проверки (CSL). Ведётся Trade.gov и объединяет 11 различных списков проверки нескольких ведомств, включая OFAC SDN, BIS Entity List, BIS Denied Persons и ITAR Debarred. Доступен как JSON API, но у каждого исходного списка свои структуры полей и критерии сопоставления.
Тарифные данные WTO. Сервис Tariff Download Facility Всемирной торговой организации предоставляет ставки режима наибольшего благоприятствования по странам и кодам HS. Полезен для проверки заявленных ставок пошлин в коммерческих счетах. Доступен в виде скачиваемых наборов данных, а не API реального времени.
Каждый источник использует свои форматы данных, обновляется по своему расписанию, имеет свои характеристики надёжности и требует своих стратегий запросов. Единого государственного API для проверки соответствия нет. Вы создаёте его сами либо не имеете его.
Проблема актуальности
Когда специалист по соблюдению требований проверяет, включена ли компания в санкционный список, ему нужно знать, что ответ актуален. Не на прошлую неделю, а прямо сейчас.
Это создаёт инженерное противоречие. Некоторые базы, например USDA Organic Integrity Database, доступны только в виде периодических выгрузок. Другие, например OFAC, имеют сторонние API-сервисы, заявляющие доступ в реальном времени, но «реальное время» на деле означает «мы синхронизируемся каждые несколько часов».
Наш подход — многоуровневая стратегия актуальности:
Уровень 1: Проверка через действующий API. Для критически важных проверок соответствия, таких как санкционная проверка и списки запрещённых сторон, мы вызываем внешние API в момент запроса. Результат настолько актуален, насколько актуальны данные поставщика API. Мы кратко кэшируем результаты для повторных запросов в рамках одного сеанса проверки, но никогда не предоставляем устаревшие санкционные данные между сеансами.
Уровень 2: Синхронизированные локальные данные. Для крупных справочных наборов, таких как органические хозяйства USDA, Consolidated Screening List и индексы портов, мы поддерживаем синхронизированные копии в собственной базе. Автоматические задания синхронизации выполняются по настраиваемому расписанию, получая свежие данные из источника. Локальные запросы быстры и не зависят от доступности источника.
Уровень 3: Статические справочные данные. Для редко меняющихся наборов, таких как тарифные расписания WTO, определения кодов HS и характеристики портов, мы загружаем справочные данные и обновляем их с более длинным циклом. Они меняются ежеквартально или ежегодно, поэтому ежедневная актуальность избыточна.
Каждый результат запроса включает метаданные актуальности: когда исходный источник был синхронизирован последний раз и каков максимальный период устаревания. Последующие системы и пользователи могут принимать обоснованные решения на основе этих метаданных.
Проблема нечёткого сопоставления
Государственные базы не знают, как названия компаний написаны в ваших документах. А ваши документы не знают, как их пишут в государственной базе.
Это нетривиальная проблема. Одна компания может фигурировать как «Pearl White International Limited» в коносаменте, «PEARL WHITE INTERNATIONAL LIMITED» в записи OFAC, «Pearl White Intl. Ltd.» в сертификате происхождения и «Pearl White Int'l» от руки в упаковочном листе. Это одна и та же организация.
Эффективное сопоставление организаций при проверке соответствия требует совместной работы нескольких стратегий:
Нормализация. Перед сравнением нормализуются и запрос, и записи базы: приводится регистр, удаляется пунктуация, раскрываются сокращения и стандартизируются пробелы. Это решает простые случаи.
Фонетическое сопоставление. Названия компаний, звучащие одинаково, но написанные по-разному, что часто бывает при транслитерации из нелатинских письменностей, требуют фонетических алгоритмов. Название, транслитерированное из китайских или арабских символов, часто имеет несколько допустимых английских написаний.
Сходство на основе токенов. Вместо сравнения полных строк мы разбиваем названия на токены и измеряем совпадение. «Pearl White International Limited» и «International Pearl White Ltd» содержат те же токены в другом порядке. Подходы на основе токенов хорошо обрабатывают изменение порядка слов.
Устранение неоднозначности по контексту. Когда нечёткое сопоставление даёт несколько кандидатов, контекст документа помогает выбрать нужного. Если документ указывает, что компания находится в Мумбаи, Индия, и только одно из трёх совпадений «Pearl White» относится к Индии, это нужная компания.
Процесс сопоставления оценивает каждого кандидата по нескольким измерениям. Совпадения с высокой уверенностью автоматически переходят к проверке. Совпадения с низкой уверенностью показываются пользователю вместе с доказательствами для каждого кандидата.
Создание адаптеров для ненадёжных источников
Государственные API не созданы для высокодоступного коммерческого использования. Они отключаются для обслуживания без предупреждения. Жёстко ограничивают частоту запросов. Меняют форматы ответов при небольших обновлениях версии. Возвращают HTML-страницы ошибок вместо корректных ответов об ошибке.
Каждый внешний источник данных нашей системы доступен через слой адаптеров, учитывающий эти реалии:
Автоматические выключатели. Если источник неоднократно отказывает, адаптер прекращает отправку запросов на период ожидания. Это предотвращает каскадные сбои: если один API недоступен, мы не хотим, чтобы все параллельные проверки зависали в ожидании тайм-аутов.
Плавное снижение функциональности. Когда источник данных недоступен, проверка продолжается с доступными данными. Результат ясно показывает, какие проверки завершены, а какие пропущены из-за недоступности источника.
Валидация ответов. Мы проверяем каждый ответ на соответствие ожидаемым схемам до обработки. Государственные API иногда возвращают некорректные данные, пустое тело с кодом 200 или корректный JSON с неожиданной структурой.
Повторные попытки с увеличением задержки. Временные сбои вызывают автоматические повторные попытки с экспоненциальным увеличением задержки. Стратегия настраивается для каждого источника: некоторые государственные API быстро восстанавливаются, другие остаются недоступными длительное время.
Цепочка проверки
Один торговый документ может запустить проверки по пяти или более независимым источникам. Коносамент может требовать санкционной проверки OFAC всех сторон, проверки предупреждений FDA об импорте, Consolidated Screening List, положения судна, отслеживания контейнера и тарифов.
Эти проверки независимы и выполняются параллельно. Но все должны завершиться или корректно обработать отказ до представления результата проверки. Наша система одновременно запускает все применимые проверки, отслеживает их состояние и собирает итоговый результат по мере завершения. Быстрые проверки сразу предоставляются пользователю, а медленные появляются по мере готовности.
Слой оркестрации также обрабатывает зависимости между проверками. Если санкционная проверка возвращает совпадение с высокой уверенностью, система отмечает всю проверку как требующую рассмотрения человеком независимо от результатов остальных проверок.
От исходных данных к аналитике для действий
Самая исходная форма результата проверки соответствия бесполезна: «API вернул объект JSON с 3 потенциальными совпадениями». Специалист должен понимать, что эти совпадения означают, насколько им доверять и какие действия предпринять.
Наш слой обработки результатов превращает исходные ответы API в структурированные выводы, позволяющие действовать:
Оценка. Каждое совпадение оценивается по сходству названия, географической связи и совпадению типа организации. Совпадение названия на 97% с подсанкционной организацией в той же стране сильно отличается от совпадения на 72% с организацией на другом континенте.
Контекстуализация. Результаты представлены в контексте конкретного документа и проверки. Выводы включают конкретную проверяемую сторону, сведения о совпадающей организации и объяснение значимости совпадения.
Приоритизация. Не все выводы равнозначны. Подтверждённое санкционное совпадение критично. Истёкшая органическая сертификация важна. Небольшое тарифное расхождение носит информационный характер. Система классифицирует выводы по степени серьёзности.
Рекомендуемые действия. По возможности система предлагает следующие шаги: «Рассмотрите запрос обновлённого сертификата», «Проверьте регистрационный номер компании напрямую», «Направьте на углублённую комплексную проверку». Это превращает поиск данных в рабочий процесс.
Проектирование ради доверия
Основная проблема подключения ИИ к государственным базам не техническая — она связана с доверием. Специалисты по соблюдению требований юридически отвечают за свои решения при проверке. Им нужна уверенность в актуальности данных, точности сопоставления, полноте результатов и прозрачности системы относительно её ограничений.
Каждое проектное решение в нашем слое данных о соответствии служит этому принципу. Мы показываем временные метки актуальности данных. Объясняем баллы совпадения. Сообщаем о недоступности источников. Никогда не представляем неполные результаты как полные.
Создание такого доверия требует инженерной строгости, выходящей за пределы получения правильного ответа в большинстве случаев. Нужно получать правильный ответ каждый раз и честно говорить о случаях, когда ответ неопределён.
Atlas Verified подключается к десяткам государственных и нормативных баз данных для проверки соответствия торговым требованиям в реальном времени. Наш слой данных справляется со сложностью разрозненной государственной инфраструктуры, чтобы специалисты могли сосредоточиться на решениях, а не сборе данных.