Комплаєнс
Запуск платформи влітку 2026 · Тестовий доступ відкритий уже сьогодні
Compliance Platform
Перевірка торгівлі та санкцій із доказовою базою.
CN / TARIC
Санкційні списки
Screening Cases
Платежі ISO 20022
API + MCP
Не пов'язано з Європейською Комісією. Не замінює офіційні джерела чи рішення компетентних органів.
v6 · 20 травня 2026
02 · Виклик
Складність не в скринінгу. Складність — у захисті результату.
Комплаєнс-робота зазнає невдачі, коли відповідь неможливо відтворити, задокументувати джерелом чи пояснити аудитору.
- Санкційні списки, заходи TARIC та реєстри суб'єктів розподілені між десятками регуляторів. Ручне їх об'єднання витрачає час контролерів.
- Більшість інструментів дають відповідь так/ні. Аудитори хочуть посилання на джерело, відмітку часу та обґрунтування контролера.
- Псевдоніми, транслітерації та локальні варіанти імен перетворюють чисте «без збігів» сьогодні на пропущений збіг завтра.
- Перевірки TARIC, скринінги суб'єктів та верифікації суден накопичуються в таблицях і листах — а не як одна перевіряна справа.
- Коли інструмент позначає збіг, контролери не завжди бачать чому. Це робить рішення складним для захисту під час аудиту.
- Інженери, які створюють внутрішню автоматизацію, зазвичай змушені парсити той самий інтерфейс, яким користуються комплаєнс-команди.
Прогалина захисту аудиту
1
Багато офіційних джерел
Санкційні списки, заходи TARIC, реєстри суб'єктів
2
Ручне об'єднання
Таблиці, скріншоти, листи електронної пошти
?
Рішення в аудиті
«Де докази?»
Захищаємий результат тримає разом дані, джерело, параметри, контролера та час.
03 · Цільова аудиторія + позиціонування
Комплаєнс-інструменти створювалися для банків першого рівня. Комплаєнс-робота відбувається всюди в інших місцях.
Той самий регуляторний тиск тепер торкається команд без окремого комплаєнс-відділу.
- Комплаєнс-інструменти виникли після 11 вересня й сформувалися всередині банків та консалтингових фірм Big Four. Вони досі коштують і налаштовуються відповідно.
- Той самий регуляторний тиск, значно ширше поле: транснаціональні корпорації, регіональні та МСП-банки, логістичні компанії, митні брокери, регіональні аеропорти, поліцейські оперативні групи, нотаріуси та комунальні служби.
- У цих командах немає окремого комплаєнс-відділу. Робота лягає на операційний, юридичний відділи або керівництво — поряд з основною роботою.
- Їм потрібні такі ж захищаємі скринінгові докази, як і банку першого рівня — але вони не можуть виправдати шестизначну ліцензію чи шестимісячну інтеграцію.
- Їм потрібен доступ там, де вони працюють: вебінструмент для юриста, API для інженера, MCP-сервер для AI-агента.
- Довгий хвіст комплаєнсу на порядки більший за ядро банків / Big Four — той самий регуляторний ризик, значно менше інструментів, жодного серйозного гравця, який їх обслуговує.
Довгий хвіст комплаєнсу
Ядро банків / Big Four
Транснаціональні корпорації
Регіональні та МСП-банки
Логістичні компанії
Митні брокери
Регіональні аеропорти
Поліцейські оперативні групи
Нотаріуси
Комунальні служби
Той самий тиск. Значно менше інструментів. Жодного серйозного гравця для всієї ширини.
04 · Основні функції
Захищаємий комплаєнс — без окремого комплаєнс-відділу.
Платформа перетворює щоденні скринінгові операції на доказово готові рішення.
- Отримайте одну прив'язану до джерела відповідь на запитання «Чи можна це відправити, обробити чи провести?» — охоплюючи заходи TARIC/CN, санкції та реєстри суб'єктів, а не три окремі інструменти.
- Виробляйте захищаємі докази як побічний продукт роботи. Кожна перевірка автоматично отримує відмітку часу, прив'язку до джерела та прив'язку до контролера — окрема підготовка до аудиту не потрібна.
- Виявляйте те, що ручна перевірка пропускає. Збіги псевдонімів, варіанти транслітерацій та локальні шаблони імен виявляють кандидатів, яких сканування так/ні пропустило б.
- Групуйте пов'язані перевірки в одну справу. Запити TARIC, скринінги суб'єктів та верифікації суден подорожують разом — один перевіряний артефакт на одне рішення.
- Використовуйте там, де відбувається робота. Юрист у вебзастосунку, інженер через API, AI-агент через MCP — ті ж дані, ті ж джерела, той самий слід аудиту.
- Починайте в тестовому робочому просторі вже сьогодні. Без шестизначного мінімуму, без шестимісячної інтеграції, без вимоги окремого комплаєнс-відділу.
Стан робочого простору, активовані сервіси, готовність та останні перевірки в одному узгодженому вигляді.
05 · Канали
Три інтерфейси, одне джерело істини.
Контролер, інженер та AI-агент під капотом використовують ті самі дані.
- Web UI — повний інтерфейс скринінгу для прямого використання контролером. Ті самі дані, ті самі докази, той самий слід аудиту, що й в інших каналах.
- API — REST-ендпоїнти для кожного робочого потоку, доступного в інтерфейсі. Вбудовуйте комплаєнс у KYC-онбординг, перевірку постачальників, моніторинг транзакцій або будь-яку внутрішню автоматизацію.
- MCP Server — надає скринінгові робочі потоки як нативні інструменти для AI-агентів. Будь-який сумісний з MCP клієнт (Claude, ChatGPT Agents, власний) може викликати перевірки й отримувати докази з посиланнями на джерело.
- Один слід аудиту. Перевірка, виконана через API, потрапляє в той самий реєстр Screening Cases, що й перевірка через інтерфейс. Контролер бачить обидві. Аудитор бачить обидві.
- Одне джерело істини. Усі три канали запитують ті самі санкційні дані, ті самі заходи TARIC, ту саму логіку близьких збігів. Жодних розбіжностей між «API-версією» та «версією інтерфейсу».
- API та MCP — першорядні, не лише для enterprise. Доступні в тестовому робочому просторі вже сьогодні, так само як і Web UI.
Екосистема
Web UI
Інтерфейс контролера
REST API
Внутрішня автоматизація
MCP Server
Інструменти для агентів
Уніфіковані дані
Санкції · TARIC · близькі збіги
Один слід аудиту
Реєстр Screening Cases
Жодних розбіжностей між інтерфейсом і API — ті самі джерела, та сама логіка близьких збігів, той самий артефакт справи.
06 · Перевірки кодів TARIC / CN
Один запит, усі застосовні заходи, з посиланням на джерело.
Перевірки з урахуванням дати зберігають дані, які створили результат.
- Введіть те, що потрібно для митної декларації: код CN/TARIC, країну призначення, відповідну дату. Опціональні уточнення — тип заходу, додаткові коди.
- Отримайте два рівні в одному звіті: повідомлення про санкційний додаток за необхідності, плюс повну картину заходів TARIC — тарифні зупинки, контроль імпорту/експорту, заборони, правила за походженням — кожен з посиланням на регламент, діапазоном дат та вбудованими визначеннями умов.
- Кожен захід посилається на своє джерело — відповідний регламент ЄС або запис бази даних TARIC. Звіт показує контролерам (та аудиторам) обґрунтування, а не лише вирок.
- Запити з урахуванням дати. Відтворіть перевірку для будь-якої попередньої дати. Захищайте попереднє рішення за регуляторним станом, що діяв на той час.
- Збережені параметри подорожують з результатами. Дані, які створили перевірку, зберігаються поряд з результатом. Жодних прогалин на кшталт «що я шукав?» у сліді аудиту.
- Та сама перевірка, кожен канал — веб, API, MCP. Ідентичний результат, ідентичні джерела.
За датою
Параметри збережено
Однаково через API/MCP
07 · Скринінг санкцій
Сімнадцять списків. Кожна варіація. Один перевіряний результат.
Офіційні джерела санкцій можна переглядати, і вони пов'язані з первинним записом.
- Що сканується. Імена — особи, компанії, судна, повітряні судна — разом з псевдонімами, локальними варіантами імен, транслітераціями, датами народження та ідентифікаторами (паспорт, IMO, BIC, реєстраційні номери).
- Проти чого сканується. Сімнадцять офіційних списків, що підтримуються автоматично (таблиця поруч).
- Логіка зіставлення виявляє те, що пропускає ручна перевірка. Псевдоніми, транслітерації, фонетичні еквіваленти та локальні шаблони імен оцінюються поряд з точними збігами. Порогове значення налаштовується для кожної перевірки.
- Кожен збіг приходить зі своїм джерелом. Кожен збіг посилається на первинний запис списку — назва списку, програма, посилання на регламент, підстави включення. Контролер бачить докази, а не лише вирок.
- Також санкції на рівні товарів. Той самий робочий потік перевіряє коди CN/TARIC щодо додатків з обмеженням товарів (наприклад, Регламент ЄС № 833/2014, ДОДАТОК XXIII), щоб перевірка суб'єкта і перевірка товарів потрапляли в одну справу.
- Безпосередньо перегляньте структурований набір даних. Reference Library показує таблицю включених суб'єктів — фільтруйте за програмою, типом, країною чи джерелом, коли перевіряєте первинний запис поза активним скринінгом.
Охоплення даних · 17 джерел
| Офіційне джерело | Орган |
|---|
| OFAC SDN | США |
| OFAC Non-SDN | США |
| EU FSF | Європейський Союз |
| EU Russia (Reg. 833/2014) | Європейський Союз |
| EU Belarus (Reg. 765/2006) | Європейський Союз |
| EU Russia asset-freeze (Reg. 269/2014) | Європейський Союз |
| UN SC Consolidated | ООН |
| UK Sanctions List | Велика Британія |
| CH SECO | Швейцарія |
| JP MOF | Японія |
| AU DFAT | Австралія |
| CA SEMA | Канада |
| EE national sanctions | Естонія |
| LV FID | Латвія |
| LV FID frozen-assets | Латвія |
| PL MSWiA | Польща |
| UA NSDC | Україна |
Списки оновлюються автоматично. Санкції на рівні товарів одночасно перевіряються щодо TARIC-анексів.
08 · Скринінг платежів ISO 20022
Pre-flight скринінг для pain.001 та pacs.008.
Повідомлення-обізнаний wrapper навколо того ж движка. Сирий payload збережений як аудиторський доказ.
- Full Payload Mandate. Увесь сирий XML pain.001 / pacs.008 зберігається як незмінний бінарний артефакт. Попередньо відфільтровані поля заборонені — вони порушують ланцюг доказів.
- XSD-валідація щодо офіційних схем iso20022.org. Структурні збої викликають Integrity Error та утримують справу в "Needs Review", поки контролер не зафіксує обґрунтування.
- Модель 6 вузлів учасників. Sender Bank, Ordering Institution, Ordering Customer, Intermediary Banks, Beneficiary Bank, Beneficiary — кожен перевірений щодо тих самих чотирнадцяти джерел. Деталі на наступному слайді.
- Водоспад розв'язання BIC у сутність. Tier 1 локальний кеш GLEIF · Tier 2 API в реальному часі · Tier 3 заземлений LLM веб-пошук — URL джерела зафіксовано як незмінний доказ.
- Unified Verdict + Persona Separation. Одне високоризикове влучання на будь-якому вузлі позначає транзакцію. Вузли осіб отримують логіку Особи; корпоративні — логіку Корпорації.
- Conflict Detection. Якщо BIC-розв'язане ім'я відрізняється від XML, справа підіймає Data Integrity Warning — захист від тактик маскування імені.
Обіцянка бренду · case-as-audit
Складна частина — не скринінг. Складна частина — захист результату.
Кожен перехід стану має часову мітку та тег контролера. Історичні знімки зберігають стан списків на момент скринінгу — захист від майбутніх аргументів "data drift".
Для корпорацій, регіональних банків, нотаріусів — для будь-кого, чий вихідний переказ піддає їх відповідальності OFAC, ЄС або Великої Британії — справа є аудитом.
09 · Модель 6 вузлів учасників
Кожен pain.001 розкладається на шість перевірюваних учасників.
Кожен вузол перевіряється незалежно. Високоризикове влучання на будь-якому позначає всю транзакцію.
| # | Роль | Маппінг 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) | Особа | Юридична особа, що ініціює платіж. Логіка Особи (DOB, паспорт), повний збіг імені. |
| 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) | Особа | Кінцева сторона-одержувач — юридична або фізична особа. Логіка Особи або Корпорації за типом. |
Чому шість, не два
Більшість інструментів на стороні корпорації перевіряють Beneficiary (вузол 6) та зупиняються. Реальна експозиція у вузлах 4 та 5 — проміжні кореспонденти та банк бенефіціара. Чистий бенефіціар при санкційному кореспонденті — не захищувана транзакція.
10 · Screening Cases — диференціатор
Кожна перевірка потрапляє у справу. Кожна справа — це окремий аудит.
Артефакт рішення, а не лише сирий результат скринінгу.
- Одиниця комплаєнс-роботи — це справа, а не перевірка. Одна транзакція, клієнт чи відправлення породжує багато перевірок — але аудитор бачить одне рішення. Справа — це артефакт цього рішення.
- Кожна перевірка приєднується до справи. Запити TARIC, санкційні скринінги проти осіб/компаній/суден/повітряних суден, банківські верифікації та скринінги платежів ISO 20022 (повідомлення pain.001 / pacs.008) — усі нитки одного рішення подорожують разом.
- Стани життєвого циклу керують робочим потоком. Відкрита → Потребує перевірки → Закрита → Архівована. Кожен перехід фіксується з відміткою часу, контролером і станом даних на момент.
- Збіги з'являються у справі. Червоні маркери «збіг», записи з посиланнями на джерело, нотатки контролера — видимі в контексті справи, не приховані в окремому інструменті сповіщень.
- Диференціатор від Refinitiv, Dow Jones, Sayari: вони дають вам результати скринінгу. Compliance Platform дає вам справу, до якої ці результати належать — артефакт, готовий до аудиту, а не сирий результат.
- Відтворюється пізніше. Знову відкрийте будь-яку справу, щоб побачити точні параметри, збіги, джерела та обґрунтування контролера в тому стані, в якому вони були тоді. Аудит — це не окреме завдання — справа і є аудитом.
ISO 20022
Скринінг платежів, готовий до справи. Вставте pain.001 / pacs.008 XML — ланцюг (до 6 вузлів) перевіряється щодо чотирнадцяти списків (див. слайд 9), докази поряд зі справою.
Аудит — це не окреме завдання — справа і є аудитом.
11 · AI Assistant + MCP
Той самий слід доказів. Тепер доступний агенту.
Шар агентів обґрунтований, цитований і записаний — не паралельний AI-силос.
- AI Assistant — це інтерфейс пошуку, а не інструмент генерації. Запитайте, які заходи TARIC застосовуються, які списки містять ім'я, які справи стосувалися контрагента — асистент запитує проіндексовані дані й повертає цитовані результати.
- MCP надає ті ж робочі потоки зовнішнім агентам. Будь-який сумісний з MCP клієнт — Claude, ChatGPT Agents, власний — може викликати скринінг як нативний інструмент і отримувати докази з посиланнями на джерело.
- Обидва інтерфейси обґрунтовані. Жодних галюцинованих регламентів, жодних вигаданих санкційних програм, жодних правдоподібних, але хибних цитат. Агент повертає те, що платформа індексує — нічого більше.
- Перевірки, керовані агентом, потрапляють у той самий реєстр Screening Cases. Веб, API, MCP — та сама справа, той самий слід аудиту. Жодного «AI-силосу», в якому перевірки уникають аудиту.
- Практичне використання: складання нотаток контролера для неоднозначних збігів, отримання попередніх справ, пов'язаних із країною чи програмою, пакетна перевірка списків контрагентів / суден / банків, узагальнення умов регламентів простою мовою.
- Покупці комплаєнсу в 2026 році цілком слушно скептично ставляться до AI. Шар агентів платформи здобуває довіру, оскільки він обґрунтований, цитований і записаний — а не через твердження «довіряйте нам, наш AI — інший».
Агентний інтелект
AI Assistant
Пошук у консолі
MCP Server
Зовнішні агенти
Проіндексовані дані
Без галюцинацій
Screening Cases
Та сама справа · той самий аудит
Довіру до AI здобувають цитатами та записом аудиту — а не туманною обіцянкою «з AI-двигуном».
12 · Статус і заклик до дії
Перед запуском. Тестовий доступ відкритий уже сьогодні.
Партнерство зворотного зв'язку для команд, яким потрібен захищаємий скринінг без корпоративних накладних витрат.
- Стадія. Запуск виробничої платформи запланований на літо 2026 року.
- Тестовий доступ доступний уже сьогодні. Без шестизначного мінімуму, без шестимісячної інтеграції, без вимоги окремого комплаєнс-відділу. Доступний командам будь-якого розміру.
- Що включає тестовий доступ. Повний Web UI, API та MCP Server; актуальні санкційні списки; поточні заходи TARIC; Screening Cases та слід аудиту.
- Що ми попросимо натомість. Справжні запитання щодо робочого потоку, відгуки про прогалини в покритті, випадки використання інтеграції. Без зобов'язання платячого клієнта.
- Захисна прозорість. Не пов'язано з Європейською Комісією. Не замінює офіційні джерела чи рішення компетентних органів.
- Зв'язок. Напишіть на sales@norvext.com
Зв'язок
sales@norvext.com
Поділіться конкретним випадком використання та очікуваним обсягом — ми налаштовуємо пілотний доступ навколо торговельних та регуляторних перевірок, перегляду санкцій, підготовки доказів або інтеграції API/MCP.
Додаток A · Підтримувані санкційні списки
Сімнадцять офіційних джерел. Один прогін скринінгу.
Кожен список нижче — офіційне урядове або наднаціональне джерело: автоматично синхронізується, пов'язане з первинним записом і перевіряється разом.
| Офіційне джерело |
Орган |
Юрисдикція |
| UN SC Consolidated List | UN SC | Організація Об'єднаних Націй |
| EU Consolidated Financial Sanctions (FSF) | Європейська Комісія / DG FISMA | Європейський Союз |
| EU Russia asset-freeze — Reg. 269/2014 | EUR-Lex | Європейський Союз |
| EU Russia — Reg. 833/2014 | EUR-Lex | Європейський Союз |
| EU Belarus — Reg. 765/2006 | EUR-Lex | Європейський Союз |
| OFAC SDN List | Мінфін США / OFAC | США |
| OFAC Consolidated Non-SDN List | Мінфін США / OFAC | США |
| UK Sanctions List | UK FCDO | Велика Британія |
| Swiss SECO Sanctions List | SECO | Швейцарія |
| Canada Consolidated (SEMA) | Global Affairs Canada | Канада |
| Australian Sanctions Consolidated List | DFAT | Австралія |
| Japan MOF economic sanctions | Міністерство фінансів Японії | Японія |
| Ukraine State Register of Sanctions | РНБО України | Україна |
| Estonian Government national sanctions | МЗС Естонії | Естонія |
| Latvia FID National Sanctions List | Латвійський FID | Латвія |
| Latvian FID frozen-assets registry | Латвійський FID | Латвія |
| Poland MSWiA national sanctions list | Польське MSWiA | Польща |
Охоплення з першого погляду
5 багатосторонніх / загальносоюзних — Рада Безпеки ООН, EU FSF та три регламенти EUR-Lex щодо Росії/Білорусі (269/2014, 833/2014, 765/2006).
8 національних — Сполучені Штати (OFAC SDN + Non-SDN), Велика Британія, Швейцарія, Канада, Австралія, Японія, Україна.
4 держав-членів ЄС — Естонія, Латвія (список FID + реєстр заморожених активів), Польща.
Як джерела залишаються актуальними
Більшість джерел синхронізуються щодня; списки на основі публікацій оновлюються при кожному офіційному оновленні. Кожне співпадіння скринінгу цитує свій список-джерело, програму та юридичне посилання — див. Додаток B щодо алгоритмів зіставлення.
Додаток B · Алгоритми пошуку close-match
Шість шляхів пошуку працюють паралельно. Перемагає найсильніший сигнал.
Імена рідко збігаються точно. Trigram, token-sort, фонетика, edit-distance, exact-token та ідентифікатор оцінюють той самий запит — оцінка відображає найсильніший шлях.
| # | Алгоритм | Технологія | Що він ловить |
|---|
| 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, податковий ID. Примушує оцінку до 100. |
Модель оцінки
raw = max(сигнал) × 100 через шість шляхів вище.
+ бонуси: DOB збігся +10, країна збіглася +5.
− safety cap: один токен fuzzy-only обмежений до 84 (review tier) — "Ivanov" наодинці ніколи не підтверджує особу.
↑ override: точне співпадіння ідентифікатора примушує 100.
Рівні оцінки · поріг за замовчуванням 75
100 Підтверджений доказ · 90–99 Hit (ручна перевірка обов'язкова) · 75–89 Review (розслідувати перед закриттям) · <75 Слабкий (не повертається за порогом за замовчуванням)
Додаток C · VoP — Verification of Payee
Класифікація close-match EPC288-23 поверх стандартного скринінгу.
Згідно з Reg. (ЄС) 2024/886 відправник повинен перевірити ім'я одержувача — не лише його банк. Наш VoP-wrapper бере тих самих санкційних кандидатів з Додатку B та класифікує співпадіння імені за правилами EPC288-23.
| Результат | Сценарій | Логіка | Приклад |
|---|
| 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 | зареєстроване ім'я недоступне | PSP одержувача не повернув ім'я |
Класичний VoP vs наш VoP
Класичний VoP питає "чи збігається ім'я одержувача з власником IBAN-рахунку?" — відповідає PSP одержувача.
Наш VoP питає "чи збігається ім'я одержувача з санкційним кандидатом?" — wrapper над стандартним скринінгом з Додатку B з класифікацією close-match EPC288-23.
VoP-нормалізація · 6 кроків
1. Малі літери · 2. Скандинавське розширення (ø→oe, ä→ae, ß→ss) · 3. Unaccent (é→e) · 4. Видалити правові суфікси (SIA, LLC, GmbH) · 5. Whitelist [a-z0-9\s] · 6. Стиснути пробіли
