Консультації з Blockchain у Мюнхені: Посібник з відповідності

Мюнхен став практичною базою для блокчейн-компаній, які працюють на німецькому та ширшому європейському ринках, проте для запуску діяльності відповідно до регуляторних вимог недостатньо обрати організаційно-правову форму й розгорнути контракт токена. Перш ніж звертатися до банків, інституційних партнерів чи регуляторів, проєкти мають узгодити регуляторну класифікацію, заходи протидії відмиванню коштів, інформаційну безпеку, інженерію приватності та операційне управління.

Завдання дотримання вимог має ще й транскордонний вимір. На мюнхенську компанію можуть поширюватися очікування німецьких наглядових органів, Регламент Європейського Союзу про ринки криптоактивів (MiCA), GDPR, а якщо вона просуває свої продукти у Сполучених Штатах — ще й регулювання SEC щодо активів на основі блокчейну. У цій статті пояснюється, як ці обов’язки пов’язані між собою і як засновникам вибудувати комплаєнс-програму, яка витримає перевірку.

Що охоплює блокчейн-консалтинг у Мюнхені?

Блокчейн-консалтинг у Мюнхені поєднує регуляторну класифікацію, заходи контролю у сфері AML, інформаційну безпеку, інженерію приватності та планування впровадження для компаній, які використовують технологію розподіленого реєстру. Мета полягає не просто в підготовці юридичних документів, а у створенні операційної моделі, здатної витримати належну перевірку з боку піднаглядних BaFin партнерів, банків, аудиторів, інвесторів і корпоративних клієнтів.

На практиці серйозний консалтинговий проєкт зазвичай охоплює п’ять напрямів роботи:

1. Класифікація бізнесу та токена
2. Чи є актив утилітарним токеном, стейблкоїном, токеном електронних грошей, токеном, прив’язаним до активів, цінним папером або іншим регульованим інструментом?
3. Чи надає компанія послуги зі зберігання, обміну, брокерського обслуговування, переказу, управління портфелем або емісії?

4. Чи підпадає діяльність під MiCA, німецьке законодавство про цінні папери, регулювання платіжних послуг або одразу кілька режимів?

5. AML і заходи протидії фінансовим злочинам

6. Ідентифікація та верифікація клієнтів
7. Встановлення бенефіціарних власників
8. Скринінг щодо санкцій і політично значущих осіб
9. Моніторинг транзакцій
10. Ескалація підозрілої активності

11. Впровадження «правила подорожі» (Travel Rule), де воно застосовується

12. Безпека та стійкість

13. Заходи контролю з керування ключами
14. Безпека смартконтрактів та інфраструктури
15. Реагування на інциденти
16. Ризики постачальників
17. Безперервність діяльності

18. Збереження доказів і ведення журналів аудиту

19. Приватність і управління даними

20. Картування даних за GDPR
21. Правова підстава обробки
22. Мінімізація даних
23. Строки зберігання
24. Права суб’єктів даних

25. Розподіл ролей контролера та процесора

26. Управління та впровадження

27. Політики та процедури
28. Відповідальність за комплаєнс
29. Звітування керівництву
30. Контроль аутсорсингу
31. Навчання персоналу
32. Постійне тестування

Для мюнхенських компаній регуляторний аналіз має також враховувати структуру німецької юридичної особи. GmbH, філія, фонд або іноземна дочірня компанія породжують різні питання щодо відповідальності керівництва, оподаткування, реальної присутності, банківського обслуговування та взаємодії з наглядовими органами. Правильна структура залежить від продукту та клієнтів, а не від типового шаблону «криптокомпанії».

Наш досвід аудиту та консультування Web3-компаній у Soken показує: найпоширеніша помилка на ранньому етапі — ставитися до комплаєнсу як до пакета документів. Політика, яка не відповідає фактичній архітектурі гаманців, шляху клієнта чи можливостям моніторингу транзакцій, не витримає належної перевірки з боку інвесторів, банків або регуляторів.

Проєкт, що базується в Мюнхені, зазвичай має підготувати до запуску такі базові документи:

• Меморандум про регуляторний периметр і класифікацію токена
• Схема продукту та руху коштів
• Оцінка ризиків AML
• Реєстр даних за GDPR і карта обробки
• Реєстр ризиків інформаційної безпеки
• План реагування на інциденти
• Реєстр аутсорсингу та постачальників
• Записи про затвердження радою або керівництвом
• Умови для клієнтів і повідомлення про приватність
• План доказів, який показує, як тестуватиметься кожен захід контролю

Для ширшого вивчення регулювання та ринку зручною відправною точкою є Soken Hub, де можна ознайомитися з пов’язаними матеріалами про комплаєнс і безпеку у Web3.

Як регулювання SEC і MiCA впливають на блокчейн-бізнес у Мюнхені?

Регулювання SEC щодо блокчейн-проєктів залишається актуальним для мюнхенських компаній щоразу, коли вони пропонують, продають, рекламують цифрові активи учасникам зі Сполучених Штатів або сприяють їхньому доступу до таких активів. MiCA визначає значну частину європейської нормативної бази, але не усуває ризиків за законодавством США про цінні папери, і жоден із цих режимів не можна оцінювати, зважаючи лише на місце реєстрації компанії.

Аналіз SEC зазвичай зосереджується на тому, чи містить операція інвестиційний контракт за тестом Хоуї (Howey). Значення можуть мати, зокрема, такі обставини:

• Чи вкладають покупці гроші або іншу форму цінності
• Чи спрямовуються кошти у спільне підприємство
• Чи очікують покупці прибутку
• Чи залежить цей прибуток значною мірою від управлінських або підприємницьких зусиль

Назва «утилітарний токен» не є визначальною. На аналіз можуть вплинути маркетингові формулювання, механіка розподілу токенів, обіцянки зворотного викупу, механізми стейкінгу, права на участь в управлінні та роль команди засновників. Судовий процес 2023 року за участю Ripple показав, що правова кваліфікація цифрового активу може відрізнятися для інституційних продажів, біржових операцій та інших каналів розповсюдження.

Мирова угода 2024 року за участю Terraform Labs та її колишнього генерального директора, сума якої, за повідомленнями, становила приблизно $4,47 млрд, також показала фінансові наслідки інкримінованих неправдивих заяв і порушень законодавства про цінні папери, пов’язаних із великою блокчейн-екосистемою. Тому мюнхенській компанії, яка орієнтується на користувачів зі США, слід документувати свої географічні обмеження, заходи контролю маркетингу, запевнення інвесторів і канали розповсюдження.

MiCA запроваджує більш структуровану європейську нормативну базу. Від дат початку її застосування у 2024 році відповідні обов’язки охоплюють вимоги щодо:

• Білих книг (white paper) криптоактивів
• Запобігання ринковим зловживанням
• Авторизації постачальників послуг, пов’язаних із криптоактивами
• Пруденційних запобіжників
• Управління та розгляду скарг
• Захисту активів клієнтів
• Обов’язків щодо резервів і розкриття інформації для певних категорій токенів

Наведене нижче порівняння ілюструє, чому єдиної глобальної комплаєнс-політики рідко буває достатньо.

Питання	Європейський Союз / Німеччина	Ризики у Сполучених Штатах
Основний регуляторний підхід	MiCA, німецьке право, правила AML, регулювання платежів і цінних паперів	Федеральні правила щодо цінних паперів, біржових товарів, переказу коштів і правила на рівні штатів
Класифікація токенів	Ключове значення мають категорія активу та вид послуг	Ключове значення мають економічна суть і аналіз за тестом Хоуї
Стейблкоїни	До токенів, прив’язаних до активів, і токенів електронних грошей можуть застосовуватися додаткові вимоги	Класифікація може стосуватися цінних паперів, біржових товарів, платежів або ризику правозастосування
Постачальники послуг	Можуть застосовуватися вимоги щодо авторизації та організаційні вимоги	Реєстрація, ліцензування або ризик правозастосування залежать від виду діяльності
Маркетинг	Заходи контролю щодо білої книги, розкриття інформації, ринкових зловживань і ділової поведінки	Заходи контролю щодо протидії шахрайству, розкриття інформації, залучення клієнтів і юрисдикції
Приватність	GDPR застосовується до обробки персональних даних	Обов’язки щодо приватності у США різняться залежно від штату та сектору
Практичний захід контролю	Підтримувати периметр авторизації в ЄС і докази	Обмежувати або структурувати доступ зі США, якщо його не оцінено окремо

Мюнхенській компанії слід вести матрицю юрисдикцій, у якій зазначено кожен продукт, місцезнаходження клієнтів, маркетинговий канал, вид послуги та регуляторне припущення. Методологія Soken розглядає цю матрицю як живий контрольний документ, а не як одноразовий юридичний меморандум, оскільки зміни продукту можуть змінити периметр.

Компаніям, які працюють у Німеччині та інших юрисдикціях, упорядкувати регуляторні дослідження за юрисдикціями допоможе Crypto Map. Вона має доповнювати, а не замінювати юридичний аналіз конкретного продукту.

Які заходи контролю AML слід впровадити блокчейн-проєкту в Мюнхені?

Заходи контролю AML для блокчейну мають поєднувати традиційну належну перевірку клієнтів зі специфічним для блокчейну аналізом гаманців, транзакцій і ризикових зв’язків. Програма, що відповідає вимогам, має пояснювати, хто є клієнтом, хто зрештою контролює кошти, що означає характер транзакцій і як компанія реагує, коли ончейн- та офчейн-докази суперечать одне одному.

Нормативна база ЄС у сфері AML та обов’язки в Німеччині за Законом про протидію відмиванню коштів (Geldwäschegesetz) вимагають ризик-орієнтованого підходу. Це означає, що заходи контролю мають бути пропорційними клієнтській базі, географії, продукту, швидкості транзакцій, типу активів, моделі зберігання та зв’язкам із сервісами підвищеного ризику.

Переконлива операційна модель AML має включати:

1. Онбординг клієнтів
2. Верифікація особи з використанням надійних джерел
3. Перевірка бенефіціарних власників для компаній
4. Верифікація директорів та уповноважених представників

5. Оцінювання ризику на основі географії, діяльності та профілю клієнта

6. Оцінка гаманців

7. Скринінг адрес для депозитів і виведень
8. Виявлення санкційних ризиків
9. Виявлення зв’язків із міксерами, програмами-вимагачами, даркнет-ринками, шахрайськими схемами та викраденими коштами

10. Ескалація, коли неможливо встановити власника гаманця

11. Моніторинг транзакцій

12. Правила щодо швидкості, дроблення операцій, швидкого переміщення коштів і незвичних контрагентів
13. Сповіщення про невідповідність профілю клієнта
14. Моніторинг мостів, децентралізованих бірж і механізмів підвищення приватності

15. Ведення справ із задокументованими результатами розслідувань

16. Звітування та ескалація

17. Записи рішень щодо підозрілої активності
18. Внутрішня ескалація до відповідального за фінансовий моніторинг (MLRO)
19. Звітування компетентному органу, якщо цього вимагає закон

20. Збереження доказів і комунікацій

21. «Правило подорожі» та інформація про перекази

22. Збирання та передавання необхідної інформації про ініціатора й отримувача
23. Процедури для переказів за участю некастодіальних гаманців
24. Правила відхилення або перевірки в разі неповної інформації

Блокчейн-аналітика цінна, але вона не є заміною для управління. Інструмент скринінгу може давати хибнопозитивні спрацювання, пропускати нові типології або неправильно присвоювати ризик, коли активи рухаються через мости та смартконтракти. Кожна модель сповіщень потребує задокументованих порогів, контролю якості, періодичного налаштування та перевірки людиною.

Безпекове спостереження: найсильніший захід контролю AML — це не найагресивніше правило блокування гаманців. Це задокументований процес ухвалення рішень, який пов’язує ризик клієнта, докази щодо транзакцій, повноваження з ескалації та періодичне тестування моделі. Надмірне автоматичне блокування може створювати операційні ризики та ризики несправедливого ставлення і водночас не виявляти складних схем відмивання.

Крадіжка з Ronin Bridge 2022 року на суму приблизно $625 млн показала, як швидко скомпрометовані облікові дані та слабкі операційні заходи контролю можуть створити системний ризик. Хоча інцидент був передусім провалом у безпеці, він також ілюструє, чому AML, зберігання, управління доступом і реагування на інциденти не можуть працювати як ізольовані підрозділи.

В аудиторській практиці Soken ми очікуємо, що проєкт продемонструє не лише наявність підписки на аналітичний сервіс, а й те, як аналітик розслідує сповіщення, як керівництво погоджує винятки та як зберігаються докази для аудитора чи регулятора.

Мюнхенському проєкту слід задокументувати щонайменше:

• Обов’язки призначених відповідальних за комплаєнс і MLRO
• Методологію оцінювання ризику клієнтів
• Постачальника скринінгу гаманців і резервну процедуру
• Пороги сповіщень і нормативні строки їх розгляду
• Маршрути ескалації
• Строки зберігання записів
• Вимоги до навчання персоналу
• Графік незалежного тестування

Оскільки заходи контролю AML залежать від архітектури продукту, проєкту слід провести перевірку комплаєнс-архітектури до остаточного затвердження потоків гаманців або онбордингу клієнтів. Юридичні та корпоративні послуги Soken можуть допомогти з класифікацією токенів, аналізом ліцензування VASP і за MiCA, створенням компанії та відповідною юридичною документацією для операційної моделі з базою в Мюнхені.

Як проєктувати заходи контролю ISO 27001 та інформаційної безпеки для блокчейну?

Заходи контролю ISO 27001 для блокчейну слід впроваджувати як систему управління інформаційною безпекою, адаптовану до розподілених реєстрів, гаманців, смартконтрактів, хмарної інфраструктури та чутливих даних клієнтів. Сертифікація корисна, але справжня мета — дієва система управління ризиками, яка захищає конфіденційність, цілісність, доступність і підзвітність.

ISO/IEC 27001:2022 задає рамку системи управління, а ISO/IEC 27002:2022 містить настанови щодо заходів контролю. Блокчейн-компаніям варто також зважати на NIST Cybersecurity Framework 2.0, опублікований у 2024 році, особливо в частині управління, ідентифікації, захисту, виявлення, реагування та відновлення.

Середовище контролю має охоплювати:

• Керування ключами: генерування, зберігання, ротація, резервне копіювання, відновлення та знищення
• Привілейований доступ: розподіл ролей, багатостороннє погодження, доступ за принципом just-in-time і надійна автентифікація
• Управління смартконтрактами: незалежна перевірка, контроль розгортання, повноваження на призупинення, обмеження оновлень та аварійні процедури
• Безпека інфраструктури: конфігурація хмари, зміцнення захисту вузлів, керування секретами, журналювання та усунення вразливостей
• Управління змінами: взаємна перевірка, тестові середовища, погодження релізів і планування відкату
• Безпека постачальників: постачальники послуг зберігання, RPC-провайдери, аналітичні платформи, хмарні постачальники та підрядники з розробки
• Управління інцидентами: класифікація за серйозністю, комунікації, поводження з доказами та рішення щодо повідомлення регуляторів
• Стійкість: резервні копії, географічне резервування, цільові показники відновлення та кризові навчання

Ключова відмінність полягає в тому, що незмінність блокчейну не гарантує цілісності застосунку. Незмінна транзакція може достеменно зафіксувати шкідливу або помилкову дію. Тому програма безпеки має захищати інтерфейси, системи підписання, процеси управління та операційні облікові записи, які визначають, що потрапляє до реєстру.

Експлойт Euler Finance у березні 2023 року спричинив збитки приблизно на $197 млн після того, як зловмисник скористався вадами в логіці пожертв і ліквідацій протоколу. Інцидент підтвердив повторюваний висновок аудитів: фінансову логіку, привілейовані функції та аварійне реагування потрібно тестувати разом, а не перевіряти як окремі технічні компоненти.

Для інформаційної безпеки блокчейн-проєктів практичний набір доказів включає:

Сфера контролю	Докази, яких має очікувати перевіряльник
Контроль доступу	Матриця ролей, перевірки доступу, записи MFA, журнали привілейованих сесій
Безпека ключів	Архітектура зберігання, політика кворуму, тест відновлення, погодження підписів
Безпечна розробка	Моделі загроз, перевірки коду, сканування залежностей, тести на проникнення
Моніторинг	Каталог сповіщень, налаштування зберігання журналів, тікети щодо інцидентів
Стійкість	Тести резервних копій, цільовий час відновлення, результати штабних навчань
Треті сторони	Записи належної перевірки, договори, підтвердження безпеки
Управління	Реєстр ризиків, аналіз із боку керівництва, відстеження коригувальних дій

У роботі Soken з аудиту смартконтрактів і тестування на проникнення зазвичай досліджується взаємодія між вразливостями на рівні коду та операційними заходами контролю. Технічно бездоганний контракт усе одно може виявитися вразливим через незахищений ключ розгортання, слабке адміністрування оракула або процес оновлення без незалежного погодження.

Як GDPR застосовується до блокчейн-компаній у Мюнхені?

Дотримання GDPR у блокчейні вимагає від проєкту мінімізувати персональні дані в блокчейні, розподілити обов’язки контролера та процесора і спроєктувати заходи захисту приватності до розгортання. Адреси публічних ключів не є автоматично анонімними: якщо їх пов’язано з особою, яку можна ідентифікувати, через біржу, клієнтський акаунт, досьє KYC або аналітичний запис, вони можуть становити персональні дані.

Центральний принцип проєктування — тримати інформацію, що прямо ідентифікує особу, поза ланцюгом, де це можливо. Краща архітектура часто зберігає в блокчейні криптографічне зобов’язання, посилання або індикатор статусу, а самі персональні дані залишає в контрольованій офчейн-системі. Навіть тоді проєкт має оцінити, чи можна й надалі пов’язати хеші, ідентифікатори, метадані та історії транзакцій із конкретними особами.

До відповідних положень GDPR належать:

• Стаття 5: обмеження мети, мінімізація даних, точність, обмеження зберігання, цілісність і конфіденційність
• Стаття 6: правова підстава обробки
• Стаття 25: захист даних за призначенням і за замовчуванням
• Стаття 32: належні технічні та організаційні заходи безпеки
• Стаття 35: оцінки впливу на захист даних для обробки з високим ризиком
• Статті 44–49: міжнародна передача даних

Позірний конфлікт між незмінністю та такими правами, як право на видалення, слід розв’язувати через архітектуру та управління, а не обіцянкою, що дані можна просто видалити з публічного ланцюга. Серед можливих технік — офчейн-зберігання, шифрування з контрольованим знищенням ключів, реєстри з обмеженим доступом, вибіркове розкриття та сувора мінімізація метаданих.

Перед розгортанням мюнхенській компанії слід відповісти на такі запитання:

1. Які саме дані записуються до реєстру?
2. Чи можуть ці дані прямо або опосередковано ідентифікувати фізичну особу?
3. Хто визначає мету та засоби обробки?
4. Яка юридична особа відповідає на запити про доступ, виправлення, заперечення та видалення?
5. Де розташовані вузли, бази даних, резервні копії та аналітичні системи?
6. Що відбувається, якщо суб’єкт даних реалізує право, яке суперечить постійному зберіганню даних у реєстрі?
7. Чи проведено оцінку впливу на захист даних?

Інженерія приватності має також охоплювати інструменти підтримки клієнтів, постачальників KYC, блокчейн-аналітику, телеметрію, файли cookie та системи для працівників. Ончейн-архітектура може оберігати приватність, тоді як навколишній вебзастосунок непомітно збирає надмірну персональну інформацію.

Порада фахівця: зіставте карту даних за GDPR зі схемою потоку транзакцій рядок за рядком. У реальних перевірках найбільші прогалини в приватності часто виявляються в журналах RPC, аналітичних панелях, зверненнях до підтримки та базах даних, що пов’язують гаманці з особами, а не в самому смартконтракті.

Як блокчейн-компанії в Мюнхені побудувати готову до аудиту комплаєнс-програму?

Мюнхенська блокчейн-компанія стає готовою до аудиту, коли перетворює юридичні обов’язки на конкретно названі заходи контролю, призначає відповідальних власників, тестує ці заходи та зберігає докази, які підтверджують їхню дію з плином часу. Самих лише політик недостатньо: банки, інвестори, аудитори та регулятори дедалі частіше перевіряють, чи відповідають управлінські рішення розгорнутому продукту.

Практична послідовність впровадження така:

1. Визначте периметр продукту
2. Опишіть функції токена, потоки зберігання, типи користувачів, юрисдикції та джерела доходу.

3. Визначте види діяльності, які можуть спричинити обов’язки за MiCA, німецьким законодавством у сфері AML, платежів або цінних паперів.

4. Створіть реєстр регуляторних рішень

5. Зафіксуйте правові припущення, виключені юрисдикції, дати погодження та тригери змін.

6. Переглядайте реєстр, коли змінюються утилітарні функції токена, стейкінг, зберігання або маркетинг.

7. Спроєктуйте систему заходів контролю

8. Пов’яжіть кожен обов’язок із політикою, власником процесу, системним заходом контролю, методом тестування та місцем зберігання доказів.

9. Передбачте винятки та компенсаційні заходи контролю.

10. Закладіть AML і приватність ще на етапі проєктування

11. Інтегруйте KYC, скринінг гаманців, моніторинг транзакцій, зберігання даних і процедури розгляду запитів щодо прав у життєвий цикл продукту.

12. Запровадьте управління безпекою

13. Ведіть реєстр ризиків, узгоджений з ISO 27001.

14. Проводьте моделювання загроз, тестування на проникнення, перевірки доступу, тести аварійного відновлення та навчання з реагування на інциденти.

15. Тестуйте до запуску

16. Залучайте незалежні перевірки юридичної класифікації, смартконтрактів, інфраструктури, операцій AML і приватності.

17. Відстежуйте виявлені недоліки до їх закриття, а не вважайте звіт завершенням процесу.

18. Забезпечте безперервне підтвердження відповідності

19. Заплануйте щоквартальні перегляди ризиків, регулярну повторну атестацію доступу, повторне оцінювання постачальників, оновлення політик і тестування заходів контролю.
20. Зберігайте докази у сховищі, захищеному від втручання та з контрольованим доступом.

Корисний реєстр заходів контролю може містити такі поля:

Поле	Приклад
Вимога	Стаття 32 GDPR
Ризик	Несанкціонований доступ до записів KYC
Власник заходу контролю	Керівник з інформаційної безпеки
Захід контролю	MFA, шифрування, щоквартальна перевірка доступу
Періодичність	Безперервний моніторинг і щоквартальний перегляд
Докази	Звіт про доступ, записи сповіщень, підпис про затвердження перевірки
Метод тестування	Внутрішня перевірка та незалежна оцінка
Усунення недоліків	Власник, строк, серйозність, докази закриття

Для технічної перевірки проєкти можуть скористатися Security X-Ray від Soken як попереднім оцінюванням, щоб виявити очевидні слабкі місця в архітектурі, контролі доступу, документації та операційній готовності. Його слід розглядати як первинну діагностику, а не як заміну офіційного аудиту, тесту на проникнення, юридичного висновку чи процесу сертифікації.

Методологія Soken полягає в тому, щоб поєднати три рівні: чого вимагає закон, що робить архітектура і що доводять докази. Цей зв’язок особливо важливий для мюнхенських компаній, які прагнуть інституційних партнерств, адже сильна презентація переконує менше, ніж відтворюване середовище контролю.

Компанії слід також підтримувати чітке дерево рішень на випадок інцидентів. Наприклад, скомпрометований ключ підпису може вимагати негайного призупинення транзакцій, збереження криміналістичних доказів, комунікації з клієнтами, перевірки з погляду AML, повідомлень за договорами та оцінки обов’язків зі звітування за GDPR або перед регулятором. Ці дії слід відпрацювати до того, як станеться інцидент.

Найефективніший наступний крок — задокументована оцінка прогалин, що охоплює модель токена, шлях клієнта, архітектуру гаманців, заходи контролю AML, потоки персональних даних і заходи безпеки, узгоджені з ISO 27001. Результати слід упорядкувати за пріоритетністю з огляду на правовий ризик, фінансовий вплив, можливість експлуатації та залежності впровадження.

Мюнхен відкриває добрий доступ до європейських ринків технологій, фінансів і корпоративних клієнтів, але ця можливість супроводжується вимогливим комплаєнс-периметром. Блокчейн-бізнес, здатний витримати перевірку, має поєднати аналіз регулювання SEC, де це доречно, вимоги MiCA та німецького права, заходи контролю транзакцій у сфері AML, управління за ISO 27001, інженерію інформаційної безпеки та архітектуру, що враховує GDPR.

Конкретний наступний крок — підготувати одну інтегровану матрицю регуляторних вимог і заходів контролю до запуску або значних змін продукту, а потім підтвердити її через юридичну перевірку, тестування безпеки та операційні докази. Фахівці Soken з юридичних питань, комплаєнсу та технологій можуть підтримати таку оцінку на шляху проєкту від концепції до контрольованої діяльності.