Комплаєнс
Робочі комплаєнс-процеси · Web UI · API · MCP
Compliance Platform
Перевірка торгівлі та санкцій із доказовою базою.
CN / TARIC
Санкційні списки
Screening Cases
Платежі ISO 20022
API + MCP
Не пов'язано з Європейською Комісією. Не замінює офіційні джерела чи рішення компетентних органів.
v7 · вересень 2026
02 · Виклик
Складність не в скринінгу. Складність — у захисті результату.
Комплаєнс-робота зазнає невдачі, коли відповідь неможливо відтворити, задокументувати джерелом чи пояснити аудитору.
- Санкційні списки, заходи TARIC та реєстри суб'єктів розподілені між десятками регуляторів. Ручне їх об'єднання витрачає час контролерів.
- Більшість інструментів дають відповідь так/ні. Аудитори хочуть посилання на джерело, відмітку часу та обґрунтування контролера.
- Псевдоніми, транслітерації та локальні варіанти імен перетворюють чисте «без збігів» сьогодні на пропущений збіг завтра.
- Перевірки TARIC, скринінги суб'єктів та верифікації суден накопичуються в таблицях і листах — а не як одна перевіряна справа.
- Коли інструмент позначає збіг, контролери не завжди бачать чому. Це робить рішення складним для захисту під час аудиту.
- Інженери, які створюють внутрішню автоматизацію, зазвичай змушені парсити той самий інтерфейс, яким користуються комплаєнс-команди.
Прогалина захисту аудиту
1
Багато офіційних джерел
Санкційні списки, заходи TARIC, реєстри суб'єктів
2
Ручне об'єднання
Таблиці, скріншоти, листи електронної пошти
?
Рішення в аудиті
«Де докази?»
Захищаємий результат тримає разом дані, джерело, параметри, контролера та час.
03 · Цільова аудиторія + позиціонування
Комплаєнс-інструменти створювалися для банків першого рівня. Комплаєнс-робота відбувається всюди в інших місцях.
Той самий регуляторний тиск тепер торкається команд без окремого комплаєнс-відділу.
- Комплаєнс-інструменти виникли після 11 вересня й сформувалися всередині банків та консалтингових фірм Big Four. Вони досі коштують і налаштовуються відповідно.
- Той самий регуляторний тиск, значно ширше поле: транснаціональні корпорації, регіональні та МСП-банки, логістичні компанії, митні брокери, регіональні аеропорти, поліцейські оперативні групи, нотаріуси та комунальні служби.
- У цих командах немає окремого комплаєнс-відділу. Робота лягає на операційний, юридичний відділи або керівництво — поряд з основною роботою.
- Їм потрібні такі ж захищаємі скринінгові докази, як і банку першого рівня — але вони не можуть виправдати шестизначну ліцензію чи шестимісячну інтеграцію.
- Їм потрібен доступ там, де вони працюють: вебінструмент для юриста, API для інженера, MCP-сервер для AI-агента.
- Довгий хвіст комплаєнсу на порядки більший за ядро банків / Big Four — той самий регуляторний ризик, значно менше інструментів, жодного серйозного гравця, який їх обслуговує.
Довгий хвіст комплаєнсу
Ядро банків / Big Four
Транснаціональні корпорації
Регіональні та МСП-банки
Логістичні компанії
Митні брокери
Регіональні аеропорти
Поліцейські оперативні групи
Нотаріуси
Комунальні служби
Той самий тиск. Значно менше інструментів. Жодного серйозного гравця для всієї ширини.
04 · Основні функції
Захищаємий комплаєнс — без окремого комплаєнс-відділу.
Платформа перетворює щоденні скринінгові операції на доказово готові рішення.
- Отримайте одну прив'язану до джерела відповідь на запитання «Чи можна це відправити, обробити чи провести?» — охоплюючи заходи TARIC/CN, санкції та реєстри суб'єктів, а не три окремі інструменти.
- Виробляйте захищаємі докази як побічний продукт роботи. Кожна збережена перевірка автоматично отримує відмітку часу, прив'язку до джерела та прив'язку до контролера — окрема підготовка до аудиту не потрібна.
- Виявляйте те, що ручна перевірка пропускає. Збіги псевдонімів, варіанти транслітерацій та локальні шаблони імен виявляють кандидатів, яких сканування так/ні пропустило б.
- Починайте з реєстру, а не лише з імені. Завантажте компанію з підтримуваних даних реєстрів Латвії, Естонії, Польщі або Казахстану. Якщо офіційний запис показує посадових осіб чи власників, додайте їх до скринінгу.
- Створюйте захищувані докази в робочому процесі. Збережені справи поєднують час, посилання на джерела, параметри, результати та контекст перевіряльника.
- Починайте в робочому просторі вже сьогодні. Без шестизначного мінімуму, без шестимісячної інтеграції, без вимоги окремого комплаєнс-відділу.
Стан робочого простору, активовані сервіси, готовність та останні перевірки в одному узгодженому вигляді.
05 · Канали
Три інтерфейси, одне джерело істини.
Контролер, інженер та AI-агент під капотом використовують ті самі дані.
- Web UI — повний інтерфейс скринінгу для прямого використання контролером. Ті самі дані, ті самі докази, той самий слід аудиту, що й в інших каналах.
- API — REST-ендпоїнти для підтримуваних інтеграційних процесів. У self-service тарифах канал є платною опцією; у Enterprise він включений.
- MCP Server — надає скринінгові робочі потоки як нативні інструменти для AI-агентів. Будь-який сумісний з MCP клієнт (Claude, ChatGPT Agents, власний) може викликати перевірки й отримувати докази з посиланнями на джерело.
- Один аудиторський слід після збереження. Web, API та MCP можуть створити той самий артефакт Screening Case; швидкі разові перевірки залишаються тимчасовими.
- Спільне ядро. Усі три канали використовують базову логіку перевірки та каталог джерел. Права доступу, зберігання й формат результату залежать від каналу.
- Прозорі права. MCP включено в ліміти тарифу; REST API є платною опцією або частиною Enterprise.
Екосистема
Web UI
Інтерфейс контролера
REST API
Внутрішня автоматизація
MCP Server
Інструменти для агентів
Уніфіковані дані
Санкції · TARIC · близькі збіги
Один слід аудиту
Реєстр Screening Cases
Спільна базова перевірка; збережені перевірки використовують єдиний артефакт справи.
06 · Перевірки кодів TARIC / CN
Один запит, усі застосовні заходи, з посиланням на джерело.
Перевірки з урахуванням дати зберігають дані, які створили результат.
- Введіть те, що потрібно для митної декларації: код CN/TARIC, країну призначення, відповідну дату. Опціональні уточнення — тип заходу, додаткові коди.
- Отримайте два рівні в одному звіті: повідомлення про санкційний додаток за необхідності, плюс повну картину заходів TARIC — тарифні зупинки, контроль імпорту/експорту, заборони, правила за походженням — кожен з посиланням на регламент, діапазоном дат та вбудованими визначеннями умов.
- Кожен захід посилається на своє джерело — відповідний регламент ЄС або запис бази даних TARIC. Звіт показує контролерам (та аудиторам) обґрунтування, а не лише вирок.
- Запити з урахуванням дати. Відтворіть перевірку для будь-якої попередньої дати. Захищайте попереднє рішення за регуляторним станом, що діяв на той час.
- Збережені параметри подорожують з результатами. Дані, які створили перевірку, зберігаються поряд з результатом. Жодних прогалин на кшталт «що я шукав?» у сліді аудиту.
- Уся декларація за один раз. Перевірте всі позиції митної декларації одним прогоном, а не код за кодом, і отримайте один виправдальний звіт на всі.
За датою
Параметри збережено
07 · Скринінг санкцій
150+ офіційних джерел. Кожен результат пов'язаний із доказами.
Офіційні джерела можна переглядати, а записи посилаються на першоджерело.
- Що сканується. Імена — особи, компанії, судна, повітряні судна — разом з псевдонімами, локальними варіантами імен, транслітераціями, датами народження та ідентифікаторами (паспорт, IMO, BIC, реєстраційні номери).
- З чим звіряється. Каталог із 150+ офіційних джерел: санкції, PEP/EDD, відсторонення, експортний контроль, морський ризик, наглядові списки попереджень, реєстри компаній і митні довідники.
- Логіка зіставлення виявляє те, що пропускає ручна перевірка. Псевдоніми, транслітерації, фонетичні еквіваленти та локальні шаблони імен оцінюються поряд з точними збігами. Порогове значення налаштовується для кожної перевірки.
- Кожен збіг приходить зі своїм джерелом. Кожен збіг посилається на первинний запис списку — назва списку, програма, посилання на регламент, підстави включення. Контролер бачить докази, а не лише вирок.
- Також санкції на рівні товарів. Той самий робочий потік перевіряє коди CN/TARIC щодо додатків з обмеженням товарів (наприклад, Регламент ЄС № 833/2014, ДОДАТОК XXIII), щоб перевірка суб'єкта і перевірка товарів потрапляли в одну справу.
- Переглядайте набір даних напряму. Reference Library — таблиця включених суб’єктів із фільтрами за програмою, типом, країною та джерелом.
Покриття даних · 14 прикладів із каталогу 150+
| Офіційне джерело | Орган |
|---|
| OFAC SDN | США |
| EU FSF | Європейський Союз |
| EU Russia (Reg. 833/2014) | Європейський Союз |
| EU Belarus (Reg. 765/2006) | Європейський Союз |
| UN SC Consolidated | ООН |
| UK Sanctions List | Велика Британія |
| CH SECO | Швейцарія |
| JP MOF | Японія |
| AU DFAT | Австралія |
| CA SEMA | Канада |
| LV FID | Латвія |
| LV FID frozen-assets | Латвія |
| PL MSWiA | Польща |
| UA NSDC | Україна |
Для кожного процесу обирається релевантний профіль джерел. Частота оновлення та докази свіжості відповідають офіційному видавцю.
08 · Скринінг платежів ISO 20022
Pre-flight скринінг для pain.001 та pacs.008.
Парсер виділяє присутні в повідомленні сторони; збережена справа містить початковий payload і докази.
- Повне повідомлення. XML pain.001 / pacs.008 обробляється у переданому вигляді. Під час створення PaymentCase зберігаються сирий XML, SHA-256, метадані й попередження.
- Явна валідація. Структурні перевірки виконуються завжди. XSD-статус: valid, invalid або not configured; помилка налаштованої XSD створює Integrity Error.
- Учасники за ролями. Банки, боржник, кредитор і наявні посередники виділяються окремо; відсутні обов'язкові ролі стають попередженнями.
- Джерела за політикою. Кожен учасник перевіряється за профілем справи, а не безумовно за всім каталогом.
- BIC-розв'язання з доказами. Налаштовані резолвери можуть додати юридичну назву; нерозв'язані ID та конфлікти залишаються видимими.
- Збереження за вибором. Швидкий прогін тимчасовий; PaymentCase зберігає результати й докази повідомлення.
Обіцянка бренду · case-as-audit
Складна частина — не скринінг. Складна частина — захист результату.
Збережений PaymentCase об'єднує хеш XML, статус валідації, учасників, обрану політику та докази скринінгу.
Аудиторський слід виникає після збереження як справи; one-shot прогони відокремлені й обмежені в часі.
09 · Ролі учасників ISO 20022
Розпізнаються шість класів ролей. Перевіряються лише присутні сторони.
pain.001 і pacs.008 містять різні ланцюжки; кожен виділений учасник оцінюється окремо.
| # | Роль | Маппінг pain.001 | Маппінг pacs.008 | Сутність | Що перевіряється |
|---|
| 1 | Sender Bank | DbtrAgt (implied initiation) | InstgAgt | Корпорація | Банк-ініціатор або інструктуючий банк, якщо він присутній. BIC і знайдена назва перевіряються за обраною політикою джерел. |
| 2 | Ordering Institution | DbtrAgt (Debtor Agent) | DbtrAgt (Debtor Agent) | Корпорація | Debtor Agent, ідентифікований у XML. Часто той самий, що Sender Bank для прямого pain.001 — не завжди. Перевіряється окремо. |
| 3 | Ordering Customer | Dbtr (Debtor) | Dbtr (Debtor) | Сторона | Дані боржника з XML. Ім'я та доступні ідентифікатори стають входами й доказами скринінгу. |
| 4 | Intermediary Banks | N/A | IntrmyAgt1 → IntrmyAgt[n] | Корпорація | Ланцюг кореспондентів. Часто невидимий для відправника, але матеріально піддається, якщо санкційний кореспондент на шляху. |
| 5 | Beneficiary Bank | CdtrAgt (Creditor Agent) | CdtrAgt (Creditor Agent) | Корпорація | Приймаюча установа. Найчастіше упускана ціль скринінгу — ловить ЄС Росія/Білорусь під Reg. 833/765. |
| 6 | Beneficiary | Cdtr (Creditor) | Cdtr (Creditor) | Сторона | Дані кредитора з XML. Ім'я та доступні ідентифікатори стають входами й доказами скринінгу. |
Чому ролі, а не фіксована кількість
У pain.001 зазвичай немає банків-посередників, а pacs.008 може містити кілька. Парсер фіксує наявні ролі та попереджає про відсутні обов'язкові ролі.
10 · Screening Cases — диференціатор
Зберігайте перевірки, яким потрібен аудиторський слід.
Артефакт рішення, а не лише сирий результат скринінгу.
- Одиниця комплаєнс-роботи — це справа, а не перевірка. Одна транзакція, клієнт чи відправлення породжує багато перевірок — але аудитор бачить одне рішення. Справа — це артефакт цього рішення.
- Збережувані процеси входять до справи. TARIC, санкції, банки та ISO 20022 можна документувати разом; швидкі перевірки можуть залишатися тимчасовими.
- Статуси керують процесом. Справи мають Open, Closed і Archived; елементи — Pending, Clear, Hit, Review або Error із часом і контекстом перевіряльника.
- Збіги з'являються у справі. Червоні маркери «збіг», записи з посиланнями на джерело, нотатки контролера — видимі в контексті справи, не приховані в окремому інструменті сповіщень.
- Чим ми відрізняємось. Великі постачальники даних дають результати скринінгу. Compliance Platform дає справу, до якої вони належать, — артефакт, готовий до аудиту.
- Відтворюється пізніше. Знову відкрийте будь-яку справу, щоб побачити точні параметри, збіги, джерела та обґрунтування контролера в тому стані, в якому вони були тоді. Аудит — це не окреме завдання — справа і є аудитом.
ISO 20022
Скринінг платежів, готовий до справи. Вставте pain.001 / pacs.008, перегляньте учасників і валідацію, потім збережіть прогін, якщо потрібен постійний запис.
Аудит — це не окреме завдання — справа і є аудитом.
11 · AI Assistant + MCP
Той самий слід доказів. Тепер доступний агенту.
Шар агентів обґрунтований, цитований і записаний — не паралельний AI-силос.
- AI Assistant спирається на джерела. Він викликає інструменти TARIC, санкцій, сутностей, платежів і справ та відокремлює докази інструменту від згенерованого пояснення.
- MCP надає ті ж робочі потоки зовнішнім агентам. Будь-який сумісний з MCP клієнт — Claude, ChatGPT Agents, власний — може викликати скринінг як нативний інструмент і отримувати докази з посиланнями на джерело.
- Докази залишаються атрибутованими. Результати містять посилання на джерела й контекст свіжості; згенероване резюме не замінює первинний запис.
- Збереження явне. Агент може створити той самий Screening Case, що й Web UI; one-shot виклик лишається тимчасовим до збереження.
- Практичне використання: складання нотаток контролера для неоднозначних збігів, отримання попередніх справ, пов'язаних із країною чи програмою, пакетна перевірка списків контрагентів / суден / банків, узагальнення умов регламентів простою мовою.
- Покупці комплаєнсу в 2026 році цілком слушно скептично ставляться до AI. Шар агентів платформи здобуває довіру, оскільки він обґрунтований, цитований і записаний — а не через твердження «довіряйте нам, наш AI — інший».
Агентний інтелект
AI Assistant
Пошук у консолі
MCP Server
Зовнішні агенти
Проіндексовані дані
Докази з посиланнями
Screening Cases
Та сама справа · той самий аудит
Довіра до AI походить від атрибутованих доказів інструментів і явного збереження, а не від непідтвердженої обіцянки автоматизації.
12 · Статус і заклик до дії
Готово для реальних комплаєнс-процесів.
Повноцінний робочий простір для команд, яким потрібен обґрунтований скринінг без корпоративної складності.
- Доступ. Запросіть робочий простір і почніть із першого процесу.
- Доступно сьогодні. Без шестизначного мінімуму, шестимісячної інтеграції та вимоги мати комплаєнс-відділ. Для команд будь-якого розміру.
- Що входить у доступ. Web UI і MCP у межах тарифу, скринінг за джерелами, заходи TARIC, Screening Cases та аудиторський слід. REST API — опція платних self-service тарифів і частина Enterprise.
- Як ми все налаштуємо. Розкажіть про процес, очікуваний обсяг і користувачів. Ми налаштуємо відповідний тариф, ліміти та доступ до інтеграцій.
- Захисна прозорість. Не пов'язано з Європейською Комісією. Не замінює офіційні джерела чи рішення компетентних органів.
- Зв'язок. Напишіть на sales@norvext.com
Зв'язок
sales@norvext.com
Розкажіть про конкретний сценарій і очікуваний обсяг — ми налаштуємо робочий простір для торговельних і регуляторних перевірок, перевірки санкцій, підготовки доказів або інтеграції API/MCP.
Додаток A · Репрезентативні джерела за шарами
150+ офіційних джерел. Релевантне покриття для кожного процесу.
Нижче названо опорне джерело кожного шару перевірки — основа, а не повний перелік. Повний, завжди актуальний каталог доступний онлайн.
| Шар |
Опорні джерела |
| Санкції · 49 | OFAC (SDN + Non-SDN) · EU Consolidated (FSF) + EUR-Lex Russia/Belarus (Reg. 269/2014, 833/2014, 765/2006) · UN Security Council · UK · Switzerland (SECO) · Canada (SEMA) · Australia (DFAT) · Japan (MOF) · Ukraine (NSDC) · Baltic + Poland national lists |
| Експортний контроль · 33 | EU Dual-Use (Reg. 2021/821) + Common Military List · US Consolidated Screening List + Commerce Control List · EU/G7 Common High-Priority Items · Japan METI End-User List · UAE control list |
| PEP / EDD · 28 | European Parliament · UK, German, Spanish and Danish parliaments · France HATVP · Baltic + Central-Asia legislatures · role-scoped UK public bodies |
| Відсторонення (МБР) · 5 | World Bank · EBRD · Asian Development Bank · Inter-American Development Bank · African Development Bank |
| Морський ризик · 8 | Paris, Tokyo, Black Sea, Abuja, Riyadh, Caribbean and Viña del Mar Port State Control (bans + detentions) |
| Наглядові списки попереджень · 8 | Baltic supervisory, gaming and consumer-protection warning lists |
| Реєстри компаній · 8 | Latvia and Estonia enterprise registers · Poland KRS · Hong Kong Companies Registry · Japan NTA · GLEIF LEI |
| Митниця + правова довідка · 12 | EU TARIC · ECICS chemicals · EUR-Lex · EU Sanctions Map · EU AML high-risk third countries · EU VIES |
Покриття з першого погляду
151 активне джерело у десяти категоріях. У таблиці названо опорне джерело кожного шару; у повному каталозі кожне джерело зазначене з органом, юрисдикцією та ознакою свіжості.
Відкрити повний каталог:
compliance-mcp.com/sources
Як джерела залишаються актуальними
Частота оновлення відповідає графіку кожного офіційного видавця, а свіжість фіксується. Процес обирає релевантний профіль; кожен кандидат зазначає список, програму й правове посилання.
Додаток B · Алгоритми пошуку close-match
Шість сигналів доказів. Точні ідентифікатори залишаються вирішальними.
Exact-token та ідентифікатор перевіряються першими; fuzzy- й фонетичні кандидати запускаються за потреби або разом у deep search. Оцінка імені ранжує кандидатів.
| # | Алгоритм | Технологія | Що він ловить |
|---|
| 1 | Trigram-схожість | pg_trgm · GIN | Перекриття трибуквенних фрагментів. Іванов Іван ↔ Іванов Іван Петрович. |
| 2 | Token-sort trigram | pg_trgm · відсортовані токени | Знімає ефект порядку слів. Sirius Trading ↔ Trading House Sirius. |
| 3 | Double Metaphone | fuzzystrmatch | Фонетична еквівалентність. Іванов ↔ Ivanoff, Михайло ↔ Michael. Кирилиця спочатку транслітерується. |
| 4 | Levenshtein | levenshtein_less_equal() | Мінімум правок для коротких рядків і друкарських помилок. Ivanov ↔ Ivanoff. |
| 5 | Exact token | таблиця токенів · btree | Детермінований lookup за аліасами/транслітераціями. Сбербанк ↔ збережений аліас. |
| 6 | Match ідентифікатора | нормалізовані ідентифікатори | Реєстрація, IMO, BIC/SWIFT, паспорт, національний і податковий ID. |
Модель оцінки
Оцінка імені: найсильніший застосовний сигнал схожості або покриття токенів, потім захист за типом сутності.
Підтвердження: точна дата народження +10, збіг країни суб'єкта +5.
Малоінформативні запити: частий одиночний токен компанії обмежено 70; fuzzy одного токена/особи та рідкісне входження компанії — 84.
Лише фонетика: непідтверджені багатослівні, корпоративні та суднові кандидати обмежені 60.
Точний ідентифікатор: повертає 100 і показується окремо від доказу лише за іменем.
Повна методика:
compliance-mcp.com/library/learning/entity-screening-algorithms
Рівні оцінки · поріг за замовчуванням 75
Порог кандидата за замовчуванням — 75. Оцінка імені, навіть 100, ранжує кандидата й не підтверджує особу; точний ідентифікатор є окремим підтверджувальним сигналом.
Додаток C · VoP — Verification of Payee
Мітки close-match у стилі EPC для кандидатів скринінгу.
Регламент (ЄС) 2024/886 вимагає, щоб PSP платника пропонував перевірку IBAN/імені з PSP одержувача. Ця функція класифікує відстань імені до санкційних кандидатів і не є банківською перевіркою власника рахунку.
| Результат | Сценарій | Логіка | Приклад |
|---|
| MTCH | exact | рівне після нормалізації | Jan Kowalski = Jan Kowalski |
| CMTC | s2a_levenshtein | edit-distance ≤ 2 | Muller ~ Mueller |
| CMTC | s2b_transposition | одна суміжна перестановка | Smtih ~ Smith |
| CMTC | s2c_initial | ініціал + прізвище | J Smith ~ John Smith · лише фізична особа |
| CMTC | s2d_phonetic | фонетична еквівалентність | Kowalsky ~ Kowalski · лише фізична особа |
| NMTC | no_match | жоден сценарій не спрацював | ABC Trading vs XYZ Logistics |
| NOAP | not applicable | немає вхідного імені або імені кандидата | порівняння неможливе |
Регульований VoP і класифікатор скринінгу
Регульований VoP звіряє ім'я або ID від платника з даними власника рахунку, які зберігає PSP одержувача.
Класифікатор скринінгу застосовує MTCH / CMTC / NMTC / NOAP до кандидатів платформи. Він допомагає перевірці, але сам не виконує PSP VoP.
Джерела: Регламент (ЄС) 2024/886, ст. 5c; EPC VOP Scheme Rulebook v1.1 (чинний із 20 вересня 2026).
Повна методика:
compliance-mcp.com/library/learning/entity-screening-algorithms
VoP-нормалізація · 6 кроків
1. Малі літери · 2. Скандинавське розширення (ø→oe, ä→ae, ß→ss) · 3. Unaccent (é→e) · 4. Видалити правові суфікси (SIA, LLC, GmbH) · 5. Whitelist [a-z0-9\s] · 6. Стиснути пробіли
